不管是做网络安全、开发调试还是网络运维的人手里都得有个好使的抓包工具。而在这一堆工具里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 之后会看到一个网卡选择列表。很多人到这里就迷茫了我究竟该选哪张网卡这里有个经验如果只是看本机回环流量比如本机服务之间通信、抓浏览器的请求选 Loopbacklo或 Npcap Loopback Adapter如果要分析局域网里其他设备的报文那就绝对不能忽略“混杂模式”这个开关。Wireshark 默认会把网卡设为混杂模式相当于把你网卡能听到的所有数据包都收进来而不仅仅是发给自己的包。关掉混杂模式后你只能看到发给自己 MAC 地址的单播包和广播包分析局域网内其他设备的流量时就会什么都看不到。真正动手之前还有三个配置习惯我建议你先养成。第一在 “捕获 - 选项” 里面把 “使用 promiscuous mode on all interfaces” 勾上这个一般默认就开然后到 “统计” 菜单里打开 “协议分级” 之前最好先做一次采样测试看看自己的接口流量正不正常。第二在 “视图 - 时间显示格式” 里把时间改成 “自抓包开始的秒数” 或 “UTC 日期和时间”不要用默认的相对时间。原因很简单分析异常流量时你需要精确到毫秒级的时间戳来做关联比如排查 DNS 慢查询时你看发起时间和响应时间差了多少毫秒这直接决定了你是不是要走对排查方向。第三开启 “视图 - 着色规则”Wireshark 自带了一套基于协议和 TCP 标志的着色规则比如 TCP 重传会显示为浅红色TCP 乱序会显示为黄色。刚开始你可以直接用默认设置等看得多了再调整成自己的风格。2. 抓包与过滤器从“看得见”到“看得懂”2.1 捕获过滤器与显示过滤器的本质区别抓包前设置的那个过滤叫做“捕获过滤器”Capture Filter它的作用是决定哪些包被放进内存这个过滤是由底层 libpcap/WinPcap 完成的。语法用的是 BPFBerkeley 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 常用过滤器表达式速查表为了方便你直接抄作业这里整理了一份我日常用得最多的过滤器表达式适用于大多数排查场景需求过滤器写法看某个主机的全部流量ip.addr 192.168.1.100看某个 TCP 端口的流量tcp.port 8080看 HTTP 请求报文http.request看 HTTP 响应报文http.response看 HTTP 响应码http.response.code 404看 TLS 握手包tls.handshake.type 1看 DNS 查询请求dns.flags.response 0看 DNS 响应dns.flags.response 1看 TCP 重传tcp.analysis.retransmission看 TCP 零窗口tcp.analysis.zero_window看 ARP 报文arp看 DHCP 报文dhcp看长度超过 1400 的包frame.len 1400搜索包含特定字符串的包frame contains password这些过滤器看起来简单但组合起来威力巨大。比如你要定位一个“访问特定域名返回 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 会用seq0这种相对序列号显示方便我们观看。第二个包是服务端回复的 SYN-ACK标志位是0x012它除了自己随机一个初始序列号外还带了一个ACK1表示收到客户端的 seq0 之后的期待下一个字节。这个 ACK 就不是 1 字节那么简单了它代表的是“下一字节的序号”。第三个包是客户端的 ACK标志位是0x010里面带着ACK1此时连接才真正建立。为什么要理解这一点因为如果第三个 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 后用脚本来分析。比如你可以用 tsharkWireshark 的命令行版本跑一条命令tshark -r capture.pcap -Y tcp.flags.syn1 tcp.flags.ack0 -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(interfaceeth0)报权限错误就加上use_jsonTrue参数或者用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 甚至几个 GBWireshark 打开卡成幻灯片是家常便饭。几个建议第一使用dumpcap命令行工具抓包而不是直接用 Wireshark 的图形界面它能更高效地落盘第二在抓包前就设置环形缓冲在“捕获 - 选项”里把输出改成多个文件、每个文件 100MB、保存最近 20 个文件这样既不会撑爆磁盘又能保留最近一段时间的流量第三不要在 Wireshark 里直接分析特大文件先用editcap -c 100000 input.pcap split/out.pcap把它切成多个小文件再逐个看。抓包时机方面很多人习惯先开启抓包再复现问题这很可能错过早先的问题报文。正确的做法是常驻一个环形缓冲让 Wireshark 一直处于记录状态等异常出现后再停下来这样可以保证你拿到了完整的“案发现场”。6.5 HTTP/2、QUIC 与 TLS 1.3 对抓包的影响现在的互联网流量已经大量使用 HTTP/2 和 QUICWireshark 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 从“看花眼”变成“看得懂”以后遇到任何网络疑难杂症都能多点底气。
不管是做网络安全、开发调试还是网络运维的人手里都得有个好使的抓包工具。而在这一堆工具里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 之后会看到一个网卡选择列表。很多人到这里就迷茫了我究竟该选哪张网卡这里有个经验如果只是看本机回环流量比如本机服务之间通信、抓浏览器的请求选 Loopbacklo或 Npcap Loopback Adapter如果要分析局域网里其他设备的报文那就绝对不能忽略“混杂模式”这个开关。Wireshark 默认会把网卡设为混杂模式相当于把你网卡能听到的所有数据包都收进来而不仅仅是发给自己的包。关掉混杂模式后你只能看到发给自己 MAC 地址的单播包和广播包分析局域网内其他设备的流量时就会什么都看不到。真正动手之前还有三个配置习惯我建议你先养成。第一在 “捕获 - 选项” 里面把 “使用 promiscuous mode on all interfaces” 勾上这个一般默认就开然后到 “统计” 菜单里打开 “协议分级” 之前最好先做一次采样测试看看自己的接口流量正不正常。第二在 “视图 - 时间显示格式” 里把时间改成 “自抓包开始的秒数” 或 “UTC 日期和时间”不要用默认的相对时间。原因很简单分析异常流量时你需要精确到毫秒级的时间戳来做关联比如排查 DNS 慢查询时你看发起时间和响应时间差了多少毫秒这直接决定了你是不是要走对排查方向。第三开启 “视图 - 着色规则”Wireshark 自带了一套基于协议和 TCP 标志的着色规则比如 TCP 重传会显示为浅红色TCP 乱序会显示为黄色。刚开始你可以直接用默认设置等看得多了再调整成自己的风格。2. 抓包与过滤器从“看得见”到“看得懂”2.1 捕获过滤器与显示过滤器的本质区别抓包前设置的那个过滤叫做“捕获过滤器”Capture Filter它的作用是决定哪些包被放进内存这个过滤是由底层 libpcap/WinPcap 完成的。语法用的是 BPFBerkeley 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 常用过滤器表达式速查表为了方便你直接抄作业这里整理了一份我日常用得最多的过滤器表达式适用于大多数排查场景需求过滤器写法看某个主机的全部流量ip.addr 192.168.1.100看某个 TCP 端口的流量tcp.port 8080看 HTTP 请求报文http.request看 HTTP 响应报文http.response看 HTTP 响应码http.response.code 404看 TLS 握手包tls.handshake.type 1看 DNS 查询请求dns.flags.response 0看 DNS 响应dns.flags.response 1看 TCP 重传tcp.analysis.retransmission看 TCP 零窗口tcp.analysis.zero_window看 ARP 报文arp看 DHCP 报文dhcp看长度超过 1400 的包frame.len 1400搜索包含特定字符串的包frame contains password这些过滤器看起来简单但组合起来威力巨大。比如你要定位一个“访问特定域名返回 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 会用seq0这种相对序列号显示方便我们观看。第二个包是服务端回复的 SYN-ACK标志位是0x012它除了自己随机一个初始序列号外还带了一个ACK1表示收到客户端的 seq0 之后的期待下一个字节。这个 ACK 就不是 1 字节那么简单了它代表的是“下一字节的序号”。第三个包是客户端的 ACK标志位是0x010里面带着ACK1此时连接才真正建立。为什么要理解这一点因为如果第三个 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 后用脚本来分析。比如你可以用 tsharkWireshark 的命令行版本跑一条命令tshark -r capture.pcap -Y tcp.flags.syn1 tcp.flags.ack0 -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(interfaceeth0)报权限错误就加上use_jsonTrue参数或者用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 甚至几个 GBWireshark 打开卡成幻灯片是家常便饭。几个建议第一使用dumpcap命令行工具抓包而不是直接用 Wireshark 的图形界面它能更高效地落盘第二在抓包前就设置环形缓冲在“捕获 - 选项”里把输出改成多个文件、每个文件 100MB、保存最近 20 个文件这样既不会撑爆磁盘又能保留最近一段时间的流量第三不要在 Wireshark 里直接分析特大文件先用editcap -c 100000 input.pcap split/out.pcap把它切成多个小文件再逐个看。抓包时机方面很多人习惯先开启抓包再复现问题这很可能错过早先的问题报文。正确的做法是常驻一个环形缓冲让 Wireshark 一直处于记录状态等异常出现后再停下来这样可以保证你拿到了完整的“案发现场”。6.5 HTTP/2、QUIC 与 TLS 1.3 对抓包的影响现在的互联网流量已经大量使用 HTTP/2 和 QUICWireshark 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 从“看花眼”变成“看得懂”以后遇到任何网络疑难杂症都能多点底气。
