企业官网建设流程全解析

先说个场景。你接手一个线上问题，客户反馈页面打不开、接口超时，你打开Wireshark抓了一把包，结果满屏都是密密麻麻的帧，几百个连接混在一起，根本不知道从哪看起。这时候你心里想的不是“Wireshark真强大”，而是“这工具到底怎么让我快速找到想要的那条流”。答案就是过滤器。过滤器这玩意，说白了就是把一堆杂乱的网络流量按照你的意图筛出来，让你只看到该看的。我用了Wireshark快十年，从最早抓包全靠肉眼翻，到现在闭着眼能写出组合过滤条件，最大的体会就是：过滤器的熟练程度，直接决定你排查网络问题的效率。

这篇就把我日常用得最多的9类Wireshark过滤器全部拆开讲一遍，从零基础到进阶全都有。不管你是刚接触抓包的新手，还是已经被各种协议字段搞到头大的老油条，只要照着这篇的思路走一遍，至少能解决日常90%的过滤需求。适合谁看？运维、开发、网络工程师、测试，以及所有需要跟数据包打交道的人。

1. Wireshark有两套过滤器，先别搞混

很多人一开始就栽在“过滤器”这三个字上，因为Wireshark里其实有捕获过滤器和显示过滤器两种，完全是两套东西，语法不同、作用时机也不同。如果不先分清这两者，后面的九类技巧你学起来大概率会乱。

1.1 捕获过滤器：抓包前就已经在过滤

捕获过滤器是在抓包开始之前就设置的，它只保留符合条件的数据包，不符合的包根本不会被网卡捕获进来。它的语法是BPF（Berkeley Packet Filter）语法，跟tcpdump的写法基本一样，写的是“允许什么流量进入抓包结果”。

比如你只想抓和192.168.1.1这台主机相关的流量，就用：

host 192.168.1.1

或者只想抓80端口的TCP流量：

tcp port 80

这个入口在Wireshark主界面的Capture Options里，也可以点抓包旁边的齿轮图标进去设置。有个很容易被忽略的细节：捕获过滤器的语法错误不会弹窗提示，它会在你点击开始抓包后直接报“Invalid capture filter”，有些版本甚至静默失败。所以我一直的建议是，能用显示过滤就别用捕获过滤，除非你确实要抓超大流量、怕文件膨胀才考虑它。

1.2 显示过滤器：抓包完成后再过滤

显示过滤器是抓包完成后、在包列表上方的过滤栏里输入的条件，它不会改变已抓到的数据包，只是在界面层面把不符合条件的包“藏”起来。这个语法才是Wireshark真正好用的地方，非常丰富，支持字段、协议、比较运算、逻辑组合，甚至正则。

比如你要看所有HTTP请求：

http

看IP是192.168.1.1的包：

ip.addr == 192.168.1.1

看端口是443的TCP包：

tcp.port == 443

显示过滤器是这篇文章绝对的主角，后面要讲的九类过滤器，讲的都是显示过滤器。

1.3 为什么我几乎只用显示过滤器

这里说点我自己的习惯。我日常排障，绝大多数场景都是“先全量抓，再慢慢筛”，因为网络问题有个特点——你永远不知道问题藏在哪一层。比如一个web访问很慢，可能是TCP重传多，可能是DNS解析慢，也可能是HTTP响应体过大，如果你抓包前就用捕获过滤器只留80端口，那DNS问题就被你亲手过滤掉了。先全抓、再显示过滤，等于保留了完整的现场，随时可以换一个角度重新排查。只有一种情况我会用捕获过滤器：流量实在太大，比如每秒几万包，全抓下来磁盘扛不住，这时候才在源头就先切一刀。

2. 第1类：IP地址过滤器，定位主机最快的方式

IP地址过滤是使用频率最高的一类，你想看某个服务器、某个客户端的所有流量，它就是第一道筛选。

2.1 最常用的三个关键字

• ip.addr：不管源地址还是目的地址，只要等于你填的IP就显示
• ip.src：只看源地址
• ip.dst：只看目的地址

ip.addr == 192.168.1.10 ip.src == 192.168.1.10 ip.dst == 192.168.1.10

ip.addr最常用，因为很多时候你只关心“跟这台机器有关的流量”，至于是它发的还是发给它的，后面再细看。如果你要区分上下行方向，再用ip.src和ip.dst。

2.2 网段过滤

