内容摘要：Wireshark 一打开，满屏的 TCP、HTTP 包滚得飞快，很多人第一反应是关掉。其实抓包这事儿没那么玄乎——你只需要看懂其中不到 10% 的信息，就能解决 90% 的问题。上周排查一个接口超时

Wireshark 一打开，网络满屏的抓包 TCP、HTTP 包滚得飞快，分析很多人第一反应是教程关掉。其实抓包这事儿没那么玄乎——你只需要看懂其中不到 10% 的网络信息，就能解决 90% 的抓包问题。上周排查一个接口超时，分析从抓包到定位，教程前后花了不到六分钟。网络下面把我平时用的抓包流程拆开讲一遍。

先搞清楚你要抓什么

抓包最忌讳上来就“全抓”。分析网卡上跑着几十种协议，教程你全收下来，网络文件几个 G，抓包分析时跟大海捞针一样。分析正确的做法是先缩小范围。比如你怀疑是某个 API 返回慢，那就先在 Wireshark 的捕获过滤器里写 host 10.0.3.47 and port 8080，只抓这台服务器这个端口的流量。过滤器语法不难，host、port、net 三个词组合一下，能砍掉八成噪音。

我习惯在终端先用 tcpdump 快速确认有没有流量。命令很简单：tcpdump -i eth0 -nn host 10.0.3.47 and port 8080 -c 20。敲下去如果二十个包瞬间刷完，说明链路是通的，问题在上层；如果一个包都没有，那先查路由和防火墙，别急着开 Wireshark。

抓包时机的把握

有个细节容易被忽略：Wireshark 启动抓包的那一瞬间，可能已经错过了关键握手包。比如排查 TLS 握手失败，你得在客户端发起连接之前就点下开始按钮。我的做法是先把 Wireshark 挂上，设好过滤器，然后才去触发那个出问题的操作。多等几秒无所谓，漏了 SYN 包才麻烦。

另外，如果你抓的是本机回环流量（localhost），Wireshark 在 Windows 上默认抓不到。得装 Npcap 时勾选回环适配器，或者干脆用 RawCap 这类小工具。这个坑我踩过两次，明明服务在跑，抓包一片空白，查了半天才发现是回环的问题。

看懂三个关键指标

包抓到了，怎么读？别一行行看。先点“统计”菜单里的“对话”，按字节数排序。排最前面的那条流，大概率就是问题所在。然后右键选择“追踪 TCP 流”，Wireshark 会把整条会话拼成可读文本。HTTP 请求和响应一目了然。

接下来盯三个东西。第一，时间差。在抓包列表里看相邻两个包的时间戳，如果客户端发完请求后隔了 3 秒服务器才回 ACK，那网络或服务端处理肯定有问题。第二，TCP 重传。过滤器输入 tcp.analysis.retransmission，如果满屏都是，说明链路丢包严重。第三，窗口大小。在 TCP 头部字段里看 Window Size，如果一直很小甚至变成零，接收方处理不过来，发送方在等。

一个真实案例

之前有个服务偶尔报“连接被重置”。抓包后发现，客户端发完 Client Hello 后，服务器直接回了 RST。但奇怪的是，同一台客户端连另一台服务器就正常。对比两个抓包文件，发现出问题的那次，客户端 TCP 头部的 MSS 值设成了 1460，而中间有个 MTU 是 1400 的隧道。大包过不去，触发了 PMTUD 黑洞，服务器等不到后续分片，直接重置。把客户端 MSS 调成 1360，问题消失。这个案例里，Wireshark 的“专家信息”功能帮了大忙——它用黄色感叹号标出了所有异常，省去逐包翻找的功夫。

保存与复现

抓完别急着关。养成习惯：文件命名带上日期和问题关键词，比如 20250312_api_timeout.pcapng。Wireshark 默认的 pcapng 格式比老的 pcap 多存了接口和注释信息，方便以后回溯。如果文件太大，用 editcap 按时间切分，或者只导出过滤后的包。我见过同事把 2G 的抓包文件直接发邮件，结果被网关拦了，白白浪费一上午。

最后说一句，抓包不是万能药。如果问题出在应用层逻辑，比如数据库查询慢，抓包只能告诉你“响应来得晚”，具体为什么晚，还得去看日志和火焰图。但至少，它能帮你排除掉网络这个最大的嫌疑对象。下次遇到“时好时坏”的毛病，别猜，先抓一包看看。