模块八 · 抓包与排错
分层排错法
前面学习了协议原理与观察限制，现在用分层方法逐步缩小故障范围。每次检查都明确能证明什么，再决定下一步；不能承诺所有问题都能在几分钟内定位。
本章要解决的问题：前面学习了协议原理与观察限制，现在用分层方法逐步缩小故障范围。每次检查都明确能证明什么，再决定下一步；不能承诺所有问题都能在几分钟内定位。
本章的证据来源：历史实测记录（一个按层体检的脚本及其完整输出）。故障模式对照表属于标准/经验，因为本机网络正常，没有真实故障可复现。
先从一个例子理解概念
同一句“打不开网页”，可能是查名字失败，也可能是通信、加密或服务器处理失败。排错先要把要验证的问题说具体。
先认清在测试什么：目标、协议与路径
目标是具体地址/服务，协议是ICMP、TCP、HTTP等规则，路径是实际经过的接口与下一步。它们不同，测试结果不能随意替代。
看到的现象与它的原因：症状、假设、证据
“超时”是症状，“可能是防火墙”是假设；能够区分候选原因的日志、配置、抓包或对照才是证据。先列假设，再验证，不直接把猜测写成结论。
可以统计的时间：采样窗口
采样窗口是统计覆盖的时间范围。对比相近时间、同一目标的变化，比拿从开机累积到现在的总数判断某次故障更有依据。
逐环节缩小范围：分层排查
分层排查是分别验证接口、地址/路由、解析、传输、安全与应用。它是一种工作顺序，不是“某次ping失败就证明所有网页失败”的定理。
下面再用这些概念看原理、命令和结果。规范与官方资料列在本章末尾，类比只帮助理解，不代替协议规则。
排错失败的常见原因：跳过定位，直接猜
网络不通时，最常见的反应是立刻开始猜原因：
这些动作的问题不是"错"，而是"没有依据"。 你可能会碰巧修好，但更常见的是：
- 改了一堆设置，最后不知道是哪一项生效的
- 把原本正常的东西改坏了
- 下次遇到同样的问题还是要重新猜
正确的做法是先定位"哪一层坏了"，再在这一层里找原因。
核心方法：按层往上查
按层排查是组织证据的方法，不是“一次探测失败就锁定某层”的定理。先确认实际应用、目标、地址族、接口与路径，再收集对应证据。
- 接口：链路状态、正在使用的接口、无线信号；不把断开的备用网卡当出口。
- 地址与路由：IPv4/IPv6源地址、掩码、下一跳、socket绑定和TUN路径。
- 链路邻居：需要ARP/NDP时检查映射和时间线；回环、TUN、广播/多播单独解释。
- 解析：核对应用实际解析方式、缓存、hosts、传统DNS或DoH/DoT。
- 传输：测试应用实际使用的TCP/UDP服务；ICMP成功或失败不能代替它。
- TLS/应用：校验证书与协议握手、HTTP响应和业务结果。
- 趋势：在相关时间窗口观察延迟、吞吐、重传和资源变化。
APIPA可作链路本地通信，其他接口或IPv6可能仍工作；ping通一个地址也不证明所有协议正常。“能上QQ不能打开网页”可以怀疑DNS，也可能是已有长连接、缓存、浏览器代理、TLS或HTTP策略，需逐项验证。RFC 3927、Microsoft TCP/IP排错指南
实测：在本机上跑一遍这个清单
我写了个脚本（tools/net-doctor.ps1）把上面七步自动化了。历史实测记录输出：
网络分层体检
[L1-L2] 物理与链路层：网卡在不在、连上没有
· WLAN 1.9 Gbps Intel(R) Wi-Fi 6E AX211 160MHz
· vEthernet (WSL (Hyper-V firewall)) 10 Gbps Hyper-V Virtual Ethernet Adapter
· FlClash 100 Gbps Meta Tunnel
✓ 有 3 块网卡处于连接状态
[L3] IP 配置：地址、掩码、网关、有没有掉进 APIPA
· vEthernet (WSL (Hyper-V firewall)) 172.30.0.1/20
· FlClash 198.18.0.1/30
· WLAN 192.168.31.215/24
✓ 所有接口都有正常地址
✓ 有 2 条默认路由
[L3] 路由：去公网实际会走哪条路
· 接口=FlClash 下一跳=198.18.0.2
✓ 路由查找正常
[L3] 网关可达性：二层能不能找到网关
✓ 网关 192.168.31.1 可达
· 邻居缓存状态 = Reachable MAC = A4-39-B3-0B-AB-19
[L7] DNS：域名能不能解析
· example.com -> 198.18.0.205
· 解析结果落在 198.18.0.0/15 —— 这是 fake-IP，说明 DNS 被代理接管（见《应用层》模块）
✓ DNS 能返回结果
[L4] 传输层：目标端口能不能连上
✓ 能建立到 1.1.1.1:443 的 TCP 连接
· 当前已建立的 TCP 连接数 = 277
[L7] 应用层：能不能取到真实内容
· HTTP 状态码 = 200 内容长度 = 577 字节
✓ 取到了实际内容，应用层正常
════════════════════════════════════════════════════════════════════
结论：各层检查全部通过，网络工作正常。本机全绿。 但这个输出本身很有信息量 —— 注意脚本自动识别出了两件事：
- "解析结果落在
198.18.0.0/15，这是 fake-IP" —— 它把《应用层》模块的知识做成了判断规则 - 邻居缓存的 MAC 是
A4-39-B3-0B-AB-19—— 和《链路层和局域网》模块 ARP 那章抓到的是同一个
每一步用到了前面哪些知识
这张表把前面各层的知识与排查步骤联系起来：
| 检查步骤 | 用到的知识 | 在哪一章 |
|---|---|---|
| 网卡状态与速率 | 链路层、双工、Wi-Fi 协商速率 | 《链路层和局域网》模块、《无线网络和移动网络》模块 |
地址是不是 169.254 | DHCP 与 APIPA | 《应用层》模块 |
| 地址和掩码是否匹配 | 子网划分、按位与 | 《网络层》模块 |
| 网关是否可达 | ARP 解析、邻居缓存状态 | 《链路层和局域网》模块 |
| 走哪条路由 | 最长前缀匹配、路由度量 | 《网络层》模块 |
| DNS 解析结果是否可疑 | fake-IP、保留地址段 | 《应用层》模块 |
| 端口能不能连 | TCP 握手、RST 与 ICMP 端口不可达 | 《运输层》模块 |
| TCP 连接数、重传率 | 传输层状态与统计 | 《运输层》模块 |
| HTTP 状态码 | 4xx/5xx 的分界 | 《应用层》模块 |
| 证书是否可疑 | TLS 与中间人 | 《应用层》模块 |
排错不是另一门学问，它就是把原理用起来。
常见故障模式对照表
| 现象 | 候选原因 | 如何缩小范围 |
|---|---|---|
| 有169.254地址 | 未获DHCP、手工配置或历史状态 | 先确认使用接口、地址族、链路和租约 |
| 网关ping不通 | ICMP策略、无线/二层、丢失 | 结合邻居、路由、端口与抓包 |
| IP可探测但域名页面失败 | DNS、代理、TLS、应用策略 | 分别验证实际解析与对应服务 |
| 小请求通、大传输失败 | PMTU、限速、超时、服务或连接策略 | 结合包长、ICMP差错与应用日志 |
| 首次超时后续成功 | 邻居解析、省电、瞬态丢失等 | 连续观察并抓包，不直接归因ARP |
| RST终止 | 对端或中间处理 | 多点捕获及端点日志，TTL只是线索 |
| 间歇异常 | 争用、资源压力、路由或服务波动 | 对应时间窗口的趋势与请求证据 |
PMTU探测必须在ICMP可用、目标响应及协议版本明确的条件下解释；一次超时不能当成“包长超过MTU”。端口建立成功也不代表应用业务正常。
一个真实案例的复盘：本教程自己做过的排错
本教程保留三组历史观察，但改正原先的过度归因：
- tracert重复地址/短路径：可以怀疑TUN或隧道影响，也可能与回包选源、路由环路等有关；原记录未独立确认代理代答。
- 连接文档保留地址快速成功：与本地代理接受连接相容，但不能证明远端应用可用；应检查实际端点和代理日志。
- HTTP/2耗时较慢：未控制复用、并发、缓存与路径，不能把33秒都归因于代理；连接数实验也人为禁用了HTTP/1.1复用。
共同方法是把观察和候选原因分开，补充能区分原因的对照，而不是宣布一个看起来合理的解释已经被证明。
实测限制
本机网络工作正常，所以本章没有真实的故障案例。
具体来说：
- 体检脚本输出全绿（这才是"正常"应有的样子）
- 故障模式对照表来自标准与经验，不是本机复现的
- 那三个"案例复盘"是本教程过程中真实发生过的判断失误，不是我构造的教学例子
要练排错，最好的办法是主动制造故障（在你能恢复的前提下）：
- 把 DNS 服务器改成一个不存在的地址 → 观察第 5 步失败
- 禁用网卡 → 观察第 1 步失败
- 在 hosts 文件里把某个域名指向
127.0.0.1→ 观察 DNS 那步看起来正常但连接失败 - 把 MTU 调小 → 观察大包失败
每制造一次故障，再跑一遍体检脚本，就能看到"哪一层先红"。 这比读十篇排错文章有用。
常见误解
一次检查全绿不等于整机所有网络正常。 它只覆盖所测目标、协议和时间，代理还可能接受连接却无法访问真实目标。
ping不通不等于TCP/HTTP不通，ping通也不代表应用正常。 使用不同协议的探测不能互相替代。
重启后恢复不等于找到原因。 先保留现场、时间、接口、路由、请求错误和相关统计，便于之后对照。
能使用聊天软件而网页失败不唯一指向DNS。 检查解析、已建立连接、代理、TLS和HTTP等候选原因。
本章小结
| 结论 | 性质 |
|---|---|
| 分层排错组织候选原因与证据，不是单次失败定位定理 | 方法 |
| 确认应用、目标、地址族、接口与路径，再解释探测 | 前提 |
| APIPA不代表无效IP或全机不能联网 | 协议边界 |
| ICMP、TCP/UDP、TLS与业务结果需要分别核查 | 协议区别 |
| 对应时间窗口、对照与多点抓包比单次计数更有证据力 | 方法 |
自测题
7 题 · 先自己答，再展开对照
按层排错的核心原则是什么？为什么这个顺序比"直接猜原因"有效？
先确认目标、应用、地址族和路径，再按接口、地址/路由、邻居、解析、传输、TLS/业务收集证据。某个探测失败不自动证明该层故障或所有上层必然失败。你的电脑地址是
169.254.100.20。还需要往下查 DNS、端口吗？为什么？先确认它是否为实际出口，是否还有其他接口或IPv6；169.254是有效链路本地地址。若目标需要经该IPv4出口访问公网，再查租约、链路与配置，不能跳过所有应用检查。能 ping 通
8.8.8.8，但浏览器打不开任何网页。问题最可能在哪一层？怎么确认？DNS只是候选；ping证明该次ICMP成功，不证明TCP443、代理或TLS正常。分别验证浏览器实际解析、端口、TLS和HTTP响应。你能上 QQ，但打不开网页。这个现象为什么指向 DNS？
可能已有长连接或缓存，也可能网页受代理、TLS、端口或HTTP策略影响；DNS需要验证，不能光凭聊天软件成功就唯一定位。网页能打开，但下载大文件总是失败。可能是什么问题？怎么确认？
很可能是 MTU / 路径 MTU 发现问题。 小包（网页请求和首页）能过，大包（文件传输时数据接近 MTU 满负荷）在某段链路上超限被丢弃；如果同时屏蔽了 ICMP，发送方收不到"需要分片但设置了 DF"的通知（《全景与基础》模块讲过），就会一直重试大包、一直失败。
怎么确认：用ping -f -l <大小>逐字节探测路径 MTU —— 就是《全景与基础》模块那个实验。探测出实际 MTU 比预期小很多，就说明路径上有更小的瓶颈。网络时好时坏，应该看哪些指标？
观察对应时间窗口的RTT、失败请求、无线重试、租约/路由变化、重传与资源使用；固定1%阈值和正常缓存老化都不能单独证明故障。重启路由器解决了问题。这样做有什么不足？应该先做什么？
不足在于：你不知道问题是什么，下次还会发生。 重启确实能清掉一些临时状态（ARP 缓存、半开连接、卡住的 DHCP 续租），所以常常"有效"，但它没有提供任何诊断信息。
应该先做的事：抓一份现场。
- 跑一遍分层体检脚本，记下哪一层是红的
- 记下当时的 IP 地址、网关、DNS 配置
- 如果可能，保存netstat -s的统计
有了现场，即使重启解决了问题，你也能回头分析原因；否则这次故障就白白浪费了。
参考资料与适用范围
- Microsoft：TCP/IP通信排错指南
- RFC 3927：IPv4链路本地地址和转发限制
- Microsoft tracert：探测TTL与超时的含义
- RFC 9293 §3.3–3.10：TCP状态、建立关闭、字节流与接口
修订核对日期：2026-10-13。规则按所列协议与实现范围理解；文中的原始命令输出是历史观察，不表示本次重新实测。跨版本、代理/隧道及不同捕获位置需要另行核对。