大陆机房 NAT VPS 重装后 SSH 超时排查实录：问题竟在服务商端口映射

1. 问题现象

一台位于大陆机房的 NAT VPS（内网 10.x.x.x 段，无公网直连 IP，公网靠服务商「高端口 → 内网 22」映射访问），在重装系统（CentOS 7.2 → NixOS 26.05）后，外部 SSH 从「一直可用」变成Operation timed out。

重装前，通过同一公网端口 SSH 连接一直正常，期间还做过多次操作；重装后，同一公网端口直接超时，VPS 内部服务从未变过。

2. 排查过程

先按常规思路排查了 VPS 内防火墙、sshd、网络，一轮下来全部正常：

• sshd 监听：监听0.0.0.0:22，服务正常。
• 防火墙：防火墙服务Unit not loaded，根本没启用。
• 网络：IP 配置正常，内网连通。

服务侧完全正常，问题出在外部链路。最后发现是服务商 NAT 端口映射失效——重装前后，同一公网端口的映射状态悄悄变了。

2.1 VPS 内三连确认服务侧正常

在 VPS 内部执行以下命令，确认服务侧一切正常：

systemctl status sshd # active (running)，监听 0.0.0.0:22 + :: 22 systemctl stop nixos-firewall # Failed: Unit not loaded —— 防火墙根本没启用 ip addr # eth0 10.x.x.x/16 正常，网关正常

2.2 外部端口矩阵区分问题归属

换端口前，用外部机器对同一公网 IP 的不同端口做连通性测试，并结合服务商控制台权威对照表与 VPS 内实际监听端口交叉验证：

# ① 控制台权威对照表（服务商「查看管理帐号」页，实测）： # 远程桌面连接端口 X（公网）/ 在云主机系统内使用 33xx ← 模板端口！ # 公网端口 X 映射到系统内 33xx（购买时 Windows 模板的 SSH 端口），而不是 22。 ② VPS 内 ss 验证实际监听端口（重装后的 NixOS）： ss -tln | grep ':22 ' → LISTEN 0.0.0.0:22 （sshd 在 22） ss -tln | grep ':33xx ' → 无输出 （33xx 上无任何服务） ③ 外部端口矩阵（换端口前）： nc 公网IP X（原 SSH 映射）→ Operation timed out （映射指向空端口 33xx） nc 公网IP VNC端口 → Connection succeeded （同一 IP 其他端口通 → IP 链路正常）

对照结论：映射指向 33xx（无服务）→ 外部打过去被丢弃 →Operation timed out。IP 链路通、VPS 服务通，唯独 SSH 映射端口不通——问题锁定在服务商 NAT 映射，不是 VPS。

对照组实锤「模板决定内部端口」：同一服务商的原生 Linux 模板（Ubuntu 20.4）订单，控制台写明「公网端口 243xx / 系统内使用 22」——Linux 模板内部端口就是 22，直接对上；而 Windows 模板是 33xx，重装成 Linux 后必然错位。

修复：控制台「端口管理」删旧加新——类型 TCP → 公网端口（限固定范围）→ 内网端口填22→ 添加 → 立即「运行」，无需重启。换端口后nc 公网IP 新端口succeeded，SSH 登录成功（hostname/nixos-version 确认连对机器）。

2.3 服务商控制台操作

在服务商控制台「端口管理」页实测，操作步骤如下：

1. 页面显示「已开放端口列表」：状态/类型/公网端口/内网端口/端口用处。
2. 「添加端口映射」：类型 TCP → 公网端口（限固定范围内取值）→ 内网端口填 22 → 端口用处备注 → 添加。
3. 新规则立即「运行」，无需重启机器。
4. 换端口后立即验证：nc 公网IP 新端口succeeded → SSH 登录成功，hostname/nixos-version确认连的就是目标机器。

2.4 端口限制实测

产品限 5 个端口；公网端口限一段固定范围；内网端口 < 65000；共享 IP 产品默认关闭非白名单端口（远程管理/FTP/Web 除外），特殊端口需申请且管理员有权删除。

补充：失效的旧映射仍占端口名额（限 5 个），记得在控制台删掉，避免占满配额。

3. 谬误溯源

3.1 「外部 SSH 连不上 = VPS 防火墙/sshd 问题」——不成立

VPS 内实测：sshd 监听0.0.0.0:22、防火墙服务Unit not loaded（根本没启用）、网络 IP 正常——服务侧完全正常，问题出在外部链路。

3.2 「端口映射配好了就一直有效」——部分不成立