一个IP太窄了，有时候你想看整个子网的流量，比如排查办公室一个网段里的广播风暴，或者看某个VLAN里所有主机的流量：

ip.addr == 192.168.1.0/24

这里有个坑，有些朋友会写成：

ip.addr == 192.168.1.0 && ip.addr == 255.255.255.0

这是错的，完全不对。Wireshark里直接支持CIDR写法，ip.addr == 192.168.1.0/24就表示整个192.168.1.x网段。如果是IPv6环境，写法一样，比如ipv6.addr == fe80::/16。

2.3 IP加端口组合

排查问题时IP和端口几乎总是绑在一起出现的。比如你怀疑某个客户端访问某台服务器的HTTPS服务异常，最简单直接的写法：

ip.addr == 192.168.1.100 && tcp.port == 443

如果这两个IP之间有很多业务流量，你还想精确到某一个Web服务的连接，就再加上HTTP层过滤：

ip.addr == 192.168.1.100 && http

这一条基本能帮你从海量数据包里锁到一个目标服务。

2.4 容易忽略的广播和组播地址

接口上总有一些广播流量，比如ARP请求、NetBIOS、mDNS之类，如果你在抓包结果里经常看到一堆224.0.0.x或者255.255.255.255，不用慌，这不是什么异常攻击，很多是正常的发现协议。过滤的时候想排除它们，可以在过滤条件里加个排除：

ip.addr != 224.0.0.0/4 && ip.addr != 255.255.255.255

不过这里要特别提醒：ip.addr != xxx这个写法在Wireshark里有隐藏的坑，它实际上是“存在一个不等于xxx的IP地址字段”就显示，而一个数据包通常有src和dst两个地址字段，所以结果往往和你预期不一样。更稳妥的做法是：

!(ip.addr == 224.0.0.0/4) && !(ip.addr == 255.255.255.255)

新手很容易在这里栽跟头，判断“不等于”的时候要注意括号和取反的用法，后面讲逻辑运算符的时候再详细说。

3. 第2类：端口过滤器，锁住每一个服务

IP过滤解决的是“谁和谁”的问题，端口过滤解决的是“哪个服务”的问题。一个IP上可能跑了Web、数据库、SSH各种服务，你要想看HTTP，就把80、8080、443这些端口捞出来。

3.1 基础三件套

• tcp.port == 80：只要TCP层端口是80就显示，不管源还是目的
• tcp.srcport == 80：只看源端口
• tcp.dstport == 80：只看目的端口

同样，UDP就是udp.port、udp.srcport、udp.dstport。

很多情况下，服务器端的端口是固定的，但客户端的端口是随机的，所以如果你想看“所有发往某台服务器80端口的请求”，用tcp.dstport == 80更精确；如果你想看“所有从服务器80端口返回的数据”，就用tcp.srcport == 80。做接口联调时我经常要区分这两个方向。

3.2 多端口组合

服务可能不只跑一个端口，比如HTTP跑在80和8080，HTTPS跑在443，可以这样写：

tcp.port == 80 || tcp.port == 8080 || tcp.port == 443

当然你也可以用tcp.port in {80, 443, 8080}这种集合写法，更简洁：

tcp.port in {80, 443, 8080}

这个语法挺实用，尤其在配置了好多端口的场景下，不用写一串长长的或运算。

3.3 端口范围和大小比较

Wireshark的显示过滤器支持比较运算，端口也一样。比如你想看所有高端口流量（通常客户端随机端口范围在1024以上），可以写：

tcp.port > 1024

想做范围限制也可以：

tcp.port >= 1024 && tcp.port <= 65535

这种写法平时用得不那么多，但在分析端口扫描或者临时服务时很管用。

注意：UDP和TCP都有端口，但两者是独立的。你在过滤栏写port 80的意思是“TCP的80端口或UDP的80端口”，而tcp.port == 80只匹配TCP。做精确过滤时，我建议用带协议的写法，避免UDP和TCP混在一起。

4. 第3类：协议过滤器与第4类：字段级过滤

端口过滤能锁住服务，但还不能区分这个数据包是握手包、数据包还是断开包。这时候就要上到协议层和字段级的过滤。这两类放在一起讲，因为它们本质上是一回事：先选协议，再选字段，最终定位到某个具体行为。

4.1 直接按协议名过滤

最简单粗暴的方式，直接在过滤栏里输入协议名。比如只看ARP、DNS、HTTP、HTTPS、TCP、UDP、ICMP：

arp dns http tls tcp udp icmp

