Wireshark 网络故障排除完整指南：从入门到精通

Wireshark 网络故障排查抓包实例：过滤出 TCP 重传与重复 ACK
用 tcp.analysis.flags 过滤器一键定位重传与重复 ACK，红色行即异常报文

网络出问题时，最难的不是解决，而是定位。Ping 不通、网页打不开、传文件慢，这些现象背后可能是链路丢包、DNS 故障、TLS 握手失败，也可能是应用层自己超时。靠猜来排查，一轮下来几小时就过去了。

Wireshark 网络故障排除的价值就在于把"看不见"的通信过程变成可逐帧回看的数据。本文不讲界面操作（那部分可以看Wireshark 零基础入门教程），只讲一件事：拿到一个故障现象后，怎么用 Wireshark 在最短时间内定位到根因。

一、排查前的准备：抓包位置决定你能看到什么

很多人一上来就打开 Wireshark 点开始，抓了半天什么异常都没发现——问题往往出在抓包点选错了。

1. 该在哪台机器上抓包

最有效的做法是在通信两端同时抓。只在一端抓，你无法区分"包没发出去"和"发出去但没回来"：

抓包位置能看到看不到的
客户端本机请求是否发出、DNS 是否解析、重传是否发生服务端是否真的收到
服务端本机请求是否到达、程序是否响应响应是否回到客户端
中间网关 / 防火墙包是否被策略丢弃、NAT 转换是否正确两端应用层状态
交换机镜像端口链路真实流量（含被中间设备丢弃前的包）需要额外镜像配置

两端同时抓时，用时间同步很关键。两边系统时间差超过几秒，对照起来会非常痛苦——先确认 NTP 已同步。

2. 捕获过滤器先设好，别等抓完再筛

生产环境全量抓包几分钟就能产生几个 GB 的文件，打开时 Wireshark 会卡到无法操作。开始之前先用 BPF 捕获过滤器缩小范围：

# 只抓与 10.0.0.25 的往来流量
host 10.0.0.25

# 只抓 80 和 443 端口
tcp port 80 or tcp port 443

# 排除 SSH 自己的流量，避免干扰
host 10.0.0.25 and not port 22

# 只抓 SYN 包（用于看连接建立情况）
tcp[tcpflags] & tcp-syn != 0

捕获过滤器用的是 BPF 语法，和显示过滤器不是一套东西，这点在Wireshark 过滤器完全手册里有完整对照。

提醒：在交换机普通端口上，你只能收到广播、组播和发给自己的单播帧。想抓其他主机的流量，必须在交换机上配置端口镜像（SPAN），或者在链路中串入 TAP 设备。这是"抓不到别人包"最常见的原因。

二、五步定位法：从现象到根因

拿到抓包文件后，建议按固定顺序走一遍，避免在大海里捞针。

步骤动作使用的功能想回答的问题
1看整体画像统计 → 协议分级、会话流量构成正常吗？谁在占带宽？
2扫异常分析 → 专家信息（Expert Info）有没有重传、乱序、重置？
3缩范围显示过滤器能不能只看故障相关的那几十个包？
4跟踪流右键 → 追踪流 → TCP 流完整会话里，哪一步开始不对劲？
5定根因时间序列图、往返时间是网络问题，还是应用自己慢？

第 1 步：先看协议分级，建立基线

打开统计 → 协议分级（Protocol Hierarchy），先确认流量构成是否符合预期。如果你在排查一个 Web 服务，结果 TCP 占了 99% 却几乎没有 HTTP/TLS，那要么抓错了接口，要么服务根本没在通信。这一步只要几秒钟，却能避免后面几十分钟的误判。

第 2 步：专家信息是最高性价比的入口

分析 → 专家信息（Expert Information）是 Wireshark 内置的问题汇总，会把重传、乱序、重复 ACK、零窗口、重置等异常按严重程度归类。大多数故障在这一步就能直接看到方向。