映射条目可能一直在（没被删除），但它的「内部端口」是购买模板时代的旧端口。重装系统（尤其换发行版，如 Windows→NixOS）后系统实际端口变了，映射仍指向旧端口——端口错位。误判成「映射失效」会让人去怀疑映射条目，实际要对照的是「映射内部端口 vs 系统实际监听端口」。

3.3 「重装机器不用动服务商配置」——不成立

重装前记录映射表 + 控制台「查看管理帐号」页注明的「系统内端口」，重装后对照，能省掉一整轮排查。正确姿势：重装前记录映射表，重装后先测端口再深入排查——先测同 IP 的其他端口，能一分钟区分「端口错位」还是「服务问题」。

3.4 「超时 = 被防火墙丢包」——不一定是

Operation timed out常见归因是 VPS 防火墙 DROP，但本次防火墙根本没开，真正的 DROP 点在服务商 NAT 侧（映射指向的模板端口无服务，公网进不来）。

3.5 「服务商映射的内部端口 = 系统当前 SSH 端口」——不成立（核心纠错）

内部端口由模板决定：Windows 模板的 SSH 内部端口不是 22（本次环境为 33xx 段），Linux 模板才是 22。控制台「查看管理帐号」页会写明「公网端口 X（系统内使用 Y）」——这是排查时第一优先读的权威对照表。

4. 环境信息

本次排查涉及的服务商控制台与产品约束如下：

• 控制台入口：服务商控制台「端口管理」页（订单号 + 公网 IP + 内网 IP）。
• 映射规则格式：「公网端口 → 内网端口」。
• 端口数量限制：产品限 5 个端口。
• 公网端口范围：限一段固定范围（如 1xxxx-1xxxx）。
• 内网端口限制：65000 以下。
• 共享 IP 产品默认策略：默认关闭除远程管理/FTP/Web 外的端口，特殊端口需申请。

5. 经验总结

这次排障最大的教训是：重装系统后，不要默认服务商侧的 NAT 映射还保持原样。重装前先记录好映射表，重装后第一时间用同 IP 的其他端口做连通性测试，就能快速区分是「映射问题」还是「服务问题」，避免在 VPS 内部白白浪费排查时间。

6. 落地结论：NAT VPS 端口映射运维 checklist（含模板端口坑）

1. 重装前：记录映射表 + 控制台「查看管理帐号」页注明的「系统内端口」（模板端口，如 Windows 模板 = 33xx 段、Linux 模板 = 22）——这是后续对照的基线。
2. 重装后先测端口，再查 VPS：外部不通时先做端口矩阵（同 IP 其他端口通 = 映射/端口问题；全不通 = 链路问题），然后读控制台「系统内端口」对照 VPS 实际监听——「映射指向模板旧端口、系统实际监听 22」的端口错位是重装后超时的最高频原因。
3. VPS 内确认监听端口：ss -tln看 sshd 实际监听（本次 22；映射指向的 33xx 无服务）。
4. 错位修复：控制台「端口管理」加新映射，内网端口填系统实际端口（22），立即生效无需重启；失效旧映射删除释放名额（限 5 端口）。
5. 对照组：原生 Linux 模板订单的映射内部端口就是 22（直接对上）——内部端口由模板决定，重装不更新，这是平台机制不是 bug。

6.1 判定速查

6.2 三类读者速查

人类开发者

先ss -tln | grep -E ':22 |:33xx '看系统实际监听，再翻控制台「查看管理帐号」页的「系统内端口」对照；两者不一致就是端口错位，加新映射指向实际端口即可。

对话式 AI

一句话问法：NAT VPS 重装成 Linux 后外部 SSH 超时，先查什么？回答要点：① 测同 IP 其他端口区分链路 vs 映射；②读控制台「系统内端口」对照ss -tln——映射内部端口由购买模板决定（Windows 模板≠22），重装不更新，端口错位是高频原因；③ 加新映射指向系统实际端口（22），立即生效。

代码 Agent

可复制命令（脱敏）：

# 1. VPS 内看实际监听端口（sshd 在 22？模板端口 33xx 有没有服务？） ss -tln | grep -E ':22 |:33xx ' 2. 外部端口矩阵：通 / 超时 / 拒绝 for p in 端口A 端口B; do printf "%s: " "$p"; nc -vz -w 5 公网IP "$p" 2>&1 | tail -1 done 3. 修复后验证 nc -vz -w 5 公网IP 新端口 && ssh -p 新端口 root@公网IP

注意：先读控制台「系统内端口」文字（权威），别默认映射指向 22。