这个方法的妙处在于它可以和IP、端口自由组合。比如看某个IP的所有ICMP包（排查网络通不通的最常见操作）：

ip.addr == 10.0.0.1 && icmp

如果只想看ARP里的某个主机，就加上arp.src.proto_ipv4这种字段（Wireshark会自动补全字段名，你输入arp后点下拉列表能看到所有可选字段）。

4.2 常见的字段级过滤

协议名过滤是粗筛，字段级过滤才是精细活。我平时用得最多的字段过滤器有这么几个。

HTTP相关：

http.request.method == "GET" http.request.method == "POST" http.host == "www.example.com" http.response.code == 200 http.response.code >= 400

DNS相关：

dns.flags.response == 1 dns.qry.name == "example.com" dns.qry.type == 1 // A记录查询 dns.qry.type == 28 // AAAA记录查询

TCP相关：

tcp.flags.syn == 1 tcp.flags.ack == 1 tcp.window_size == 0 tcp.analysis.retransmission

举个实际例子。某天有同事说“某个域名解析很慢”，我抓包后用下面这条过滤条件：

dns.qry.name contains "slowdomain"

结果一眼看到一串DNS查询，每次间隔好几秒，说明客户端在超时重查，问题定位到DNS服务器响应慢，跟链路无关。这就是字段级过滤的威力——直接看向具体哪个域名、哪个记录类型。

4.3 关于大小写和字段名

新手最容易吐槽的就是Wireshark字段名记不住，其实完全不需要硬记。你在过滤栏输入时，Wireshark会有自动补全和提示，比如你输入http.它会列出所有以http.开头的字段，直接点选就行。另外一个技巧：在包详情面板里右键某个字段，选择“作为过滤器应用”，它会自动帮你生成准确的过滤表达式，这就是做可视化筛选最快的方式，后面专门讲。

5. 第5类：TCP标志位与状态过滤，看懂连接的一生

TCP三次握手、四次挥手、重传、零窗口，这些状态全靠标志位来表示。排查网络质量问题时，只看TCP状态就能发现很多端倪。

5.1 抓住SYN和ACK

看一个TCP连接是怎么建立的，用SYN和ACK来筛：

tcp.flags.syn == 1 && tcp.flags.ack == 0

这是纯SYN包，也就是连接发起方发出的第一个握手包。

tcp.flags.syn == 1 && tcp.flags.ack == 1

这是SYN+ACK包，是服务端对SYN的回应。这两条一组合，你就能很清楚看到一次握手的起止。

判断是客户端还是服务端发起的连接，最直接的办法就是先看SYN包，它的源IP就是主动发起连接的一方。

5.2 重传与乱序

TCP的重传是排查网络丢包的“铁证”。在Wireshark里，不需要手动对比序列号，直接过滤：

tcp.analysis.retransmission

所有被判定为重传的包会立刻高亮出来。如果重传的包很多，说明链路有一定丢包；如果重传集中在一个IP对之间，可能是某一段网络质量问题；如果重传是乱序的、反复的，那就要进一步看是不是设备性能问题。

此外还有：

tcp.analysis.duplicate_ack tcp.analysis.zero_window

前者表示重复确认，通常和乱序或丢包相关；后者表示接收方窗口为0，意思是接收方处理不过来了，常见于应用层阻塞、Java GC停顿之类。这些都是网络排查里非常典型的“红灯”信号。

5.3 按TCP流过滤

如果已经找到了一条感兴趣的TCP连接，想看整条流的所有包，右键某个包，选择“Follow TCP Stream”，Wireshark会帮你把这条流里的所有包单独列出来。注意这是临时行为，不会改变下层其他过滤条件，而且如果你想从这条流里再继续深挖，可以把这个“Follow”的过滤表达式复制出来。它的内部表达式一般是：

tcp.stream eq 0

你也可以直接手写，比如tcp.stream eq 5就看第5条TCP流。这个方法在做HTTP排障时特别方便，直接看一个请求-响应对的完整生命周期。

6. 第6类：字符串与内容检索，在包体里大海捞针

有些问题光看头部字段解决不了，比如你怀疑某个API返回的报文里出现了某个异常关键词，或者想知道有没有某个SQL语句传到数据库，这时候就要在数据包的应用层内容里做匹配。

6.1 contains：简单子串匹配

contains用来判断某个字段中是否包含指定字符串。最常用于HTTP、Modbus、MySQL这类明文协议。

