Wireshark 打开的电脑那一瞬间，网卡上的抓包数据像开了闸的水龙头。我盯着屏幕上滚动的工具上千行记录，TCP、电脑DNS、抓包TLS 握手，工具密密麻麻。电脑这是抓包我第一次真切意识到——网线上跑的东西，远比浏览器里看到的工具页面复杂得多。

抓包工具干的电脑事说白了就一件：把经过网卡的数据帧截下来，拆开给你看。抓包但“拆开”这两个字背后的工具分量，用过一次就懂了。电脑HTTP 请求里的抓包 header、cookie、工具POST 的 body，只要没走加密，全都赤裸裸摆在那里。早年很多网站还在用纯 HTTP 的时候，论坛上有人用 Fiddler 抓自己手机上的流量，结果发现 App 偷偷往某个 IP 传了设备的 IMEI 和位置信息。这种事你光看界面永远看不出来。

工具不止一种，用哪个看场景

Wireshark 是绕不过去的名字。它工作在链路层往上，什么协议都能解，功能全得吓人。但正因为全，新手打开容易懵——过滤器语法要单独学，tcp.port==443 这种写法跟写代码差不多。我见过有人抓了半天包，发现抓的全是自己电脑跟路由器的 ARP 广播，跟目标业务毫无关系。

Fiddler 和 Charles 是另一个路数。它们本质上是代理服务器，浏览器或手机把请求发给它们，它们再转发出去。好处是只关心 HTTP/HTTPS，界面清爽，还能改包重放。做 Web 开发或者测接口的人，基本人手一个。Charles 在 Mac 上体验更好，Fiddler 老版本只支持 Windows，后来才有了跨平台的 Fiddler Everywhere，但那个新版本我用着总觉得卡。

tcpdump 是命令行的老炮儿。服务器上没图形界面，SSH 进去敲一行 tcpdump -i eth0 port 80 -w capture.pcap，回头把文件拉到本地用 Wireshark 分析。运维的人对这个再熟悉不过。它的过滤表达式跟 BPF 语法一致，效率极高，但输出读起来费眼睛。

HTTPS 不是终点，但确实是一道墙

现在绝大多数流量都走 TLS 了，直接抓包看到的是加密后的二进制。Charles 和 Fiddler 能解 HTTPS，原理是让你在设备上装一个它们的根证书，它们充当中间人，对浏览器伪装成服务器，对服务器伪装成浏览器。听起来简单，实际操作经常踩坑。iOS 从某个版本开始，装了证书还得去“关于本机”里手动信任，很多人卡在这一步以为工具坏了。Android 7 以后，App 默认不信任用户安装的证书，除非 App 自己开了 debug 模式或者你 root 了手机把证书塞进系统目录。

我自己的经验是，抓 HTTPS 之前先想清楚目标是什么。如果只是看某个 App 调了哪些接口，用 mitmproxy 写个脚本过滤一下，比在 Wireshark 里翻加密流舒服得多。如果要分析 TLS 握手本身的性能问题，比如证书链太长导致延迟，那就得回到 Wireshark，看 Client Hello 和 Server Hello 之间的时间差。

几个容易忽略的细节

抓包工具本身会消耗资源。Wireshark 在高速网络下跑，内存占用能飙到几个 G，硬盘写入也猛。长时间抓包记得设个 ring buffer，不然硬盘满了都不知道。

还有网卡模式的问题。默认情况下网卡只接收发给自己的帧，想抓局域网里其他设备的流量，得把网卡设成混杂模式。但现在的交换机基本都隔离端口了，除非你在网关或者核心交换机上做端口镜像，否则抓不到别人的包。这一点跟很多人想的不一样。

最后说个我自己的习惯：每次抓完包，先把 pcap 文件按时间戳命名存好，再写个简短的备注说明当时在测什么。过了一周回头看，没有备注的抓包文件跟垃圾没区别。