Chrome DevTools 的网页 Network 面板，我每天至少打开二十次。抓包F12 按下去，工具勾选 Preserve log，网页刷新页面，抓包密密麻麻的工具请求就铺满屏幕。这东西本质上就是网页一个 HTTP 抓包工具，只不过它长在浏览器肚子里，抓包不用额外装软件。工具

很多人第一次看到这些请求列表是网页懵的。Name、抓包Status、工具Type、网页Size、抓包Time——每列都认识，工具合在一起不知道能干嘛。我刚开始也这样。直到有次线上接口返回的数据跟本地对不上，后端同事说“我这边看是正常的”，我打开 Network，找到那个 XHR 请求，点开 Response 标签页，把返回的 JSON 截图甩过去，对方沉默了五秒说“我查一下”。从那以后我就知道，抓包工具最大的价值不是技术，是证据。

浏览器自带的抓包能力其实被严重低估了。右键任意请求 → Copy → Copy as cURL，直接丢到终端就能复现这个请求。调接口鉴权问题的时候，这招比看文档快十倍。还有 Filter 输入框，敲 mime-type:application/json 能把所有 API 请求筛出来，页面里夹杂的图片、字体、埋点脚本瞬间消失。这个过滤语法知道的人不多，但用过就回不去。

当然浏览器抓包有盲区。它只能看 HTTP 和 HTTPS，TCP 层以下的事管不了。而且 HTTPS 默认加密，你看到的请求体是明文，那是因为浏览器在 TLS 握手时就把密钥交给了 DevTools。换成 Wireshark 抓同样的流量，看到的全是加密的二进制流。所以做移动端抓包的时候，得在手机和路由器之间架一层代理，Charles 或者 Fiddler 干的就是这个活。

Charles 我用得不多，但有个场景离不开它：抓 App 的包。手机连上 Charles 的代理，装个根证书，App 发的请求就全落在 Charles 的 Session 列表里。有次排查一个 H5 页面在 App WebView 里白屏的问题，Chrome DevTools 完全看不到 WebView 内部的请求，Charles 一开，发现是一个 CDN 域名在 App 环境里被 DNS 污染了。这种问题，没有代理层抓包根本定位不到。

还有个冷门工具叫 tcpdump。服务器上没图形界面，Charles 跑不起来，tcpdump 抓包存成 pcap 文件，拖回本地用 Wireshark 分析。命令就一行：tcpdump -i eth0 -w capture.pcap port 443。朴实无华，但线上排障的时候能救命。我见过一个 bug，Nginx 日志显示请求正常返回 200，但客户端就是收不到响应。tcpdump 抓下来一看，服务端确实发了，但 TCP 窗口为零，客户端网卡缓冲区满了。这种问题，应用层日志永远看不出来。

抓包工具的选择其实取决于你在哪一层。看 HTTP 语义，DevTools 最快。看 TCP 重传、窗口、握手，Wireshark 和 tcpdump 是唯一选择。看移动端 App 的 HTTPS 请求，中间人代理绕不开。三个层级对应三类工具，没有哪个能通吃。

最后说个细节。DevTools 的 Network 面板里，Timing 标签页有个 Waterfall 图。每个请求的 DNS 查询、TCP 连接、TLS 握手、TTFB、内容下载，各占多少毫秒，一目了然。有次优化一个页面加载速度，看 Waterfall 发现一个接口的 TTFB 高达 1.2 秒，后端查了半天说数据库没问题。最后发现是那台机器上配了个错误的 DNS，每次请求都要等 DNS 超时。抓包工具不光能看“发了什么”，还能看“时间花在哪”。这个维度，比看请求内容更有杀伤力。

(责任编辑：探索)