kp-033 网络排错方法论与常用命令

注：本文基于模型知识整理，建议结合权威教材与 RFC 原文核对细节。

一句话定义

网络排错方法论是一套证据驱动的定位流程：按协议栈分层收集证据、一次只改一个变量，用 ip、ping、traceroute/mtr、dig、ss、curl、nc 等命令把「不通」逐步收窄到具体的层与组件。

为什么重要

生产环境里「网页打不开」极少直接给出原因。没有方法论的排查全凭感觉：重启、换 DNS、改配置一起上，好了也不知道是谁治好的。分层排查把混沌问题变成决策树，每一层都有明确证据，几分钟内就能回答「断在 DNS、防火墙还是证书」，是值班与面试共同的硬技能。用它有个隐含前提：你得知道「正常长什么样」——这正是 kp-013 的 ICMP 工具族与 kp-018 的握手过程要打底的地方。

前置知识

建议先读 kp-013《ARP/ICMP》，理解 ping、traceroute、arp 表分别依赖的 ICMP 回显、超时报文与地址解析机制；建议先读 kp-018《TCP 连接管理》，理解端口、握手与 RTT（Round-Trip Time，往返时延）的含义；证据的深挖手段见 kp-034《抓包分析：tcpdump 与 Wireshark》。

核心概念

总原则四条：分层排查（自下而上或自上而下，选定一种走完，不跳层）；一次只改一个变量（同时改 DNS 又换网卡，好了也不知道归功谁）；先测量后结论（ping 通就是通，不凭「应该没问题」跳步）；记录现场（保存输出与时间戳，可复盘可交接）。

五层证据链，每层给出证据来源与判读标准：

层	证据	判读
物理	网口灯、`ethtool eth0` 的 Link detected、Wi-Fi 信号	灯不亮或未检测到链路，到此为止
链路	`arp -a`（或 `ip neigh`）里网关 MAC 是否解析成功	无网关 MAC 说明二层不通
网络	`ping 网关`、`ping 1.1.1.1`、`traceroute`	分辨本机—出口—运营商哪一段断
传输	`ss -tlnp` 看监听、`nc -zv host 443` 测建连	端口未监听或被防火墙拦截
应用	`curl -v` 的状态码与响应头、服务端日志	4xx 查请求，5xx 查服务端

工具与输出读法：ip addr 看接口是否 UP、地址是否正确；ip route 第一行应有 default via <网关>，缺默认路由则一切外网皆不通；ping 给出连通性与 RTT；traceroute 显示逐跳路径，mtr 是它的持续版——循环探测并统计每跳丢包率，能区分瞬时抖动与持续丢包；dig +trace 域名 从根服务器逐级走完解析链，可区分本地 DNS 故障与权威记录错误；ss -tlnp 中 t/l/n/p 分别指 TCP、监听、数字端口、进程；curl -v 把 TLS 握手、请求头、状态码全程打印出来。

图示

「网页打不开」排错决策树

能 ping 通网关吗？
 ├─否→ 物理层(网线/Wi-Fi/网卡) 与链路层(arp 是否解析到网关 MAC)
 └─是→ 能 ping 通公网 IP(如 1.1.1.1) 吗？
        ├─否→ 默认路由 / 运营商线路(traceroute 看断在哪一跳)
        └─是→ 能 dig 出域名 IP 吗？
               ├─否→ DNS(换 resolver / dig +trace 定位)
               └─是→ TCP 443 能建连吗？(nc -zv)
                      ├─否→ 防火墙/安全组/端口监听(ss -tlnp)
                      └─是→ TLS 握手成功吗？(curl -v)
                             ├─否→ 证书链/证书过期/SNI 配置
                             └─是→ HTTP 返回什么码？
                                    ├─4xx→ 请求或权限问题
                                    ├─5xx→ 服务端问题(看服务日志)
                                    └─2xx 仍异常→ 查前端资源与内容

原理与机制

分层排查有效的原因是协议栈是一条串行依赖链：下层不通，上层必然不通。arp 解析不到网关 MAC 时，讨论 DNS 毫无意义；ping 不通网关时，ping 公网只会得到无回音。因此证据要自下而上逐层确认，第一处失败点就是嫌疑层。

traceroute 的原理：发送 TTL（Time To Live，生存时间）=1,2,3… 的探测包，每台路由器把 TTL 减到 0 后回送 ICMP 超时报文，从而逐跳暴露路径。注意中间跳持续显示 * * * 未必是断点——不少路由器对超时不作应答，判断标准是「最后一跳有回应、其后全部星号」。mtr 用同一原理循环发探测并统计每跳丢包率。dig +trace 则把 kp-022 讲的「根→顶级域→权威」迭代解析完整可视化。

两条经验：DNS 是最高频嫌疑人，缓存污染、配置错误、劫持都能让域名解析出错；先用两个二分问句缩小范围——「全体故障还是个别故障」（全公司不通还是只有你）、「全部站点还是个别站点」（所有网站不通还是只有某站），一问就能砍掉一半可能。

实例分析

现象：容器内 curl https://api.example.com 超时。按链走：ip addr 正常、ip route 有默认网关、ping 网关 通、ping 1.1.1.1 通——物理、链路、路由三层排除；dig api.example.com 返回空，第四步失败；换 dig @8.8.8.8 api.example.com 能解析，锁定容器 /etc/resolv.conf 指向的内网 resolver 故障；改用公共 DNS 后恢复。全程只改了 resolver 一个变量，几分钟收案。若第四步正常而 nc -zv api.example.com 443 超时，则转查安全组与端口监听——决策树的意义就在于每一步排除掉剩下的一半可能。

常见误区

ping 不通就判「网络挂了」：很多主机禁 ICMP（Internet Control Message Protocol），应改用 nc -zv 测目标端口。
只 ping 域名不 ping IP：先 ping 通 IP 再 ping 域名，一步区分网络故障与解析故障。
把 traceroute 中间跳的 * * * 当断点：中间路由不应答是常态，看趋势不看单点。
同时改多处配置碰运气：破坏现场，事后无法归因。
5xx 只在客户端折腾：客户端证据链到 TCP 就断了，必须去服务端看日志。

自测题

为什么排错要先 ping 网关、再 ping 公网 IP、最后才 ping 域名？

答案要点： 三步分别验证本机到出口、运营商与外网、域名解析，每步只新增一个变量，能把故障定位到物理/链路、路由、DNS 中的具体一层，避免混因。

mtr 相比一次性 traceroute 的优势是什么？

答案要点： traceroute 是瞬时快照；mtr 持续循环探测并统计每跳丢包率与延迟分布，能区分瞬时抖动与持续丢包，并定位从哪一跳开始劣化。

curl 返回 502 说明问题在哪一侧？下一步看什么？

答案要点： 502 Bad Gateway 表示反向代理收到了请求但上游应用不可用或返回异常，问题在服务端内部；应查代理与上游应用日志，客户端侧证据已走完。

ss -tlnp 各选项含义是什么？目标端口报 Connection refused 时先查什么？

答案要点： t=TCP、l=监听、n=数字端口不解析服务名、p=显示进程；refused 常说明目标端口无进程监听或被明确拒绝，先确认服务已启动、监听地址覆盖目标 IP。

「全体还是个别」「全部站点还是个别站点」两个问句为什么有效？

答案要点： 它们是对故障空间的二分：前者区分本机或环境问题与区域性故障，后者区分链路问题与特定服务问题，各砍一半可能性，配合决策树快速收敛。