企业官网建设流程全解析

不管是做网络安全、开发调试，还是网络运维的人，手里都得有个好使的抓包工具。而在这一堆工具里，Wireshark 始终是绕不开的那个名字。工作这十多年，从最开始用 tcpdump 在小黑框里一条条看报文，到后来装上 Wireshark 图形界面做协议分析，再到靠它定位线上超时问题、分析恶意流量样本，我几乎是把自己大部分排障经验都沉淀在了这个软件里。今天这篇东西，手把手带你把 Wireshark 的流量分析、协议拆解、异常流量识别这三块真正用起来，不只是教你点几个按钮，而是把背后为什么要这么做的逻辑也讲清楚，让你拿到一个 pcap 包之后能真正读懂它，而不是只会看个大概。

这个内容适合谁看？一类是刚入门网络分析、被 TCP 三次握手和过滤器语法折磨的新人，另一类是日常要处理 APK 抓包、PCAP 取证、定位慢请求的研发和运维同学，还有一类就是打 CTF 时遇到流量分析题会卡住的选手。我会从最基础的准备工作开始，一路讲到 HTTPS 解密、异常流量特征、CTF 常见套路的完整实操流程，如果你能跟着我的思路从头到尾走一遍，收获的绝对不只是会安装软件而已。

1. 开局准备：装对、配好，抓包才不白费

1.1 优先使用最新稳定版，但别盲目追新

Wireshark 的官网下载页面提供了 Windows、macOS、Linux 的安装包，这里我建议你优先使用稳定版本。比如当前到了 4.x 时代，界面比老版本清爽不少，很多显示逻辑和协议解析器都有优化，但核心功能并没有变化。我最初接触的时候还在用 1.x，后来一路升到 4.x，最大的感受是启动速度和过滤器的智能提示越来越好了，打开几个几百兆的大包也不像以前那样卡成幻灯片。

有一点需要特别注意：Wireshark 在 Windows 上只是个壳，真正做底层抓包的是 Npcap。安装 Wireshark 的时候会提示你安装 Npcap，不要跳过它。Npcap 是 WinPcap 的继任者，目前被 Wireshark 官方推荐。装完 Npcap 之后，还需要确保自己的 Windows 账号有管理员权限来抓包，否则即使装好了驱动，Wireshark 也拿不到网卡列表或者抓到一堆无意义的空包。

1.2 网卡、混杂模式与抓包前的三个配置习惯

打开 Wireshark 之后，会看到一个网卡选择列表。很多人到这里就迷茫了，我究竟该选哪张网卡？这里有个经验：如果只是看本机回环流量（比如本机服务之间通信、抓浏览器的请求），选 Loopback（lo）或 Npcap Loopback Adapter；如果要分析局域网里其他设备的报文，那就绝对不能忽略“混杂模式”这个开关。Wireshark 默认会把网卡设为混杂模式，相当于把你网卡能听到的所有数据包都收进来，而不仅仅是发给自己的包。关掉混杂模式后，你只能看到发给自己 MAC 地址的单播包和广播包，分析局域网内其他设备的流量时就会什么都看不到。

真正动手之前，还有三个配置习惯我建议你先养成。第一，在 “捕获 -> 选项” 里面，把 “使用 promiscuous mode on all interfaces” 勾上（这个一般默认就开），然后到 “统计” 菜单里打开 “协议分级” 之前，最好先做一次采样测试，看看自己的接口流量正不正常。第二，在 “视图 -> 时间显示格式” 里，把时间改成 “自抓包开始的秒数” 或 “UTC 日期和时间”，不要用默认的相对时间。原因很简单：分析异常流量时，你需要精确到毫秒级的时间戳来做关联，比如排查 DNS 慢查询时，你看发起时间和响应时间差了多少毫秒，这直接决定了你是不是要走对排查方向。第三，开启 “视图 -> 着色规则”，Wireshark 自带了一套基于协议和 TCP 标志的着色规则，比如 TCP 重传会显示为浅红色，TCP 乱序会显示为黄色。刚开始你可以直接用默认设置，等看得多了再调整成自己的风格。

2. 抓包与过滤器：从“看得见”到“看得懂”

