Wireshark 一打开，数据网卡列表里跳出七八个接口，抓包选哪个？分析方法我一般直接挑流量最大的那个。抓包这事，过程第一步不是数据点“开始”，而是抓包先想清楚你要看什么。上周排查一个 API 超时问题，分析方法同事抓了 200MB 的过程包丢给我，说“你分析下”。数据我翻了五分钟就关了——他抓的抓包是无线网卡，而请求走的分析方法是有线。方向错了，过程数据再多也是数据噪音。

选对接口只是抓包起点。过滤器分两种：抓包前和抓包后。分析方法抓包前用 BPF 语法，比如 host 10.0.1.5 and port 8080，直接砍掉无关流量。抓包后用显示过滤器，比如 http.response.code == 500，灵活但已经占着磁盘了。我习惯先粗抓，再用显示过滤器精筛。有一次线上环境不能重启服务，只能抓 30 秒，那就必须把 BPF 写死，否则抓到的全是心跳包。

开始抓包后，别盯着滚动列表发呆。先看统计。Wireshark 的“Conversations”按流量排序，谁在跟谁说话、传了多少字节，一目了然。我遇到过一台机器疯狂重传，Conversations 里它的 TCP 流占了 70% 的包量。点进去看 Expert Info，满屏的“Retransmission”。再追到具体流，发现是 MTU 不匹配——发送端 1500，中间某跳只有 1400，大包全被丢弃。这种问题，光看单包看不出来，得看流。

TCP 流追踪是核心技能。右键任意包 → Follow → TCP Stream，原始字节和解析后的文本并排显示。HTTP 请求头、响应体、甚至 gzip 压缩后的乱码都在里面。我经常在这步发现“意外”：比如接口返回 200，但 body 里是 { "code":500}；或者 Content-Length 对不上，导致客户端一直等剩余数据。有个案例更隐蔽——服务端发了 Connection: keep-alive，但 30 秒后自己关了连接，客户端没收到 FIN 就复用了旧连接，结果第一个请求超时。这种时序问题，必须靠时间戳列。

时间戳默认是相对时间，我建议切成“Seconds Since Beginning of Capture”。然后按时间排序，看两个包之间的间隔。正常 RTT 在 10ms 以内，如果某个 ACK 等了 200ms 才来，中间要么有丢包，要么有延迟。曾经有个数据库查询慢，抓包发现客户端发完 SQL 后，服务端 1.2 秒才回第一个字节。这 1.2 秒里没有任何网络交互，说明是服务端自身处理慢，跟网络无关。抓包直接排除了网络嫌疑，省得运维和开发互相甩锅。

HTTPS 流量默认是加密的，只能看到 TLS 握手和包长。要解密得拿到会话密钥。浏览器可以设 SSLKEYLOGFILE 环境变量，Wireshark 里配好路径就能解。但线上服务没这么方便。我的做法：如果服务是自己的，临时在测试环境关掉 TLS，或者用 mitmproxy 做中间人。生产环境别这么干，合规风险太大。实在要查，看 TLS 握手的 SNI 和证书有效期也能挖出不少信息——比如证书过期导致握手失败，客户端报的却是“连接超时”。

最后说个反直觉的：不是所有问题都能靠抓包解决。有一次应用层报“连接被重置”，抓包看到 RST 包来自客户端自己。查了半天，是本地防火墙规则误杀了。抓包只告诉你“发生了什么”，不告诉你“为什么”。你得结合系统日志、netstat、甚至 strace 一起看。工具是死的，思路是活的。抓包分析的本质，是用数据包的时间线和内容去还原一次通信的真实过程，然后跟你的预期做对比。差异点，就是 bug 所在。