云海天狼第一次真正用到 Wireshark，是我调一个上云 SDK 的超时问题。当时代码里日志打了“已发出请求”，服务端也说“没收到”，两边都要甩锅给对方。我打开 Wireshark，点了开始捕获，复现了一次请求，结果满屏的 TCP 包根本不是我以为的那样：连接根本没建立成功，三次握手只出去了一个 SYN，后面全是重传。那一刻我才意识到，Wireshark 抓包不是用来“证明请求发出去”的，它是把网卡上经过的每一帧按时间顺序录下来，让你看到协议栈到底做了什么事。
这篇文章就是围绕 Wireshark 抓包实战来写的，不打算念手册，只讲真正有用的部分：怎么选接口、怎么区分两种过滤器、怎么从包里判断三次握手和重传、加密流量还能看什么、包多了怎么用 TShark 批量处理，最后补充无线、USB 这类特殊抓包方向。适合刚接触抓包、想系统排查网络问题的开发、运维和网络工程师。建议你打开电脑跟着操作，因为抓包这种东西，看十篇教程不如自己抓一个错包。
1. 先用一句话说清 Wireshark 的本质：它不是“截图”，是“全程录像”
很多人对抓包的期待是：我点一下开始，然后复现问题，最后得到一个“包”，就能从这“包”里看出是谁的错。这个理解基本是错的。Wireshark 抓下来的不是一个包，而是成千上万个包组成的时间序列。应用层的一次请求，在网络里会被拆成十几个甚至几十个 TCP 分片，每个分片又都有序号、确认号、时间戳。单个包只是拼图里的一块，整体顺序才能还原现场。
1.1 抓包能回答哪类问题，回答不了哪类问题
先说能回答的：
- 连接到底建没建立成功，卡在 TCP 三次握手的哪一步。
- DNS 查询有没有发出去，响应耗时多少，返回的 IP 地址对不对。
- TLS 握手协商到了哪个版本，证书有没有被正确交换。
- 请求发出去之后收到的是 RST、超时，还是正常的 ACK。
- 数据是否出现了重传、乱序、重复 ACK，这往往指向丢包或拥塞。
- 客户端声称发了 10 个请求，实际上网络里只有 2 个，这是非常有力的排障证据。
回答不了的，比如“服务端业务逻辑为什么返回 500”，这属于 HTTP 负载里的业务字段，抓包只能告诉你 500 响应回来了，具体原因得看服务端日志。
1.2 抓包不等于全部数据可见
还有一个容易踩的误区：抓包工具能看到连接双方所有的数据吗？不一定。如果流量走的是你本机网卡，你自然能看到本机发出的和收到的帧。但如果想抓的是交换机上其它两台设备的通信，普通接口模式下你的网卡根本收不到那些帧。交换机会把帧只转发到目标端口，不会广撒网给所有端口。
再说细一点，网卡有一个叫“混杂模式”的功能，打开后可以让驱动把不是发给本机的帧也交上来。但交换机的隔离机制决定了，只要你的端口不是镜像口，开混杂模式也收不到其它设备之间的流量。所以在开发、联调、排障场景下，我建议的原则是：只抓你自己这台设备、自己启动的服务、自己有权分析的数据流，千万不要跑到公网交换机上乱接线采集。这既是效率问题，也是合规底线。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 抓包真正第一步：先把接口选对，不然抓一晚上都是 ARP
Wireshark 启动后，首页会列出一堆接口名称，什么“以太网”“WLAN”“Npcap Loopback adapter”，甚至还有虚拟机的虚拟网卡。新手最容易犯的错是看到一个名字就双击，比如笔记本连着 Wi-Fi，却去抓“以太网”，这时候你访问互联网的流量根本不走这个接口，自然会抓了个寂寞。正确做法是打开任务管理器或系统设置，先确认当前活动网络连接用的是哪块网卡，再回 Wireshark 里选对应名称。
2.1 接口列表里为什么那么多选项
在 Windows 上，Wireshark 通常依赖 Npcap 驱动来读取网卡数据，所以每个能被 Npcap 识别的网卡都会出现。VMware、VirtualBox、Hyper-V 这类虚拟化软件会创建自己的虚拟网卡，也会混在列表里。如果你同时在跑虚拟机，很容易搞混。我的习惯是给接口列表加一列“IP 地址”排序，直接看哪个 IP 是当前我机器正在用的，再双击它，基本不会错。
Linux 下同样，ip addr 看主接口是 eth0 还是 ens33，再回到 Wireshark 抓对应的接口名。如果界面里的接口数量很少或抓不到包，先检查 Wireshark 安装时有没有勾选 Npcap 组件。Windows 下 Npcap 安装失败是最常见的空包原因之一，装完建议重启一次系统，让驱动正常加载。
2.2 一个高效的工作流：先明确“我要抓什么”
我建议不要上来就点开始按钮，先做三件事：
- 写下问题现象，比如“调用某个接口超时”。
- 确认访问的目标 IP 和端口，比如 192.0.2.10 的 443 端口。
- 选择抓包接口，尽量只勾选当前通信相关的网卡。
然后开始抓包、复现问题，等到问题出现后立刻停止，再保存文件。抓包时间越短越好，时间长了包文件会变得巨大。如果你是在做协议分析学习，可以抓个十几秒就够，不用一直挂着。包文件到几百 MB 以后，打开和过滤都会明显变慢，所以控制抓包时长本身就是一种优化。
3. 过滤器的最大坑：捕获过滤器和显示过滤器是两套语法
Wireshark 里有两个“过滤器”入口，长得像，但作用完全不同。工具栏上写着“Capture Filter”的是捕获过滤器，在开始抓包之前设置，作用是只把符合条件的包保存到内存里，不符合的直接丢弃。主界面中间那个写着“Display Filter”的是显示过滤器，抓包结束后输入，作用是把已经抓到的包隐藏掉不符合条件的，并没有删除任何数据。两套语法的字段名完全不一样，这是很多人把网上抄来的表达式粘贴进去却报错的根源。
3.1 捕获过滤器：网卡侧的 BPF 语法
捕获过滤器的历史很老，底层是伯克利包过滤（BPF）语法。它看的是网卡驱动层的字段，所以名字都很底层，比如 host、port、net、tcp。举个例子，如果你只想抓和目标 192.0.2.10 的 443 端口之间的流量，应该写成：
bash复制host 192.0.2.10 and tcp port 443
这段没有引号，也不能用它来筛选 HTTP URI、DNS 域名这类高层字段，因为捕获发生时，Wireshark 还没对应用层做完整解析。设置方式：在 Wireshark 主界面点击捕获过滤器下拉框旁边的“Capture Options”，输入上面的表达式即可。不建议长时间用它做复杂过滤，毕竟如果过滤条件写错，可能把关键包全丢掉，后面再怎么分析都没用了。
3.2 显示过滤器：解析后的字段体系
显示过滤器是 Wireshark 值钱的地方，它是基于协议解析后的字段来写的。同样是筛选目标 IP 和端口，显示过滤器写法是：
bash复制ip.addr == 192.0.2.10 && tcp.port == 443
注意这里用的是 ip.addr，因为显示的包已经解析出 IP 头里的源地址和目的地址。ip.addr == x 的意思是只要包里的源 IP 或目的 IP 任意一个等于 x 就显示。如果只想看从本机发往 192.0.2.10 的包，更精确的写法是：
bash复制ip.src == 192.168.1.100 && ip.dst == 192.0.2.10 && tcp.port == 443
显示过滤器支持很多高级字段，比如 http.request.method == "GET"、dns.qry.name contains "example.com"、tcp.flags.reset == 1 等等。输入时如果字段不存在，编辑框会变红色；字段存在但表达式有逻辑问题，会变黄色。这是 Wireshark 给你的即时提示，别忽略。
提示：显示过滤器只是“临时隐藏”包，不是删除。你随时可以清空过滤框恢复全部包，所以放心大胆实验，不会丢数据。
3.3 我常用的几个过滤器模板
直接列几个我在实际排查中高频使用的过滤条件：
| 目的 | 过滤表达式 |
|---|---|
| 看某个 IP 的所有进出流量 | ip.addr == 192.0.2.10 |
| 只看 HTTP 请求 | http.request |
| 只看 DNS 查询请求 | dns.flags.response == 0 |
| 只看 TCP 重传 | tcp.analysis.retransmission |
| 只看 TCP RST 包 | tcp.flags.reset == 1 |
| 跟踪某条 TCP 连接 | tcp.stream eq 0 |
| 筛选 TLS 握手中的 ClientHello | tls.handshake.type == 1 |
其中 tcp.stream eq 0 非常常用。每条 TCP 连接在 Wireshark 里都有一个编号，称为流编号。右键任何一个 TCP 包，选择“追踪流 > TCP流”，或者直接输入 tcp.stream eq 5，就能把这条连接上所有双向包过滤出来，按顺序回放整个会话，极大提升排查效率。
4. 实例复盘：三个高频故障现场，包是怎么“说话”的
每次讲理论知识多少有点抽象，我挑三个日常工作中最常见的故障现场，带你走一遍实际分析流程。这三个案例没有依赖特殊环境，你完全可以用自己的测试服务复现。
4.1 现象一：客户端一直“连接超时”，日志里全是 Timeout
先说两次抓包通常能定位到哪个起点：
复现步骤：开启 Wireshark，选活动接口，开始抓包，运行客户端，等到超时后停止。
筛选条件：
bash复制ip.addr == 服务器IP && tcp.port == 8081
如果结果里只看到客户端发出的 SYN，没有任何 SYN-ACK，而且 SYN 出现了多次，那就是典型的服务器没响应或中间设备把 SYN-ACK 丢了。判断顺序是：客户端第一个 SYN 发出，等待一段时间没收到包，又重发一个 SYN——这会被 Wireshark 标成 tcp.analysis.retransmission。找到这些包后继续问下一步：为什么服务器的 SYN-ACK 没回来？
这时候要看服务端抓包结果。如果服务端有监听进程，抓包却看不到任何到达的 SYN，那就需要检查两个方向之间的路由、安全组策略、主机防火墙；如果服务端能看到 SYN，但没有响应，重点看服务端程序 backlog 队列是不是满了、系统有没有丢包。一次抓包定位不了全部，但能帮你把排查半径从一个模糊问题缩小到具体环节。
4.2 现象二：请求被“重置”，应用报 Connection reset
重置在包里的表现是 RST 包。筛选条件很简单：
bash复制tcp.flags.reset == 1
看到 RST 后，先看它出现在哪一方。Wireshark 里每一行都有 Source 和 Destination 两列，如果 RST 是从服务器发往客户端的，说明服务器端主动断开了这条连接；反之亦然。常见的几种原因：
- 服务端进程监听端口根本没开，操作系统收到 SYN 后直接回 RST。
- 客户端或服务端程序主动调用 close，且 socket 里还有未读数据，协议栈会回 RST 而不是正常的 FIN。
- 连接超时被中间网络安全设备断掉，也有可能以 RST 形式出现。
把一个 RST 包右键“追踪 TCP 流”，看它之前的数据能了解断开时的上下文。比如某个服务器端口根本没人监听，RST 通常是在 SYN 之后立刻出现，这时处理方案就是去确认服务进程状态和端口监听状态，跟“网络断开”没什么关系。
4.3 现象三：接口响应慢，但应用日志看不出耗时
这种情况我建议把显示列调整一下，加上“时间增量”列。默认情况下 Wireshark 的 Time 列是从开始抓包算起经过多少秒，但排查耗时更看重的是“上一帧和这一帧之间隔了多少毫秒”。右键列头，添加自定义列，字段名填：
bash复制frame.time_delta_displayed
此列会显示当前包和上一个显示过滤后的包之间的时间差。比如你看到一个 HTTP 请求发出后，过了 800ms 才等到服务器的 ACK，那就找到了耗时区间。再结合 DNS 查询、TLS 握手的时间点，就能判断耗时消耗在哪一段。另外还可以用“统计 > HTTP > 请求性能”看整体平均耗时，适合数据量比较大的文件。
5. HTTPS 时代抓包：加密让“看内容”变得困难，但也给了别的线索
以前抓 HTTP，能看到完整的 URL、Header、请求体，分析起来特别直观。现在绝大多数服务都上了 HTTPS，包体内容经过 TLS 加密，直接看是一堆不可读的密文。这不代表 Wireshark 没有作用，实际排障中照样可以利用 TLS 协议本身的结构快速定位问题。
5.1 不用解密也能判断的维度
TLS 握手在加密之前有很多明文字段：
- ClientHello 里包含客户端支持的 TLS 版本、加密套件列表、扩展字段。
- SNI（Server Name Indication）字段会携带客户端要访问的域名。
- ServerHello 里能看出服务端最终选定的 TLS 版本、协商出的加密套件。
- 证书消息在加密前传输，能看到证书链和证书有效期。
筛选 ClientHello 可以输入：
bash复制tls.handshake.type == 1
或者直接看 SNI：
bash复制tls.handshake.extensions_server_name contains "你的域名"
这些信息能帮你在加密流量里做粗粒度判断。比如客户端 TLS 版本太低、服务器拒绝了版本、证书大小异常导致握手慢，都能在不解密的情况下有个初步结论。
5.2 如何在自己有权限的实验环境里解密 TLS
如果你调试的是自己开发的服务、自己控制的测试环境，想直接看到 HTTP 明文，可以在应用侧开启 SSL 日志记录。主流做法是通过环境变量 SSLKEYLOGFILE 把 TLS 会话密钥导出到文件：
- Linux/macOS 命令行启动进程时，先设置
export SSLKEYLOGFILE=/tmp/tlskeys.log。 - Windows PowerShell 里可以用
$env:SSLKEYLOGFILE="C:\temp\tlskeys.log"后再启动进程。 - 浏览器一般也有对应策略，但仅限测试浏览器个人环境。
然后在 Wireshark 里配置：菜单“编辑 > 首选项 > Protocols > TLS”，在 (Pre)-Master-Secret log filename 里填入刚才的日志文件路径。重新抓包后，如果握手成功且密钥匹配，Wireshark 会自动解密 HTTP 明文内容。
重要：这种解密只适用于自己有权控制的客户端和服务端测试环境。请勿用来分析未经授权的第三方流量，也不要把生产环境的密钥文件随意导入抓包工具。做技术实验要有边界感。
6. 数据量一大，界面临危：改用 TShark 和 Python 批量提取
Wireshark 图形界面适合交互式分析，但当你手里有几十个 pcap 文件，或者文件里包含几百万个包，靠鼠标点来点去就不现实了。Wireshark 自带一个命令行版本叫 tshark，它跟 Wireshark 共用同一套解析引擎，能做批量处理。
6.1 TShark 快速提取字段
比如我拿到一个抓包文件 api.pcapng，想提取所有 HTTP 请求的来源 IP、目标 IP、Host、URI，可以这样：
bash复制tshark -r api.pcapng -Y "http.request" -T fields -e ip.src -e ip.dst -e http.host -e http.request.uri
这个命令的意思是用显示过滤器 http.request 过滤出请求包，然后按字段提取。输出是表格，每列对应一个 -e 参数，很容易导入 Excel 或做后续脚本处理。
想统计某种协议的包数量分布，用 -z 参数：
bash复制tshark -r api.pcapng -q -z io,phs
这个输出比 Wireshark 的“协议分级统计”更适合写进报告。想要按 IP 统计流量排行：
bash复制tshark -r api.pcapng -q -z ipv4,hosts
如果要拿 DNS 查询的域名列表做去重统计，可以配合管道命令：
bash复制tshark -r api.pcapng -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c | sort -rn
这在定位“某个域名在短时间内被高频解析”的场景里特别有用。
6.2 用 Python 的 pyshark 时最常遇到的问题
Python 环境里想解析 pcap 文件，很多人用 pyshark 库。它本质上是调用 tshark 引擎再去解析。碰到的头号问题就是“无法打开网卡”或“No such file or directory”。如果你在 Linux 的普通用户下运行 pyshark，tshark 需要读取网络接口的权限，普通用户很可能没有权限。用 sudo 或切换到有抓包权限的用户可以解决，但生产环境不要为了方便直接 sudo 挂一个常驻进程。
还有个更隐蔽的坑：pyshark 解析大 pcap 时默认会把整个文件读入内存再交给 tshark，如果你一次性喂一个 2 GB 的文件，可能会把内存耗尽。建议先用 tshark 把文件切成小段，或者只保留需要的字段再导出，再用 pyshark 做分析。抓包分析本来就是“先缩小范围再精读”，不要一开始就在 Python 里处理全量包。
7. 别把眼光只放以太网：Wireshark 还能做无线、USB、蓝牙抓包
Wireshark 的名字容易让人以为它只处理以太网等常规网卡。实际上，Npcap/libpcap 背后支持多种数据源，Wireshark 还能打开并不少特殊的 pcap 文件格式。这里列出几个在不同场景会用到的扩展方向。
7.1 无线网络抓包：和普通有线抓包的主要差别
在 Windows 上直接抓 Wi-Fi 网卡，多数情况下只能看到本机作为客户端收发的那部分无线帧，而且不是所有网卡都开放了捕获管理帧的接口。想抓满整个信道的无线环境，往往需要网卡和驱动支持“监听模式”。Linux 下可以用 ip link set wlan0 down 配合相关命令把无线网卡切到监听，macOS 对内置网卡也有限制，实验要搭在可信测试环境里。
这里不展开讲盗听场景，因为无线信道的捕获很容易超出授权范围。如果你真的需要做无线协议分析，更合适的做法是搭建自己的实验网络，使用支持监听模式的外置网卡和开源工具，然后把抓到的 pcap 文件放进 Wireshark 分析管理帧、信标帧、认证过程。这个方向对调试 IoT 设备很有价值。
7.2 USB 抓包：一种藏在系统驱动里数据源
有些非网络问题也能靠 Wireshark 分析。比如你在 Windows 上调试一个 USB 设备，发现命令没响应，可以安装 USBPcap 驱动，Wireshark 接口列表里就会多出一个 USBPcap1 之类的新入口，把 USB 总线上传输的 URB 请求抓下来。通过筛选 usb.transfer_type == 0x02 可以看批量传输，配合 usb.idVendor 定位到具体设备，这在做硬件调试时是利器。Linux 系统则用 usbmon 模块，加载后 Wireshark 同样可以读取 USB 流量。USB 抓包和分析门槛比网络抓包高，要求你懂 USB 协议基本概念，但作为排查思路值得记住。
7.3 蓝牙和低功耗蓝牙抓包
抓蓝牙流量比 Wi-Fi 更要看硬件脸色。普通笔记本内置蓝牙一般不给上层提供抓取所有蓝牙数据包的接口，专业一点的方案是使用支持监听模式的蓝牙嗅探器，配合 Wireshark 解析 HCI 日志或基带包。如果你只是调试 BLE 广播包，也可以在代码里开启系统的 HCI 日志，再生成 log 文件导入 Wireshark 查看。这类抓包最有用的场景是分析设备配对失败、连接参数更新和断链原因，但硬件投入通常不会太小。
7.4 远程抓包怎么处理
如果需要分析另一台服务器上的流量，而那里不方便安装图形界面，常见的办法是在远程服务器上用 tcpdump 抓包生成 pcap 文件，再传输到本地用 Wireshark 打开。操作很简单：
bash复制tcpdump -i any -w /tmp/remote.pcap host 192.0.2.10 and port 443
等待复现完成后停止 tcpdump，取回 pcap 文件做分析。如果抓包时间较长，建议按时间轮转写入文件，用 -G 和 -W 参数控制分片数量。对远程服务器的权限管理和 pcap 文件传输，请只在你有管理权限的机器上进行。
最后分享一个我个人的习惯：每次排查问题之前，别急着抓包，先在纸上写清楚“我预期会看到什么、没看到什么代表什么问题”，哪怕只有一句话都行。因为 Wireshark 的信息量太大，没有预期就没有重点，很容易被满屏 ARP、广播包带跑。顺着问题做一轮干净的小流量抓包，会比抓一个巨大的文件然后慢慢搜要高效得多。常用的过滤器建议保存成 Wireshark 的“显示过滤器按钮”，我自己的 Profile 里就存了十几个，比如重传、RST、HTTP请求、DNS查询这些都是固定按钮，替换 IP 就能直接用。抓包这件事，本质上是在帮我们建立一个更真实的网络视角，学会之后，你会发现自己对整个请求链路从“半懂不懂”变成“心里有数”。