游戏服务器已启动，玩家却连不上？按这条顺序定位
开服后连不上，先保留客户端的完整错误提示和发生时间，再沿着实际监听、公网入口、游戏握手逐层检查。一次只改一个位置，才能知道是哪一步起作用。进程仍在、安全组中已有规则，都需要继续用实际连接验证。
下面以 Linux 上的原版 Minecraft Java、Minecraft 基岩版和帕鲁专用服务器为例。使用代理、容器、模组服或插件服时，还要检查它们各自增加的转发和兼容性要求。
先确认游戏版本和传输方式
记录客户端实际填写的地址、端口和游戏版本，再与服务端配置逐项对照。默认端口只是起点，修改过端口的机器以实际配置为准。
| 服务类型 | 常见入口 | 需要核对的配置 |
|---|---|---|
| Minecraft Java 原版 | TCP 25565 | server.properties中的 server-port |
| 基岩版 NetherNet | TCP 握手端口，另加 UDP 游戏端口 | transport=nethernet、server-port和 server-udp-ports |
| 基岩版旧 RakNet 模式 | 通常为 IPv4 UDP 19132、IPv6 UDP 19133 | 仅用于对应旧版本的检查，不能套用到 NetherNet |
| 帕鲁专用服务器 | UDP 8211 | 实际启动参数中的 -port |
基岩版从 26.50 开始默认使用 NetherNet，26.60 已将未使用 NetherNet 的提示提升为错误。遇到新版客户端连接问题，应核对支持的传输方式，不能照旧教程只检查 UDP 19132，也不要把退回旧传输方式当作通用修复。
Java 配置里的 query.port不是玩家默认连接端口。帕鲁的 PublicPort也不能代替真正的监听端口和路由映射。
在服务器里查实际监听
按正在排查的服务执行对应命令。下面的数字均为示例，修改过端口就换成实际值：
# Minecraft Java
sudo ss -lntp 'sport = :25565'
# 基岩版 NetherNet 的 TCP 握手入口
sudo ss -lntp 'sport = :19132'
# 旧 RakNet 基岩版的 IPv4 UDP 入口
sudo ss -lnup 'sport = :19132'
# 帕鲁
sudo ss -lnup 'sport = :8211'TCP 通常查看 LISTEN，UDP 常见状态为 UNCONN。只有表头、没有服务记录时，先检查初始化是否完成、端口是否改过、配置是否被实际读取、进程是否已经退出，不要先反复添加安全组规则。
NetherNet 的 UDP 端口要按 server-udp-ports检查。例如配置了 49152-49200，就观察这个范围；没有配置时，端口可能从系统临时范围中分配。连接过程中执行 sudo ss -lnup，结合进程和端口确认，不要拿旧 RakNet 的固定 UDP 入口判断所有版本。
如果只监听在 127.0.0.1，外部客户端通常无法直连。Java 的 server-ip一般留空；需要指定绑定地址时，先用 ip -br address核对本机网卡。公网地址经过 NAT 时，不能把不属于本机接口的地址直接填进去。
日志也要看当前进程的记录：Java 通常查看当前服务目录的 logs/latest.log；基岩版和帕鲁先看启动控制台，若使用系统服务运行，再看对应服务的日志。旧目录中的日志可能与当前进程无关。
核对公网入口和每一层规则
- 云侧规则：确认规则绑定到正在使用的实例，协议、端口和来源地址都正确。玩家换了 Wi-Fi 或移动网络后，原有来源 IP 限制可能已经不匹配。
- 系统防火墙：检查实际使用的 UFW、firewalld 或 nftables。UFW 显示 inactive，不代表机器里没有其他生效规则。
- NAT 映射：逐项核对公网地址、外部端口、协议、内部地址和内部端口。客户端使用外部端口，服务进程监听内部端口。
- 容器发布：检查主机端口是否真正发布到容器，以及发布的是 TCP 还是 UDP。容器内监听正常，不等于主机外部能够连接。
操作入口可参照安全组教程和NAT 端口映射教程。只修正需要的规则，保留 SSH 等管理通道，不要靠关闭整套防火墙定位普通端口问题。
NetherNet 还要检查两个阶段：TCP 握手入口是否可达，以及服务端向客户端提供的 UDP 地址、端口是否真的能从公网访问。能通过 TCP 看到服务器信息，却在进世界时失败，仍可能是 UDP 范围、NAT 映射或公布的地址不正确。
把TCP测试和游戏联机分开验证
在服务器外部的 Windows 电脑上打开 PowerShell，按实际服务选择一个端口测试。示例地址 203.0.113.10必须替换：
# Minecraft Java 的 TCP 入口示例
Test-NetConnection -ComputerName 203.0.113.10 -Port 25565
# 基岩版 NetherNet 的 TCP 握手入口示例
Test-NetConnection -ComputerName 203.0.113.10 -Port 19132TcpTestSucceeded : True只表示这次 TCP 连接建立，不代表版本、玩家认证和世界加载已经通过。这个命令不能验证帕鲁的 UDP 8211，也不能验证 NetherNet 后续的 UDP 游戏连接。
对于 NetherNet，还可以在安装了 curl 的外部 Windows 电脑上检查信令接口：
curl.exe -i --max-time 5 http://203.0.113.10:19132/v1/join使用 NAT 外部端口或反向代理时，地址要与实际入口一致。返回成功状态并包含正确的服务器名称、版本等 JSON 信息，说明信令入口能够响应；仍需用匹配版本的基岩版客户端加入世界，才能继续验证后续连接。
UDP 服务优先使用实际游戏客户端复测，同时记录准确时间，查看服务端是否收到连接。通用 UDP 探测没有响应，不能单独证明端口关闭；Ping 检查的是 ICMP，也不能替代游戏联机。
已有明确拒绝提示，就按提示继续查
| 看到的现象 | 下一步 |
|---|---|
| 客户端或服务端版本过旧 | 记录两端完整版本，核对正式版与预览版是否混用；模组服还要检查加载器、模组和版本组合。 |
| 不在白名单、未被邀请 | Java 核对实际游戏账号名；基岩版核对 Xbox Gamertag 与允许列表是否加载。不要用网站昵称代替。 |
| 认证失败、会话无效 | 重新登录对应游戏平台，检查系统时间及认证服务连通性，不关闭玩家认证来掩盖问题。 |
| 帕鲁密码不正确 | 区分玩家进服密码与管理员密码，检查实际读取的配置文件和重启后的值。 |
| 基岩版出现 Door 或 InitialConnection 错误 | 保留错误详情中的传输方式和编号，分别核对信令响应、UDP 范围、NAT 地址和同期服务端日志，不能只凭错误名称断定某一个端口关闭。 |
| 基岩版每次重启都重新提示服务器身份 | 先确认连接目标正确，再检查服务器身份是否保存。不要在未核实目标时反复信任陌生身份。 |
| 只有某一名玩家无法连接 | 优先对比客户端版本、账号状态、来源 IP 和所用网络，再决定是否需要调整服务器。 |
每完成一处修正，就用原来的客户端再次连接，观察是否能够进入世界、移动和交互。涉及版本或存档调整时，再完成一次正常保存、关闭和重新加入，确认进度仍然保留。
需要提交工单时，一次提供产品编号、发生时间及所在时区、客户端与服务端完整版本、实际连接地址和端口、完整错误提示，以及前后相邻的服务端日志。密码、令牌、服务器身份私钥等资料不要直接贴入工单。
从头部署时，可按对应教程操作：Minecraft Java 开服、Minecraft 基岩版开服、帕鲁专用服务器部署。