Chrome DevTools 的网站 Network 面板能抓到的信息，远比大多数人想象的抓包多。上周排查一个登录接口的工具 bug，前端死活说参数传对了，网站我打开 Network，抓包看到请求体里 password 字段的工具值是空的——前端代码里 `JSON.stringify` 漏掉了这个属性。整个过程不到两分钟。网站如果靠 console.log 一行行打，抓包半小时都未必找得到。工具

这就是网站抓包工具存在的意义。它站在浏览器和服务器之间，抓包把所有 HTTP 通信摊开给你看。工具

抓包到底抓的网站是什么

浏览器每发出一个请求，都会经过一条完整的抓包链路：DNS 解析、TCP 握手、工具TLS 协商、发送 HTTP 请求、等待响应、接收数据。抓包工具能让你看到其中 HTTP 层的全部内容——请求头、请求体、响应头、响应体、状态码、耗时分布。

拿 DevTools 来说，打开 Network 面板，刷新页面，你会看到一列请求像流水一样滚出来。点开任意一条，Headers 标签里是原始报文，Payload 是发送的数据，Response 是服务器返回的内容，Timing 则把整个请求拆成了 Queueing、Stalling、DNS Lookup、Initial Connection、SSL、Request Sent、Waiting、Content Download 这些阶段。

我常跟同事说，Timing 这个面板值得反复看。有次一个页面加载慢，后端接口响应只花了 80ms，但 Timing 显示 Waiting 阶段占了 3 秒。问题出在服务器前面的负载均衡上，跟后端代码毫无关系。没有这个面板，你只能瞎猜。

不只是 DevTools

浏览器自带的工具够用，但有些场景它覆盖不了。比如你要抓 App 的请求，或者需要修改请求内容做测试，就得换更专业的工具。

Charles 和 Fiddler 是两类被用得最多的代理型抓包工具。原理不复杂：它们在本机启动一个代理服务器，你把设备或浏览器的代理指向它，所有流量就都从它那里过。HTTPS 需要装一张根证书才能解密，这一步劝退了不少人，但装完之后确实方便。

Charles 的 Map Local 功能我几乎每天都在用。后端接口还没写好，我把某个 URL 映射到本地一个 JSON 文件，前端就能正常联调。Rewrite 功能也好使，批量替换请求头或者重定向域名，改配置比改代码快得多。

Wireshark 是另一个层级的东西。它抓的是网卡上的原始数据包，TCP、UDP、甚至更底层的协议都能看。日常 Web 开发用不上，但要分析 WebSocket 帧结构或者排查 TCP 重传问题，它是唯一的选择。界面复杂，过滤表达式得现查，上手门槛不低。

移动端抓包的一个坑

抓手机 App 的包，最容易卡在证书上。Android 7 以后，系统不再信任用户安装的 CA 证书，App 默认也不信任。解决办法要么 root 后把证书装到系统目录，要么用 Xposed 模块绕过 SSL Pinning。iOS 稍微简单些，设置里信任证书就行，但遇到做了证书绑定的 App 同样没辙。

还有个细节：抓包时记得关掉其他代理软件。Clash、Surge 这类工具会占用系统代理，和 Charles 冲突。我第一次用 Charles 抓不到包，折腾了半小时才发现是 Clash 在后台跑着。

什么时候不该用抓包

抓包工具不是万能的。WebSocket 长连接、HTTP/2 的多路复用、gRPC 的二进制帧，在 DevTools 里的展示都不够直观。这时候与其硬看抓包结果，不如直接看服务端日志。

另外，生产环境的流量别随便抓。涉及用户隐私的数据，抓下来存到本地就是隐患。公司内部有合规要求的话，抓包前先确认清楚。

说到底，抓包工具的价值在于消除信息不对称。前端说传了，后端说没收到，中间到底发生了什么，抓一次就清楚了。省下来的扯皮时间，够你多写好几个接口。