比如我想看所有HTTP请求URL里带“login”的包：

http.request.full_uri contains "login"

想找TCP载荷里出现某个关键字：

tcp.payload contains "admin"

想找某个域名相关的TLS SNI：

tls.handshake.extensions_server_name contains "example"

contains支持引号，也可以用字节序列匹配，比如找十六进制的特征：

tcp.payload contains 01:02:03:04

这个功能在分析一些自定义TCP私有协议时很救命，因为你不知道对方的协议结构，但你知道正常报文里肯定有一段固定的魔数开头，一梭子打过去就能把相关包全捞出来。

6.2 matches：正则表达式

matches比contains更高级，支持正则。Wireshark的正则语法用的是PCRE风格。比如你要找某个域名下所有子域名的流量：

http.host matches "cdn\\.(example|test)\\.com"

注意Wireshark里正则的转义，一个点要写成\\.，这个细节让很多人踩坑。还有matches只支持字符串比较，如果用在不支持字符串的字段上会直接报错。

举一个实际用法：排查某APP客户端连接了哪个服务器地址版本，但后缀不确定，只知道是prod还是gray，那就用matches一把梭：

tls.handshake.extensions_server_name matches "api.*(prod|gray)"

6.3 关于大小写敏感

contains是大小写敏感的，HTTP和http是两个不同的串。如果你需要忽略大小写，多数情况下得靠正则，或者用Wireshark的string函数。这个函数比较偏门，但确实存在：

string(http.request.uri) contains "login"

不过实际项目中我通常直接用matches写一下正则，更灵活。

7. 第7类：时间过滤器，揪出慢的根源

排查性能问题时，“时间”是关键维度。一个接口慢，慢在哪，是握手慢、首字节慢还是传输慢？时间过滤器就是干这个的。

7.1 帧间时间差

Wireshark里每个数据包都有时间戳，两个最常用的时间相关的派生字段是：

• frame.time_delta：与上一帧的间隔，单位是秒
• frame.time_delta_displayed：与上一条“显示出来的”包的间隔

后者特别有用，因为当你用了显示过滤之后，界面上的包已经不是原始顺序的相邻帧了，但frame.time_delta仍然基于原始帧，而frame.time_delta_displayed则基于你过滤之后看到的包。

比如我想找出所有“在上一帧之后等了超过0.5秒才有响应”的包：

frame.time_delta_displayed > 0.5

这个过滤条件配合HTTP请求，能快速定位是哪个阶段耗时长。比如一个HTTP请求的响应包之前隔了2秒，那问题基本就在服务端处理逻辑上。

7.2 请求到响应的耗时

HTTP请求和响应配对之后，Wireshark会计算一个http.time字段，代表请求发出到响应完成的时间。直接：

http.time > 1

所有超过1秒的HTTP请求全部浮出来，这在接口性能分析里是一招绝活。

7.3 相对时间和绝对时间

• frame.time_relative：包相对于抓包开始时间的时间偏移
• frame.time：包的绝对时间

想抓某个时间窗口内的包，比如下午两点到两点十分：

frame.time >= "2025-03-01 14:00:00" && frame.time <= "2025-03-01 14:10:00"

这种用法对事后分析pcap文件很有用，尤其是抓了一整天的包，先按时间段切分再逐步缩小范围。

8. 第8类：逻辑组合与括号优先级，过滤器真正的灵魂

前面讲了七类，单独用它们你已经能处理很多场景。但真实世界的问题往往需要用两个、三个条件组合才能精确命中。逻辑运算符就是把这些条件像乐高一样拼起来的关键。

8.1 三种基本逻辑运算

• &&：且，前后条件都要满足
• ||：或，前后条件满足其中一个即可
• !：取反，否定后面的条件

比如我想找A主机访问B主机80端口的HTTP请求：

ip.src == 192.168.1.10 && ip.dst == 192.168.1.20 && tcp.port == 80 && http.request

排除掉某个IP的所有流量：

!(ip.addr == 192.168.1.10)

8.2 括号的优先级

组合条件一多，优先级就很重要。默认情况下&&优先级高于||，但阅读起来容易混乱，最好的习惯是把每个逻辑块用括号包起来。

比如“主机A的HTTP流量，或者主机B的DNS流量”：

(ip.addr == 192.168.1.10 && http) || (ip.addr == 192.168.1.11 && dns)

不写括号的话，很容易被Wireshark解释成完全不同的意思。我曾经见过一个同事写的条件：