2.1 捕获过滤器与显示过滤器的本质区别

抓包前设置的那个过滤叫做“捕获过滤器”（Capture Filter），它的作用是决定哪些包被放进内存，这个过滤是由底层 libpcap/WinPcap 完成的。语法用的是 BPF（Berkeley Packet Filter），比如只抓 80 端口流量，可以写port 80，只抓指定主机的通信可以写host 192.168.1.1。这个过滤器有个坏处：丢掉的信息找不回来，所以正常情况下我不建议大家上来就加捕获过滤器，宁可先全部抓下来。

真正工作中高频使用的是“显示过滤器”（Display Filter），它的作用是决定哪些包被显示在界面上，但 pcap 文件里其实还在。显示过滤器的语法非常丰富，是我们做协议分析的核心。比如我想看源地址或目的地址是 192.168.1.100 的所有包，就写ip.addr == 192.168.1.100；想看 HTTP 请求，直接写http.request；想看 TCP 端口 443 上的所有流量，写tcp.port == 443。这些表达式之间还可以组合，比如ip.addr == 192.168.1.100 && tcp.port in {80, 443}，或者用||表示或者。显示过滤器的判断逻辑是由 Wireshark 的显示过滤器引擎完成的，字段非常多，几乎你能想到的协议头字段都可以作为过滤条件。

2.2 常用过滤器表达式速查表

为了方便你直接抄作业，这里整理了一份我日常用得最多的过滤器表达式，适用于大多数排查场景：

这些过滤器看起来简单，但组合起来威力巨大。比如你要定位一个“访问特定域名返回 502”的问题，先dns.qry.name contains "example.com"找出解析 IP，再用ip.addr == 那个IP && http.response.code == 502来缩小范围。平时没事的时候，多玩玩这些表达式，会比看多少篇教程都管用。

2.3 “跟随 TCP 流”和“导出对象”两个救命功能

当你点开一个 TCP 包，右键选择 “追踪流 -> TCP 流”，Wireshark 会把这条 TCP 连接之前传过的所有数据按时间顺序拼起来，直接拼接成整个会话的原始内容。这个功能是我排障时最常用的一个。比如排查 HTTP 接口报错，一条 TCP 流里既有请求头、请求体，又有响应头、响应体，你一眼就能看出服务端到底返回了什么。

另一个极其实用的功能是 “文件 -> 导出对象 -> HTTP”，它能把 pcap 包里的所有 HTTP 传输对象（HTML、JS、图片、文件等）全部提取出来。CTF 流量分析题里最常见的套路就是让你导出图片、压缩包或者脚本文件来看隐藏信息。工作中如果你怀疑内网有人通过 HTTP 下载恶意软件，也可以先用这个功能把对象都导出来，再丢给杀毒引擎扫一遍。Fiddler 和 Charles 虽然也能看 HTTP 内容，但论“从 pcap 里恢复文件”这个操作，Wireshark 真的是独一份。

3. 协议拆解：从握手到应用层，把每个字节都读懂

3.1 TCP 三次握手：不只是 SYN、SYN-ACK、ACK

很多人觉得三次握手太基础了，但实际排查问题的时候，大部分连接超时的根因跟握手阶段的字段细节脱不开关系。我们看一个典型的 TCP 三次握手包：

第一个包是客户端发来的 SYN，标志位是0x002。这里不能只看标志位缩写，还得关注“Sequence Number（序列号）”和“Window Size（窗口大小）”。SYN 包的序列号是一个随机初始值，Wireshark 会用seq=0这种相对序列号显示，方便我们观看。第二个包是服务端回复的 SYN-ACK，标志位是0x012，它除了自己随机一个初始序列号外，还带了一个ACK=1，表示收到客户端的 seq=0 之后的期待下一个字节。这个 ACK 就不是 1 字节那么简单了，它代表的是“下一字节的序号”。第三个包是客户端的 ACK，标志位是0x010，里面带着ACK=1，此时连接才真正建立。

