云上服务排障：为什么“能 Ping 通”并不代表网络正常？

很多刚接触云服务器的人都会遇到一种情况：网页打不开、SSH 连不上，或者接口一直超时，但执行 ping 时却能看到正常回复。于是很容易得出一个结论：“网络没问题，肯定是服务挂了。”

实际上，能 Ping 通只能说明网络层还有可达性，并不能证明业务端口和应用服务正常。 一次完整的访问至少会经过 DNS、路由、端口、防火墙、进程监听、应用协议等多个环节，任何一个环节异常，都可能表现为“连不上”。

最常见的第一层误区，是把 ICMP 当成业务通道。Ping 使用的是 ICMP 协议，而网站、SSH、数据库和代理通常使用 TCP 或 UDP。某些网络路径允许 ICMP 通过，却会限制、丢弃或重置 TCP 连接。也就是说，Ping 正常只能证明“机器可能还活着”，不能证明 22、80、443 等业务端口可以访问。

第二层要看端口有没有真正监听。服务器上可以执行：

ss -lntp

如果目标端口没有出现在结果里，说明服务可能没有启动，或者只监听了 127.0.0.1。例如 Nginx 只绑定本机地址时，从服务器内部可以访问，但外部用户永远无法连接。此时问题不是网络，而是服务配置。

第三层要区分“超时”和“拒绝”。如果外部连接显示 Connection refused，通常说明数据包已经到达目标主机，但对应端口没有进程监听；如果一直显示 timeout，更可能是安全组、防火墙、路由链路或上游网络把数据包丢弃了。两者的排查方向完全不同，不能一看到连不上就重启服务。

第四层才是应用本身。有些端口可以连通，但 TLS 证书过期、反向代理配置错误、后端进程卡死、数据库连接池耗尽，都会让页面最终返回 502、504 或直接断开。此时应查看应用日志，而不是继续测试 Ping。

因此，比较可靠的排障顺序应该是：

1. 域名是否解析到了正确 IP；
2. 服务器是否有公网路由；
3. 目标端口是否正在监听；
4. 云安全组和主机防火墙是否放行；
5. 从本机、同网段、境外节点分别测试；
6. 最后检查应用日志和依赖服务。

云环境排障最忌讳“凭感觉重启”。重启可能掩盖真实原因，也可能让本来可以定位的日志消失。真正高效的方法，是把网络访问拆成一层一层，用现象判断问题位于 DNS、路由、端口还是应用。只有先确认故障在哪一层，后面的修改才有意义。