网络排障这件事最怕的不是问题复杂而是你根本不知道数据包长什么样。我见过太多人一遇到连接超时、接口报错、丢包卡顿第一反应就是重启服务、翻日志、猜配置折腾半天没结果。其实只要把 Wireshark 打开抓一段包用对过滤器大部分问题几分钟就能定位到根因。这篇内容就是围绕这个思路展开的不讲大而全的协议理论只聚焦 5 个最常用的过滤器覆盖日常排障中 80% 的场景。不管你是刚接触抓包的新手还是已经用过 Wireshark 但每次都在过滤栏里瞎试的老手都能从这里拿到可以直接抄作业的过滤表达式和排查思路。1. 先搞清楚为什么过滤器才是 Wireshark 的核心战斗力很多人装完 Wireshark点一下网卡就开始抓然后面对满屏花花绿绿的包完全不知道从哪看起。这不是你的问题是方法不对。Wireshark 真正的价值不在于抓到包而在于从海量包里精准捞出你需要的那几个。一个中等流量的办公网10 秒钟就能抓出几万个包没有过滤器你就是在干草堆里找一根特定的针。1.1 抓包过滤和显示过滤别搞混了这是新手最容易踩的第一个坑。Wireshark 有两套过滤机制作用时机和语法完全不同抓包过滤器Capture Filter在抓包之前设置决定哪些包被记录下来。语法用的是 BPFBerkeley Packet Filter语法比如host 192.168.1.100。它的好处是减少抓包文件体积坏处是一旦设错想要的包根本没被记录下来只能重抓。显示过滤器Display Filter在抓完包之后使用决定哪些包被显示出来。语法是 Wireshark 自己的一套表达式比如ip.addr 192.168.1.100。它不会丢数据你随时可以改条件重新筛选。我的建议很明确除非流量特别大或者要长时间抓包否则抓包阶段不要设过滤全抓下来用显示过滤器慢慢分析。原因很简单——你往往在抓包之前并不确定问题出在哪个 IP、哪个协议上提前过滤等于提前假设假设错了就得重来。显示过滤器则可以反复调整试错成本几乎为零。1.2 过滤栏的隐藏技巧自动补全和语法校验Wireshark 的显示过滤栏有两个非常实用的功能很多人不知道第一输入时自动补全。当你在过滤栏敲下ip.的时候它会弹出所有以ip.开头的可用字段你直接上下键选择就行不用死记硬背字段名。第二语法校验。如果表达式写错了过滤栏会变红写对了变绿。这个即时反馈能帮你快速纠正语法错误不用等到回车之后发现没结果才怀疑自己写错了。提示过滤栏变绿不代表逻辑一定对只代表语法合法。比如你写ip.addr 192.168.1.999语法没问题但 IP 不合法Wireshark 可能不会报错但永远筛不出结果。IP 地址、端口号这些值还是要自己确认清楚。1.3 五个过滤器的选择逻辑我挑选这 5 个过滤器的标准很简单覆盖频率高、语法简单、组合灵活。它们分别解决的是按 IP 筛按协议筛按端口筛按连接状态筛按内容特征筛这五类最基础的需求。你不需要记住上百个过滤字段把这 5 个用熟再根据具体场景做简单组合就能应付绝大多数排障任务。2. 过滤器一ip.addr——锁定一台设备的所有通信排障时最常见的起点就是这台机器到底在跟谁通信ip.addr就是回答这个问题的。2.1 基本用法和方向控制# 筛选所有与 192.168.1.100 相关的包无论源还是目的 ip.addr 192.168.1.100 # 只筛源地址是 192.168.1.100 的包 ip.src 192.168.1.100 # 只筛目的地址是 192.168.1.100 的包 ip.dst 192.168.1.100ip.addr是双向匹配等价于ip.src X or ip.dst X。在实际排障中我建议先用ip.addr看全貌确认通信双方之后再用ip.src或ip.dst缩小范围。2.2 实战场景接口超时到底卡在哪一跳假设你有一个服务部署在 10.0.1.50调用方反馈接口经常超时。你的排查步骤可以这样走第一步在调用方或者服务端抓包用ip.addr 10.0.1.50筛出所有相关流量。第二步观察 TCP 三次握手是否正常完成。如果 SYN 发出去了但没有 SYN-ACK 回来说明服务端没响应或者中间网络设备拦了。第三步如果握手正常但请求发出去后长时间没有响应看服务端有没有回 RST 或者干脆没回。第四步如果服务端回了但调用方没收到那问题就在回程链路上。这一套下来你不需要看任何应用日志就能判断问题出在网络层还是应用层。我遇到过好几次运维一口咬定是网络抖动结果抓包一看SYN 到了服务端但服务端压根没回 SYN-ACK最后查出来是服务端 backlog 满了。没有抓包这种问题能扯皮一整天。2.3 多 IP 组合筛选实际场景中经常需要同时关注多台设备# 同时筛选两台机器的流量 ip.addr 10.0.1.50 or ip.addr 10.0.1.51 # 排除某台机器的干扰流量 ip.addr 10.0.1.50 and ip.addr ! 10.0.1.1注意ip.addr ! 10.0.1.1这个写法要小心。它的含义是源或目的地址中至少有一个不是 10.0.1.1而不是完全排除与 10.0.1.1 的通信。如果要完全排除应该用!(ip.addr 10.0.1.1)。这个逻辑差异在复杂过滤中很容易搞错我自己就曾经因为这个写错导致漏看了关键包。3. 过滤器二tcp.port——按服务端口快速定位业务流量知道 IP 之后下一步往往是按端口缩小范围。一台服务器上可能跑着几十个服务你只关心其中某一个。3.1 端口过滤的基本写法# 筛选 8080 端口的所有 TCP 流量 tcp.port 8080 # 只筛目的端口是 8080 的即发往该服务的请求 tcp.dstport 8080 # 只筛源端口是 8080 的即该服务发出的响应 tcp.srcport 8080这里有个细节值得展开说服务端和客户端看到的端口方向是相反的。在服务端抓包时请求的tcp.dstport是 8080但在客户端抓包时请求的tcp.dstport才是 8080响应的tcp.srcport是 8080。所以你在哪一端抓包决定了你应该用dstport还是srcport。搞混了就会筛出空结果然后怀疑人生。3.2 多端口和端口范围# 同时关注多个端口 tcp.port 8080 or tcp.port 9090 or tcp.port 3306 # 端口范围比如 8000-9000 tcp.port 8000 and tcp.port 9000微服务架构下一个请求可能经过网关、多个服务、数据库涉及好几个端口。这时候我通常先用ip.addr锁定调用链上的机器再用tcp.port逐个看每个环节的交互。不要一上来就把所有端口都筛出来那样跟不筛区别不大。3.3 结合 HTTP 协议看请求内容端口筛出来之后如果跑的是 HTTP 服务可以直接叠加协议过滤# 只看 8080 端口上的 HTTP 请求 tcp.port 8080 and http # 只看 HTTP POST 请求 tcp.port 8080 and http.request.method POST # 只看某个 URL 路径 tcp.port 8080 and http.request.uri contains /api/order这套组合拳在排查接口问题时极其好用。比如前端反馈某个接口返回 500你直接http.response.code 500就能把所有报错响应筛出来再顺着 TCP 流往回看请求内容几分钟就能定位到是参数问题还是服务端逻辑问题。4. 过滤器三tcp.flags——从连接状态判断问题性质TCP 标志位是判断连接健康状况的利器。SYN、ACK、FIN、RST 这几个标志位的组合能告诉你连接是正常建立、正常关闭还是被异常中断。4.1 常用标志位过滤表达式# 只看 SYN 包连接请求 tcp.flags.syn 1 and tcp.flags.ack 0 # 只看 RST 包连接被重置 tcp.flags.reset 1 # 只看 FIN 包正常关闭 tcp.flags.fin 1 # 看所有含 SYN 的包包括 SYN-ACK tcp.flags.syn 1RST 包是我在排障中关注最多的。RST 出现的位置和频率往往直接指向问题根因。服务端主动发 RST可能是端口没监听、连接队列满了、或者应用主动拒绝中间设备发 RST可能是防火墙策略、负载均衡超时。区分这两种情况就看 RST 的源 IP 是谁。4.2 实战三次握手失败的三种典型模式我把常见的握手失败归纳成三种模式用tcp.flags配合ip.addr就能快速识别现象过滤表达式可能原因SYN 发出无响应tcp.flags.syn1 and ip.dst目标IP目标不可达、防火墙丢包、服务未监听SYN 后收到 RSTtcp.flags.reset1 and ip.src目标IP端口未监听、连接被拒绝SYN 后收到 SYN-ACK 但客户端不回 ACKtcp.flags.syn1 and tcp.flags.ack1客户端侧问题、回程路由异常这张表我建议你存下来下次遇到连接问题直接对照。我自己的经验是80% 的连不上问题用这三行过滤就能定性剩下的才是深入分析。4.3 连接重置的排查链路当你发现大量 RST 包时排查顺序应该是这样的先确认 RST 是谁发的——用tcp.flags.reset 1筛出来看 Source 列。如果是服务端发的登录服务端检查端口监听状态和连接队列。如果是中间设备发的检查防火墙和负载均衡的超时配置。如果是客户端发的检查客户端是不是主动断开了连接。再确认 RST 出现的时机——是在握手阶段还是数据传输阶段。握手阶段出现 RST基本就是端口或策略问题数据传输阶段出现 RST可能是应用层协议不匹配、超时、或者中间设备干预。最后看 RST 的频率——偶发还是持续。偶发可能是某个特定请求触发的持续则说明是配置或资源问题。5. 过滤器四http——应用层排障的快速通道网络层看完之后如果确认连接没问题问题大概率在应用层。HTTP 过滤器能让你直接跳到业务层面看问题。5.1 按请求方法、状态码、URL 筛选# 只看 GET 请求 http.request.method GET # 只看 4xx 和 5xx 响应 http.response.code 400 # 只看某个域名的请求 http.host contains api.example.com # 只看包含特定关键词的 URL http.request.uri contains login这几个表达式组合起来基本能覆盖接口排障的常见需求。比如用户反馈登录失败你直接http.request.uri contains login把登录请求筛出来看请求参数、响应状态码、响应内容比翻应用日志快得多。5.2 导出 HTTP 对象把抓包变成文件分析Wireshark 有一个非常好用的功能File - Export Objects - HTTP。它能把抓到的所有 HTTP 响应体图片、JSON、HTML、JS 等导出成文件。这个功能在排查文件上传下载问题时特别有用。我遇到过一个案例用户上传 PDF 文件后服务端报解析失败。抓包之后用 Export Objects 把上传的 PDF 导出来发现文件大小比原文件小了 2KB对比之后确认是传输过程中被截断了。这种问题看日志根本看不出来只有把实际传输的内容导出来对比才能发现。5.3 HTTP 过滤的局限性需要提醒的是HTTP 过滤器只对明文 HTTP 有效。如果流量走了 HTTPS你只能看到 TCP 层的交互看不到 HTTP 内容。这时候要么在服务端配置密钥日志SSLKEYLOGFILE让 Wireshark 解密要么就只能退回到 TCP 层分析。关于 HTTPS 解密的具体操作涉及证书和密钥配置这里不展开但你要知道这个边界——不要对着 HTTPS 流量用http过滤器然后纳闷为什么筛不出东西。6. 过滤器五tcp.analysis——Wireshark 自带的专家诊断这是最容易被忽略但价值极高的一个过滤器类别。Wireshark 在抓包过程中会自动分析 TCP 流把发现的异常重传、乱序、重复 ACK、零窗口等标记出来。tcp.analysis就是用来筛选这些标记的。6.1 常用分析标记# 所有 TCP 分析异常 tcp.analysis.flags # 重传包 tcp.analysis.retransmission # 快速重传 tcp.analysis.fast_retransmission # 重复 ACK tcp.analysis.duplicate_ack # 零窗口 tcp.analysis.zero_window # 乱序 tcp.analysis.out_of_order直接输入tcp.analysis.flags就能把所有被标记为异常的包筛出来。这相当于 Wireshark 帮你做了一轮初步诊断你只需要看它标出来的包就行。6.2 重传和乱序说明了什么重传意味着发出的包没有收到 ACK发送方认为丢了重新发了一遍。少量重传是正常的网络本来就有一定丢包率。但如果重传率超过 1%就说明链路质量有问题了。你可以用tcp.analysis.retransmission筛出所有重传包然后看它们的源 IP 和时间分布判断是哪个方向、哪个时间段丢包严重。乱序意味着包到达的顺序和发送顺序不一致。轻微乱序影响不大TCP 会重新排序。但大量乱序会导致接收方频繁发送重复 ACK触发快速重传反而降低传输效率。如果乱序集中在某条链路上可能是多路径路由或者负载均衡导致的。零窗口是最需要警惕的信号。它意味着接收方的缓冲区满了告诉发送方你先别发了。如果频繁出现零窗口说明接收方处理速度跟不上发送速度应用层可能存在性能瓶颈。这时候你需要去看接收方应用的 CPU、内存、线程池状态而不是继续在网络层折腾。6.3 用 tcp.analysis 快速定位慢请求排查接口慢的问题时我的标准流程是这样的先用tcp.analysis.flags看有没有异常标记。如果有大量重传问题在网络链路如果有零窗口问题在接收方处理能力如果什么都没有但就是慢那可能是应用层逻辑耗时需要结合 HTTP 层的请求响应时间来分析。这个流程的好处是先排除网络因素再定位应用因素避免在错误的方向上浪费时间。我见过太多人一遇到慢就怀疑网络抓包一看网络层干干净净最后发现是数据库慢查询。7. 五个过滤器的组合实战一次完整的排障复盘光说不练假把式。我用一个真实场景把这 5 个过滤器串起来你可以跟着这个思路走一遍。7.1 问题描述和初步抓包场景某微服务接口偶发超时调用方设置的超时时间是 3 秒但偶尔会报 timeout。服务端日志显示请求正常处理完成耗时不到 500ms。这种客户端超时但服务端说没问题的情况十有八九是网络层或者中间件的问题。我在调用方机器上抓包抓包过滤器不设直接全抓。7.2 逐步缩小范围第一步用ip.addr 服务端IP筛出所有相关流量。发现请求量不大但确实有几次请求的响应时间明显偏长。第二步用tcp.port 服务端口进一步聚焦。观察这几次慢请求的 TCP 交互发现一个共同特征请求发出后服务端的响应包出现了重传。第三步用tcp.analysis.retransmission筛出所有重传包。发现重传集中在服务端到调用方这个方向而且时间点跟慢请求完全吻合。第四步用tcp.flags检查连接状态。连接没有异常断开也没有 RST说明不是连接层面的问题。第五步用http过滤器看应用层。确认服务端确实在 500ms 内就返回了响应但响应包在网络传输中丢了TCP 重传后才到达导致总耗时超过了 3 秒。7.3 根因和修复问题定位到服务端到调用方之间的网络链路存在偶发丢包。进一步排查发现中间某台交换机的某个端口有 CRC 错误计数增长更换网线后问题消失。这个案例里如果只看服务端日志你永远找不到原因——服务端确实处理得很快。只有通过抓包看到重传才能把问题定位到网络链路上。而整个排查过程用的就是ip.addr、tcp.port、tcp.analysis、tcp.flags、http这五个过滤器。8. 几个容易踩的坑和实操建议最后分享几个我在实际使用中踩过的坑都是文档里不会写的。8.1 抓包位置决定了你能看到什么这是最核心的一条经验在哪个位置抓包决定了你能看到什么层次的流量。在客户端抓看到的是客户端视角在服务端抓看到的是服务端视角在中间设备抓可能看到的是经过 NAT 之后的流量。同一个请求在不同位置抓到的包源 IP、目的 IP、端口都可能不一样。所以排障时优先在离问题最近的两端同时抓包对比两边的包就能判断包是在哪一段丢失或延迟的。只在一端抓很多问题你根本判断不了。8.2 时间显示要调成北京时间Wireshark 默认显示的是相对时间或者 UTC 时间跟你的日志时间对不上排查时会很痛苦。建议在 View - Time Display Format 里选择 Time of Day然后在 Preferences - Appearance - Columns 里把时间列格式调成你习惯的格式。这样抓包时间就能直接跟应用日志时间对齐省去换算的麻烦。8.3 大文件抓包的性能问题长时间抓包会产生巨大的文件Wireshark 打开和过滤都会变慢。我的做法是用dumpcap或者tshark配合环形缓冲区抓包限制单个文件大小和文件数量。比如# 每个文件最大 100MB最多保留 10 个文件 dumpcap -i eth0 -b filesize:102400 -b files:10 -w capture.pcapng这样既能持续抓包又不会把磁盘撑爆。需要分析的时候挑时间点对应的文件打开就行。8.4 过滤表达式要养成保存习惯常用的过滤表达式建议保存成按钮或者书签。Wireshark 的过滤栏旁边有个书签按钮可以把当前表达式存下来下次一键调用。我把自己常用的十几个表达式都存了书签排障时直接点不用每次重新敲。这个习惯能帮你省下大量时间尤其是在紧张的生产排障场景下。8.5 不要忽略 TCP 流追踪功能当你用过滤器筛出某个包之后右键选择 Follow - TCP StreamWireshark 会把整条 TCP 流的所有数据拼在一起展示。这个功能在分析应用层协议时极其好用比一个个包点开看效率高得多。尤其是分析 HTTP、Redis、MySQL 这些文本协议时Follow TCP Stream 能让你直接看到完整的请求响应内容。我在实际排障中的体会是Wireshark 的过滤器体系看起来字段很多很杂但真正高频使用的就那么几个。把ip.addr、tcp.port、tcp.flags、http、tcp.analysis这五个用熟再学会根据场景做简单组合你就能覆盖绝大多数日常排障需求。剩下的那些冷门字段等真正遇到特定场景时再查文档也不迟。关键是要养成遇到问题先抓包的习惯而不是凭经验猜。猜对了是运气抓到了才是本事。