排查网络问题排查到后半夜的人大概都有过这种体验日志里看不出所以然服务端说没收到请求客户端说超时了中间隔着一堆设备和一层层转发谁也说不清那一瞬间链路上到底跑了什么。这时候能救命的只有一个动作——在正确的位置抓一段包然后用一条准确的过滤表达式把可疑的那几十个包捞出来。Wireshark 抓包过滤命令看着像是一堆记忆题实际上是一套有严格分工的表达式体系捕获阶段用 BPF 粗筛显示阶段用协议字段精筛两套语法各管一段混着用就是各种“我明明写了却过滤不出来”。这篇内容适合三类人看刚接手线上排障、刚开始学抓包的新人能抓到包但每次都要翻半天才找到目标流量的中级选手以及想把排查流程沉淀成脚本、让同事也能一键复现的老手。下面这些表达式和组合基本都是我在真实排障场景里反复用过的不是从手册上抄下来的全集而是按“什么时候该用哪条、为什么这么写、写错了会怎样”这个顺序组织的。1. 捕获过滤器和显示过滤器用错地方等于白抓很多人第一次被过滤表达式坑不是因为语法写错了而是因为写对了语法、放错了位置。Wireshark 里名字里带“filter”的地方至少有三个捕获过滤器、显示过滤器、还有着色规则里的过滤表达式。这三者的执行时机、语法体系、作用范围完全不同用错一个就够你折腾半小时。1.1 执行时机的差别决定了它们能写什么捕获过滤器在数据包进入 Wireshark 之前就生效了它工作在抓包引擎libpcap/npcap那一层用的是 BPF 语法。它只能看到链路层、网络层、传输层的头部字段——换句话说它能理解tcp、udp、port 443、host 10.0.0.5但完全不知道什么是 HTTP 请求方法、什么是 DNS 查询名。你把http.request.method GET填进捕获过滤器Wireshark 会直接给你语法错误因为 BPF 里根本没有这个字段。显示过滤器是数据包已经落盘或者在内存缓冲里之后在分析界面上做的筛选。它用的是 Wireshark 自己那套基于协议字段名的表达式体系能深入到应用层的每一个字段包括http.request.uri、tls.handshake.extensions_server_name、dns.qry.name这种。代价是它不减少抓到的数据量只是让你看不见——磁盘照样被写满CPU 照样在解码。维度捕获过滤器显示过滤器语法体系BPFlibpcap 语法Wireshark 显示过滤语法执行时机抓包前抓包后或抓包中可识别层级链路层到传输层为主全部协议层含应用层字段出错表现提示语法错误无法启动抓包输入框变红不生效对性能的影响显著降低抓包量和丢包率不降低抓包量只影响显示典型写法tcp port 443 and host 10.0.0.5http.response.code 500这个表建议直接记住。判断一条表达式该往哪填只需要问一句这里面有没有出现应用层的字段名有就一定是显示过滤器全是 IP、端口、协议名那两边都能写但优先写进捕获过滤器因为能省资源。1.2 为什么捕获阶段必须“宁粗勿细”有个很常见的误区觉得捕获过滤器写得越精确越好抓到的包越少越干净。这个想法在低流量环境下没毛病在高流量链路上就是灾难的反面——你会发现写得太细反而漏了关键证据。举个具体的例子。某业务系统之间偶发连接超时你判断是 TCP 握手阶段出了问题于是捕获过滤器写tcp port 8443 and host 10.20.30.40。抓了十分钟一个超时的包都没有。为什么因为超时的原因是 DNS 解析卡住了客户端压根没发出 SYN 包链路上一开始跑的是 UDP 53 端口的查询。你的过滤器把 DNS 流量全部挡在门外等于把最关键的证据提前扔掉了。所以捕获过滤器的正确策略是按“可疑范围”而不是“确定目标”来写。确定是这台机器的问题就先只限主机怀疑是某个端口的服务就把这个端口的双向流量都放进来再加一条“不相关协议排除”。比如host 10.20.30.40 and (port 53 or port 8443 or icmp)这样 DNS、业务端口、ICMP 都在视野里量也不算大。提示如果实在拿不准范围第一轮抓包干脆不加捕获过滤器用环形缓冲限制文件大小和数量先抓后筛。宁可多存几个文件也别在第一轮就把可能性掐死。1.3 一个真实的反面案例早些年我参与排查一个接口偶发丢响应的问题同事信誓旦旦说“肯定是服务端没返回”理由是他在客户端侧抓包过滤表达式写的是tcp.srcport 443结果只看到请求包没看到响应的数据包。这条表达式的问题在于响应的源端口是 443但请求的那个包里源端口是客户端的随机高端口。他这条过滤器的语义是“只看从 443 端口发出的包”那么客户端的请求包本身就被排除了而响应包因为源端口是 443 又被保留下来——看起来就像“只有响应没有请求”结论完全反过来。改成tcp.port 443之后双向流量都进来了一眼看到服务端确实回了响应但响应之后客户端回了一个 RST说明是客户端侧的应用层提前把连接关了。一个srcport和port的区别把排查方向带偏了大半天。2. 捕获过滤器BPF 那点语法其实够用了BPF 语法看起来原始但它的表达力覆盖了日常排障的绝大部分需求。真正需要记的只有三类词类型限定符、方向限定符、协议限定符加上逻辑运算符和括号组合起来就够了。别被手册上那几十页吓到常用的其实不到二十种组合。2.1 三类限定符拼出九成表达式类型限定符决定你匹配的是什么host主机、net网段、port端口、portrange端口范围。方向限定符决定方向src、dst不写就是双向。协议限定符限定协议tcp、udp、icmp、arp、ip、ip6。这三类按[协议] [方向] [类型] [值]的顺序拼起来就能覆盖绝大多数需求# 单主机全部流量 host 10.20.30.40 # 指定网段 net 10.20.30.0/24 # 某主机的 443 端口双向 host 10.20.30.40 and tcp port 443 # 只要进入本机 8080 的流量 dst port 8080 and tcp # 排除掉运维通道和本地回环减少噪音 not port 22 and not port 3389 and not host 127.0.0.1 # 端口段常用于服务端一组实例 portrange 8000-8100 # 排除整个网段 not net 10.0.0.0/8括号的优先级要留意。BPF 里and的优先级高于or写host 10.20.30.40 and port 80 or port 443的实际语义是(host 10.20.30.40 and port 80) or port 443后半段的 443 是全量的跟你想要的可能差很远。养成加括号的习惯host 10.20.30.40 and (port 80 or port 443)才是常见意图。2.2 用vlan和pppoe处理带封装的环境在虚拟化或者经过某些接入设备的链路里抓到的包可能带 VLAN 标签。这时候host 10.20.30.40有可能匹配不上因为 BPF 默认按“第一个 IP 头”去偏移VLAN 标签插进来之后偏移量变了。处理办法是在表达式里显式声明封装层级# 抓 VLAN 100 里的指定主机 vlan 100 and host 10.20.30.40 # 双层 VLAN vlan and vlan and host 10.20.30.40 # PPPoE 会话里的流量 pppoes and host 10.20.30.40跑虚拟化环境的时候这个坑踩得特别多。现象是显示过滤器能筛出来包但同一条件写到捕获过滤器就抓不到多数情况下就是链路层多了东西偏移对不上。判断方法很简单先在无过滤的情况下抓几个包看 Packet Details 里 EtherType 是不是 0x8100是的话就加vlan。2.3 抓本机回环和“抓了个寂寞”本地起服务、本地调用流量走的是 loopback 接口。在 Linux 上就是lo在 Windows 上通常没有独立的回环接口Wireshark 会显示成Npcap Loopback Adapter或者Adapter for loopback traffic capture。选了物理网卡去抓回环流量抓到的一定是空的。另外一个更容易被忽略的点抓包位置决定了你能看到什么。在本机抓只能看到本机网卡进出的包在交换机镜像口抓能看到镜像策略覆盖的所有流量在服务端抓看到的是经过负载均衡之后的那一段。同一个请求在三处抓到的内容可能完全不同因为中间设备可能改写了源地址、加了代理头、或者直接做了 TLS 卸载。所以动手之前先问自己三个问题我要看的是哪一段链路这段链路上有哪些设备会改写报文我抓的位置能看到改写前还是改写后这三个问题想清楚了捕获过滤器写起来才有意义。3. 显示过滤器从字段名到组合表达式的进阶路显示过滤器是日常用得最多的一块也是表达式最容易写错的一块。它的核心逻辑很简单拿一个协议字段跟一个值做比较多个条件用逻辑运算符连起来。难点在于字段名要记、比较语义要理解、边界情况要避开。3.1 字段名不用背但得会查Wireshark 提供了很顺手的字段名查询方式在包详情面板里展开某一层点中你想过滤的那个字段状态栏左下角会直接显示对应的过滤字段名。想直接拿来用右键该字段选“作为过滤器应用 → 选中”表达式自动填进过滤框。常用的字段名值得形成肌肉记忆下面这张表是我自己整理的高频字段按用途分组用途字段名说明IP 地址双向ip.addr含源和目的IP 源地址ip.src只匹配源IP 目的地址ip.dst只匹配目的TCP 端口双向tcp.port含源和目的端口TCP 源端口tcp.srcport只匹配源端口TCP 负载长度tcp.len大于 0 表示带数据TCP 标志位tcp.flags.syn、tcp.flags.fin值为 1 或 0帧长度frame.len抓到的整帧字节数帧时间frame.time、frame.time_delta绝对时间和相邻帧间隔HTTP 请求方法http.request.methodGET、POST 等HTTP 响应码http.response.code数值比较HTTP 主机头http.host字符串匹配DNS 查询名dns.qry.name字符串匹配TLS 服务器名tls.handshake.extensions_server_nameSNI 字段TCP 异常分析tcp.analysis.retransmission等需开启分析选项字段名里带不带点、带不带下划线是有讲究的。ip.addr和ip.addr 中间必须有空格写成ip.addr10.0.0.1现代版本也能识别但老版本可能出问题建议统一加空格。3.2!是个陷阱!()才是你想表达的意思这是显示过滤器里最经典的一个坑也是我见过最多人栽跟头的地方。ip.addr ! 10.20.30.40的语义是什么直觉上你以为它表示“排除掉跟这个 IP 有关的流量”。但实际上一个 IP 包同时有源地址和目的地址两个ip.addr值。表达式ip.addr ! 10.20.30.40只要其中一个地址不等于这个值就成立——那么一个“从 10.20.30.40 发出、发往 10.20.30.41”的包它的目的地址不等于 10.20.30.40条件成立这个包照样显示出来。正确的排除写法是取反# 错误依然会显示跟该 IP 相关的包 ip.addr ! 10.20.30.40 # 正确完全排除该 IP !(ip.addr 10.20.30.40) # 同理端口也一样 !(tcp.port 3389)同样的道理适用于http.host、dns.qry.name这类可能在一帧里出现多次的字段。一条过滤表达式如果作用在多值字段上!的行为永远先想清楚再写拿不准就一律用取反包裹。3.3contains、matches和切片操作各有各的适用面精确匹配用模糊包含用contains正则匹配用matches位置取值用切片[]。这四种方式的性能和适用场景差别不小。# 精确匹配性能最好 http.host api.example.com # 包含匹配子串查找不区分大小写 http.host contains example # 正则匹配能力最强但开销明显更大 http.request.uri matches ^/v2/(users|orders)/[0-9] # 取字段的前 N 个字节做比较常用于二进制协议分析 tcp.payload[0:2] 16:03 # 取帧中某一段字节按十六进制比较 frame[54:2] 50:4fmatches用的是类似 PCRE 的语法写复杂正则的时候注意要对特殊字符转义。它的性能开销比contains大一个量级在几十万包的会话里用一个复杂正则界面会明显卡住。日常排障优先用和contains正则留给确实需要模糊结构匹配的场景。切片[]的语法是字段[起始偏移:长度]。上面frame[54:2]的意思是取整个帧从第 54 字节开始的两个字节跟十六进制50:4f比较。这个写法在抓私有二进制协议的时候特别有用——协议没有解码器你只能按偏移去认特征值。3.4 时间、长度这些元数据字段常常比协议字段更好用很多时候你不知道问题出在哪个协议上但你知道“这个请求花了很久才回”。这种情况下按时间过滤比按协议过滤更直接。# 相邻两个包间隔超过 0.5 秒卡顿的嫌疑点 frame.time_delta 0.5 # 从请求发出到响应到达的整体耗时配合会话过滤看更清楚 frame.time_delta_displayed 1 # 绝对时间范围注意时间格式跟本地时区设置有关 frame.time 2024-06-01 10:00:00 and frame.time 2024-06-01 10:05:00 # 大包排查 MTU 和分片问题 frame.len 1400 # TCP 负载大于 0把纯 ACK 全部过滤掉 tcp.len 0 # 只保留带数据的帧看响应体大小分布 http.content_length 100000tcp.len 0这条表达式值得单独说。它把纯粹的 ACK、SYN、FIN 全部挡掉只留下真正携带数据的帧。在排查“响应体很大导致超时”这类问题时先用这条把数据流精简出来再用Follow TCP Stream看完整交互效率高很多。4. 按故障场景组织的过滤表达式速查零散的表达式记不住很正常按场景组织就好记了。下面这几组是我排障时最常直接拿来用的基本覆盖了日常八成的需求。4.1 HTTP 与 TLS从请求特征到证书排查明文 HTTP 的排查相对简单字段都在那儿# 只要 GET 请求 http.request.method GET # 排除掉静态资源只看接口调用 http.request and !(http.request.uri contains .css) and !(http.request.uri contains .js) # 4xx 和 5xx 响应 http.response.code 400 # 特定主机头虚拟主机环境下非常必要 http.host contains api and http.response.code 500 # 请求体很大的 POST http.request.method POST and http.content_length 10000 # 带 Cookie 的请求 http.cookieHTTPS 的排查思路不一样因为内容加密了能看到的基本只有握手过程。这时候关注的重点是 SNI、证书、握手失败原因# 只看 TLS 握手的第一条 Client Hello tls.handshake.type 1 # 按 SNI 定位具体域名 tls.handshake.extensions_server_name contains example # 握手失败的告警 tls.alert_message # 证书相关字段比如签发者和有效期 x509sat.printableString contains Example如果确实需要看 HTTPS 的明文内容标准做法是在客户端侧设置环境变量SSLKEYLOGFILE指向一个文件然后在 Wireshark 的 TLS 协议首选项里把(Pre)-Master-Secret log filename指向同一个文件。这样浏览器或者支持的客户端在握手时会写出会话密钥Wireshark 就能解密。注意这个操作只能在你自己控制的客户端上做对别人的流量、对生产环境里不受你管理的机器都不适用。注意抓包分析涉及的流量可能包含账号、令牌、个人数据。在自己有权限的网络里抓、抓完及时清理、不要把 pcap 文件随手发到公共渠道这三条是底线。4.2 DNS 异常先分清没问出去还是没答回来DNS 问题的排查逻辑很清晰就是看“问出去没有”和“答回来没有”。这两个方向用捕获过滤器分开抓一对比就知道卡在哪一段。# 所有 DNS 流量 dns # 特定域名的查询 dns.qry.name contains example # 只看查询请求 dns.flags.response 0 # 只看响应 dns.flags.response 1 # 解析失败的响应码3 表示 NXDOMAIN dns.flags.rcode 3 # 查询超时无响应的情况看有没有重复查询 dns.qry.name contains example and dns.flags.response 0如果发现同一个查询名在短时间内出现多次且没有对应响应基本可以判断是链路丢包或者上游 DNS 不可达。如果响应很快但 rcode 是 3那就是域名配置本身的问题跟网络无关。这两种情况的处理路径完全不同所以第一步一定是把方向分清楚。4.3 TCP 层异常重传、乱序、零窗口各有各的表达式TCP 的异常分析依赖 Wireshark 内置的分析字段前提是首选项里“分析 TCP 序列号”是开启状态默认开。这些字段不需要你手动算Wireshark 会标出来。异常类型过滤表达式一般指向重传tcp.analysis.retransmission链路丢包或对端未确认快速重传tcp.analysis.fast_retransmission收到重复 ACK 后触发乱序tcp.analysis.out_of_order多路径转发或链路抖动零窗口tcp.analysis.zero_window接收端应用层处理不过来窗口更新tcp.analysis.window_update接收缓冲区释放重复 ACKtcp.analysis.duplicate_ack触发快速重传的前兆连接重置tcp.flags.reset 1对端拒绝或中间设备拦截握手无响应tcp.flags.syn 1 and tcp.flags.ack 0目标端口未开放或防火墙拦截零窗口是特别值得留意的信号。看到tcp.analysis.zero_window频繁出现说明接收方的缓冲区被填满了应用层读得太慢。这时候再怎么优化网络都没用得去看接收端应用的消费速度。这个判断我在好几个“网络慢”的工单里用上过最后查出来都是应用侧某个同步阻塞调用拖住了读取线程。重传的比例也值得算一下。把重传包的数量除以总包数超过百分之二就说明链路质量有问题了。计算方式是先过滤tcp.analysis.retransmission看状态栏的显示包数再清空过滤器看总包数两个数字一除就行。别嫌麻烦这个比例比任何单一指标都更能说明链路健康状况。4.4 其他常见协议ARP、DHCP、ICMP 与 QUIC# ARP 冲突检测看有没有同一个 IP 被两个 MAC 应答 arp.duplicate-address-detected # 只看 ARP 请求 arp.opcode 1 # DHCP 交互全流程 dhcp # DHCP 分配失败的 NAK dhcp.type 6 # ICMP 不可达排查链路 MTU 问题常用 icmp.type 3 # ICMP 超时 icmp.type 11 # QUIC 流量现在越来越多的服务走这个了 quic # 按 SNI 过滤 QUIC字段名跟 TLS 不同 quic.tls.handshake.extensions_server_name contains examplearp.duplicate-address-detected这个字段很多人不知道它能直接告诉你网络上存在 IP 地址冲突不用自己去人工比对。遇到“间歇性连不上某个服务”这种玄学问题先跑一下这条表达式能省掉大量猜测。5. 把常用过滤固化成随手可用的工具链每次排障都手敲一遍表达式效率低而且容易出错。Wireshark 提供了几种把过滤表达式沉淀下来的机制配合命令行工具能形成一套完整的流程。5.1 过滤器按钮和快捷方式界面过滤框右边有个加号可以把当前表达式存成一个按钮。我自己会存这么几个tcp.analysis.flags所有 TCP 异常、http.response.code 400、!(arp or icmp or dns)去掉噪音、tls.handshake.type 1只看 Client Hello、tcp.len 0只看数据帧。按钮的好处是点一下就切换不用切窗口去改表达式。更省事的做法是用Ctrl Shift F打开“管理显示过滤器”对话框把常用表达式一次性录入并命名。命名要有语义比如叫“服务端5xx”比叫“过滤器1”有用得多三个月后回来你还知道它是干嘛的。另外着色规则值得单独配一套。把重传配成红色、零窗口配成橙色、RST 配成紫色扫一眼就能看出哪几行有问题。配置入口在视图菜单的着色规则里规则本身也是过滤表达式逻辑跟显示过滤器一致会写过滤就会写着色。5.2 命令行侧的过滤tshark 和 dumpcap 的分工图形界面适合分析不适合长时间抓包。真正的生产环境抓包基本都用命令行工具因为它们资源占用低、能跑在没图形界面的服务器上、能配合脚本自动化。dumpcap只负责抓不做解码资源占用最小# 按捕获过滤器抓环形缓冲单文件 200MB最多保留 20 个 dumpcap -i eth0 -f host 10.20.30.40 and (port 443 or port 53) \ -b filesize:204800 -b files:20 -w /tmp/cap.pcapng # 按时间切分每 60 秒一个文件 dumpcap -i eth0 -f tcp port 8080 -b duration:60 -w /tmp/cap.pcapng # 列出可用接口确认网卡名字 dumpcap -Dtshark负责解码和过滤可以同时用捕获过滤器和显示过滤器# -f 是捕获过滤器-Y 是显示过滤器两者的语法不能混 tshark -i eth0 -f tcp port 443 -Y tls.handshake.type 1 -c 100 # 读取已有文件并筛选输出指定字段适合做统计分析 tshark -r cap.pcapng -Y http.response.code 500 \ -T fields -e ip.src -e http.host -e http.request.uri # 统计各响应码的数量分布 tshark -r cap.pcapng -Y http.response \ -T fields -e http.response.code | sort | uniq -c | sort -rn # 按会话统计流量找异常大的流 tshark -r cap.pcapng -q -z conv,tcp-T fields -e这个组合是自动化分析的核心。把想要的字段导出来交给sort、uniq、awk处理比在界面上肉眼扫快得多。比如上面统计响应码那条命令几秒钟就能告诉你哪个接口的错误率最高。另外editcap用来做文件裁剪和格式转换大文件打不开的时候特别管用# 按时间范围裁出一个子集 editcap -A 2024-06-01 10:00:00 -B 2024-06-01 10:05:00 in.pcapng out.pcapng # 按包序号切分每 100000 个包一个文件 editcap -c 100000 big.pcapng part.pcapng # 只保留指定协议的包减小文件体积 editcap -F pcapng in.pcapng out.pcapng5.3 抓包丢包这件事得从缓冲区下手高流量链路上最容易遇到的问题不是表达式写错是抓包工具自己丢包了。表现是 Wireshark 界面显示“已丢弃 X 个包”你以为没流量实际上是没抓到。丢包的根本原因是内核到用户态的缓冲区不够。dumpcap 有两个相关参数-B设置抓包缓冲区大小单位 MB-n控制不解析域名和端口名以降低开销。# 加大缓冲区并关闭名字解析显著降低丢包 dumpcap -i eth0 -B 256 -n -f tcp port 443 -w /tmp/cap.pcapng-B的具体数值取决于流量大小。粗略估算是链路带宽Mbps除以 8 得到每秒兆字节数再乘以你希望缓冲的秒数。千兆链路满跑大约 125 MB/s想缓冲两秒就设 256。设太大也不会有什么副作用无非是多占点内存宁可设大一点。还有一点在高流量环境下不要用 Wireshark 图形界面直接抓包。GUI 的实时解码开销很大包一多必然丢。正确姿势是用 dumpcap 抓抓完再用 Wireshark 打开文件分析。这个分工是官方推荐的不是我个人偏好。6. 抓到了却看不明白六个高频翻车点复盘表达式写得再漂亮抓到的包里如果没有你要的信息一样白搭。下面这几个坑我基本每年都会重新踩一次写下来给自己和同行提个醒。6.1 校验和错误不用管那是网卡卸载造成的打开 Wireshark 满屏红黑条纹提示 TCP checksum incorrect很多人第一反应是“链路有问题”。绝大多数情况下这是假的。原因是现代网卡支持校验和卸载checksum offload操作系统把计算校验和的工作交给网卡去做。抓包动作发生在网卡计算之前所以抓到的包校验和字段是空的或者错的。同理发送端看到的超大包超过 MTU 的那种也是网卡的分段卸载TSO/GSO造成的报文在抓到的那一刻还没被切分。判断方法如果所有出方向的包都报校验和错误入方向正常那基本就是卸载问题可以放心忽略。真想在抓包时看到真实的分段和校验和需要临时关闭卸载功能但这会影响系统性能排查完记得开回去。6.2 时间戳的精度和时区会骗人默认的frame.time显示的是本地时区的时间但 pcap 文件里存的是 UTC 时间。如果你在 Wireshark 里看到的请求时间和服务器日志里的时间差了八小时先别怀疑时钟漂移检查一下视图菜单里的时间显示格式设置。时间精度也值得注意。默认可能是秒级显示看起来很多包的时间戳一样实际上是毫秒或者微秒级的差别。把时间显示格式改成“日期和时间含毫秒”或更高精度才能准确判断两个包之间的间隔。判断“到底慢在哪一段”的时候用frame.time_delta比看绝对时间有用得多。它显示的是跟上一个被捕获到的包的时间差在客户端、服务端两处分别抓包对比各自的最大时间差出现在哪个环节就能定位到具体是哪一段链路慢。6.3 服务器上的抓包权限和接口选择在 Linux 服务器上抓包需要 root 权限或者CAP_NET_RAW能力。直接sudo当然可以但更规范的做法是给 dumpcap 加能力sudo setcap cap_net_raw,cap_net_admineip /usr/bin/dumpcap改完之后普通用户也能抓包不用每次都提权。这个操作要在有管理权限的前提下做改完记得确认一下权限设置是否符合所在环境的安全规范。接口选择上要注意容器的场景。如果服务跑在容器里在宿主机上抓看到的是经过网桥 NAT 之后的地址可能跟容器内的地址对不上。这时候要么进到容器的网络命名空间里抓要么在宿主机上按宿主机的地址过滤然后对着 NAT 规则反推。我一般倾向于前者因为看到的地址跟应用日志里的能对应上省去一层翻译。6.4 pcap 文件太大打不开的处理顺序几百兆的 pcap 直接双击打开Wireshark 会卡到你以为死机了。正确的处理顺序是先裁后开先用editcap按时间或者按包数切出一小段或者用tshark -Y筛出关心的流量重定向到新文件再打开新文件分析。如果只是想统计压根不用打开图形界面全程用 tshark 加-z参数做统计就够了。# 先筛选出关心的流量另存文件会小很多 tshark -r big.pcapng -Y tcp.analysis.flags -w suspect.pcapng # 或者直接做统计不生成文件 tshark -r big.pcapng -q -z io,stat,1,tcp.analysis.retransmission最后这条-z io,stat是按秒统计指定过滤条件下的包数用来画重传的时间分布特别直观。哪一秒重传暴增问题就出在那几秒的链路上直接把排查范围从几小时缩到几秒。6.5 显示过滤器和捕获过滤器混用导致的空结果这个前面提过一次但值得再强调因为它的表现太有迷惑性了抓包启动正常文件也在增长但打开之后一条都过滤不出来看起来就像“这个条件真的没有匹配的包”。判断方法很直接清空显示过滤器看看有没有包。有包但一加过滤器就空了说明是过滤条件的问题连包都没有说明是捕获过滤器的问题。两步一测就能分清是哪个环节拦住了。我自己的习惯是在捕获阶段只写最粗的条件主机或者端口把所有的应用层筛选都留给显示过滤器。这样即使一开始判断错了关注点数据还在文件里随时能换个角度重新筛。反过来就麻烦了捕获阶段漏掉的包只能重新抓。6.6 私密信息泄露和文件管理pcap 文件里可能包含 Cookie、Authorization 头、明文密码、个人身份信息。抓完包之后这些东西就落在磁盘上了随手一放很容易出问题。我在实践里会做三件事抓包文件统一放在指定目录并按时间命名方便定期清理对外分享前用tshark检查一遍有没有敏感头部的流量确需分享的话用editcap或者tracewrangler这类工具做脱敏处理。这些动作花不了几分钟但能避免很多麻烦。另外提醒一句抓包这件事本身要在自己负责或者已获授权的网络范围内进行。在自己机器上抓自己的流量、在负责的服务器上抓自己服务的流量这些都没问题对公共网络或者不属于自己管辖的设备做流量分析性质就完全不同了。这个边界心里得有数。我个人的经验是把上面这些表达式和流程整理成一个自己的速查文档遇到新问题就往里补一条半年下来就是一份完全贴合自己业务场景的清单比任何通用手册都好用。真正需要记的不是几十条表达式而是“先分清哪个过滤器、再确定抓的位置、最后按场景选字段”这个判断顺序。顺序对了表达式写错两次也能很快改回来。