云上网络故障排查实战：从ping不通到慢请求，一步步找到罪魁祸首

微信图片_2026-05-15_115457_556.png

去年一个客户半夜打电话，语气很急：“用户反馈服务连不上，我们排查了半天，服务器正常，防火墙也没拦，但就是不通。”

我问他：“ping通吗？”

“ping通，但业务端口不通。”

“那telnet端口呢？”

“也通。”

“那问题在哪？”

他沉默了。ping通、端口也通，但业务不通。这听起来矛盾，但网络排查里经常遇到。

后来抓包发现，TCP握手成功了，但服务端返回了一个RST包，主动断开了连接。原因是服务端代码里写了一个白名单逻辑，客户端的IP不在白名单里，直接reset。ping和telnet都不触发这个逻辑，只有业务请求才触发。

这是网络排查最尴尬的情况：每一层都告诉你通的，但业务就是不通。

今天聊聊云上网络故障排查。不是那种“ping一下”的入门课，而是帮你理清楚：从ping不通到慢请求，怎么一步步找到问题。

01 基础排查三板斧

网络出问题，先跑这三条命令，能过滤掉大部分常见故障。

ping：测试ICMP连通性和延迟。

通说明IP层可达，网络链路基本没问题。不通可能是安全组禁ICMP、路由不通、或者对方机器没开ICMP响应。ping通不代表业务端口通，因为ICMP和TCP/UDP走的路径可能不同。

telnet / nc：测试TCP端口连通性。

telnet ip port 能连上，说明TCP握手成功，防火墙、安全组都没拦。连不上，可能是端口没开、安全组拦了、服务没启动。

traceroute：看路由路径和延迟。

traceroute ip 可以看到每一跳的延迟。如果在某跳突然延迟飙升或丢包，问题可能出在那个节点或之后的路径。

那家客户的问题，ping通、telnet通，但业务不通。ping通说明IP层没问题，telnet通说明TCP握手没问题。但业务请求被RST，需要抓包才能发现是应用层拒绝。

命令和日志告诉你的，都是“别人加工过的信息”。抓包看到的是原始报文，是法庭上的“原始证据”。

tcpdump：服务器端抓包

bash

sudo tcpdump -i eth0 port 8080 -w capture.pcap

抓下来用Wireshark分析。可以看三次握手、重传、丢包、RST。

常见抓包发现的问题：

那家客户抓包后发现，客户端发送业务请求后，服务端回了RST。查代码发现有个白名单过滤，客户端的IP不在白名单里。ping和telnet都不触发这个逻辑，只有业务请求才触发。

网络问题排查要分层。每一层都有可能出问题。

排查顺序：客户端 → DNS → 网络链路 → 防火墙 → 负载均衡 → 服务端。一层层排除，不要跳。

云厂商提供了一些原生网络排查工具，比自己敲命令更直观。

VPC Flow Logs：记录VPC内网络流量日志。可以看到谁在访问谁，什么端口，允许还是拒绝。排查安全组拦阻问题时特别好用。

Reachability Analyzer：分析源到目标的网络路径是否可达。输入源IP、目标IP、端口，工具告诉你沿途哪些策略会拦。

Traffic Mirroring：复制网络流量到分析工具。适合深度排查，不影响生产。

那家客户后来用VPC Flow Logs发现，安全组其实有两条规则：一条允许ICMP，一条允许TCP。但TCP规则只开了80和443，业务端口是8080，所以没放行。ping用的是ICMP，所以通；telnet用了8080，但日志里看到被安全组拒绝。之前查安全组时漏看了端口。

一个客户反馈，从办公室访问云上服务延迟很高，超过200ms。但服务器端监控显示请求处理时间只有20ms。差出来的180ms去哪了？

排查过程：

改配置，把接入点切到就近区域，延迟降到25ms。

排查网络问题不要只看服务器端监控，要看全链路。客户端到服务器之间，每一段都可能产生延迟。

网络排查像一个侦探游戏。每一层都可能撒谎：ping通不代表端口通，端口通不代表业务通，服务端响应快不代表用户感知快。

那家客户的运维负责人后来总结了一句口诀：“先ping后telnet，不通看安全组；再抓包，真相就在报文里；分层查，从上到下不跳步；云上工具有奇效，Flow Logs Reachability。”

下次网络出问题，从ping开始，一步步走。不要跳步，不要猜。