ip.addr == 192.168.1.10 || ip.addr == 192.168.1.11 && http

表面上看他想找“A或B的HTTP流量”，但根据优先级，这个式子实际是“A的所有流量，加上B的HTTP流量”，导致匹配出大量意料之外的包。所以我的建议很明确：只要组合条件超过两个，就给每组条件加括号，没有例外。

8.3 运算符简化

Wireshark里==也可以用eq代替，!=用ne代替，&&用and代替，||用or代替，!用not代替，甚至大小写不敏感。不同教材写法不同，但实际效果一样。比如：

ip.addr == 192.168.1.10 && tcp.port == 443 ip.addr eq 192.168.1.10 and tcp.port eq 443

两种写法完全等价。我个人习惯用符号形式，因为打字更快，两种写法都能识别，根据个人习惯来就好。但有一点要记牢：在过滤栏里不能混用&&和and之外的其他写法，比如&是位运算，跟&&完全不是一回事，写错会导致语法错误。

9. 第9类：界面级快速过滤，不需要背语法的“懒人神器”

第9类严格来说不是输入过滤表达式，而是利用Wireshark界面自带的功能，把过滤器的使用效率提升一个档次。为什么我把归为第9类？因为它是所有过滤器技巧中最容易上手、也最容易被忽略的一类。

9.1 右键“作为过滤器应用”

在报文列表的任何一列上右键，比如某个包的源IP、目的IP、协议、端口号，都可以看到“作为过滤器应用”的子菜单，里面会有“选中”“未选中”等选项。点击之后过滤栏自动生成对应的过滤条件。

这是一个什么概念？你完全不用记忆ip.src == x.x.x.x这种语法，只要定位到一个包，右键一下，符合条件的流量就全筛出来了。尤其是当你想快速查看某个TCP流、某个域名对应的所有流量时，这个操作的效率比手打快三倍。

9.2 右键“作为列显示”

这个功能和过滤器关系也很大。Wireshark默认的列是No.、Time、Source、Destination、Protocol、Length、Info，但对特定场景来说不够用。你可以右键详情面板里的某个字段，选择“作为列显示”，然后把它变成一个可排序、可筛选的新列。

最实用的例子：把http.response.code或者dns.qry.name作为列显示，这样你一眼就能看到整个抓包结果里所有HTTP状态码或所有查询的域名。配上过滤条件，又能看数据又能看统计，非常直观。

9.3 对过滤器列做高亮和着色

显示过滤器不只是“筛选”，还可以用来“着色”。Wireshark的“View -> Coloring Rules”可以自定义颜色规则，本质就是过滤器表达式加颜色。比如把tcp.analysis.retransmission染成红色，把http.response.code >= 400染成橙色，把dns染成蓝色。这样抓包界面在海量流量里也能“一眼红”，不用等过滤条件切来切去。

9.4 IO Graph与统计里的过滤

Wireshark里的IO Graph、Flow Graph、Statistics菜单里几乎都支持过滤表达式。比如我在可视化流量的时候，会设置两条不同的过滤曲线，一条http.request，一条tcp.analysis.retransmission，叠在一起看拐点，哪个时间点重传飙升，哪个时间点请求量骤降，一目了然。这就是很多人说Wireshark“可视化”能力的来源，本质上还是过滤器在驱动。

10. 九类过滤器速查表

以下是日常最常用的过滤表达式汇总，建议直接收藏：

11. 实战：用这几类过滤器解决一个真实问题

纸上谈兵没意思，我用一个曾经的排障过程把这九类过滤器串起来，你感受一下它们的联动效果。

11.1 场景描述

一个内部系统的Web页面突然变慢，用户反馈点一下按钮要转圈十几秒。我先在网关出口镜像端口抓包，大概抓了五分钟，pcap文件有几百MB。然后开始逐层过滤。

第一步，先锁定目标主机的HTTP流量：

ip.addr == 10.20.1.88 && http

结果发现HTTP请求每秒没多少，但响应时间确实很长，这时候我加了时间条件：

ip.addr == 10.20.1.88 && http.time > 3

筛出一堆超过3秒的请求。再右键某个慢请求，Follow TCP Stream，看到服务端返回数据之前有大量TCP重传。

第二步，分析重传到底发生在哪一段：

ip.addr == 10.20.1.88 && tcp.analysis.retransmission

发现重传包源IP都是客户端到服务器方向的，而且集中在某一个网段。再结合IP过滤：

