记一次 ColoCrossing 网络故障排查：SSH 连不上，最后发现是默认网关差一个数

最近 ColoCrossing 的特价VPS又上架了，赶快入手了一台3C4G的，换掉 RackNerd 快到期的2C2.5G的机器，两台机器价格基本一样。

按理说，这类 VPS 开通后应该是拿到 IP、连接 SSH、部署网站，一套流程十分钟内完成。但这次开机后的情况有些反常：分配到 IP 后，无论是本地 Ping 还是 SSH 连接，全部失败。

通过几个全球 Ping 检测工具测试，结果也一样——100% 丢包。

既然是美国机房，全球都无法访问，那基本可以排除地域网络因素，问题大概率出在 VPS 本身或者机房网络配置上。

从 VNC 开始排查

因为 SSH 无法连接，只能先进入后台提供的 VNC 控制台。好消息是系统已经正常启动，能够看到登录界面，也能正常进入 Shell。

第一步自然是确认 VPS 是否拿到了公网 IP。

原本准备执行：

ip addr

结果系统直接返回：

ip: command not found

看来镜像做得相当精简，连 iproute2 都没有安装。于是换了个更简单的办法：

hostname -I

系统返回了正确的公网 IP，这说明至少有两件事是正常的：

• 网卡已经启动
• IP 地址已经正确分配

问题显然不在这里。

VPS 自己也上不了网

接下来测试外部连通性。

最简单的方法是直接 Ping 公共 DNS：

ping -c 4 8.8.8.8

结果：

100% packet loss

这很关键。因为它说明问题不仅仅是“别人访问不了我”，而是“这台 VPS 自己也访问不了外网”。如果 VPS 连 8.8.8.8 都访问不了，那么 DNS、防火墙甚至 SSH 配置都已经不是重点了。

为了看看数据包究竟卡在哪里，追踪一下：

tracepath 8.8.8.8

输出基本如下：

1: [LOCALHOST]
1: no reply
2: no reply
3: no reply
...

连第一跳都没有任何响应。

查看路由表

这时候重点开始转向网络配置。

查看当前路由：

ip route

得到：

default via 204.44.74.194 dev eth0 onlink
204.44.74.192/26 dev eth0 proto kernel scope link src 204.44.74.199

系统配置的默认网关是：

204.44.74.194

表面看起来没有什么异常，但问题是，它不转发任何流量，继续检查 ARP 邻居表：

ip neigh

结果显示：

204.44.74.194 dev eth0 lladdr xx:xx:xx:xx:xx:xx REACHABLE

说明：

• 网关地址存在
• ARP 可以正常解析
• 二层通信没有问题

但奇怪的是，所有流量仍然无法离开这台 VPS。

一个意外的发现

由于整个网段是：

204.44.74.192/26

按照经验，很多 VPS 网络会把该网段的第一个可用地址作为网关。

于是尝试将默认网关从 .194 改成 .193：

ip route del default via 204.44.74.194

ip route add default via 204.44.74.193 dev eth0 onlink

修改完成后再次测试：

ping 8.8.8.8

结果立刻恢复正常。

随后：

curl ifconfig.me

成功返回公网 IP，本地电脑也能够正常 Ping 通 VPS，并通过 SSH 登录，问题至此基本定位完成。

真正的问题在哪里

从排查结果来看，VPS 本身并没有故障，系统正常、网卡正常、IP 正常、SSH 服务也正常。真正的问题出现在默认网关配置上，系统自动配置的 204.44.74.194 无法正常转发流量。而 204.44.74.193 才是能够正常工作的网关。

更有意思的是，即使重装系统，这个问题依然会再次出现。因为每次重装后，自动化部署脚本都会重新写入 .194 作为默认网关。这意味着问题并不在 VPS 内部，而是在机房的自动化网络配置模板中。

后续处理

虽然可以通过修改网络配置文件永久修复当前系统，但只要重装 VPS，错误配置仍然会被重新生成。

最终我向机房提交了工单，并附上测试结果，希望他们检查对应节点或网络模板的默认网关配置。

一点经验总结

这次故障有意思的地方在于，它几乎满足了“服务器看起来正常”的所有条件：

• 有公网 IP
• 网卡正常
• SSH 服务正常
• 路由表存在

但实际上完全无法联网。如果以后遇到类似情况，我觉得最有价值的几个检查步骤是：

1. 先确认 VPS 自己能否访问外网；
2. 使用 tracepath 或 traceroute 判断数据包卡在哪一跳；
3. 检查默认路由和网关配置；
4. 查看 ARP 邻居表，确认二层网络是否正常；
5. 不要过早怀疑 SSH、防火墙或 DNS。

很多时候，问题比想象中更底层。

接下来把我的oddbbo先迁移过来。