开区前别只在服务器上看到进程运行，就认定玩家一定能连上。使用这份开服前网络连通性与端口可达性自检清单，按“服务监听—主机规则—公网路径—玩家端验证”逐层检查，能更快定位是程序配置、端口协议还是网络边界出了问题。
先确认服务实际监听什么
先查清服务使用的端口、协议和绑定地址。端口号要以应用配置或产品文档为准；同一端口的 TCP 和 UDP 是不同通道，不能相互替代。也不要因为网页能打开，就推断登录、语音或游戏数据通道都已放通。
- 在服务配置中记录需要开放的端口、TCP 或 UDP 类型，以及是否还有独立的登录、查询或管理端口。
- 确认服务绑定的是公网接口、内网接口还是仅限本机的 127.0.0.1。若只监听本机地址，外部连接通常无法到达。
- 在 Linux 上可用 ss -lntup 查看 TCP、UDP 监听情况；Windows 可查看应用配置和本机防火墙规则，并确认进程确实已启动。
- 从服务器本机连接一次只能验证本机服务状态，不能代替玩家侧测试。
沿网络路径逐层排查
主机防火墙与公网入口
检查操作系统防火墙是否允许对应协议和端口，并核对云平台安全规则、机房边界防火墙或家用路由器的端口转发。若服务器位于 NAT 后方，还要确认公网地址映射到了正确的内网主机；双层路由或运营商级 NAT 可能使单靠本地转发仍无法从公网访问。
规则应尽量限定目的端口、协议和必要来源范围。不要为了排错长期关闭整台主机防火墙；若临时调整，记录原规则并在验证后恢复。端口开放也不等于服务安全，管理界面应与面向玩家的服务分开限制。
DNS、路由与地址族
核对玩家使用的域名是否解析到当前公网地址。检查 DNS 解析时，同时留意 A 记录（IPv4）与 AAAA 记录（IPv6）：若域名发布了不可用的 IPv6 地址，部分客户端可能优先尝试 IPv6，表现为连接超时，而 IPv4 测试正常。路由追踪可帮助观察路径在哪一段停止，但中间节点不回应探测包并不必然代表业务流量被阻断。
从真正的外网环境测试
- 准备服务器公网 IP 或玩家实际使用的域名，并从不在同一局域网的网络发起测试；手机关闭 Wi-Fi、使用蜂窝网络是一种简单选择。
- 测试 TCP 端口时，Windows PowerShell 可运行 Test-NetConnection 主机名 -Port 端口号；Linux 可用 nc -vz 主机名 端口号。将示例文字替换为实际地址和端口。
- 若测试失败，依次复核 DNS、服务监听、主机防火墙、云侧或边界规则、路由器映射。每改一处就重新测试，并记录时间、来源网络和结果。
- UDP 端口不能仅凭普通 TCP 连通性测试判断。UDP 往往没有握手或明确回包，应使用实际客户端功能、服务端日志或具备对应协议的探测方式共同验证。
- 最后用真实客户端完成登录或进入服务的关键流程，并观察服务器日志是否收到请求、是否返回错误。
同一局域网测试公网地址可能受路由器是否支持 NAT 回环影响，因此结果不一定代表外网玩家体验。ICMP 的 ping 被屏蔽，也不能单独证明业务端口不可达；应以目标协议的外网测试和实际客户端表现为准。
开区前记录结果，便于快速回退
把端口、协议、监听地址、DNS 解析结果、放行规则和外网测试结果记在一张表里，并注明测试网络及时间。若服务有多个入口，逐项核验，不要只测主端口。发现问题时先判断请求是否到达服务器：服务端没有日志，优先查解析与网络规则；已有请求但应用拒绝，则继续查服务配置、认证或版本兼容。
这份开服前网络连通性与端口可达性自检清单的核心，是让每个检查都能对应到一段明确路径，并保留可复查的结果。全部关键端口通过外网和真实客户端验证后，再对外开放入口。
常见问题
端口扫描显示开放，为什么客户端仍连不上？
扫描结果只反映特定来源、时间和探测方式。应用协议、登录流程、DNS 地址或客户端版本仍可能有问题，应继续检查服务日志并实测完整流程。
ping 不通是否说明服务器离线？
不一定。ICMP 可能被防火墙或网络策略过滤；改用目标 TCP 测试，或通过实际客户端验证。
UDP 端口怎样确认可达？
优先用对应客户端发起实际请求，再结合服务端日志或协议专用探测。单纯的 TCP 端口测试无法验证 UDP。
必须从多种网络测试吗？
建议至少从一条与服务器不同的外网连接测试；若玩家分布区域或运营商差异明显，再增加不同网络来源，以发现特定路径问题。