ip.src == 10.20.1.88 && tcp.analysis.retransmission

和：

ip.dst == 10.20.1.88 && tcp.analysis.retransmission

一对比，重传集中在客户端发到服务器方向，链路丢包率偏高，问题定位到中间网络设备。整个过程不到十分钟，每一层过滤都在缩小范围，从几百MB的包到最后几十条重传记录。

11.2 第二个场景：域名解析异常

另一个案例是某天外网访问异常，抓包后直接用：

dns.qry.name contains "example.com"

查看所有相关DNS查询。把dns.flags.response和dns.qry.name组合起来，能看到查询次数、响应次数、响应时间。发现每次查询都要5秒超时重发，进一步用时间过滤：

dns.time > 1

确认DNS响应慢。最后定位到本地DNS转发配置有问题，和Wireshark无关，但全流程都是用过滤器一步步逼出来的。

11.3 第三个场景：找一条可疑的TCP流

还有一次排查安全事件，需要确认一个外联IP的TCP连接是否在传输敏感数据。这时候我先用IP地址过滤锁定目标IP所有流量：

ip.addr == 203.0.113.5

再右键任意一条连接Follow TCP Stream，发现载荷里面有大量明文关键字。然后用tcp.payload contains去统计出现了多少次：

ip.addr == 203.0.113.5 && tcp.payload contains "username"

这个结果直接成为交接给安全团队的证据之一。

12. 常见问题与避坑实录

12.1 过滤栏背景变红是怎么回事

在显示过滤器里输入内容时，背景色会跟着变化：绿色表示语法正确，黄色表示可能有问题但仍可接受，红色表示语法错误。这个设计很贴心，但很多人没注意到，导致输完一条条件后Wireshark没有任何数据返回、一脸懵。建议养成习惯：看到红色就先检查有没有少括号、字段名有没有拼错、引号有没有闭合。

12.2 “ip.addr != x.x.x.x”为什么不符合预期

这个前面提过，值得单独再强调一次。ip.addr != 192.168.1.10在Wireshark里的语义是“存在一个不等于这个IP的地址字段”，因为一个包有源地址和目的地址两个字段，只要其中一个是其他IP，就匹配成功，相当于根本没过滤掉什么。正确的排除写法是：

!(ip.addr == 192.168.1.10)

12.3 contains和matches的区别

• contains：子串匹配，大小写敏感，速度快
• matches：正则匹配，功能强，但性能消耗稍大

如果流量特别大、pcap文件几百MB，不要秒秒都上正则。先用contains粗筛，再用matches精筛，速度会快很多。

12.4 过滤结果为空，不一定是没匹配到

有几次我看到朋友过滤后结果是0条，以为是条件错了，最后发现是界面上方选中的Packet Range不对，或者当前只选中了一条TCP流导致只见到了这一条流的子集。显示过滤器是作用在当前加载的所有包上的，但如果先做了“Follow TCP Stream”，Wireshark会自动创建一个临时过滤条件，你新输入的过滤条件会和它叠加。这种情况先清空过滤栏，或者点一下过滤栏旁边的清除按钮，确保自己是在全局视图下操作。

12.5 大文件的实时处理和分片

抓包文件动辄几个G的时候，过滤器本身再快，加载和解码也是要花时间的。Wireshark 3.0之后的版本解析速度改善了很多，但依然建议抓包时在Capture Options里配置多文件保存，比如每个文件100MB，存10个文件轮转，避免内存爆炸。过滤技巧再熟练，机器卡死了也是白搭。

13. 最后再分享一点我的实操体会

如果你现在刚接触Wireshark，我劝你别急着背所有字段，先把ip.addr、tcp.port、http.request、tcp.analysis.retransmission这四个玩明白，遇到问题就右键、右键、再右键。等到你开始觉得右键不够用了，再回头系统看字段列表，那时候你会发现很多语法你其实已经会了，只是不知道它们叫什么。

另外一个小经验：抓包前先在脑子里把“我要证明什么问题”写清楚。比如“这台机器访问那台机器的80端口，为什么响应慢”——那么你的过滤条件大概率就是IP + 端口 + 时间差三层的组合。目标越明确，过滤器写得越快，排查也就越高效。

过滤器说到底就是一层窗户纸，捅破之后你会发现Wireshark真正强大的地方不只是“能看到什么”，而是“你想看什么就能看到什么”。希望这篇能帮你在下次被网络问题折磨的时候，少走几条弯路。