为什么要理解这一点？因为如果第三个 ACK 丢失了，服务端一直处于 SYN_RECEIVED 状态，会导致客户端认为连接已建立、服务端认为连接未建立。这时候排查方式就是看有没有tcp.analysis.retransmission标志，或者在 Wireshark 里统计 TCP 连接的状态图，直接看握手完成率。线上如果出现大量 SYN 包但没有对应的 SYN-ACK 包，那你优先要怀疑是不是服务端半连接队列满或者被防火墙丢了；如果 SYN-ACK 发出去了但没有最终 ACK，那多半是客户端侧出了问题或者有人伪造 IP 做 SYN Flood。

3.2 HTTP 与 HTTPS 解密实操：SSLKEYLOGFILE 大法

HTTP 抓包很好理解，到了 HTTPS 很多人就卡住了。其实 Wireshark 解 HTTPS 有一个非常实用的机制：只要你拿到了 TLS 会话的主密钥（Master Secret），就可以把加密流量还原成明文。现代的 Chrome、Firefox 都支持通过环境变量SSLKEYLOGFILE导出密钥。

我的做法是：在 Linux 或 macOS 上启动 Chrome 之前，先执行export SSLKEYLOGFILE=/tmp/sslkey.log，然后打开浏览器访问目标站点。接着回到 Wireshark，进入 “编辑 -> 首选项 -> Protocols -> TLS”，在 “(Pre)-Master-Secret log filename” 里填上这个日志文件路径。设置好之后重新抓包，HTTPS 里的 HTTP 请求、响应内容全部变成可读的了。Windows 上稍麻烦一点，需要用setx SSLKEYLOGFILE C:\sslkey.log设置用户级环境变量，然后再启动浏览器。

但这里需要强调一点：这个解密方式只对“你能控制客户端”的场景有效。如果你抓的是一个 pcap 里用 RSA 密钥交换的旧式 TLS 包，可以在 TLS 协议配置里导入服务器私钥去解；但现在的 TLS 1.3 都改成 ECDHE 密钥交换了，没有客户端导出的密钥文件，基本不可能直接解密。所以做取证的时候，别指望光靠一个 pcap 就能解密全部 HTTPS，最好能在源头机子上提前配置好日志导出，或者使用中间人代理来做，这也是很多公司内网审计设备的工作方式。

3.3 DNS 查询拆解：一眼看出解析到底卡在哪一步

DNS 分析是很多人忽略但真的很实用的技能。在 Wireshark 里输入dns过滤器后，你能看到完整的查询和响应包。典型的 DNS 查询包关键信息包括：Transaction ID（事务 ID）、Flags（标志位）、Queries（查询名和类型）、Answers（响应结果）。如果一次解析响应时间很长，你要关注的是“请求发出时间”和“响应到达时间”之间的差值。

有一次客户反馈“访问网站偶发慢”，我们抓包后发现 DNS 查询每次都要 2 秒才返回。过滤器打开看，才发现客户端连续发了三次相同的 DNS 查询，前两次根本没收到响应，第三次才回来。这说明 UDP 53 端口丢包严重，或者本地 DNS 缓存服务器有问题。顺着这个线索，把 DNS 服务器换掉后，问题立刻消失。这就是典型的“只看应用层永远查不到，看协议层一条过滤器就定位”的案例。

另外，很多人不知道 DNS 协议支持 TCP 模式，当响应数据长度超过 512 字节（或更严格的 EDNS0 协商大小）时，会从 UDP 切换成 TCP。这时你抓到的包会看到dns.flags.response == 1后面跟着tcp.stream。识别这种切换，对排查一些特殊的 DNS 解析失败也很有帮助。

3.4 TCP 异常：重传、快速重传、乱序、零窗口

TCP 的异常分析是流量识别的重头戏。Wireshark 在 TCP 协议分析这块做得很智能，它会自动标记tcp.analysis.flags以及各种专家信息。最常见的几类异常：

• TCP Retransmission（超时重传）：发送方发出一个报文后，在超时时间内没有收到 ACK，于是重发。这类包多半是网络丢包导致的，也可能是接收方处理慢导致 ACK 延迟。
• TCP Fast Retransmission（快速重传）：当接收方连续收到三个重复的 ACK 后，发送方认为报文丢失，不等超时就立刻重发。这种情况通常意味着网络中有轻微丢包或乱序。
• TCP Out-Of-Order（乱序）：接收方收到的报文的序列号不连续，后面的包先到了。这通常与多路径转发、负载均衡相关。
• TCP Zero Window（零窗口）：接收方告诉发送方自己的缓冲区满了，暂时不要继续发数据。如果零窗口持续时间很长，说明接收方应用读取速度跟不上，可能是应用层处理能力出问题，而不是网络问题。

