兄弟们，做云运维和SRE的，谁没被网络问题折磨过？业务反馈“访问慢”、“偶尔超时”、“连不上”，一查网络，ping好像又通了。这种“玄学”网络问题，最搞人心态。
很多新人一遇到网络问题就慌，重启网卡、改路由、换IP，一顿操作猛如虎，结果问题还在，甚至把业务搞挂了。今天这篇复盘，就是给一线兄弟们的“网络排障保命指南”。
一、 开篇立规矩：网络排查“四不要”与“总原则”
动手之前，先把这几条红线刻在脑子里，严禁以下操作：
处置总原则：
先分图层定位，再对症处理；先确认物理链路，再看配置。
二、 正确开局：先定性，再动手
第一件事，别急着敲命令，先问清楚业务：是彻底不通、还是间歇性丢包、还是延迟高？
确认问题范围：是单台实例、整个网段、还是跨地域访问？
排查收敛路径：客户端 -> 本地网络 -> 虚拟网络（VPC/安全组） -> 公网/专线 -> 目标服务器。
明确区分三类情况：
三、 排查主链路：命令与操作指南
以下是Linux环境下的排查动作，直接复制可用。
1. ping 测连通性和丢包（小包/大包对比）
# 小包测试（默认64字节）
ping -c 100 <目标IP>
# 大包测试（1472字节，测试MTU）
ping -c 100 -s 1472 <目标IP>
- 现象：小包通，大包不通或丢包严重。
- 结论：大概率是MTU问题，中间链路有节点丢弃了大包。
2. traceroute/mtr 看每一跳的延迟和丢包
# mtr 持续测试，生成报告
mtr -r -c 100 <目标IP>
# 或者 traceroute
traceroute -n <目标IP>
- 现象：某一跳延迟突然飙升，或者丢包率（Loss%）很高。
- 结论：定位网络瓶颈在哪一跳。注意：中间节点ICMP限速导致的丢包不一定是真丢包，看最后一跳。
3. 检查MTU
# 探测路径MTU（Linux）
ping -M do -s 1472 <目标IP>
# 如果报错 Message too long，逐渐减小 -s 的值，直到通为止
- 现象：-s 1472 不通，-s 1400 通了。
- 结论：路径MTU小于1500，需要调整本地或应用层MTU。
4. 检查网卡状态和丢包计数
# 查看网卡统计信息（重点看 errors, dropped, overruns）
ifconfig eth0
# 或者
ip -s link show eth0
# 查看网卡环回和队列
ethtool -S eth0
- 现象：dropped 或 errors 计数持续增加。
- 结论：本地网卡拥塞、驱动问题或硬件故障。
5. 查看路由表
ip route show
# 或者
route -n
- 现象：默认路由指向错误，或者目标网段路由缺失。
- 结论：路由配置错误，流量没发出去。
6. 抓包看重传和乱序
# 抓取指定端口流量，保存为pcap文件
tcpdump -i eth0 host <目标IP> and port 80 -w net_issue.pcap
- 现象：Wireshark分析发现大量 TCP Retransmission（重传）或 Out-of-Order（乱序）。
- 结论：网络质量差，存在丢包或延迟抖动。
7. 对比同网络下其他实例
# 在同VPC、同可用区的另一台正常机器上执行同样的 ping/mtr
ping -c 100 <目标IP>
- 现象：其他机器正常，只有这台有问题。
- 结论：问题出在这台实例本身（安全组、系统配置、网卡），而不是云平台底层网络。
8. 查安全组/防火墙
# 查看 iptables 规则
iptables -L -n -v
# 检查云控制台安全组入方向/出方向规则
- 现象：规则里没有放行目标端口，或者被默认拒绝。
- 结论：流量被安全组或系统防火墙拦截。
四、 高频现场逐个拆：现象+命令+处理
1. 公网访问慢（跨地域延迟高）
- 现象：北京用户访问广州服务器，延迟200ms+。
- 命令：mtr -r -c 100 <目标IP>
- 处理：看mtr报告，如果从第5跳开始延迟变高，说明是骨干网或跨运营商问题。临时方案：上CDN或全球加速（GA）；根治：业务多地域部署。
2. 间歇性丢包
- 现象：业务偶尔超时，ping丢包率5%。
- 命令：mtr -r -c 1000 <目标IP>（加大测试包数量）
- 处理：如果丢包集中在中间某几跳，且最后一跳也丢，联系运营商或云厂商提工单，附上mtr报告。如果是云内丢包，检查宿主机负载。
3. 小包通大包不通（MTU问题）
- 现象：ping通，但SSH卡顿，大文件传输出错。
- 命令：ping -M do -s 1472 <目标IP>
- 处理：确认MTU问题。在网卡配置里调小MTU（如改为1450），或者在应用层（如Nginx、数据库连接串）调整MSS。注意：改MTU会轻微增加CPU开销。
4. 内网不通
- 现象：同VPC两台机器ping不通。
- 命令：ip route show，iptables -L
- 处理：先查云控制台安全组是否放行ICMP和对应端口；再查系统内iptables/firewalld；最后查路由表是否指向了正确的虚拟网卡。
5. 延迟忽高忽低（抖动）
- 现象：ping延迟平时10ms，偶尔飙到500ms。
- 命令：ping -c 1000 <目标IP> 看 mdev（抖动值）。
- 处理：检查源端和目标端CPU是否跑满（软中断高）；检查是否有大流量背景流（如备份任务）占满带宽导致拥塞。
6. 专线/云连接不稳定
- 现象：本地IDC到云上专线延迟大、丢包。
- 命令：在专线网关和云企业网（CEN/CCN）看监控。
- 处理：检查专线物理端口光衰；检查BGP路由是否频繁震荡；联系运营商测物理链路质量。
7. DNS解析慢导致访问慢
- 现象：curl访问域名很慢，但直接访问IP很快。
- 命令：dig <域名> 或 nslookup <域名>，看 Query time。
- 处理：DNS服务器响应慢。换用公共DNS（如114.114.114.114或8.8.8.8），或在本地部署DNS缓存（如dnsmasq）。
8. 云平台健康检查导致的连接重置误判
- 现象：SLB后端服务器日志里大量连接被RST。
- 处理：这是SLB健康检查探活导致的。调整健康检查的间隔时间、超时时间，或者让应用层正确响应健康检查（返回200），而不是直接断开TCP。
五、 处置与落地：三档策略
别一上来就改配置，按这个顺序来：
临时绕行（止血）：
- 如果是公网链路问题，临时换EIP、换NAT网关，或者切到备用线路。
- 如果是DNS问题，临时改本地hosts。
调整配置（救火）：
- MTU问题：改网卡MTU或应用MSS。
- 路由问题：加静态路由，修正下一跳。
- 注意：改MTU和路由要在业务低峰期，改完立刻验证。
联系供应商（根治）：
- 如果是运营商骨干网丢包、专线光衰，自己修不了，立刻提工单。
- 关键：提工单必须带证据（mtr报告、tcpdump抓包文件、时间点），不然客服只会让你重启。
验证：处置后，用 mtr 和 ping 跑5分钟，看丢包率和延迟是否恢复正常曲线。
六、 根因分析：怎么定位责任
网络问题，根因通常跑不出这几个：
怎么定位：拉出 mtr 链路图和 tcpdump 抓包时间线。
- 如果是云内丢包，看云监控（网卡PPS、带宽）。
- 如果是云外丢包，看mtr中间跳，带证据找运营商。
- 如果是应用层连不上，看抓包有没有SYN，有没有RST，定位是防火墙拦了还是应用没监听。
七、 事后加固要点
别等下次断网再抓瞎，平时把这些做了：
八、 总结：排查高频踩坑清单
最后再啰嗦一遍，这些都是血泪教训：
- 没分图层乱排查：应用层超时当网络层修，查半天网络发现是代码死锁。
- 只测连通不测质量：ping通了就说网络没问题，结果丢包率30%。
- 忽略MTU：大包不通死活查路由，其实是MTU被丢弃。
- 看到某一跳丢包就骂运营商：中间节点ICMP限速是常态，看最后一跳！
- 没对比同网络实例：单机问题当成全网故障，瞎改云网络配置。
- 安全组误拦没查：新开的机器连不上，原来是安全组没放通22端口。
- DNS问题当网络问题修：域名访问慢，ping IP秒开，其实是DNS解析慢。
兄弟们，网络排查是个细致活，讲究的是逻辑和证据。平时多积累命令，故障时才能稳如老狗。
博主互动：
如果你觉得这篇复盘对你有帮助，或者你在排查网络问题时遇到过什么“玄学”坑，欢迎在评论区留言交流！
觉得有用请点赞、收藏、关注，后续还会更新更多云运维实战干货（数据库慢查询、K8s排障等）。咱们下期见！
