抓包这件事，何抓Wireshark 干得最漂亮的何抓时候，往往是何抓你已经知道大概哪儿出了问题。它不像 tcpdump 那样只给你一行行裸数据，何抓也不像 Fiddler 只盯着 HTTP。何抓它把网卡拽进混杂模式，何抓把经过的何抓每一个帧都摊开给你看，从以太网头到 TCP 载荷，何抓再到 TLS 握手里的何抓 SNI 字段，一层层剥。何抓

先解决一个新手最容易卡住的何抓地方：为什么打开 Wireshark 之后，接口列表里只有 lo 和一堆看不懂的何抓名字？Windows 上通常是因为没装 Npcap，或者装的何抓时候没勾“支持混杂模式”。Linux 下多半是何抓权限问题，普通用户没权访问 /dev/bpf。何抓macOS 稍微省心，但第一次运行会弹窗让你输密码授权。我见过有人折腾半小时，最后发现是网卡选错了——抓的是无线网卡，流量却全走有线。

选对接口，点开始，流量就涌进来了。但别急着看，先设个捕获过滤器。比如只想看某台设备的 HTTP 请求，填 host 192.168.1.100 and tcp port 80。这个过滤器在驱动层就生效，抓不到的东西不会进内存，省得你抓了几百兆再慢慢筛。显示过滤器是另一回事，它只影响你看到什么，不影响已经抓到的包。很多人分不清这两者，结果抓了一堆无关流量，过滤表达式还写错。

真正开始分析的时候，我习惯先看 Statistics → Conversations。哪个 IP 跟哪个 IP 聊得最凶，一目了然。有一次帮同事查一个“网页偶尔打不开”的问题，Conversations 里有个内网地址跟外网某 IP 的 TCP 重传率高得离谱。点进去看 Expert Info，全是“TCP Retransmission”和“Duplicate ACK”。顺着流追踪，发现是中间一台交换机的端口有 CRC 错误，导致丢包。这种问题，光看应用日志根本找不着北。

HTTP 抓包更直观。在显示过滤器里敲 http.request，所有 GET 和 POST 就列出来了。右键某个请求，Follow → HTTP Stream，整个会话的请求头和响应体都拼在一起。我常拿这个看 API 返回的 JSON 里有没有少字段，或者检查 Content-Type 是不是写错了。有一次前端说接口没返回数据，我抓包一看，后端确实回了 200，但 body 是空的。再一看请求头，Accept-Encoding 是 gzip，响应却没压缩——后端中间件配置漏了。这种细节，不抓包根本扯不清。

HTTPS 也不是完全没辙。如果服务端用的是 RSA 密钥交换，可以在 Wireshark 里配私钥解密。但现在基本都是 ECDHE，私钥解不了。更实用的办法是设 SSLKEYLOGFILE 环境变量，让浏览器把会话密钥写到一个文件里，Wireshark 加载这个文件就能解密 TLS 流量。Chrome 和 Firefox 都支持。我试过抓自己写的爬虫，把 requests 库的密钥日志导出来，Wireshark 里直接看明文，比加日志打印方便多了。

无线抓包是另一个坑。你得先把网卡切成监听模式，Linux 下用 airmon-ng start wlan0，然后 Wireshark 里选 mon0 接口。但只能抓到没加密的或者你知道密码的 WPA2 流量——而且得在四次握手的时候在场，抓到握手包才能解密。我试过在咖啡馆抓自己的手机流量，结果周围几十个 AP 的信标帧先把我淹了。后来加了 wlan.fc.type_subtype == 0x08 只显示信标帧，才勉强找到自己的设备。

抓包最怕的是抓太多。有一次排查一个偶发的连接超时，我开着 Wireshark 跑了两个小时，抓了 2GB 的 pcap。用 tshark 命令行筛 tcp.analysis.flags 才找到那几十个异常包。所以现在我都习惯先想清楚要抓什么，过滤器写细一点，抓完立刻用 File → Export Specified Packets 把无关的删掉。pcap 文件小，后面分析也快。

最后说个真事。有次线上服务响应慢，运维说网络没问题，开发说代码没问题。我抓了台前端机器的包，发现 TCP 三次握手之后，客户端发完请求，服务端隔了 3 秒才回 ACK。这 3 秒里没有任何重传，就是干等。后来查出来是服务端所在宿主机的网卡中断亲和性配错了，所有中断都打到 CPU0 上，那个核忙不过来。这种问题，不抓包你永远只能猜。

(责任编辑：热点)