我用零窗口这个指标排查过一次性能故障。当时一个网关服务响应越来越慢，抓包后发现客户端一直在发tcp.analysis.zero_window，窗口大小一度跌到 0。顺着这个线索查到服务端 JVM GC 频繁停顿，导致业务线程无法及时从 Socket 缓冲区读取数据，缓冲区最终被写满。问题根本不在网络，而在应用 GC。这就是抓包分析最有意思的地方：表面上你看到的是 TCP 层的症状，实际根因可能在应用的任何角落。

4. 异常流量识别：从海量数据里揪出“坏包”

4.1 端口扫描与暴力破解：流量里的“侦察兵”

异常流量识别是安全分析和运维排障的进阶能力。常见的场景是有人在内网里做端口扫描。你可以通过tcp.flags.syn == 1 && tcp.flags.ack == 0过滤出所有 SYN 包，然后到 “统计 -> 端点” 或 “统计 -> 对话” 里看哪个 IP 发起了大量 SYN 请求。正常客户端访问服务器不会在几秒钟内对上百个端口发起连接，如果你看到一个源 IP 在短时间请求了大量不同目的端口，基本可以断定是扫描行为。

暴力破解也一样，特征是大量针对同一端口（比如 22、3389、3306）的 TCP 连接，每次连接里都有认证失败的交互。你可以用tcp.port == 22 && tcp.flags.syn == 1过滤出所有 SSH 连接尝试，然后到 “统计 -> 流量图 -> TCP 时序图” 里看连接次数。如果同一秒内有几十次握手尝试，再说不是爆破都没人信。

但这里要提醒一点：光靠 Wireshark 人工盯实时流量不现实，更适合的方式是抓包保存成 pcap 后用脚本来分析。比如你可以用 tshark（Wireshark 的命令行版本）跑一条命令：tshark -r capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e ip.src | sort | uniq -c | sort -rn，把 SYN 包按源 IP 统计出来。这才是处理大流量时的正确姿势。

4.2 SYN Flood 与连接耗尽：DDoS 的最基本形态

SYN Flood 的原理简单粗暴：攻击者发送大量 SYN 包，但不完成第三次握手，服务端的半连接队列很快被塞满，正常用户连接无法建立。在 Wireshark 里看这个特征非常明显：大量源 IP（或者被伪造的源 IP）发 SYN，但没有对应的 SYN-ACK，或者 SYN-ACK 发出去了但后续没有 ACK 跟上。此时你可以在 IO Graph 里加一条过滤器tcp.flags.syn == 1 && tcp.flags.ack == 0，看这条曲线是否呈脉冲状暴涨。

有一次我做攻防演练分析，抓到一个 pcap 里短短 30 秒内出现了 20 万个 SYN 包，而正常完成握手的连接只有几百个。抓住这个数据后，我立刻去端点统计里看源 IP 分布，发现大多数源 IP 都是随机伪造的，只有几个 IP 在持续贡献大量包，基本可以定位到是压测机器或肉鸡在打流量。这里有个实操技巧：当你看到大量源 IP 但不知道哪个是重点时，用“统计 -> IPv4 统计 -> 所有地址”按包数量排序，瞬间就能锁定前几名。

4.3 ARP 异常和广播风暴：二层网络的隐形杀手

二层网络的异常不像 TCP 那样能直观看到重传，但它破坏力也不小。ARP 风暴的特征是短时间内出现大量arp报文，而且很多是同一对 IP/MAC 的重复广播。正常情况下 ARP 请求只会在刚接入网络或缓存过期时出现，如果你看到上百个 ARP 包在 1 秒内出现，基本可以判断网络里存在 ARP 广播风暴或者有设备在做扫描。

