一、先定框架：网络排查的"三层漏斗模型"

网络问题看起来复杂，但本质上只有三层。我把它叫做"三层漏斗模型"——从外到内，逐层缩小范围，直到锁定根因。

核心原则：先排除自己，再怀疑别人。 80%的"网络问题"其实是自己的配置问题，但我们总是习惯性地先怪运营商。

二、第一层：云上网络层排查——"先扫自家院子"

当你发现延迟高的第一步，不是去ping百度，而是先检查你自己的云上配置。

2.1 第一步：查带宽，是不是被打满了？

这是最常见、也最容易被忽略的原因。

打开云控制台，查看你的云主机或负载均衡的带宽监控曲线。如果出方向带宽已经打满（比如你买的是5Mbps，但实际跑到了4.8Mbps），那延迟高就是必然的——管道堵了，水流再急也没用。

怎么判断？看两个指标：

• 带宽利用率：超过80%就要警惕，超过95%基本就是瓶颈
• 丢包率：带宽打满时，丢包率会从0%飙升到5%以上

某电商团队在大促期间发现API响应慢，排查了半小时应用代码没找到问题，最后一看带宽监控——出方向带宽打满了，丢包率12%。临时升级带宽后，响应时间从3秒降到200毫秒。

工具：控制台带宽监控 + 云监控告警（建议设置80%利用率告警）

2.2 第二步：查安全组，是不是规则太多导致性能下降？

安全组规则不是免费的。每一条规则都需要匹配，规则越多，匹配开销越大。当安全组规则超过50条时，可能导致网络包处理延迟增加。

排查方法：

• 查看安全组规则数量，超过50条考虑拆分
• 检查是否有重叠规则（比如允许了0.0.0.0/0访问80端口，又单独允许了某个IP访问80端口——后面那条是多余的）
• 检查是否有过于宽泛的规则（比如允许所有ICMP——这在生产环境是大忌）

2.3 第三步：查路由表，是不是流量走了弯路？

路由表配置错误，会导致流量绕远路。

典型场景：你的云主机在VPC-A，需要访问同区域的云数据库，但路由表把流量导向了NAT网关，先出公网再回来——延迟直接翻倍。

排查方法：

• 检查VPC路由表，确认内网流量走的是"内网互通"而不是"出公网"
• 检查是否有不必要的静态路由把流量导向了错误的下一跳

某企业的开发环境就出过这个问题：路由表配置错误，内网流量全部走NAT网关出公网再回来，延迟从1ms变成了80ms。改了一条路由，问题瞬间解决。

2.4 第四步：查NAT网关，是不是SNAT连接数打满了？

NAT网关是有连接数上限的。当大量云主机通过同一个NAT网关出公网时，SNAT连接数可能被打满，新连接被拒绝或排队。

排查方法：

• 查看NAT网关的连接数监控，超过最大连接数的80%就要扩容
• 查看是否有僵尸连接（长时间不关闭的连接占着坑位）
• 考虑增加EIP数量，分散SNAT压力

工具：NAT网关控制台连接数监控 + SNAT端口利用率

三、第二层：公网链路层排查——"查路上的坑"

确认云上配置没问题后，下一步就是查公网链路。

3.1 第一步：ping + traceroute——定位丢包在哪一跳

这是最基础、也最有效的组合拳。

ping 告诉你"通不通、延迟多少"。
traceroute（或mtr） 告诉你"在哪一跳开始出问题"。

操作方法：

1# 先ping目标，看延迟和丢包
2ping -c 20 目标IP
3
4# 再trace路径，看哪一跳开始异常
5traceroute 目标IP
6# 或用更强大的mtr
7mtr -r -c 20 目标IP
8

怎么看结果？

某跨境电商的案例：用户反馈访问海外站慢。mtr结果显示，流量在跨太平洋链路的第8跳开始丢包率飙升到30%。这不是云的问题，是国际海底光缆在那个时段拥塞——换了个时段访问，问题自动消失。

3.2 第二步：mtr——比traceroute强10倍的神器

traceroute只能看一次路径，但mtr能持续监测每一跳的延迟和丢包率，实时刷新。

mtr的输出怎么看？