看专家信息有个经验：不要被"Note"级别淹没，优先看 Warning 和 Error；同时看数量级——3 次重传可能是正常抖动，300 次就是明确的链路问题。

第 3 步：用过滤器锁定范围

专家信息里点任意一条，Wireshark 会自动跳到对应数据帧。接着右键该包，用对话过滤器（Conversation Filter）把范围缩到这一个会话，剩下的包通常只有几十个，可以逐个看。

第 4 步：追踪 TCP 流看完整对话

追踪流（Follow TCP Stream）把双向数据拼成一段连续文本，是判断"请求有没有发出去、响应有没有回来、谁先断开"的最快方式。看的时候注意三点：请求是否完整、响应状态码是什么、连接是被谁以什么方式关闭的。

第 5 步：区分网络慢还是应用慢

这是最容易被误判的一步。判断依据很简单：看时间戳落在哪里。

用统计 → TCP 流图形 → 时间序列（Stevens）能直观看到数据随时间的位置，一眼区分是网络延迟还是应用延迟。

三、六类高频故障的诊断过滤器

下面这些过滤器建议直接保存成过滤按钮，遇到对应现象时一键调用。

故障现象显示过滤器判读要点
连接超时、无响应tcp.analysis.retransmission大量重传且无 ACK，多为链路丢包或目标不可达
频繁断开tcp.flags.reset == 1谁发的 RST 谁是主动断开方；防火墙常伪装 RST
网速慢、吞吐低tcp.analysis.zero_window接收方处理不过来，问题在接收端不在网络
网页打不开dns.flags.rcode != 0非 0 返回码即解析失败，看是 NXDOMAIN 还是超时
HTTPS 证书告警tls.alert_message展开看具体告警类型，如 unknown_ca、handshake_failure
丢包、乱序tcp.analysis.out_of_order多出现于多路径路由或无线链路

1. 连接超时与无响应

典型特征是客户端反复发 SYN，收不到 SYN-ACK。用 tcp.flags.syn == 1 && tcp.flags.ack == 0 过滤，如果看到同一个 SYN 间隔 1 秒、2 秒、4 秒地重发（指数退避），说明对端完全没有回应——可能是服务未监听、防火墙静默丢包，或路由不通。

2. TCP 重传

重传本身是 TCP 的正常纠错机制，关键看规模。用统计 → 会话（Conversations），在 TCP 标签页勾选"限制显示过滤器"，可以直观看到哪些会话的重传占比最高。持续超过 1% 的重传率，就需要查链路质量了。

3. 连接被重置（RST）

RST 表示连接被立即终止。定位时要注意：发 RST 的一方不一定是故障源。中间防火墙、负载均衡器也会发 RST。结合 IP 的 TTL 值可以辅助判断——如果 RST 包的 TTL 与其他包的规律明显不同，很可能来自中间设备而非真正的通信端。

4. DNS 问题

DNS 故障常被误判为"网络慢"。用 dns 过滤后看两件事：查询有没有响应，以及响应时间。Wireshark 会把超过阈值的 DNS 查询标记为响应过慢。如果看到大量相同域名的重复查询且无响应，多半是 DNS 服务器配置错误或不可达。

5. TLS 握手失败

HTTPS 问题优先看 Client Hello 之后发生了什么。常见情况：服务端直接回 RST（端口未开或 SNI 被拦截）、返回 Alert（证书或协议版本不匹配）、握手完成后立刻被关闭（应用层策略）。用 tls.handshake.type == 1 找到 Client Hello，再追踪流看完整过程。

6. 吞吐量上不去

这类问题看窗口。tcp.analysis.zero_window 说明接收方缓冲区满，是接收端性能问题；tcp.analysis.window_full 说明发送方被窗口限制，同样指向接收端。如果是长肥管道（高带宽 × 高延迟），还要检查是否启用了窗口缩放（Window Scaling）——三次握手里的 WS 选项。