我之前处理过一个“全网卡顿”的工单，登录交换机一看 CPU 飙升，抓包发现一个 IP 在疯狂广播 ARP 请求，请求的却全是不存在的地址。排查后发现是有台机器的网卡驱动异常，导致不断重新发送 ARP 查询。这时候在 Wireshark 里输入过滤条件arp，再按时间排序，你会发现这个源 MAC 地址几乎占满了所有 ARP 包。用eth.src == xx:xx:xx:xx:xx:xx一过滤，问题设备立刻暴露出来。

4.4 DNS 隧道、ICMP 隧道与数据外带：高级外传手法

如果你的企业网络有严格的安全审计，那就要关注 DNS 隧道这类隐蔽信道。DNS 隧道利用 DNS 协议做数据传递，常见特征包括：单一源 IP 对某个域名发起大量 DNS 查询，而且查询内容非常长、像是编码后的数据；请求的域名前缀是随机字符串，长度异常；响应包中 TXT 记录携带大段 Base64 内容。

在 Wireshark 里，你可以用dns.qry.name.len > 50这个过滤器把查询名异常长的 DNS 请求筛出来。正常情况下没人会把超过 50 字符的随机子域名当作日常访问。ICMP 隧道也类似，特征是大量 ICMP Echo Request 和 Echo Reply 报文，而且数据段不是规律的 32 字节或 56 字节，而是几百上千字节的随机数据。用icmp过滤后，按包大小排序，如果发现大量小包变超大包，多半有问题。

5. 实战案例：从 CTF 到手机抓包，一次讲透

5.1 CTF 流量分析题的正确打开方式

CTF 比赛里流量分析题经常出场，常见的 flag 藏法有几种：直接明文藏在 HTTP 请求头、藏在图片文件尾部、藏在 DNS 查询记录中、或者是通过 TCP 流传输了一个压缩包。拿到一个 pcap 后的第一件事，不是第一时间盯着一堆 TCP 包看，而是先看“统计 -> 协议分级”。这一步能让你快速了解流量里主要是什么协议。如果 HTTP 请求特别多，优先导出 HTTP 对象；如果 DNS 查询很多，优先看有没有 Base64 编码的子域名；如果只有 TCP 裸流量，那一般就是让你分析文件传输。

我再分享一个真正好用的小技巧：在 Wireshark 的显示过滤器里输入frame contains "flag"，很多题目直接把 flag 字符串放在包里，这一下就能筛出来。如果 flag 被 Base64 或者 URL 编码过，可以先观察响应包的 Data 部分，看看有没有像ZmxhZ3s=这样的特征。之前有一道题把 flag 藏在图片里，我先导出 HTTP 对象拿下一张 PNG，然后看图片尾部数据，果然发现了附加字符串。CTF 流量分析最忌讳“大海捞针”，一定要先从统计和对象导出这两个模块动手。

5.2 自顶向下 Wireshark 实验包的分析思路

很多人会接触到《计算机网络：自顶向下方法》那本教材配套的实验 pcap（比如 wireshark-traces-9e.zip 里的 tcp-wireshark-trace-1.pcap）。这类实验包的价值不在于“做题”，而在于让你弄清 TCP 序列号、ACK、窗口、重传之间的关系。我做这种分析时一般分三步走：第一步，过滤出tcp.stream eq 0，找一条完整连接；第二步，按时间顺序逐个看 SYN、SYN-ACK、ACK 的 seq/ack 字段变化；第三步，找tcp.analysis.retransmission标记，看它发生在哪个阶段。

如果你对序列号的增长规律还不熟，可以打开“统计 -> TCP 流图 -> 时间序列图”，能直观看到序列号随时间的变化曲线。这个图在分析慢启动和拥塞避免时非常直观，拥塞窗口变化、快重传的发生时机一目了然。

5.3 手机 App 抓包与 CA 证书配置

移动端抓包是很多开发头疼的问题，尤其是 Android 7.0 之后，App 默认不信任用户安装的 CA 证书，导致你用 Fiddler、Charles 或 BurpSuite 抓 HTTPS 时只能看到一堆 TLS 握手失败。解决思路基本就两条：要么用 root 后的手机把代理 CA 证书装进系统证书目录，要么用 VirtualXposed、LSPosed 这类框架配合 JustTrustMe 模块绕过证书校验。

