上周客服反馈说客户端时不时卡顿，手上没有任何后端日志和监控数据，在线上的服务器前看了半天只能干着急。我打开Wireshark抓了不到两分钟，顺着TCP流里的重传和乱序就定位到了问题——连接池配置得太小，服务端在高并发下频繁断开连接。这活儿如果全靠猜，可能得折腾一个下午。
Wireshark这款免费开源的网络分析工具，在整个网络排障和协议分析领域几乎是绕不开的存在。不管你是开发、运维、测试，还是刚入行的网络小白，只要你需要跟网络数据打交道，就迟早会和它相遇。它能帮你看到网络上每一个数据包的来龙去脉，也能帮你定位“为什么慢”“为什么连不上”“为什么后台收到的是乱码”这类平时让人头疼的问题。
这篇文章不是官方文档的翻译，也不是菜单功能的罗列，而是我长期用Wireshark排查各种疑难杂症后的实战经验总结。从安装、界面、过滤器语法，到抓包分析、手机App调试、疑难杂症排查，一条线捋下来，尽量说人话，保证你照着做就能上手。适合刚接触抓包的新手，也适合已经有基础、想系统补齐技术短板的开发者。
1. 搭建抓包基础环境，熟悉Wireshark的工作界面
1.1 下载安装与驱动选择
先去Wireshark官网下载最新稳定版。Windows安装的时候有一个关键步骤很多人会忽略：安装到组件选择界面，会询问你是否安装Npcap，这里一定要勾选并安装。Npcap是Windows平台上的数据包捕获驱动库，它的前身是WinPcap。Wireshark本身只是一个“分析壳子”，真正从网卡底层抓取数据的活儿是靠驱动完成的，不装驱动等于买了车没装发动机。
旧教材里经常让人装WinPcap，但在Windows 10/11上Npcap已经是主流方案，它对现代网卡驱动、加密回环流量、802.11无线帧的支持都比老驱动好很多，Wireshark新版默认也只有Npcap选项。安装完成后重启一下电脑，让驱动生效，别急着打开软件。
macOS和Linux用户稍微简单点，macOS上直接brew install wireshark，Linux上apt或yum装wireshark，但需要保证当前用户有权限访问网络接口。Linux下如果提示找不到网卡，多半是权限不够，sudo运行或者把用户加进wireshark组即可。
1.2 抓包前必须想清楚的三件事
很多新手打开Wireshark就是选个网卡，然后开始抓，抓了一大堆乱七八糟的包，完全无从下手。我每次抓包前会先逼自己回答三个问题：
第一，我到底要分析哪个网卡上的流量？本机上网走的是有线网卡还是无线网卡？虚拟机里抓宿主机的包，或者远程服务器上用tcpdump抓包再拉回来，网卡选择逻辑完全不同。
第二，我要抓什么样的流量？是某个具体IP的流量，还是某个端口（比如80或443），还是整个网段的广播包？这个决定了我是否要在抓包前就启用捕获过滤器，否则流量一大文件很快就撑爆。
第三，我抓完包打算怎么看？是看三次握手有没有成功，还是分析HTTP接口响应时间，还是查某个DNS解析结果？目标越明确，后面的分析效率越高。
1.3 第一次抓包：网卡选择与基本操作
打开Wireshark，主界面会列出所有可用的捕获接口。很多人栽在第一步：不知道选哪个。我教你一个最笨但最实用的方法——看每个接口后面的“数据包计数”。你打开浏览器随便访问几个网页，谁的计数在疯狂跳动，谁就是当前真正在跑流量的网卡。如果所有接口都在跳，就选那个连接你当前网络的主要接口，有线通常是以太网，无线通常叫Wi-Fi。
选好接口后，双击进入抓包界面。界面上方的工具栏、中间的包列表、下方的包详情和十六进制字节视图，就是Wireshark的三大主战场。包列表是“目录”，告诉你有哪些包；详情是“摘要”，解析了每个字段的含义；字节视图是“原文”，让你看到最原始的二进制数据。
点击红色按钮开始抓包，蓝色方块按钮停止抓包，快捷键是Ctrl+E。抓完记得保存为pcapng格式，这个格式是Wireshark的原生格式，后续可以随时重新分析，不丢信息。
提示：抓包一定要抓“你需要的部分”，而不是“所有的部分”。大流量环境下开着无过滤抓包，几分钟就能产生几个GB的文件，Wireshark处理起来卡到你怀疑人生。后续讲过滤器的时候你就知道，抓包前和抓包后都有控制流量的手段。
2. 过滤器才是效率核心：捕获过滤器与显示过滤器必须分开学
Wireshark里有两套过滤器语法，名字长得很像，但作用机制完全不同。我发现很多人一直没搞懂这两者的区别，导致要么抓了一堆没用的包，要么过滤时表达式老报错。
2.1 捕获过滤器：抓包之前设闸门
捕获过滤器在开始抓包之前设定，作用是在数据包到达Wireshark内存之前就进行过滤。它用的是BPF语法，也就是伯克利包过滤语法，同样的语法在tcpdump里也在用。理解成“漏斗”就行，它决定了哪些数据能进入你的抓包文件。
用捕获过滤器的最大好处是省资源、省磁盘空间。比如我只关心某个IP和80端口的交互流量，那我在捕获选项里直接写：
host 192.168.1.100 and tcp port 80这样抓到的文件小很多，后期分析也聚焦。捕获过滤器默认是不过滤的，但建议在抓包前就设计好，尤其流量大的场景。
常用BPF捕获过滤器参考：
| 过滤目标 | 表达式 |
|---|---|
| 只看某个IP的所有流量 | host 192.168.1.1 |
| 只看某个源IP | src host 192.168.1.1 |
| 只看某个目标IP | dst host 192.168.1.1 |
| 只看某个网段 | net 192.168.1.0/24 |
| 只看某个端口 | port 443 |
| 只看某个源端口 | src port 8080 |
| 排除某个端口 | not port 445 |
| 综合条件 | host 172.16.0.10 and (port 80 or port 443) |
括号、and、or、not这套逻辑表达式学过数据库的都不陌生，组合起来能实现大多数抓包前的预筛需求。
2.2 显示过滤器：抓包之后的万能筛选器
显示过滤器是Wireshark里每天都要用的东西。它不改变抓包文件里的原始数据，只是控制当前界面上显示哪些包。它的语法比BPF友好得多，字段名也更语义化。比如：
ip.addr == 192.168.1.100ip.addr这个字段同时包含源IP和目标IP，所以一条命令就能筛出该IP相关的双向流量，不用像BPF那样分开写src和dst。
初学显示过滤器时死记硬背一堆字段名没多大意义，重点要理解Wireshark里每个协议都会暴露一堆“可过滤字段”。你在包详情里看到哪个字段，右键菜单就有个“作为过滤器应用”选项，点了自动生成表达式，这是最不容易出错的入门路径。
几个我平时用得最频繁的表达式：
# 只看某两个IP之间的对话 ip.addr == 192.168.1.10 && ip.addr == 52.167.10.10 # 只看某IP访问的HTTP流量 ip.addr == 192.168.1.10 && http # 只看DNS请求与响应 dns # 只看TCP重传 tcp.analysis.retransmission # 只看慢响应：RTT大于200ms的ACK tcp.analysis.ack_rtt > 0.2 # 只看包含特定字符串的包（比如某个登录接口关键词） frame contains "login" # 组合过滤：找某个网卡上针对22端口的扫描 tcp.flags.syn == 1 && tcp.flags.ack == 0 && tcp.port == 22记住，显示过滤器里输入的语法错误时，输入框背景会变红，这时候不要点回车，先看哪里写错了。正确时背景是绿色。变红的原因九成是字段名不对，或是比较运算符用错。比如等于是两个等号，不是单个；字符串包含用的是contains，不是==后跟引号。
2.3 一个真实的过滤器组合实战案例
有一次我帮同事排查“某个服务总是超时”的问题，服务端口是8080，服务器IP是10.20.30.40。我先用捕获过滤器只抓这个IP的包：
host 10.20.30.40抓了大约一分钟，停止后输入显示过滤器：
tcp.port == 8080 && tcp.analysis.retransmission几秒钟就看到了二十多次重传记录。再把重传包的时间点导出来对比操作系统日志，发现每次重传时间都对应着一次磁盘IO饱和。一个正经的网络层问题，最后在系统层找到了根因。这个流程里Wireshark过滤器的作用特别直观：没有它，我看到的将是一堆无头无尾的噪声数据。
3. 从“看得见”到“看得懂”：协议分析与HTTP排障实战
抓包只是手段，分析才是目的。这节是本文最核心的部分，认真看完你基本能独立排查一大半日常网络问题。
3.1 TCP三次握手与连接慢的定位方法
任何一个TCP连接，第一个画面通常是三次握手：客户端发SYN，服务端回SYN+ACK，客户端再回ACK。Wireshark的Flow Graph功能能直观展示这个握手过程，菜单路径是“统计” -> “流量图”。如果你看到SYN发出后久久没有SYN+ACK，那说明客户端到服务端的链路有问题，或者服务端根本没在监听。
我最常用的定位网络延迟的方法是看tcp.analysis.ack_rtt这个字段。它记录的是从数据包发送到收到对方ACK所经历的时间，通俗理解就是每一次数据交换的往返耗时。使用显示过滤器：
tcp.analysis.ack_rtt > 0.1就能把RTT大于100毫秒的包全筛出来。正常同城机房内网RTT通常在0.1ms到2ms之间，跨地域公网RTT在20ms到80ms都算正常。如果普遍大于200ms，说明链路质量差或者拥塞严重。
3.2 HTTP接口慢的定位：状态码、响应时间与Follow Stream
排查HTTP接口问题时，我最喜欢直接过滤http，"Follow HTTP Stream"一下，整个请求和响应就完整呈现在你面前。右键任意一个HTTP包，选择“追踪流 -> HTTP流”，就能看到这个TCP连接上所有的HTTP请求和响应。
这里有三个关键信息要会看：
第一是请求行和响应状态码。500、502、504分别代表服务端错误、网关错误、超时，而404之类则是资源不存在，不同的状态码直接决定了排查方向。
第二是Content-Length和Transfer-Encoding。响应内容如果是chunked编码，说明服务端是一点一点往外写的，结合每个TCP包的到达时间能判断是服务端生成慢还是网络传输慢。
第三是发送请求到收到响应的时间差。你可以在包列表里加一列“Time since previous frame in TCP stream”，或者直接看HTTP响应包里的Time字段，就能算出服务端的处理耗时。
有一次前端同学说“某个接口要3秒才返回”，我抓包后发现服务端在收到请求后1.8秒才发出第一个响应字节，问题分明在服务端业务代码，不在网络。把这个截图发给后端，后端看一眼日志就改了两个数据库查询，接口直接降到300ms。这就是抓包的价值——一锤定音地告诉你是谁的问题，而不是互相甩锅。
3.3 HTTPS解密查看：SSLKEYLOGFILE方法详解
很多新手说wireshark抓了包看不懂“乱码”，其实那根本不是乱码，是TLS加密后的密文。想要看到HTTPS里的明文请求和响应，必须让Wireshark拿到每次连接的会话密钥。
解密HTTPS的最佳方案是使用浏览器提供的SSLKEYLOGFILE环境变量。以Windows + Chrome为例：
第一步，新建一个文件夹，比如C:\sslkeylog，在里面新建文件sslkeylog.log。
第二步，设置环境变量。右键“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”，新建用户变量：
变量名：SSLKEYLOGFILE 变量值：C:\sslkeylog\sslkeylog.log第三步，重启Chrome浏览器，访问任意HTTPS网站。这会往日志文件里不断写入key信息。
第四步，打开Wireshark的偏好设置：编辑 -> 首选项 -> Protocols -> TLS，在“(Pre)-Master-Secret log filename”一项填入日志文件路径。
设置完成后重新抓包，你会发现HTTPS数据包的详情里多出了解密的明文信息，追踪流看到的就是和普通HTTP一样清晰的请求响应。Firefox也有类似机制，在about:config里搜索sslkeylogfile，在security.ssl.enable_ocsp_stapling附近的选项可以设置，不过稳定性和可用性还是Chrome方案最好。
注意：SSLKEYLOGFILE只能解密TLS会话，解密的前提是你抓到了对应的握手包，且密钥日志确实是这一条会话的。另外抓加密流量前要确认浏览器确实复用了该密钥日志文件，如果浏览器没重启，日志里可能什么都没有。
3.4 可视化利器：IO Graph和TCP时序图
排查“网络慢”“吞吐低”时，光看单个包远远不够，得看整体趋势。Wireshark提供两种特别有用的图表：
IO Graph能统计每秒的流量数。菜单“统计 -> I/O图”，可以同时叠加多条过滤条件，比如红线代表上行流量，绿线代表下行流量。通过它你能一眼发现流量激增或断崖式下跌的时刻。
TCP时序图（Time-Sequence Graph）能直观展示连接吞吐量的变化，菜单位置在“统计 -> TCP流图 -> 时序图(Stevens 或 tcptrace)”。我习惯看Stevens版本，横轴是时间，纵轴是包的序号。如果图形呈平稳上升的斜线，说明传输流畅；如果出现平台期，说明发生了拥塞或窗口瓶颈；如果出现大量下降沿，则是重传频繁的表现。
有一次我排查视频传输卡顿问题，TCP时序图上出现了非常规律的锯齿形状，一阵一阵地传一阵停一阵。对照IO图发现卡顿的时间节点和某个后台任务恰好重合，原来是备份任务占满了磁盘IO导致网络缓冲区饥饿。这些图不直接告诉你答案，但它们能把“问题是什么样子”画出来，辅助你建立模型。
4. 手机抓包与无线网络场景：从App到Wi-Fi
现在大部分业务都在App和小程序端，电脑上抓包只是一半的功夫。手机端抓包也是日常工作中避不开的场景。
4.1 手机抓包的最简方案：WiFi代理
手机抓包最简单的方式是让手机把流量转发到电脑上。流程如下：
第一，手机和电脑连同一个Wi-Fi。
第二，电脑上开启一个HTTP代理。Windows上可以用Fiddler或Charles，Linux上可以用mitmproxy，Mac上也可以用Charles。这几种代理工具其实都是“中间人代理”，它们的核心能力是把手机发上来的流量接收并转发。
第三，手机Wi-Fi设置里找到代理设置，把代理地址填成电脑的局域网IP，端口填代理工具监听的端口，保存后打开App，流量就会出现在代理工具里。
这种方案的局限在于它只能看到HTTP(80)和HTTPS(443)层面的流量，如果App用了UDP协议、QUIC或者自定义TCP协议，代理工具基本无能为力。这时候就轮到Wireshark登场了。
4.2 用Wireshark给手机抓包的正确姿势
当你已经用Fiddler或Charles配好代理，想让Wireshark同时分析底层的TCP状态时，可以在电脑上先启动Wireshark抓取以太网或Wi-Fi接口的流量，然后在代理工具的配置里把代理的入站流量指向电脑的某个端口。这样Wireshark既能抓到手机经过代理产生的TCP流，也能观察到代理转发过程中的重传和流量情况。
另一种方案是不经过代理工具，直接用Wireshark抓取无线网卡上的包。前提是你的电脑网卡支持混杂模式，且在Wireshark选择接口的时候，勾选了“在所有接口上允许混杂模式”。这种方式能看到手机在Wi-Fi网络中的所有数据帧，但加密Wi-Fi网络下只能看到802.11管理帧，想要看到数据包内容还得配好WPA2解密，操作门槛较高，而且对网卡驱动支持要求比较挑剔。
4.3 App抓包失败的原因排查与SSL Pinning问题
热搜词里“app抓包失败”“charles激活成功后无法抓包”这类问题我一直有关注，这里集中讲一下排查思路。
代理配置没问题却抓不到包的排查顺序：
第一步，确认手机确实走了代理。在手机浏览器里访问http://httpbin.org/ip，如果代理正常工作会显示代理服务器的出口IP，而不是本机的运营商公网IP。
第二步，检查电脑防火墙是否拦截了代理端口。Windows防火墙经常静默拦截入站连接，在防火墙高级设置里放行代理工具的端口就行。
第三步，确认代理工具的“允许远程连接”是打开状态。Fiddler默认只监听本机回环，需要勾选“Allow remote computers to connect”。
如果以上都没问题还是抓不到包，那大概率是目标App启用了SSL Pinning，或者说证书固定机制。这种机制下，App只信任它内置的特定证书，中间人代理的证书会被拒绝，表现就是请求直接失败或者异常关闭。对于这类问题，常规的代理手段解决不了，常规做法是让开发提供测试环境的调试包，或者在已越狱/已root的测试机上做深度证书注入。这部分操作涉及测试工具链和移动端调试，说来话长，不在Wireshark教程范围内，有个思路即可。
4.4 无线网卡监听与USB抓包
有段时间我做IoT设备的协议逆向，设备不支持代理，只能抓无线包。这就需要网卡开启监听模式（monitor mode）。Windows上Intel AX210这类卡开启难度不小，可以看看驱动有没有提供raw socket监听的开关。很多人在wireshark里看到“无线网卡接口无法开启监听模式”的提示，通常是因为驱动不支持或版本太老。相较之下，外置USB网卡比如Realtek 8812BU在Linux下配合monitor mode就稳定得多。
抓到无线包后，默认只能看到802.11层的帧，解析用户流量需要知道Wi-Fi密码。在“编辑 -> 首选项 -> Protocols -> IEEE 802.11”中勾选“启用解密”，填入WPA2密码和SSID，再用抓包期间捕获到的四次握手数据，Wireshark就能解开数据包的真正内容。
USB抓包是另一个冷门场景。Wireshark在Windows上可以通过USBPcap这个插件抓取USB总线流量，主要用在USB外设开发调试和恶意USB设备分析上。安装USBPcap后Wireshark的接口列表里会多出几个USB总线接口，选择对应的总线后抓包即可。USB协议解析不如网络协议丰富，但看设备描述符和U盘数据传输足够了。
5. pcap分析实战与常见问题速查
最后这一节，我把平时最常被问到的问题整理成一个速查表，每个问题背后都有一段实打实的踩坑经历。
5.1 抓到中文怎么是“...”或被截断显示？
用Wireshark看HTTP响应体时，中文经常显示成....，这个其实有三个原因。
原因一是Wireshark默认限制了流的显示长度，Follow Stream时如果数据量大，窗口里只显示前面一部分，后面的内容变成省略号。解决方法是把“追踪流”里的“Show data as”改成Raw，然后另存为原始二进制文件，再用编辑器打开看完整内容。
原因二是HTTP的Content-Encoding是gzip。响应体是压缩后再传输的，Wireshark在流视图里不会自动解压所有压缩内容，你看到的就是压缩后的“乱码”。处理方式是在Follow TCP Stream弹窗里尝试切换解码方式，或者把原始数据保存下来再用gunzip解压，也可以导出HTTP对象后配合curl --compressed分析。
原因三是编码问题。如果是UTF-8编码的中文，在“String”视图下应该能正常显示；如果显示的是一堆%E4%BD%A0之类的百分号，那是URL编码，不是乱码，是正常现象。你要学会分辨“编码后”和“加密后”的区别。
5.2 抓包时间显示的是UTC，想显示北京时间怎么办？
这个问题特别常见。Wireshark默认的显示格式是“自捕获开始后的秒数”，或者UTC时间，容易和北京时间搞混。要调整为你电脑的本地时间，操作是：视图 -> 时间显示格式 -> 选择“日期与时间(日期和时间)”，再把“UTC”切换为“本地时间”，这样显示的就是北京时间了。
如果你曾经保存过pcap文件，里面的时间戳本质上是Unix时间戳，无论你用什么格式显示，原始数据不变。所以不必担心显示格式影响文件本身。
5.3 如何从一个pcap文件里定位“可疑IP”
安全分析场景经常需要快速判断哪个IP是攻击者。流程一般是：先用“统计 -> 端点”看流量Top榜，着重看连接数、收发包数量、转发的字节数。攻击扫描的流量特征是高频、重复、目的端口分散，很容易在端点上形成异常突出的数据。
定位到可疑IP后，显示过滤器里输入：
ip.addr == 可疑IP然后看这个IP具体在做什么。大量SYN请求且没有后续ACK，大概率在端口扫描；大量DNS请求则可能在做DNS隧道。再配合“统计 -> 会话”看它和多少台内网机器发生过通信，基本就能拼出攻击链了。这种思路在分析靶机capture.pcapng这类题目里同样适用，先找端点，再找流量特征，最后看包详情验证。
5.4 想要导出HAR文件给前端做性能分析
Wireshark本身没有一键导出HAR的功能，但它能导出JSON和原始HTTP流。你可以用Chrome开发者工具直接导出HAR，前提是这个网站你能在浏览器里访问；也可以从Fiddler或Charles导出HAR，它们的接口列表更贴近HTTP层面。
如果非要基于Wireshark的抓包结果生成HAR，方法是用“File -> Export Packet Dissections -> As JSON”，把HTTP请求和响应的关键字段录到一个脚本里，自己组装HAR格式。这个方案适合有程序化需求的场景，日常排查建议直接用好浏览器开发者工具的“导出HAR”功能。
5.5 Wireshark捕获接口空白、无法抓包、pyshark兼容性问题
Windows上打开Wireshark却发现所有接口都显示“没有可捕获的数据包”或者接口列表空白，第一件事是以管理员身份重新运行Wireshark。第二件事是检查Npcap服务是否正常，重新安装Npcap能解决八成驱动相关的问题。
在Linux下遇到捕获接口无法选择时，先运行sudo wireshark，或者在终端里执行sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap给dumpcap工具赋予抓包能力，这样普通用户后面才能正常抓包。
Python环境里集成Wireshark经常用的库是pyshark，它本质上是调用tshark命令行工具解析pcap文件。Python 2.7版本的项目遇到pyshark无法抓包，首先核对tshark版本是否与pyshark兼容，其次确认调用时有没有指定tshark路径，最后检查所用的Python版本是否过旧。这个技术栈本身就有点老，遇到问题优先考虑升级方案，而不是在旧版本里死磕。
5.6 抓包文件太大导致卡顿的救急方法
忘了加过滤条件，一抓就是几个GB，Wireshark打开就卡十分钟，怎么办？有两个挽救方案。
第一是使用“文件 -> 导出指定分组”或者通过显示过滤器缩小范围，再在文件菜单里导出当前过滤后的结果。但文件本身太大时导出操作依然很慢。
第二是回到命令行用tshark一次性处理大文件。tshark是Wireshark自带的命令行工具，纯文本处理不会加载整个GUI。用它按过滤器提取子集非常高效，例如：
tshark -r big.pcapng -Y "ip.addr==192.168.1.100" -w filtered.pcapng这样处理几个百MB的文件几秒钟就完成，比GUI硬扛快得多。平时养成抓包前用捕获过滤器、抓包后用显示过滤器的习惯，能避免绝大多数大文件问题。
我个人在实际操作中的体会是，Wireshark真正值钱的地方不在于它会“抓包”，而在于它会“看包”。很多人抓完包之后面对几百兆数据一脸迷茫，核心原因是没有形成一套分析套路。我的建议是先从掌握“筛选重传+TCP时序图+Follow流”这三板斧开始，遇到问题就知道先看三件事：连接是否正常建立、数据是否在持续传输、内容是否符合预期。这三件事能回答80%的日常网络问题，剩下的20%查协议字段，查经验帖，也不会太难。先把这套方法论练熟了，再往深了研究过滤器语法和自动化脚本，你会发现Wireshark从“看不懂”到“离不开”其实并没有那么长的路。
