Wireshark 网络抓包实战：从抓包过滤到故障定位

排查网络问题时，应用层日志往往只能告诉你「请求失败了」，却说不清失败发生在哪一层。Wireshark 抓包能直接把网卡上收发的数据包完整还原成可视化的协议树，让你看到 TCP 三次握手、HTTP 请求、TLS 握手的全过程。本文从抓包过滤器的正确用法讲起，用三个真实场景带你掌握 Wireshark 的故障定位方法，把「网络有问题」变成可复现、可解释的证据链。

为什么需要 Wireshark：它能看到别人看不到的东西

很多网络故障藏在协议栈的底层：连接被 RST 掉、TLS 握手卡在 Certificate 阶段、HTTP 响应被悄无声息地截断。这些现象在应用日志里通常只表现为一个笼统的超时或连接异常。Wireshark 工作在网卡抓包层面，对应用无侵入，因此能还原最原始的交互时序。它和 Whistle 这类 HTTP 代理抓包 互补：Whistle 只能看到 HTTP/HTTPS 应用层，而 Wireshark 能看穿 TCP、DNS、TLS、ARP 全协议栈，是定位「到底哪一环断了」的终极手段。

更关键的是，Wireshark 把「感觉网络卡」变成了可量化的证据：你能直接读出每一个请求从发出到收到响应的耗时、看到重传发生在哪一个包、确认证书在哪一步被拒绝。这种确定性对和运维、网络、云厂商三方扯皮时尤其重要——与其说「好像不通」，不如甩出一段抓包说「SYN 发了三次都没回包，问题不在我们应用」。它的学习曲线并不陡峭，只要先记住「抓包过滤器收敛范围、显示过滤器定位异常、协议树还原时序」这条主线，就能解决八成以上的线上网络问题。

安装与三种抓包入口

桌面端直接用 Wireshark GUI 即可；在服务器上更常用命令行三件套：tshark（Wireshark 的 CLI）、dumpcap（纯抓包引擎）、tcpdump（兼容格式）。生产机通常无 GUI，用 tshark 抓成 pcap 再下载到本地用 GUI 分析是标准姿势。

# 列出可用网卡
tshark -D

# 在 eth0 上抓 1000 个包，按时间写到文件
tshark -i eth0 -c 1000 -w capture.pcap

# 边抓边用显示过滤器实时看 HTTP 请求
tshark -i eth0 -Y "http.request" -T fields -e ip.src -e http.host -e http.request.uri

# 只抓某 IP 的流量并限制大小（防止磁盘打满，参考磁盘 I/O 雪崩排查思路）
dumpcap -i eth0 -f "host 10.0.0.5" -b filesize:10240 -b files:5 -w /tmp/app.pcap

抓包过滤器 vs 显示过滤器：最容易混淆的点

两者名字像、作用完全不同。抓包过滤器（Capture Filter）在抓包之前就决定要不要留下这个包，语法来自 libpcap，写在开始抓包时；显示过滤器（Display Filter）在抓包之后对已有结果做筛选，语法是 Wireshark 自家的。把显示过滤器语法填到抓包过滤器里会直接报错。

# 抓包过滤器：只采目标主机与 443 端口（开始抓包时填写）
host 10.0.0.5 and port 443

# 显示过滤器：抓完后按需筛选
ip.addr == 10.0.0.5 && tcp.port == 443
tcp.flags.syn == 1 && tcp.flags.ack == 0
http.response.code >= 400

实战一：TCP 连接失败与重传定位

服务连不上时，先确认 TCP 层面是否握手成功。用 tcp.analysis 一组专家信息过滤器，Wireshark 会自动标出异常：SYN 重传说明对端没回包（可能被防火墙丢弃或端口未监听），RST 说明对端主动拒绝，Duplicate ACK 与 Retransmission 则说明链路存在丢包或拥塞。

# 只看建连相关
tcp.flags.syn == 1 || tcp.flags.reset == 1

# 所有重传与乱序（性能与丢包信号）
tcp.analysis.retransmission || tcp.analysis.duplicate_ack || tcp.analysis.out_of_order