四、三个真实排障案例

案例一：内网 OA 系统间歇性打不开

现象是每天上午 9 点左右，部分同事访问 OA 会卡住十几秒。在客户端抓包后发现：TCP 三次握手正常，HTTP 请求发出后约 15 秒才收到响应。追踪流看到服务端返回的是完整页面，说明服务端处理慢，不是网络问题。进一步定位到 OA 在那个时间段有定时任务占满数据库 CPU。结论：网络无责，问题在服务端负载。

案例二：上传大文件到对象存储速度上不去

带宽 100 Mbps，实际上传只有 5 Mbps。抓包后统计发现重传率接近 8%，且大量 tcp.analysis.duplicate_ack。追踪时间序列图，看到数据包呈阶梯状、中间有明显空档——典型的链路丢包特征。最后查出是出口链路某个光模块衰耗超标，更换后恢复到 90 Mbps 以上。

案例三：HTTPS 站点部分区域用户打不开

现象是只有某运营商的用户反馈打不开。抓包看到 TLS 握手停在 Client Hello，随后收到 RST。对比正常用户的包，发现被拒绝的 Client Hello 里 SNI 字段被中间设备篡改。最终确认是该运营商的 DNS 劫持导致解析到了错误的 IP。这类问题只有在客户端侧抓包才能看到，服务端抓包一切正常。

五、提高效率的配置习惯

建议修改的首选项

值得添加的自定义列

在编辑 → 首选项 → 列里加几列，能省掉大量点开数据包的操作：

长时间抓包用 tshark

需要抓几个小时甚至几天时，图形界面不合适，用命令行版本 tshark 配合环形缓冲：

tshark -i eth0 -f "host 10.0.0.25" \
  -b filesize:100000 -b files:20 \
  -w /var/capture/oa.pcapng

上面命令每 100 MB 切一个文件、最多保留 20 个，超出自动覆盖最旧的。抓完再用 Wireshark 逐个分析。

常见问题

Wireshark 抓不到包怎么办？
先确认三件事：抓包用的是不是流量真正经过的那块网卡；交换机环境下目标流量是否被镜像到你的端口；Windows 上是否以管理员身份运行。如果接口列表里根本看不到网卡，多为 Npcap 未正确安装。
为什么抓到的包看不到自己的请求？
多数是因为抓错了网卡，或者开了混杂模式但流量其实不走这台机器。在交换网络中，普通端口只能收到广播、组播和发给自己的单播帧，要看别人的流量必须做端口镜像（SPAN）或用 TAP 设备。
TCP 重传一定是网络问题吗？
不一定。少量重传（低于 0.1%）在无线、跨运营商链路中属于正常现象。真正要关注的是成片的重传、超时重传（RTO）和 Dup ACK 引发的快速重传，这些才指向丢包或链路质量劣化。
抓包文件大小怎么控制？
用捕获选项里的多文件环形缓冲：设置每文件 100 MB、最多 20 个文件，超出后自动覆盖最旧的。长时间抓包务必开启，否则单个文件几个 GB 后 Wireshark 打开会非常慢甚至卡死。
生产环境抓包有风险吗？
有。高流量接口上全量抓包会占用大量磁盘和 CPU；抓取的明文流量可能包含敏感信息，保存和转发前要做脱敏。建议先加捕获过滤器只抓目标 IP 或端口，把影响降到最低。

写在最后

故障排查能力的差距，不在于记住多少过滤器，而在于有没有稳定的排查路径。把上面五步固化成习惯——先看画像、再扫异常、缩范围、追流、定位置——大部分网络问题都能在十分钟内给出方向，而不是反复重启设备碰运气。

如果需要系统梳理过滤器语法，可以看Wireshark 过滤器完全手册；刚接触这个工具的读者建议先从零基础入门教程开始。更多中文教程资源请访问Wireshark 中文站。