第一次用Wireshark抓包，验心是验心因为宿舍网一到晚上就卡得离谱。路由器重启了三次，验心运营商客服只会说"帮您刷新一下端口"。验心我盯着屏幕上那个绿色的验心鲨鱼鳍图标，心想：行，验心那我自己看。验心

装好之后点开接口列表，验心选了正在用的验心无线网卡，流量像开闸一样涌进列表。验心满屏的验心TCP、TLS、验心ARP，验心密密麻麻。验心我当时的验心反应就俩字：懵了。这玩意儿跟想象中不一样，我以为抓包会直接告诉我"谁在占网速"，结果它只给了我几万行原始数据。

真正让我上手的是一次DNS查询。我在过滤栏敲了 dns，回车。列表瞬间清爽了。我看到自己电脑每隔几秒就向 8.8.8.8 发一次查询，请求的域名是一个我完全不认识的广告追踪地址。那台设备是舍友的旧手机，连了WiFi之后一直在后台跑某个清理软件的推送服务。这就是抓包的意义——它不替你判断，但把证据摆在你面前。

过滤器的语法我踩了不少坑。ip.addr == 192.168.1.5 和 ip.src == 192.168.1.5 是两码事，前者抓双向流量，后者只看发出方向。我一开始分不清，排查一个HTTP请求超时的问题时，只看了源地址，结果响应包全被过滤掉了。后来养成习惯：先抓宽一点，再用 tcp.stream eq 追踪完整会话。Wireshark 的"Follow TCP Stream"功能救过我很多次，它把分散在几十个包里的请求和响应拼成一段可读文本，HTTP头和body一目了然。

有个细节我印象很深。一次调试内部API，客户端一直报"连接被重置"。抓包后发现，服务端在TCP三次握手之后立刻回了RST。展开那个包看TTL值，只有64。而正常响应的TTL是52。这说明RST不是服务端应用层发的，是中间某台设备伪造的。顺着TTL跳数推算，大概是公司出口的防火墙在拦截。拿着这个结论去找运维，对方查了规则，果然是那条新上的安全策略误伤了内网调用。

这件事让我意识到，Wireshark 最值钱的地方不是"看到流量"，而是看到流量的细节——TTL、窗口大小、TCP标志位、时间戳。这些字段平时藏在协议栈里，没人关心。可一旦出问题，它们就是破案的关键线索。比如 tcp.analysis.flags 这个过滤器，能直接筛出重传、乱序、零窗口这些异常包。网络慢的时候，先看有没有大量重传，基本能判断是链路质量问题还是应用层问题。

当然，它也不是万能的。HTTPS流量抓下来，应用层全是加密的，只能看到TLS握手和证书信息。想深入分析内容，得配合SSLKEYLOGFILE或者中间人代理。另外，长时间抓包文件巨大，我一般会限制 Capture Options 里的缓冲区大小，或者用 ring buffer 自动分割。有次忘了设限制，抓了一下午，文件快2个G，Wireshark打开直接卡死。后来学乖了，先想清楚要抓什么，再设过滤条件，别上来就全量捕获。

现在我的习惯是：遇到网络问题，先开Wireshark抓30秒。看ARP有没有冲突，看DNS解析快不快，看TCP握手有没有异常。大多数问题在这一步就能定位个七七八八。它就像给网络做了一次X光，骨头长什么样，哪里裂了，清清楚楚。比起反复重启设备和猜测，这种方式踏实得多。