如果你只是抓普通小程序流量，简单一点的做法是：手机和电脑连同一个 Wi-Fi，代理设成电脑的局域网 IP 加代理端口，然后在手机上安装并信任 Charles 或 Fiddler 的 CA 证书。如果 App 本身就做了证书校验，抓包软件会收到 ClientHello 后直接被 RST 掉。此时就要上 LSPosed 了，装好模块后重启 App，再配合抓包工具就能看到明文。但这里我非常建议：在公司环境做这类操作前一定要确认是合规的测试环境，不要拿生产环境的 App 做试验。

还有一个容易被忽略的点：很多抓包代理默认只监听 IPv4 的某个端口，而 Android 9 之后默认可能走 IPv6 或双栈，代理地址填不对就抓不到包。遇到“能联网但抓不到 App 请求”的问题，先检查代理设置里是http://192.168.x.x:8888还是http://[::1]:8888，以及手机和电脑的防火墙有没有放行端口。

5.4 USB 抓包与特殊接口抓包

除了传统网卡，Wireshark 还能抓 USB 流量，这也是很多硬件开发、外设调试同学的刚需。Windows 下需要安装 USBPcap 驱动，装完在 Wireshark 的接口列表里会出现 USBPcap1、USBPcap2 之类的接口。抓包后用usb.transfer_type == URB_INTERRUPT或usb.device_address == 1这类过滤器来筛选特定设备的数据。

Linux 下抓 USB 一般用 usbmon 模块，加载后/dev/usbmon*就出现了，然后用dumpcap -i usbmon1 -w usb.pcapng采集。采集出来的 USB 包里面最常用到的是控制传输、批量传输和中断传输。如果你想分析一个自定义 HID 设备上报的数据，抓完包直接看 URB 的数据段，比用日志打印高效得多。当然，USB 抓包不是所有硬件都支持得完美，部分厂商的私有驱动可能不走标准 USB 协议栈，这时候就另当别论了。

6. 常见问题与排查技巧实录

6.1 为什么 Wireshark 只显示 520 字节，怎么看到 2090 字节？

这个问题在各类搜索引擎里出现频率极高，其实根本原因是在“编辑 -> 首选项 -> Appearance -> Layout”之外，还有一个数据字节显示范围的设置。当你在包详情面板选中某个协议字段时，下方的数据视图默认只显示一定字节范围，不同版本默认值不同。Wireshark 里的“Bytes”视图默认可能只展示前 520 字节，但实际包长度是 2090 字节。解决办法是：进入“编辑 -> 首选项 -> Protocol -> 对应协议（如 TCP）”，找到 “Show byte range” 之类的选项，改成全量范围。更通用的做法是直接点开 Packet Details 里的[Expert Info]，或者在“视图 -> 内部”里调整。其实最方便的是在十六进制视图下方的状态栏上，有一个可以切换显示范围的按钮，把它从“限制到 520 字节”改成“不限制”就好了。

这个问题看似简单，但多少工程师在关键排障时被它坑过：明明包是 2000 多字节，自己看到的只有前面 520 字节，然后误判应用层数据不完整。如果你也遇到类似问题，先确认是不是显示截断，而不是真的丢包。

6.2 pyshark、tshark 无法抓包怎么办？

热词里有人提到 python2.7 + pyshark 无法抓包的问题。pyshark 本质上是一个调用 tshark 的 Python 封装，版本兼容性比较特殊。如果你还在用 python2.7，大概率会遇到依赖 libpcap 或 tshark 路径不匹配的问题。解决办法：优先升级到 Python 3.8+，安装最新版 pyshark；如果是用pyshark.LiveCapture(interface='eth0')报权限错误，就加上use_json=True参数，或者用tshark -i eth0 -w out.pcap先落盘再交给解析器分析。绝大多数“无法抓包”的错误，本质上是：接口名错误、权限不足、tshark 的可执行文件路径没有加入系统 PATH。先跑一下tshark -D列出所有接口，再确认当前用户对接口有抓包权限，问题基本就解决了一大半。

6.3 手机代理抓不到包、CA 证书装不上的排查思路

