这是「图解 HTTP」系列的最后一篇。前面 29 篇把 HTTP 从 URL 到 HTTP/3 的机制拆了个遍，这一篇做两件事：一是讲怎么用工具把这套机制「看」清楚（抓包排障），二是把整个系列收束成一张地图。
排障的第一原则：分层定位
HTTP 问题排障，第一原则是分层定位——先判断问题卡在协议栈的哪一层，再针对性排查。
一个「请求不通」或「响应不对」的问题，按层排查：
- DNS 层：域名能解析吗？
nslookup/dig看域名是否解析到正确 IP。 - 连接层：TCP 能连上吗？
telnet host 443或curl -v看握手成不成。 - TLS 层：证书有效吗？握手成功吗？
openssl s_client看证书链和握手。 - HTTP 层：请求发出去了吗？状态码对吗？header 对吗？
- 应用层：状态码 200 但内容不对？那是业务逻辑问题，不是 HTTP 问题。
这个分层思路能避免「到处乱查」。先确定是哪层的问题，再用对应工具。
两个核心工具：DevTools 和抓包
排障离不开两个工具：
浏览器 DevTools（Network 面板）
最常用的工具。它能看：每个请求的 method、status、header、body、耗时瀑布图、缓存状态（(disk cache) / (memory cache)）。适合排查应用层问题——请求对不对、响应对不对、缓存命中没、哪个请求慢。
DevTools 的局限：它看的是浏览器视角，HTTPS 的内容是解密后的，看不到 TLS 握手细节；也看不到连接复用等底层行为。
抓包工具（Wireshark / mitmproxy / Charles）
看底层的工具。Wireshark 能抓到每个 TCP 包、TLS 握手、DNS 查询——真正的字节级。mitmproxy / Charles 通过中间人代理（装它的根证书）解密 HTTPS，看 HTTP 报文内容。
抓包适合排查连接层、TLS 层、代理改写的问题——这些 DevTools 看不到。比如「为什么 TLS 握手失败」「为什么代理改了我的 header」，得靠抓包。
排障实战：几个典型场景
把前面的知识和工具结合，看几个典型排障场景：
场景一：接口跨域报错（CORS）
DevTools 看到控制台 CORS 报错 → 检查响应头有没有 Access-Control-Allow-Origin → 没有，后端没配 CORS。这是第 22 篇的内容。
场景二：缓存不生效
DevTools Network 看请求状态：还是 200（重新下载），不是 (disk cache) 也不是 304 → 检查响应头 Cache-Control 配对没 → 可能配了 no-store 或 max-age=0。这是第 11-12 篇的内容。
场景三：HTTPS 连不上
curl 报证书错误 → 用 openssl s_client 看证书链 → 证书过期了 / 证书域名不匹配 / 证书链不完整（缺中间 CA）。这是第 10 篇的内容。
场景四：接口慢
DevTools 瀑布图看耗时构成：是 DNS 慢、连接慢、还是 TTFB（首字节时间）慢？连接慢可能是 TLS 握手开销（没复用连接）；TTFB 慢是服务器处理慢。这是第 6-9 篇的内容。
系列总收束：HTTP 的三层骨架
回顾这 30 篇，HTTP 的全部内容可以归到三层骨架：
第一层：报文层（01-05、16-20）
URL 定位资源、报文三段式表达意图、method/status 语义对偶、body 编码、内容协商、压缩、分块、范围请求、表单。这一层回答「HTTP 怎么表达」。
第二层：传输与治理层（06-15、26-29）
TCP/TLS 连接、keep-alive、队头阻塞、缓存体系（强缓存/协商/Vary/层级/失效）、HTTP/2 多路复用和 HPACK、HTTP/3 和 QUIC、代理网关。这一层回答「HTTP 怎么传输、怎么优化」。
第三层：安全层（21-25）
Cookie 状态、CORS 跨域、CSP 防 XSS、HSTS 防降级、Web 攻击防御。这一层回答「HTTP 怎么保证安全」。
这三层不是孤立的——缓存和 Vary 横跨报文层和传输层，CORS 和 Cookie 横跨安全层和报文层。但用这三层做心智模型，你遇到任何 HTTP 问题都能快速归类：这是表达问题、传输问题、还是安全问题。
一个贯穿全系列的判断
写完这 30 篇，我最大的感受是：HTTP 能跑三十多年还在用，不是因为技术多先进，而是因为它的设计把最关键的意图编码进了协议。
URL 让资源可寻址，method/status 让意图可理解，header 让元信息可扩展，缓存让性能可优化，分层让实现可演进。这些设计在 1991 年定下骨架，到 HTTP/3 改了传输层都没动语义层——这就是好协议的韧性。
理解 HTTP 不在于背多少 header、多少状态码，而在于理解这套「为什么这么设计」的取舍。当你能回答「为什么报文是三段式而不是 JSON」「为什么 GET 必须安全」「为什么 HTTP/2 多路复用反而放大了 TCP 层队头阻塞」——你就真正理解了 HTTP。
这也是这套「图解 HTTP」想留给你的东西：不是知识点手册，而是一套判断坐标。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
这套「图解 HTTP」到此完整收束，30 篇沿着 URL 与报文、连接与传输、缓存与协商、安全与边界、HTTP/2 与 HTTP/3 这条线，把这套协议的机制和取舍拆了个遍。
如果你跟着读到了这里，感谢你。HTTP 是 Web 的地基，理解了它，你处理任何 Web 问题都有了判断坐标。后续我会继续按图解主线更新其他系列，欢迎关注公众号 「十三Tech」。