# 计算某连接的往返时延分布
tcp.analysis.ack_rtt && ip.addr == 10.0.0.5

看到连续 SYN 重传但无 SYN-ACK，优先排查对端服务是否监听、安全组/iptables 是否放行；看到 RST 且带 tcp.flags.reset == 1，多半是端口无进程或连接被中间设备掐断。这类问题往往和 Nginx 反向代理的负载均衡配置 或后端端口未起有关。

重传还分「尾包重传」和「快速重传」：前者通常意味着链路丢包或带宽打满，后者说明接收方连续收到失序包、触发了快速重传机制。如果同时出现 TCP Zero Window，说明对端应用消费太慢、接收缓冲区被占满，连接被迫停顿——这往往是后端线程池耗尽或 GC 停顿的信号，而非网络本身的问题。把 RTT（往返时延）列出来看分布，比单看平均值更能发现问题：偶尔一个 800ms 的尖刺，可能就是那次用户感知到的「卡了一下」。

实战二：HTTP 接口变慢与 4xx/5xx 排查

接口偶发 502/504，应用日志却查无罪名，多半是网关与后端之间的链路问题。Nginx 502/504 排查实录 里强调过超时与连接池，而用 Wireshark 可以直接在包上看到：请求是否到达后端、后端多久才回、回的是 FIN 还是完整响应。配合 HTTP 显示过滤器，能快速锁定是哪个接口、哪次调用超时。

# 只看 HTTP 请求与响应
http.request || http.response

# 找出所有非 2xx 的响应
http.response.code >= 400

# 看某个域名的完整请求 URI 与时间
http.request.uri contains "/api/" && http.host == "api.example.com"

若请求已发出但响应迟迟不来，看响应方向的 TCP 是否有重传或零窗口（Zero Window，对端处理不过来）；若响应是 502，通常抓不到后端回包，说明连接在被代理层拒绝。把抓包时间轴和 Nginx 错误日志时间对齐，基本就能坐实根因。

实战三：TLS 握手失败与证书问题

HTTPS 站点突然连不上，常见原因是证书过期、域名不匹配或握手算法协商失败。Wireshark 可以解密 TLS（需配置密钥日志），即使不解密，也能从握手阶段的 Client Hello / Server Hello / Certificate 看出卡在哪一步。这与 Whistle 的 HTTPS 调试 思路一致，但 Wireshark 能下探到握手包本身。

# 只看 TLS 握手
tls.handshake

# 握手类型：1=Client Hello, 2=Server Hello, 11=Certificate, 16=Client Key Exchange
tls.handshake.type == 1 || tls.handshake.type == 11

# 解密后查看应用数据（需预先设置 SSLKEYLOGFILE）
tls.app_data

抓到 Client Hello 却没 Server Hello，多半是对端 443 端口未通或防火墙拦截；有 Certificate 但浏览器报不安全，则是证书链或 CN/SAN 不匹配。把证书的 Not After 时间与故障发生时间对照，过期问题一目了然。

常用显示过滤器速查表

抓包文件保存、回放与 CI 集成

抓到的 pcap 可以用 -r 回放分析，也可以提交到仓库做回归比对。在 GitHub Actions 流水线 里加入网络连通性抓包步骤，能在测试环境自动留存故障证据；把关键链路的延迟指标导出给 Prometheus + Grafana 监控面板，则能把「偶发网络抖动」变成可观测的长期曲线。

# 回放分析已抓文件，统计各 HTTP 响应码
tshark -r capture.pcap -Y "http.response" -T fields -e http.response.code | sort | uniq -c

# CI 中临时抓包：测试前后各抓一段，产物上传为 artifact
tshark -i eth0 -f "host api.example.com" -a duration:30 -w ci-trace.pcap

五个高频坑与处置

小结：把网络问题变成证据

Wireshark 不是「看了就会」的工具，而是「带着问题去验证」的工具。记住三步：先用抓包过滤器收敛范围，再用显示过滤器定位异常包，最后用协议树还原时序。当你能指着某一个 RST 或某一次重传说出「就是这里断了」，网络故障就从玄学变成了工程问题。