这个问题我见得太多了。手机上安装了抓包代理的证书，App 的流量还是抓不到，排查顺序建议是：第一，检查手机和电脑的代理设置是否填对，代理 IP 必须是电脑在当前 Wi-Fi 下的实际 IP，而不是 127.0.0.1；第二，检查代理端口是否被防火墙挡住，最简单的验证是在手机浏览器里访问http://代理IP:端口，如果能打开抓包软件的证书下载页面，说明链路是通的；第三，确认 CA 证书安装位置是否正确。Android 9 之后，用户 CA 证书默认不被 App 信任，如果你没有 root，那就得考虑用 VirtualXposed 或重打包的方式让 App 信任你的 CA；第四，检查抓包工具是否开启了“SSL Proxying”功能，很多代理工具默认只代理 HTTP，没有勾选 TLS 解密。按这个顺序走下来，绝大多数“抓不到包”的问题都能定位到具体环节。

6.4 大包文件卡顿、磁盘写满、抓包时机太晚

抓包文件动辄几百 MB 甚至几个 GB，Wireshark 打开卡成幻灯片是家常便饭。几个建议：第一，使用dumpcap命令行工具抓包而不是直接用 Wireshark 的图形界面，它能更高效地落盘；第二，在抓包前就设置环形缓冲：在“捕获 -> 选项”里，把输出改成多个文件、每个文件 100MB、保存最近 20 个文件，这样既不会撑爆磁盘，又能保留最近一段时间的流量；第三，不要在 Wireshark 里直接分析特大文件，先用editcap -c 100000 input.pcap split/out.pcap把它切成多个小文件，再逐个看。抓包时机方面，很多人习惯先开启抓包再复现问题，这很可能错过早先的问题报文。正确的做法是常驻一个环形缓冲，让 Wireshark 一直处于记录状态，等异常出现后再停下来，这样可以保证你拿到了完整的“案发现场”。

6.5 HTTP/2、QUIC 与 TLS 1.3 对抓包的影响

现在的互联网流量已经大量使用 HTTP/2 和 QUIC，Wireshark 4.x 对 HTTP/2 和 QUIC 的解析已经很成熟了。如果你发现 HTTP 过滤器筛不出任何包，先看看是不是流量走了 HTTP/2 或 HTTP/3。HTTP/2 的帧结构不同于 HTTP/1.1，但 Wireshark 依然可以通过http2过滤器来查看帧和头部。QUIC（基于 UDP 的传输协议）需要用quic过滤器，而且 QUIC 默认是加密的，如果没有密钥，只能看到连接建立过程，看不见应用数据。

TLS 1.3 同样给解密带来挑战，因为所有握手密钥交换都使用 ECDHE，会话密钥无法通过服务端私钥还原。唯一的办法还是我在前面提到的SSLKEYLOGFILE。如果条件允许，建议在客户端环境统一开启密钥日志记录，这对于排查生产问题、做安全分析都非常有利。

7. 关于抓包这件事，我的几点实际体会

最后聊点我自己的习惯吧。用了 Wireshark 这么多年，我的体会是：这个工具的学习曲线其实不算陡峭，真正难的是培养“分层排查”的思维方式。遇到一个网络问题，不要一上来就全量抓包，先想清楚问题出现在哪一层——是物理链路不通，还是二层 ARP 出错，还是三层路由不可达，还是四层端口不通，还是七层应用数据异常。带着这个分层思维去抓包，你会发现过滤器和时间统计的用法完全不一样，每个包在你眼里也不再是一堆十六进制数字，而是一个一个能说话的“现场目击者”。

还有一个很小的技巧，但我想特别送给新人：抓包后一定要养成保存 pcap 的习惯。很多人复现完问题，看完一眼界面就把文件关了，后面再被问到“上次那个包里面有没有 XX 特征”时，只能重新抓一遍浪费时间。我一般会在每个排障项目下建一个文件夹，命名格式是“日期-现象-接口”，把抓到的 pcap 和截图都丢进去，时间一长，这些文件就是自己的排障知识库。再配上 tshark 的二次分析，很多以前要花一小时解决的问题，现在五分钟就能定位。希望这篇东西能帮你把 Wireshark 从“看花眼”变成“看得懂”，以后遇到任何网络疑难杂症，都能多点底气。