做网络排查久了手里没有一套顺手的 Wireshark 抓包过滤命令效率会低得离谱。一份几百兆的抓包文件里面几万个包你要找的是某个客户端到服务端的某一次登录请求或者那几次异常重传。没有过滤器就得靠肉眼一行行翻翻到后面眼睛都是花的。这份 Wireshark 抓包过滤命令大全我按实际排查场景重新梳理了一遍捕获阶段怎么把无关流量挡在门外显示阶段怎么用字段和运算符精确定位TCP 重传、零窗口、HTTP 慢响应、DNS 解析异常这些高频问题分别对应哪几条命令都会给到能直接复制的写法。适合谁看刚接触抓包、只知道ip.addr x.x.x.x的朋友可以把它当语法手册从头过一遍已经能抓包但经常卡在“过滤不出来”“明明有这个包却匹配不到”的同行可以重点看语法陷阱和排查实录那两章。文章里所有命令都是我日常真在用的组合不是从帮助文档里抄下来的字段清单参数为什么这么写、什么情况下会失效我都会一并说清楚。1. 两种过滤器的分工为什么很多人第一步就搞反了1.1 捕获过滤器和显示过滤器到底差在哪Wireshark 里有两套完全独立的过滤语言很多人混着用结果就是写出来的表达式一会儿能生效一会儿报红。捕获过滤器Capture Filter走的是 libpcap 的 BPF 语法它在网卡把数据交给 Wireshark 之前就生效不匹配的包根本不会进内存所以它快、省资源但表达能力有限只能看到链路层、网络层、传输层那点字段看不见 HTTP 的 Host、DNS 的查询名。显示过滤器Display Filter是 Wireshark 自己的语言作用在已经抓下来的包上能深入任意协议字段改一次立刻重算一次但代价是包已经进内存了该占的内存一点没少。我给它们的定位是捕获过滤器负责“别让垃圾进门”显示过滤器负责“在一堆东西里挑出我要的那件”。前者是门卫后者是整理师。搞反的典型症状是一开抓包就全量录抓到几个 G 再回头筛机器卡到鼠标都飘或者反过来在捕获过滤器里写http.host contains apiWireshark 直接给你报语法错因为 BPF 压根不认识这个字段。提示捕获过滤器输入框在抓包选项里显示过滤器输入框在主界面顶部。两处的输入框长得像但语法不通用报红的时候先确认自己写在哪一栏。1.2 为什么我建议“窄捕获 宽显示”实际排查里我的习惯是捕获阶段就收窄但留出足够余量。比如排查某业务接口慢我知道服务端地址和端口就直接写host 10.20.30.40 and tcp port 8443抓下来的文件通常只有几十兆打开秒响应。如果我一时不确定问题出在哪会退一步只按主机过滤把端口放开宁可文件大一点也别把关键包漏掉。这里有个很现实的取舍捕获过滤器漏掉的包事后无法找回只能重抓。而显示过滤器筛错的包改一下表达式就回来了。所以窄捕获的前提是你对问题范围有基本判断。我之前踩过一次坑按tcp port 443抓结果那次故障是 DNS 解析超时导致的连接根本没建起来443 端口一个包都没有白抓了一轮。后来养成习惯不确定的时候捕获过滤器里至少把 DNS 和 ICMP 带上host 10.20.30.40 or (port 53) or icmp多抓几十兆换一个完整的现场非常划算。1.3 过滤器的执行顺序与性能账包进入 Wireshark 的路径是这样的网卡 → 抓包驱动 → BPF 过滤 → 环形缓冲区 → 协议解析 → 显示过滤。BPF 在很靠前的位置所以它省下的是内存和磁盘 IO显示过滤在很靠后的位置省下的只是你的眼睛。这就是为什么抓一个千兆口全量流量机器会直接卡死而加上捕获过滤器之后同样的口也能扛住。再算一笔账一个满载的千兆口按平均包长 700 字节算每秒大约 18 万个包。Wireshark 全量解析这种量级CPU 单核基本吃满界面刷新都跟不上。加上tcp port 8443 and host 10.20.30.40这种过滤条件后实际落到解析环节的可能只剩几百个包每秒差值接近三个数量级。所以别迷信“先全抓后分析”那是在给自己挖坑。1.4 环形缓冲长时间抓包的正确姿势需要挂几个小时甚至过夜抓包的时候别用单个文件硬扛。抓包选项里勾上“使用多个文件”设成每个文件 100MB、保留最近 20 个形成环形缓冲。这样磁盘占用被钉死在 2GB 左右最新的现场永远在旧的自动滚掉。配合捕获过滤器收窄范围一晚上下来能保住完整的故障窗口。我一般还会在显示过滤器里挂一条tcp.analysis.flags !tcp.analysis.window_update实时盯着有没有异常包冒出来不用等抓完再翻。2. 捕获过滤器BPF 语法与原语组合的实战手册2.1 基本原语host、net、port、portrangeBPF 的原语不多但组合起来覆盖绝大多数场景。核心就四类host按 IP 或主机名、net按网段、port按端口、portrange按端口区间。方向修饰符src和dst可以加在前面比如src host 10.20.30.40只抓源地址是它的包。host 10.20.30.40 # 双向源或目的为该地址 src host 10.20.30.40 # 仅源地址 dst net 10.20.30.0/24 # 目的网段 port 443 # 双向端口 src port 53 # 仅源端口 portrange 8000-8080 # 端口区间要注意port 443是双向匹配源端口或目的端口有一个是 443 就算命中。这个设计在抓服务端流量时很方便但如果你只想看客户端发出去的方向必须显式写dst port 443。我见过有人排查“服务端返回慢”用port 443抓完发现里面一半是自己发出去的请求包分析时被干扰得很厉害。组合用and、or、not也支持、||、!。not的优先级比and高写复杂表达式时最好加括号别指望解析器猜你的意图。not port 22 and host 10.20.30.40和not (port 22 and host 10.20.30.40)是两个完全不同的意思前者是“只要不是 22 端口且地址匹配”后者是“排除掉地址和端口同时匹配的那些包”。2.2 按协议和标志位过滤BPF 认识常见协议名直接写tcp、udp、icmp、arp、ip6就行。要更细一层可以访问协议头的字节偏移语法是协议[偏移:长度]。这个能力在抓 TCP 标志位时特别有用tcp[tcpflags] tcp-syn ! 0 # 所有带 SYN 的包 tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn # 纯 SYN不含 SYN-ACK tcp[tcpflags] tcp-rst ! 0 # 所有 RST icmp[icmptype] icmp-echo # 只抓 echo request ip[8] 32 # TTL 小于 32识别异常路径tcp[tcpflags] (tcp-syn|tcp-ack) tcp-syn这一条是我最常用的它能精确挑出连接建立的第一包也就是客户端发起的 SYN把服务端回的 SYN-ACK 排除掉。排查“连接建不起来”时先看有没有 SYN、有没有对应的 SYN-ACK一眼就能定位是客户端没发出去、还是服务端没回、还是回在路上被拦了。注意字节偏移语法跟 IP 头选项和 VLAN 标签关系很大。带 VLAN tag 的帧IP 头并不从第 14 字节开始你在无标签环境验证过的偏移量换到带标签的环境会全部错位。这种场景用ip[8]之类的裸偏移要格外小心。2.3 几个高频场景模板我把日常用得最多的捕获过滤器整理成表直接抄就行。前提是替换掉里面的地址和端口。排查目标捕获过滤器写法说明单业务接口host 10.20.30.40 and tcp port 8443最常用范围可控排除自身远程登录host 10.20.30.40 and not port 22避免把管理流量录进去只看 DNS 异常udp port 53域名解析问题的第一入口只看握手过程tcp[tcpflags] (tcp-syn|tcp-ack) ! 0SYN 和 SYN-ACK 全收跨网段互通性net 10.20.0.0/16 and icmp配合 ping 快速验证端口区间服务host 10.20.30.40 and portrange 9000-9100微服务常见端口段特定网卡广播ether broadcast排查广播风暴写这些表达式时有个小技巧先在显示过滤器里验证逻辑对不对确认筛选结果符合预期再翻译成 BPF 放到捕获栏。因为显示过滤器改起来没成本BPF 写错了会导致该抓的包没抓到返工成本高得多。2.4 捕获过滤器的三个硬伤第一看不见应用层。http、dns这些协议名在 BPF 里能写但语义很粗port 53不等于“DNS 查询失败”它只是端口匹配。第二VLAN 和隧道会打断匹配。带 802.1Q 标签的帧host 10.20.30.40可能匹配不上得写成vlan and host 10.20.30.40如果流量走在隧道里外层地址和内层地址对不上BPF 只能看到外层。第三分片包会漏。IP 分片后只有第一片带传输层头tcp port 8443匹配不到后续分片这在抓大包传输时会表现为“只看到请求没看到响应”。针对第三个问题我的做法是怀疑大包传输异常时捕获阶段只按host过滤不加端口条件把分片全部收进来再在显示过滤器里用ip.frag_offset 0单独看分片。这个组合救过我好几次某次文件上传卡在中途就是靠看分片偏移发现中间某一跳把大包丢了。3. 显示过滤器核心语法字段、运算符与类型陷阱3.1 字段命名规则与比较运算符显示过滤器的基本单位是字段命名规则是“协议.字段”比如ip.src、tcp.window_size、http.request.method。输入的时候 Wireshark 会做自动补全看到下拉列表里出现绿色对勾说明字段名有效出现红色波浪线说明拼错了或者协议没解析出来。这一点很重要字段不存在不等于条件不成立如果某个包根本没被解析成 HTTPhttp.host api对它永远是假不会报错但你也别指望能筛出来。比较运算符有两套写法符号和英文缩写等价运算符缩写用途eq相等!ne不等gt大于lt小于ge大于等于le小于等于contains无字节序列包含matches~正则匹配和eq完全等价我一般用符号敲起来快。contains用于字符串或字节序列的子串匹配matches走 PCRE 正则性能差一些但表达力强适合找特定模式的 URI。注意matches默认大小写不敏感想要区分大小写在模式前加(?-i)。3.2 逻辑运算符、成员运算符与优先级and、or、not是基础三件套缩写、||、!。优先级从高到低是not→and→or跟大多数语言一致但不要依赖记忆复杂表达式一律加括号。ip.addr 10.20.30.40 and tcp.port 443 or dns这种写法实际含义是(A and B) or C如果你本意是A and (B or C)结果会差很远。in是成员运算符用来做集合匹配写法是字段 in {值1, 值2, 值3}。它在做多端口、多状态码筛选时非常省事tcp.port in {80, 443, 8080, 8443} http.response.code in {500, 502, 503, 504} dns.flags.rcode in {2, 3, 5}比连着写四个or清爽得多也不容易漏括号。in后面还可以跟范围tcp.port in {8000..8100}做端口段筛选很方便。3.3 类型陷阱为什么你的条件永远不成立显示过滤器是强类型的字段有整数、地址、字符串、布尔、时间之分类型不匹配时不会报错只会静默返回空结果这是最坑的地方。几个典型tcp.flags.syn是布尔型写tcp.flags.syn 1能工作但更规范的写法是直接tcp.flags.syn 1或用tcp.flags 0x02。而tcp.flags本身是整数tcp.flags 0x02匹配的是“只有 SYN 位被置位”的包SYN-ACK0x12不匹配。这个区别在筛握手包时很关键很多人写tcp.flags 2发现抓不到 SYN-ACK就是这个原因。字符串比较区分大小写。http.request.method get匹配不到任何东西必须写GET。而contains在字符串字段上是大小写敏感的http.host contains api匹配不到API.example.com。想忽略大小写用matches (?i)api或者把条件拆成两种写法用or连起来。IP 地址字段不能用contains。ip.addr contains 10.20是无效的因为地址是结构化类型。要做网段匹配用 CIDR 写法ip.addr 10.20.0.0/16这一条会匹配该网段内所有地址等价于ip.src 10.20.0.0/16 or ip.dst 10.20.0.0/16。掩码写法的可读性比手写范围好太多也少出错。提示显示过滤器里!的行为需要留意。ip.addr ! 10.20.30.40并不是“地址不等于这个值”而是“这个包里存在某个不等于该值的地址字段”。因为一个包同时有源和目的两个地址只要有一个不等于整条就成立。想表达“源和目的都不是”得写ip.src ! x and ip.dst ! x。3.4 常用字段速查字段太多记不住很正常我把高频的整理成一张表贴在显示器边上那种。真正常用的其实就二三十个剩下的是查文档。类别字段含义帧frame.numberframe.lenframe.time_delta序号、长度、与上包间隔IPip.srcip.dstip.ttlip.id地址、生存时间、标识TCPtcp.porttcp.streamtcp.lentcp.seq端口、流编号、载荷长度、序号TCP 分析tcp.analysis.retransmissiontcp.analysis.zero_windowtcp.analysis.ack_rtt重传、零窗口、确认往返时延HTTPhttp.request.methodhttp.hosthttp.response.codehttp.time方法、主机、状态码、耗时DNSdns.qry.namedns.flags.rcodedns.time查询名、响应码、耗时TLStls.handshake.typetls.record.version握手类型、记录版本tcp.stream这个字段值得单独说。它是 Wireshark 给每条 TCP 连接分配的序号同一个连接的所有包共享一个值。找到第一条可疑连接后把它的 stream 号记下来tcp.stream eq 7就能把整条连接的往来全部筛出来配合右键“追踪 TCP 流”看完整会话这是排查应用层问题最快的一条路。4. 分协议命令速查从 IP、TCP 到 HTTP/DNS 的高频组合4.1 地址、端口与排除法最基础的几类我按使用频率排定位某台主机的全部往来、定位某个端口的全部流量、排除掉噪音流量。前两个简单第三个才是真功夫。抓包环境里总有一堆后台心跳、监控上报、时间同步的包在刷屏不过滤掉根本没法看。ip.addr 10.20.30.40 # 双向地址 ip.src 10.20.30.40 and ip.dst 10.20.30.41 # 精确点对点 tcp.port 8443 # 双向端口 tcp.srcport 8443 # 只看服务端发出方向 !(arp or icmp or dns) # 排除三类噪音 !http !tls # 只看非 HTTP/TLS 流量 tcp.port in {80, 443} and ip.addr 10.20.0.0/16最后一条!(arp or icmp or dns)是我最常用的降噪组合。ARP 广播在局域网里刷得飞快ICMP 大多是探测DNS 有周期性缓存刷新。这三类排掉之后界面上剩下的基本都是有业务含义的流量。如果还嫌乱再加一条tcp.len 0把纯 ACK 的空包也去掉剩下的就是真正带数据的请求和响应肉眼可读性立刻提升一个档次。这个组合我在给新人培训时必讲因为它解决的是“抓完不知道从哪看起”的入门痛点比教一百个字段都管用。还有一条容易被忽略frame.len和tcp.len不是一个东西。frame.len是整个帧的字节数含各层头部tcp.len只是 TCP 载荷长度纯 ACK 的tcp.len是 0。想找大包传输用tcp.len 1400想找畸形小包用tcp.len 10 tcp.len 0。4.2 TCP 疑难问题重传、乱序、零窗口TCP 层的问题是抓包分析的主战场Wireshark 内置的 TCP 分析字段能直接把异常标出来前提是你在首选项里开启了“分析 TCP 序列号”默认是开的。常用命令tcp.analysis.retransmission # 重传 tcp.analysis.fast_retransmission # 快速重传 tcp.analysis.out_of_order # 乱序 tcp.analysis.duplicate_ack # 重复 ACK tcp.analysis.zero_window # 接收窗口为零 tcp.analysis.window_full # 窗口满 tcp.analysis.lost_segment # 疑似丢段 tcp.analysis.ack_rtt 0.2 # 确认往返时延超过 200mstcp.analysis.retransmission是最常看的一条但它需要正确解读。偶尔一两次重传在网络里完全正常只有当重传在同一连接里密集出现、并且伴随duplicate_ack和out_of_order同时升高时才说明链路真的有问题。我一般的判断标准是单条连接重传率超过 1%或者连续三轮以上出现同一序号的重传就值得往下查。tcp.analysis.zero_window指向的是接收端处理不过来不是网络丢包。看到零窗口先去看接收端的应用有没有卡住、线程池有没有打满别一上来就怀疑链路。这个误判我见过太多次有人拿着零窗口的截图去找网络组查了两天发现是应用侧数据库查询慢把连接读缓冲占死了。tcp.analysis.ack_rtt反映的是从发出数据到收到确认的时间能粗略代表单向时延加处理时间。我一般用tcp.analysis.ack_rtt 0.2过滤出高时延的交互再结合tcp.stream定位到具体连接。注意这个字段只在有数据交互的包上有值纯 ACK 包上取不到所以筛选结果会比你预期的少这是正常现象。想找连接建立失败的现场用这一组tcp.flags.syn 1 tcp.flags.ack 0 # 客户端发起 tcp.flags.syn 1 tcp.flags.ack 1 # 服务端应答 tcp.flags.reset 1 # 连接被重置 tcp.flags.fin 1 # 正常关闭把 SYN 和 SYN-ACK 分别统计一下数量如果 SYN 有 100 个而 SYN-ACK 只有 60 个说明有 40 次连接没建起来。再拿这些 SYN 的源端口去对 RST 包能区分是服务端主动拒绝还是中间设备拦截。4.3 HTTP 与 TLS应用层定位HTTP 是明文字段丰富筛起来最舒服。最实用的几条http.request.method POST http.request.uri contains /api/login http.host api.example.internal http.response.code 500 http.response.code in {301, 302, 304} http.time 2 # 响应耗时超过 2 秒 http.content_type contains json http.request.full_uri contains tokenhttp.time是个宝藏字段它算的是一次请求从发出到响应完成的时间。http.time 2能直接把慢接口捞出来比在几百条请求里逐条看时间列快得多。我排查接口超时时第一步就是这个命令捞出来之后再按http.host分组看看是不是集中在某个上游。状态码筛选也有讲究http.response.code 500只看服务端错误 400会把客户端错误也带上。做健康巡检时我用http.response.code 400一次性看全量异常做故障定位时用 500减少干扰。TLS 是加密的看不到明文但握手阶段的字段仍然可读。tls.handshake.type 1是 Client Hello 2是 Server Hello 11是 Certificate。握手失败通常表现为 Client Hello 发出后没有 Server Hello 回应或者中途出现 RST。查证书问题用tls.handshake.type 11看证书链有没有带全、有效期对不对。tls.handshake.type 1 # Client Hello tls.handshake.type 2 # Server Hello tls.handshake.type 11 # Certificate tls.alert_message # 告警消息握手失败的信号tls.alert_message出现基本就是握手谈崩了常见原因是协议版本不匹配、加密套件不支持、证书校验失败。把这几个字段连起来看不用解密也能定位大部分 TLS 建连问题。4.4 DNS、DHCP、ARP基础设施层基础设施层的问题往往被忽略但它们造成的影响面最大。DNS 相关的dns.qry.name contains example dns.flags.rcode ! 0 # 非成功响应 dns.flags.rcode 3 # NXDOMAIN域名不存在 dns.time 0.5 # 解析耗时超过 500ms dns.flags.response 0 # 只看查询请求dns.time超过半秒就值得关注正常的递归解析在几十毫秒内完成超过 500ms 通常是上游解析器慢或者网络绕路。dns.flags.rcode ! 0能把所有失败响应捞出来其中 rcode 3 是域名不存在、2 是服务器失败、5 是拒绝含义不同处理方向也不同。DHCP 用dhcp.option.dhcp看消息类型1 是 Discover、3 是 Request、5 是 ACK、6 是 NAK。地址池耗尽时能连续看到 Discover 没有 Offer 回应。ARP 用arp.opcode 1看请求、 2看应答排查 IP 冲突时用arp.duplicate-address-detected这个字段是 Wireshark 内置的冲突检测。dhcp.option.dhcp 1 # Discover dhcp.option.dhcp 5 # ACK arp.opcode 1 # ARP 请求 arp.duplicate-address-detected # 地址冲突4.5 时间相关的筛选技巧时间维度经常被低估。frame.time_delta是当前包与上一个包的间隔frame.time_delta_displayed是与上一个“显示出来的包”的间隔。后者在过滤之后特别有用因为过滤后前者的值还是按原始顺序算的会出现大量无意义的大间隔。frame.time_delta 0.5 # 与上一包间隔超 500ms frame.time_delta_displayed 0.5 # 与上一个显示包间隔超 500ms frame.time 2025-01-15 10:30:00 frame.time 2025-01-15 10:35:00按绝对时间窗口筛选在对接日志时非常好用日志里显示 10:32 报了错把抓包按这个时间窗切出来前后各留两分钟范围一下缩到很小。时间格式必须严格按年-月-日 时:分:秒写格式不对会静默返回空。5. 把命令变成肌肉记忆过滤器宏、快捷按钮与批处理5.1 保存常用过滤器和过滤器宏每天在输入框里重复敲同样的长表达式纯属浪费时间。显示过滤器输入框右侧有个书签图标点开能把当前表达式保存成命名过滤器下次从下拉列表直接选。我把“重传”“零窗口”“5xx”“慢请求”这几条存成了固定项排查时点两下就切换比敲键盘快。更进阶的是显示过滤器宏。在Analyze Display Filter Macros里可以定义带参数的宏语法是$1、$2作为占位符。比如定义一个mytcp宏内容是tcp.port $1之后输入mytcp(8443)就等价于写完整表达式。这个功能适合团队内部共享一套高频表达式统一口径避免每个人写的条件不一样导致结论对不上。保存的过滤器还支持导出导入在Analyze Manage Display Filters里可以整份导出成文件换机器或者给同事配环境时直接导入不用一个个手敲。这个习惯我建议早点养成尤其是有多台分析机的时候。5.2 用 tshark 把过滤做成批处理服务器上没有图形界面或者要处理几十个抓包文件的时候tshark 就派上用场了。它和 Wireshark 共享同一套过滤语法-f对应捕获过滤器-Y对应显示过滤器别写反。# 按捕获过滤器边抓边写抓 60 秒后停止 tshark -i eth0 -f host 10.20.30.40 and tcp port 8443 -a duration:60 -w out.pcap # 读文件按显示过滤器筛选只输出关键字段 tshark -r out.pcap -Y tcp.analysis.retransmission \ -T fields -e frame.number -e ip.src -e ip.dst -e tcp.seq -e tcp.len # 统计 HTTP 状态码分布 tshark -r out.pcap -Y http.response -T fields -e http.response.code | sort | uniq -c # 批量处理目录下所有抓包文件输出慢请求 for f in *.pcap; do echo $f tshark -r $f -Y http.time 2 -T fields -e http.host -e http.request.uri -e http.time done-T fields -e 字段名这个组合是精髓它把抓包变成结构化数据直接进表格或者丢给脚本做聚合。我处理线上故障时经常先用 tshark 把关键字段导成 CSV再用普通的数据处理工具做分组统计比在图形界面里一个个点快得多。再补两个执行顺序上的坑-f必须在-i之后、读包模式下不生效-Y只能在-r或实时抓取后生效且它作用在解析之后所以-f里写应用层字段会直接报错。这两个点我在命令行里踩过不止一次尤其是脚本里参数顺序写错tshark 不报错但结果为空很难发现。5.3 着色规则让异常自己跳出来过滤是“挑出来看”着色是“让它自己显眼”。Wireshark 默认就带了一套着色规则重传是黑色背景、RST 是红色、异常是红色底。但默认规则不够用我一般会自己加几条把tcp.analysis.zero_window标成橙色底、http.response.code 500标成紫红底、dns.flags.rcode ! 0标成黄色底。着色规则在View Coloring Rules里配写法和显示过滤器一样。配好之后不写任何过滤条件扫一眼颜色就能判断这次抓包有没有明显异常。这个习惯的好处是你不需要事先知道要找什么异常会主动撞到你眼睛里。我给团队配了一套统一的着色规则文件大家导出的截图颜色含义一致讨论问题时不用反复解释“这个红色是什么”。注意着色规则是按顺序匹配的排在前面的优先。新建规则时要拖到合适的位置否则会被上面的通用规则遮住配了也不显示。5.4 导出与分享让结论可复现分析完要把结论给别人直接发整个抓包文件既大又不聚焦。用File Export Specified Packets可以只导出当前过滤结果勾上“只导出显示出来的包”几百兆的文件能瘦到几兆。导出时注意把 TCP 流完整保留别只导单向否则对方看不到上下文。配合tcp.stream eq N先定位连接再导出指定包最后在文件里保留原始时间戳。这套流程走下来别人拿到的是一个自包含的最小现场打开就能看到问题不需要你再语音解释十分钟。6. 常见问题与排查实录那些“过滤不出来”的真实原因6.1 语法没错但结果为空这是最高频的困惑。表达式语法正确、绿色对勾也出现了但列表空空如也。按这个顺序排查第一确认抓包里真的有这类流量先把显示过滤器清空用ip.addr x粗筛一下看有没有包第二确认协议解析是否正常看包列表的协议列是不是显示成TCP而不是HTTP——如果端口不是标准端口Wireshark 不会自动识别成 HTTP得手动Decode As第三检查大小写字符串比较是敏感的第四确认字段名拼对了http.request.method和http.request.methods是两个东西。第二点我踩过最多次。某次排查一个跑在 8081 端口的服务http.request怎么都筛不出来包列表里全是裸 TCP。原因是 Wireshark 只对 80、8080 等常见端口自动做 HTTP 解析。右键任意一个包选Decode As把该端口指定为 HTTP立刻就能用 HTTP 字段了。这个操作不改变抓包内容只改变解析方式随手就能做。6.2 tcp.analysis 系列字段不生效tcp.analysis.*这些字段依赖 Wireshark 的 TCP 流分析功能如果抓包是从中间截取的、缺少握手包序列号基线就建立不起来这些字段全部取不到值。表现是明明看到重传了但tcp.analysis.retransmission筛出来是空的。解决办法有两个一是尽量从连接建立开始抓抓到 SYN 包分析就完整二是实在没有握手包可以用tcp.seq手动比对把同一连接的包按序号排序看有没有重复的序号。后者麻烦但可靠我在分析别人给的片段抓包时经常这么干。还有一种情况是乱序被误判成重传。网络里轻微乱序很常见Wireshark 有时会把乱序包标成重传。这时候看tcp.analysis.out_of_order有没有同时出现两者同时存在时优先怀疑乱序而非真丢包。6.3 抓不到包或只抓到单向抓到单向流量八成是抓包位置和网卡模式的问题。在交换机上做镜像如果只镜像了一个方向那自然只有单向。在本机抓如果流量走的是回环接口得选对网卡Windows 上是Npcap Loopback AdapterLinux 上是lo。虚拟化环境里更要注意容器流量可能根本不经宿主机的物理网卡。另一个常见原因是抓包权限不足。Linux 下需要相应权限才能打开网卡权限不够时 Wireshark 会提示没有可用接口而不是报错容易被忽略。这种情况按官方推荐方式配置权限即可别用最粗暴的方式绕过长期用会有隐患。6.4 大文件打开卡死几个 G 的抓包文件打开时卡到无响应这是 IO 和解析的双重压力。我的处理顺序是先用 tshark 在命令行里做粗筛把范围缩到某个 IP 或某条流导出成小文件再用图形界面看。命令行筛几十 G 的文件也就几分钟比硬开图形界面靠谱得多。tshark -r huge.pcap -Y ip.addr 10.20.30.40 and tcp.port 8443 -w small.pcap还有个小设置能救命Edit Preferences Protocols TCP里关掉“相对序列号计算”和“允许子解析器”能显著降低大文件的解析开销。分析阶段用不上这些功能的时候关掉等定位到具体连接再打开。6.5 速查表症状到命令的映射症状首选过滤命令下一步动作连接建不起来tcp.flags.syn 1 tcp.flags.ack 0对比 SYN-ACK 数量找 RST传输慢tcp.analysis.ack_rtt 0.2按 stream 分组看是否集中在某条连接数据重复到达tcp.analysis.retransmission结合duplicate_ack判断丢包位置应用无响应tcp.analysis.zero_window查接收端应用处理能力接口超时http.time 2按 host 聚合找共同上游域名解析失败dns.flags.rcode ! 0看 rcode 值区分不存在与服务器失败地址冲突arp.duplicate-address-detected定位冲突的两个 MAC证书问题tls.alert_message看告警类型判断握手失败原因页面跳转异常http.response.code in {301,302}检查 Location 头是否循环6.6 几条个人经验过滤器写长了容易出错我的习惯是分段验证先写ip.addr x看结果对不对再加and tcp.port y再加时间条件每加一段按一次回车确认数量在减少。一次性写完再调试出错了根本不知道哪一段的问题。另外别过度依赖!。前面说过它在多值字段上的语义反直觉我现在的做法是尽量用正向条件组合实在要排除就用!(...)把整个条件包起来语义清晰得多。!(http.response.code 200)比http.response.code ! 200靠谱前者是“不满足状态码为 200”后者是“存在某个不等于 200 的状态码”在只有单个状态码字段的响应包上两者结果一样但换到地址、端口这种多值字段就天差地别。最后一点把常用的几条命令写成文本文件放在手边比记在脑子里靠谱。我到现在也记不全所有字段名但我知道去哪查、知道大概怎么拼配合自动补全写一条复杂过滤器的速度不比背下来慢。工具的价值在于用对不在于背熟。