超级简历WonderCV老规矩，先说我当时为什么折腾这个。我在雨云开了一台NAT模式的小VPS，装好MCSM面板后，把Minecraft服务端一跑，给朋友发连接地址。一开始发的是 103.xx.xx.xx:20001 这种带端口的长串，结果总有人复制漏了数字，有人以为IP后面那串数字是版本号，还有人每次我重启换端口就要重新问一遍。后来我花了点时间把域名和SRV记录配好，玩家在服务器地址栏只需要填 play.example.com 这样一个纯域名，其他什么都不用管，直接进服。这篇内容就是把这条"雨云NAT + MCSM + 域名SRV"的无端口登录链路完整讲清楚。
这篇东西适合谁看？在雨云或类似NAT机型上开了Minecraft服，想给玩家一个更稳定、更优雅的入口，同时又不太懂DNS和SRV细节的朋友。我会从最底层的原理开始，一步一步给到配置思路，后面还附了我实际踩过的坑，尽量让你一口气配完就能用。
1. NAT小主机开MC服，先弄明白这几个东西各管哪一段
1.1 NAT模式：共享公网IP与端口映射
很多人第一次用NAT机，以为跟普通VPS一样，结果进系统发现 ip addr 看到的是一堆内网地址，瞬间就懵了。NAT模式说白了就是：宿主机占着一个公网IP，上面挂了几台甚至几十台小虚拟机，每台虚拟机只分一个内网IP，宿主机再把公网IP上的一堆端口分别转发到内网对应的端口。
打个比方，这就是一栋楼只有一个大门口，每户有不同的门牌号，外人到了楼门口之后按门牌号喊一声，里面才有人应。对于Minecraft服务器来说，这种模式最大的影响是：玩家连接入口永远是“一个公网IP + 一个特定端口”，而不是“独立公网IP + 默认25565端口”。这也是为什么后边需要SRV记录来把端口藏起来，不然你发给玩家的地址永远是又长又难记的 IP:端口。
NAT主机的好处也很直白：便宜、部署快、资源够用。对于一个三五好友联机的小服务器，或者几十人的小型社区服来说，延迟和带宽往往比独立IP更重要。只要能把端口映射这条链路搞清楚，体验完全可以做得很好。
1.2 MCSM面板在整条链路里的真实位置
MCSM全称MCSManager，是跑在虚拟机上的一套Minecraft服务器管理面板。它的作用是帮你把Minecraft服务端实例管起来：在Web界面里点击创建Java版服务端、基岩版服务端，改配置文件，看控制台日志，设置计划任务重启。你可以把它理解成一个针对Minecraft的“运维平台”。
这里必须强调一个容易混淆的点：MCSM面板跟NAT端口映射没有直接关系，它们是两个不同层级的东西。
- 雨云控制台负责：给虚拟机分配内网IP、配置公网端口转发规则。
- MCSM负责：在虚拟机内部把Minecraft服务实例跑起来、管理起来。
- 真正给玩家进游戏听的端口，是Minecraft服务实例监听的端口。
很多朋友把MCSM面板的登录地址当成了游戏地址发给玩家，然后一脸懵地问“怎么连不上”。面板地址一般是 公网IP:面板管理端口，游戏地址则是 公网IP:游戏端口，同一个IP，但端口用途完全不同，一个是网页服务，一个是游戏流量。
1.3 SRV与“无端口登录”到底是什么关系
SRV记录是DNS域名系统里的一种记录类型，专门用来告诉客户端“某种服务的服务器主机名和端口”。普通A记录能告诉浏览器“这个域名对应哪个IP”，但SRV能更进一步：以 _minecraft._tcp 开头的SRV记录，能告诉Minecraft客户端“这个域名的游戏服务跑在哪个端口、哪台主机上”。
Minecraft Java版客户端在地址栏只填域名、不填端口时，会先去查这个域名的SRV记录。如果查到了，就自动连到SRV里指定的端口；如果没查到，才尝试默认的25565端口。这就是“无端口登录”的全部秘密，原理并不复杂。
这里顺便提醒：如果玩家地址栏里手动填了端口，比如 play.example.com:20001，客户端就不会再去查SRV了，而是直接用你填的端口。所以想让SRV生效，玩家那边一定不要填端口，这是个非常常见的理解误区。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开工前，先把端口、IP、域名这三层对齐
很多教程上来就让你填SRV记录，结果填完还是连不上。我的经验是：先别急着碰DNS，先把下面这三层对应关系理清楚。
- 公网IP + 公网端口：玩家从外面连接时用的入口。
- 内网IP + 内网端口：虚拟机内部Minecraft实际监听的端口。
- 域名 + SRV记录：告诉客户端怎么找到公网入口。
这三层只要有一层对不齐，后面全是白搭。
2.1 先从控制台找到端口映射表
在雨云控制台找到NAT服务器的详情页，一般会有一张端口映射表，里面列出了类似这样的信息：
| 方向 | 公网入口 | 内网被映射地址 |
|---|---|---|
| TCP | 103.xx.xx.xx:20001 | 10.x.x.x:20001 |
| TCP | 103.xx.xx.xx:20002 | 10.x.x.x:20002 |
这张表就是整条链路的根基。你要做的第一件事，是确认想给Minecraft用的公网端口是哪个，它转发到了内网的哪个端口。不同控制台的显示字段名称可能有差别，但核心信息就是这两列。
然后再把公网IP单独记下来，后面添加A记录时要用。有些控制台在服务器详情页会明确标注“公网IP”或“会话IP”，实际指的就是宿主机上的那个共享IP，SRV记录和玩家连接最终都会落到这个IP上。
2.2 调整Minecraft实例的监听端口
“端口对齐”的关键，是让Minecraft服务监听的端口，跟控制台转发规则的内网端口保持一致。比如控制台把 公网20001 转发到 内网20001，那Minecraft的 server-port 就应该是20001。如果不一致，流量到了内网却没人接，玩家自然连不上。
在MCSM面板里，如果你还没创建实例，创建时有个高级设置或端口设置项；如果实例已经存在，就找到实例的“配置文件”或者“文件管理”，打开 server.properties，把 server-port 改成对应端口。改完以后一定要在MCSM面板里重启实例，不重启不生效，这个步骤不要省。
还有一种情况：有些控制台允许你自定义“内网被映射端口”，那你可以让Minecraft的server-port保持默认25565，控制台把公网端口转发到内网25565就行。两种思路都可行，关键是三层要对齐，看清控制台那张映射表支持哪种改法。
2.3 域名解析准备：TTL先调短
域名解析这块，建议在正式配置SRV之前，先把域名托管到一个支持SRV记录的服务商。国内常用的DNSPod、阿里云DNS，国外的Cloudflare，都是支持的。
我自己习惯先把 mc.example.com 这个A记录加上，指向雨云控制台里看到的那个公网IP，TTL改成120秒。这样做的意思是：如果后续配置出错需要改IP，120秒后玩家端就能刷新到新解析，不用干等半小时。等到所有东西都稳定了，再把TTL调回600或3600秒也不迟。
这一步很多人容易忽略：SRV记录的target指向的那个主机名，必须存在对应的A记录。也就是说，SRV记录的值里写了 mc.example.com，那 mc.example.com 本身必须能解析成公网IP，否则客户端拿到SRV记录后还是不知道要往哪走。
3. 手写SRV记录：格式拆解与各平台填法
SRV记录第一眼看着像天书，其实拆开就四个数字加一个主机名，理解了之后填起来非常快。
3.1 先学会读一条SRV记录
完整的一条SRV记录长这样：
code复制_minecraft._tcp.play.example.com. 120 IN SRV 0 5 25565 mc.example.com.
从左往右拆开：
_minecraft._tcp：服务名和协议，Minecraft Java版约定就是_minecraft._tcp，不要改。play.example.com：服务所在的域名。玩家在客户端输入play.example.com时，Minecraft客户端会去查_minecraft._tcp.play.example.com的SRV记录。120：TTL，单位秒。0 5：优先级和权重。对只有一个Minecraft入口的情况，优先级填0，权重填5，后面理解成默认值就行。25565：端口。这里要填的是玩家从外部连接的“公网端口”，不是随便填内网端口，这是最容易出错的地方。mc.example.com：目标主机名，客户端最终会去连接这台主机上的对应端口。这个主机名必须有A记录指向公网IP。
理解这条记录之后，配置就没什么神秘的了。核心就是记住：SRV名字里的 play.example.com 是玩家填的域名，SRV值里的 mc.example.com 是实际服务器解析名。
3.2 主流DNS平台的SRV填写方式
不同平台的界面差别挺大，但本质都是让你填“记录名、TTL、优先级、权重、端口、目标主机”。我拿几个常见的举例：
| DNS平台 | 记录名（Name） | 记录值（Value）填写示例 |
|---|---|---|
| DNSPod | _minecraft._tcp.play |
0 5 25565 mc.example.com |
| 阿里云解析 | _minecraft._tcp.play |
0 5 25565 mc.example.com |
| Cloudflare | Service: _minecraft, Protocol: _tcp, Name: play |
Priority: 0, Weight: 5, Port: 25565, Target: mc.example.com |
比如Cloudflare的界面，会把SRV记录拆成Service、Protocol、Name、Priority、Weight、Port、Target几个独立输入框。Service填 _minecraft，Protocol填 _tcp，Name填 play，Port填实际的公网端口，Target填目标主机名。
有些平台在添加SRV记录时会对记录值做格式校验，如果提示格式不对，先检查一下是不是多了空格，或者目标域名末尾少了个点。像 mc.example.com. 末尾带点，在不少平台上是标准写法，不带点也能通过校验，但如果带点能过、不带点不能过，就按带点的来。
3.3 验证解析是否真的生效
配置完成并等TTL时间过去之后，在电脑上执行这条命令：
bash复制# Windows、macOS、Linux都能用nslookup
nslookup -type=srv _minecraft._tcp.play.example.com
Linux或macOS上也可以用dig：
bash复制dig SRV _minecraft._tcp.play.example.com
如果看到类似这样的输出，就说明SRV解析正常：
code复制_minecraft._tcp.play.example.com. 120 IN SRV 0 5 25565 mc.example.com.
如果解析结果里没有SRV记录，先确认是不是刚加记录还没到TTL刷新时间。DNS缓存是一个很恶心的事情，你自己电脑查不到，不代表别的地方查不到，可以用 https://www.itdog.cn 这类在线DNS查询工具，选择多个地区和DNS服务器测试。要是所有节点都查不到，那就要回DNS平台检查记录名和记录值有没有填错。
4. 玩家为什么还是连不上：完整排查链路
这是整个教程里最实用的一部分。配置完成后，大概率会遇到“明明我按教程配了，别人还是连不上”的情况。别慌，按照下面这个链路一条条排查。
4.1 先看客户端一侧
玩家端最容易出问题的地方有两个。
第一，地址栏里带了端口。只要地址栏里出现冒号加数字，客户端就不会查SRV，而是直接连 域名:端口。你要让玩家严格输入 play.example.com 这种纯域名，别顺手带端口。我之前就遇到过，有朋友为了“保险”，把端口也敲上去了，结果反而连不上。
第二，DNS缓存。玩家电脑如果之前解析过这个域名，可能缓存了旧结果。可以在命令行执行 ipconfig /flushdns 清理Windows的DNS缓存，再把游戏完全退出重启。客户端进程不重启的话，JVM层面的网络连接池也可能还挂在旧地址上。
另外，客户端版本太老也会有问题。Minecraft大约在1.7.2之后的版本才对SRV记录支持得比较完整。如果你还在用很老的客户端，或者某些魔改启动器关闭了SRV解析，就会失效。这个情况现在很少见了，但如果实在查不出问题，也可以留意一下。
4.2 再看服务端一侧
服务端的问题，基本集中在“监听端口”和“控制台映射”这两个地方。
先到MCSM面板确认实例确实在运行，然后在虚拟机上执行：
bash复制ss -lntp | grep java
看看Minecraft进程到底监听了哪个端口。如果命令提示 ss 不可用，就用 netstat -tlnp。如果监听的是25565，而控制台的公网端口映射到内网20001，那数据到了内网后没人接收，玩家自然连不上。
再回到雨云控制台，确认公网端口转发规则还开着，且目标内网IP确实是这台虚拟机。有时候重装系统或迁移节点后，内网IP会变，控制台里映射的内网IP却没跟着改，这种问题隐蔽得很，很容易让人排查半天。
如果服务端开了防火墙，还要确认对应的内网端口被放行：
bash复制# 以firewalld为例
firewall-cmd --list-ports
在MCSM面板的运行日志里，如果看到类似 BindException: Address already in use 的报错，说明端口被其他进程占了，那就要换端口或者杀掉占用进程。
4.3 NAT回流带来的“假故障”
NAT模式服务器有一个特别坑的现象：你在虚拟机内部用公网IP去访问自己，大概率是不通的。这不是服务器坏了，而是很多NAT网关不处理发向自身公网IP的回环流量，业内一般叫“NAT回流问题”。
所以我强烈建议：不要在服务器上自己拼公网地址测试，更不要在服务器上用 curl 公网IP:端口 判断服务是不是正常。你测不通，不代表玩家连不上，也不代表配置有问题。
正确做法是，用手机流量（一定不要连同一个WiFi，免得又走了内网路径）打开Minecraft客户端，填 play.example.com 实测。没有手机客户端的话，找一个外网朋友帮忙连一下也行。只要外网能通，本机测试不通完全不用管，那是NAT架构下的正常表现。
5. 无端口登录玩熟之后，这几点也值得做
配置成功只是起点。实际操作中，有几个“如果一开始就知道就好了”的细节，这里一并写出来。
5.1 稳定域名 + 短TTL的组合
很多服主有个习惯：IP一变就发新公告，玩家又重新复制地址。用了SRV之后，建议养成“只发域名、不发IP”的习惯。域名指向的IP变了，你只改A记录，玩家什么都不用动。
但改完A记录后，玩家端要等TTL过去才能刷新。所以前期调试阶段，TTL保持120秒非常香，等确认稳定了再调回3600秒，减少DNS查询压力。
域名本身的选择也有讲究。别选太奇怪的后缀，玩家手动输入容易打错，.com、.top、.xyz 这类都好说。主域名尽量短一点，play.example.com 比 minecraft-server.main.example.com 这种一长串好记得多，也少接到“你那个域名是啥来着”的私聊。
5.2 端口变动时的同步思路
NAT服务器的端口一般不会频繁变，但万一遇到节点维护、迁移，控制台分配的公网端口变了，除了改控制台映射，还要记得改SRV记录里的端口字段。这一步最容易漏。
我的习惯是每次维护后按三步走：先在控制台确认公网入口，然后对照SRV记录里的端口，最后让朋友从外网测一把。三项全对，才算收工。
MCSM面板本身提供API接口，理论上可以通过脚本获取实例状态，再自动去改DNS解析。我以前也试过，但说实话，在端口不是每分钟都变的前提下，这个方案属于纯粹的折腾范畴，收益很低。真要遇到频繁迁移的环境，不如先找找为什么端口老变，治标不如治本。
5.3 Java版与基岩版的SRV支持差异
这里讲的SRV无端口登录，对Minecraft Java版效果很好。但如果是基岩版客户端，比如手机版、Win10版，对SRV记录的支持相当不稳定，很多客户端压根不查SRV记录。
所以如果你的服务器同时开了基岩版端口，建议基岩版玩家还是照常用IP加端口的方式进服，或者单独做一个文档写清楚基岩版入口，不要把Java版的“只填域名”逻辑硬套到基岩版上。
这个坑我自己踩过。当时心大，告诉所有朋友都填 play.example.com 就行，结果Java版的朋友顺利进服，手机版的朋友全卡在连接界面。排查了半天，才发现是基岩版根本不认这条SRV记录，后来老老实实把基岩版端口单独发了一份。
真要说起来，整个链路其实只有三层：控制台端口映射对应外部入口，MCSM实例把服务跑起来，SRV记录把域名和入口串起来。把这三层对整齐，再给玩家一个干净的纯域名，剩下的问题基本都是查查DNS缓存、看看防火墙这些小事了。