1Host                      Loss%   Snt   Last   Avg  Best  Wrst
21. 10.0.0.1               0.0%    20    0.3   0.4   0.2   1.1
32. 100.64.0.1             0.0%    20    1.2   1.5   0.8   3.4
43. 202.97.xx.xx           2.0%    20    8.7   9.1   7.2  15.3  ← 开始升高
54. 202.97.xx.xx           5.0%    20   45.2  48.7  42.1  67.8  ← 明显异常
65. 目标IP                 3.0%    20  120.5 125.3 118.2 145.6
7

第4跳开始延迟飙升、丢包增加——问题就在这一跳。这是运营商的节点，你改不了，但你知道问题在哪了，工单就有依据了。

3.3 第三步：dig——DNS解析慢，你以为是网络慢

很多时候，你以为的"网络延迟高"，其实是DNS解析慢。

浏览器要先把域名解析成IP，才能建连接。如果DNS解析花了2秒，你会以为是网络慢，但其实是DNS慢。

排查方法：

1# 查看DNS解析耗时
2dig 目标域名
3# 关注Query time字段
4
5# 对比不同DNS的解析速度
6dig @8.8.8.8 目标域名
7dig @114.114.114.114 目标域名
8

某团队发现API调用慢，排查了一圈网络没问题，最后发现是云上默认DNS响应慢。把DNS改成114.114.114.114后，首次连接建立时间从1.5秒降到0.3秒。

3.4 第四步：httping——比curl更适合测HTTP延迟

curl能测HTTP请求的总时间，但它把DNS解析、TCP建连、SSL握手、服务器处理、内容传输全混在一起了，你看不出哪个环节慢。

httping 可以把这些环节拆开：

某API网关优化案例：httping显示connect时间正常（80ms），但wait时间高达2.3秒——问题不在网络，在后端服务处理慢。 团队立刻把排查方向从网络转向应用，半小时就找到了慢SQL。

四、第三层：应用与目标层排查——"也许不是你的锅"

确认链路没问题后，最后一步是确认：是不是目标服务器的问题？

4.1 tcping——测端口通不通，比telnet好用

telnet只能测TCP端口，tcping还能测延迟和丢包。

1tcping 目标IP 443
2

如果tcping显示延迟正常、无丢包，说明链路到目标服务器是通的，网络没问题。如果tcping也超时，那就是目标服务器的防火墙或安全组拦了你。

4.2 curl -w——把HTTP请求的每个环节计时拆开

1curl -o /dev/null -s -w "
2dns: %{time_namelookup}s
3connect: %{time_connect}s
4ssl: %{time_appconnect}s
5total: %{time_total}s
6" https://目标域名
7

输出示例：

1dns: 0.032s
2connect: 0.087s
3ssl: 0.156s
4total: 2.341s
5

dns+connect+ssl = 0.275秒，但total是2.341秒——差的那2秒，是服务器处理时间。 网络没问题，是后端慢。

4.3 对比测试：换个目标，问题还在吗？

如果你怀疑是目标服务器的问题，最简单的验证方法是：换一个目标测。

• 访问目标A慢，访问目标B快 → 目标A的问题
• 访问所有目标都慢 → 你自己的网络问题
• 访问所有目标都快，但用户反馈慢 → 可能是用户侧网络问题（弱网、跨运营商）

五、实战排查流程：一张表搞定

六、写在最后：网络排查的本质，是"排除法"

网络问题之所以难，不是因为技术难，而是因为变量太多、不可控因素太多。你控制不了运营商的骨干网，控制不了国际海底光缆，控制不了目标服务器的防火墙。

但你能控制的是：你的带宽有没有打满、你的安全组有没有写错、你的路由有没有配反、你的DNS有没有选对。

这四件事，占了80%的"网络问题"。

剩下20%，用mtr定位跳数，用httping拆分环节，用tcping确认端口——你不需要解决它，你只需要证明"不是我的问题"。 这就够了。

网络排查不是玄学，是科学。工具给你了，思路给你了，流程给你了。下次凌晨两点告警响了，别慌——打开mtr，按流程走一遍，半小时内锁定根因。

你的代码跑在网络上，网络的品质就是你应用的天花板。而诊断网络的能力，就是你在天花板上开一扇窗的能力。