Wireshark超详细抓包教程：从安装到HTTPS解密与TCP排查

Wireshark抓包这件事，圈内人都知道它是网络排查的“万金油”。不管你是后端开发、运维、测试，还是刚入门的技术新手，只要跟网络打交道，总有一天会遇到“明明代码没问题，线上就是不通”或者“接口偶发超时，日志又看不出原因”这类玄学现场。Wireshark就是那个能把“玄学”变成“科学”的工具：它会把网卡上经过的每一个数据包原封不动抓下来，把二层MAC、三层IP、四层端口、七层协议内容全部拆开给你看，而且全部是图形化界面，不用记一堆晦涩的命令。

这篇教程我按自己日常排查的思路来写，从安装、界面认识、首次抓包，到过滤规则、协议分析、HTTPS解密、TCP时延分析，再到常见坑的排查，尽量做到“超详细”三个字。内容会比较长，建议收藏后边看边操作，遇到不懂的字段可以直接在Wireshark里点开对照着学，比死记硬背效果好得多。

1. 抓包前先搞清楚：Wireshark到底在抓什么

1.1 抓包的底层原理

Wireshark本身不产生任何网络流量，它只是“旁听”。网卡在正常收发数据时，驱动程序会把收到的数据包交给协议栈处理，而Wireshark做的事情，是在协议栈处理之前，通过底层库（Npcap/WinPcap，macOS和Linux上则是BPF）把经过网卡的原始数据包复制一份出来，然后按照协议规范逐层解码，再呈现在界面上。

这个过程有点像快递驿站门口的监控摄像头：快递员（数据包）把包裹送进驿站（协议栈），监控（Wireshark）在旁边悄悄录下每一辆车的车牌和包裹外观。它不会拦截、修改快递，所以对业务本身是零侵入的。

这里要特别注意一个关键点：Wireshark默认只能抓“本机网卡上能看到的包”。几种常见情况：

• 抓本机进程发出去的请求和收到的响应，没问题。
• 抓经由本机路由转发的包，需要开启混杂模式（Promiscuous Mode）。
• 抓两台服务器之间的通信，如果流量不经过你的电脑，单靠Wireshark是抓不到的，需要镜像端口或者用代理转发。

1.2 合适的应用场景

我把平时用得最多的场景列一下，你可以对照自己的情况判断是否需要它：

• 接口偶发超时，后端日志正常，需要确认请求到底有没有到服务器、响应是什么时候发出的。
• 排查DNS解析慢或解析结果不对，想看看每次查询到底问了哪个DNS服务器、返回了什么IP。
• 调试HTTPS接口，需要解密看明文请求体，确认参数有没有被加密或篡改。
• 分析TCP重传、乱序、零窗口，定位“网络质量差”到底是物理链路问题还是应用没及时读数据。
• 验证自定义协议或抓取恶意流量样本，做安全分析。
• 学习和理解HTTP/2、QUIC这些新协议，看真实的报文交互过程。

2. 环境准备与安装

2.1 安装时最容易踩的坑

Wireshark在Windows上安装时会顺带安装Npcap（新版默认是Npcap，老版本才是WinPcap）。很多人安装完Wireshark之后发现抓不了包，弹窗提示“No interfaces found”或者“You don't have permission to capture”，八成就是Npcap没装好，或者Npcap的“WinPcap API兼容模式”没勾选。

安装时我建议这样操作：

• 从Wireshark官网下载最新的稳定版，别下Beta版。
• 安装到Npcap组件那一步时，把“Install Npcap in WinPcap API-compatible Mode”勾上，兼容性最好。
• 如果公司电脑有安全软件拦截驱动安装，需要提前联系IT放开权限，否则Npcap装不上，后面全部白搭。

macOS用户直接用Homebrew安装最省事：

1. brew install wireshark

复制代码

装完需要给用户授权抓包权限，打开“系统设置 - 隐私与安全性 - 本地网络”，确保终端或Wireshark应用在允许列表里。Linux用户一般用发行版的包管理器，例如Ubuntu：

1. sudo apt install wireshark

复制代码

安装过程中会提示是否允许非root用户抓包，选择“是”，然后把你的用户加入wireshark组：

1. sudo usermod -aG wireshark $USER

复制代码

改完用户组之后记得重新登录，否则权限不生效。

2.2 安装后的基础检查

装完后先别急着抓包，打开Wireshark看一眼主界面，正常情况下会列出当前机器所有的网络接口，包括有线网卡、无线网卡、虚拟网卡（VMware、Docker等）。如果列表是空的，在命令行跑一下：

1. dumpcap -D

复制代码

这个命令会输出所有可用的抓包接口和描述信息。如果这个命令正常但Wireshark里还是看不到接口，多半是权限问题。Windows下确认Npcap服务是否在运行，打开服务管理器，找到Npcap服务，确保状态是“正在运行”。Linux下确认当前用户在wireshark组里，并且重新登录过。

3. 第一次抓包实操

3.1 选择合适的网卡

主界面列出的接口很多，新手容易懵。记住一个原则：你访问目标服务走的是哪个网卡，就抓哪个网卡。

• 本机访问本机服务（比如访问127.0.0.1的接口），选Loopback接口，Windows上叫“Npcap Loopback Adapter”，macOS/Linux叫“Loopback: lo”。
• 访问局域网内其他机器，选有线或无线网卡的接口，通常名字里带Ethernet或Wi-Fi。
• 服务器上有多块网卡时，不确定流量走哪块，可以先打开系统的路由表看一眼，或者干脆全选，后面再用过滤条件缩小范围。

双击选中的网卡即可开始抓包。抓包开始后，工具栏上的“开始捕获”按钮会变成红色方块，界面里会快速滚动大量数据包。

3.2 界面布局和关键面板

Wireshark主界面主要分三块，从上到下依次是：

• 数据包列表区 ：显示每个包的序号、时间、源地址、目的地址、协议、长度、摘要信息。点击某一列，可以按该列排序，方便快速找大包或特定协议。
• 数据包详情区 ：把选中包按照协议栈从下往上逐层展开，链路层、网络层、传输层、应用层。每一层的关键字段都可以展开细看。
• 数据包字节区 ：包在物理链路上的原始字节，十六进制和ASCII对照展示。排查畸形包时，这里是最原始的证据。

第一次抓包你会觉得刷屏速度太快，根本看不完。不用慌，没有人靠肉眼盯滚动看抓包，核心技巧是抓完后停止，然后用过滤规则慢慢分析。这里有一个实用的小习惯：抓包过程中，如果只是为了复现某个偶发问题，最好同时记录一下操作时间和请求结果，方便事后在数据包里定位。

3.3 停止与保存文件

需要停止抓包时，点工具栏上的红色方块按钮。抓到的内容可以“文件 - 保存”成.pcapng格式，后续随时重新打开分析。保存时有两个选项：

• 保存全部 ：保留所有抓到的数据包。
• 保存选中 ：只保存当前选中的数据包，常用于从大文件中截取问题片段发给同事。

我一般线上排查时，会先把抓包文件保存下来，再配合tshark导出一个精简的CSV或者JSON摘要，方便在终端里快速过滤统计。tshark是Wireshark自带的命令行工具，用起来非常方便：

1. tshark -r capture.pcapng -Y "http" -T fields -e ip.src -e ip.dst -e http.request.uri

复制代码

这条命令会从文件里筛选出所有HTTP流量，输出源地址、目的地址和请求URI，作为初步分析非常有价值。

4. 3个必掌握的过滤规则：捕获过滤与显示过滤的区别与使用

4.1 两种过滤容易混淆，先看这个对比

Wireshark里有两套过滤体系，刚接触的人特别容易搞混：

• 捕获过滤（Capture Filter） ：在开始抓包之前设置，作用是从源头“只抓满足条件的包”，不满足的直接丢弃。因为是底层BPF语法，运行效率高，适合长时间抓包节省磁盘。缺点是一旦抓包结束，没被捕获的数据就永久丢了，无法事后补救。
• 显示过滤（Display Filter） ：在抓包完成之后使用，只影响界面显示，不影响原始数据。用错过滤条件，改一下重新输入就行，非常灵活。

我给的建议是：常规排查几乎不需要用捕获过滤，直接全量抓包，然后用显示过滤慢慢分析。只有在流量非常大、磁盘空间受限，或者明确知道只需要某类流量的时候，才用捕获过滤提前筛选。

4.2 捕获过滤的两个典型用法

捕获过滤是BPF语法，端口和协议写法比较固定：

1. # 只抓80端口的TCP流量
2. tcp port 80
4. # 只抓与某个目标IP相关的流量
5. host 192.0.2.10
7. # 只抓DNS查询和响应（UDP 53和TCP 53）
8. port 53
10. # 抓所有HTTP流量（不包含HTTPS）
11. tcp port http

复制代码

BPF语法里没有“http”这种七层协议概念，它只能基于传输层端口判断。所以如果你想抓HTTP，本质上是抓tcp port 80（或者你服务实际使用的端口），这一点和显示过滤器不同。

4.3 显示过滤语法，建议重点掌握这些

显示过滤器使用的是Wireshark自己的语法，功能强大得多，可以通过协议字段精确匹配。我平时最常用的就这几个：

1. # 只看HTTP协议的数据包
2. http
4. # 只看DNS协议
5. dns
7. # 看某个IP相关的全部流量
8. ip.addr == 192.0.2.10
10. # 看某个IP作为源地址发出的流量
11. ip.src == 192.0.2.10
13. # 看TCP端口8080的流量
14. tcp.port == 8080
16. # 看HTTP响应状态码为500的包
17. http.response.code == 500
19. # 看TCP重传的包
20. tcp.analysis.retransmission
22. # 看TCP三次握手（只筛选SYN包）
23. tcp.flags.syn == 1 && tcp.flags.ack == 0
25. # 排除ARP等广播噪音
26. !(arp or dns)

复制代码

组合条件用逻辑运算符：

1. # HTTP协议且目标IP是内网某台机器
2. http && ip.dst == 192.0.2.20
4. # 80端口或443端口
5. tcp.port == 80 || tcp.port == 443

复制代码

需要注意的是， ip.addr == x.x.x.x 这种写法是“或”逻辑，只要包的源或目的地址中任意一个匹配就显示。如果你想严格区分方向，必须用 ip.src 和 ip.dst 分开写。这是新手很容易踩的坑，会导致过滤出来的数据比预期多一倍。

5. 一眼看懂HTTP与DNS报文，拿真实抓包说话

5.1 HTTP请求和响应里，重点关注什么

在显示过滤栏输入 http ，然后随便点击一个请求包，详情区会展开HTTP协议层。我一般重点关注这几个点：

• Request URI ：请求的URL路径，确认打的是哪个接口。
• Request Method ：GET/POST/PUT等，确认方法是否符合预期。
• User-Agent ：客户端标识，排查爬虫或非预期客户端调用时很有用。
• Response Code ：HTTP状态码，配合时间列可以判断服务端响应快慢。

如果想快速定位某个接口的完整请求响应过程，可以先定位到GET或POST请求包，然后右键 - “追踪TCP流”，Wireshark会把这条TCP连接上的所有HTTP请求响应合并成一个可视化文本，按时间顺序展示，请求和响应交替出现。这个功能在排查一个页面“加载慢”或者“请求被截断”的时候特别好用。

比如我在某个项目里排查过这样一个问题：前端反馈上传文件偶发失败，服务端日志完整记录了请求，但返回给客户端的响应总是一个不完整的JSON。通过“追踪TCP流”发现，服务端包体在传输中被分包，中间还混着一个来自反向代理的TCP Keep-Alive包，导致客户端在解析时提前截断。这个用日志很难看出来，但在TCP流视图里一目了然。

5.2 DNS报文拆解：比nslookup更直观

在显示过滤栏输入 dns ，然后随便点一个DNS查询包，你可以看到一场完整的“问路”过程：

• Transaction ID ：事务ID，请求和响应需要一致，客户端靠这个把查询请求和响应配对。
• Queries ：查询的域名和类型，比如A记录、AAAA记录、CNAME记录等。
• Answers ：响应里给出的IP地址。
• Response time ：从发出查询到收到响应的时间，如果这个时间忽大忽小，DNS解析就是“慢请求”的头号嫌疑。

排查某个站点访问慢时，最直接的办法是抓包后，在过滤栏输入 dns.time > 0.1 ，看看哪些DNS查询的耗时超过了100毫秒。DNS请求本身走UDP，如果一个域名需要多次递归查询，那么每一次递归都会增加延迟。抓包能看到客户端到底问了几次DNS服务器、每次问的是哪个域名，这种证据比“感觉慢”有说服力得多。

6. HTTPS流量解密，其实不需要插件

6.1 解密原理：浏览器配合导出会话密钥

很多人在这一步被劝退了，以为HTTPS解密需要搞什么中间人劫持，其实Wireshark支持直接解密HTTPS，前提是你得让浏览器或客户端把TLS会话密钥导出给Wireshark。

现代浏览器基本都支持通过环境变量读取SSLKEYLOGFILE来导出密钥。原理是TLS握手的最后一步会生成对称加密密钥，浏览器在用这个密钥加密应用数据之前，会把密钥写入指定文件。Wireshark读取这个文件后，就能用密钥解密之前抓到的密文。

严格来说，这个方式只适用于你有权控制客户端的情况，调试自己的服务、前端联调、本地排查都是合规的。不要去解密别人的流量，那既不合规也不道德。

6.2 具体配置步骤

以Chrome浏览器和Windows/macOS为例：

在系统环境变量里新增一个变量，名字是 SSLKEYLOGFILE ，值填一个你本地有写权限的文件路径，比如：

1. C:\Users\你的用户\sslkeylog.log

复制代码

macOS/Linux可以使用：

1. export SSLKEYLOGFILE=~/sslkeylog.log

复制代码

然后用终端重新启动Chrome，这样Chrome的TLS密钥会自动写入这个文件。

接着打开Wireshark，“偏好设置 - Protocols - TLS”，在“(Pre)-Master-Secret log filename”一栏填入这个文件的路径，保存后重新抓包。你会发现HTTPS流量变成了明文，界面上直接能看到HTTP请求和响应内容。

• 如果抓包过程中密钥文件持续增长，说明Chrome正在写入密钥，没问题。
• 如果解密后还是看不到HTTP，先确认抓包时间是否在设置密钥文件之后，因为TLS握手完成前和会话复用后的密钥处理方式不同，不一定每个连接都能解出来。
• 不改全局环境变量的话，可以用命令行参数临时开启：

1. google-chrome --ssl-key-log-file=/path/to/sslkeylog.log

复制代码

6.3 几个常见解密失败的原因

我总结过自己遇到的解密失败场景，基本集中在以下几点：

• 密钥文件路径写错，Wireshark提示找不到文件。路径里尽量不要带中文和空格。
• 浏览器是通过快捷方式启动的，快捷方式没有继承环境变量，所以密钥文件一直没写入数据。
• 使用的是TLS 1.3，密钥导出格式没问题，但部分场景下0-RTT数据无法解密，只能看到部分明文。
• 抓包文件是在没有配置密钥文件的机器上抓的，事后想解密一般很难，除非你手里有当时的私钥或者密钥文件。

7. 一分钟看懂TCP三次握手，用统计图排查慢请求

7.1 三次握手怎么看

在过滤栏输入 tcp.flags.syn == 1 || tcp.flags.fin == 1 ，可以筛选出TCP连接建立和关闭的包。标准的TCP建立过程是这样的：

• 第一个包：客户端发SYN包，SYN标志为1，SEQ是客户端的初始序列号。
• 第二个包：服务端回SYN+ACK包，表示收到并同意建立连接。
• 第三个包：客户端再发ACK包，此时握手完成，连接进入ESTABLISHED状态。

在Wireshark里，第三次握手后的包通常就是从客户端发往服务端的首个应用层数据了。如果你看到只有第一个SYN，没有后续的SYN+ACK，大概率是服务端没监听这个端口，或者中间防火墙把SYN丢弃了。如果SYN重传了好几次才看到响应，那就是网络延迟高或者服务端backlog队列满了。

7.2 用统计图定位慢请求

Wireshark自带的“统计 - 流量图”功能（老版本叫IO Graph）可以用来做宏观分析。你可以设置多条过滤规则：

• tcp.analysis.retransmission 画出“重传包分布图”。
• http.response.time 画出“HTTP响应耗时分布图”。
• tcp.time_delta 可以看每个包之间的间隔，定位“某一段时间内没数据”的空窗期。

我遇到过一次比较典型的案例：某个内部系统每天晚上8点准时卡顿，持续5到10分钟。抓包后发现重传包在那个时间段密集出现，TCP窗口反复变小，但服务器CPU和内存都正常。后来定位到是某台交换机端口协商成了半双工模式，冲突导致重传率飙升。这种问题如果不看包，光凭服务端监控根本查不出来。

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

8.1 高频问题速查表

现象	典型原因	排查方向
抓包界面没有接口可选	Npcap未正确安装或权限不足	检查Npcap服务状态，管理员身份运行Wireshark
只能抓到发送的包，抓不到接收的包	网卡混杂模式未开启，或使用的是Wi-Fi网卡（无线网卡驱动常限制抓包）	在Capture Options中勾选Promiscuous Mode；有线网卡更稳定
HTTP请求能看到，但看不到响应	响应在另一条TCP连接上，或服务端根本没回包	使用“追踪TCP流”查看完整交互
HTTPS全是TLS握手，看不到明文	没有配置SSLKEYLOGFILE或配置失败	检查TLS偏好设置，确认密钥文件生成时间
TCP重传包大量出现	网络丢包、链路质量问题、服务端处理慢	结合服务端日志和流量图，区分是发送方丢包还是接收方处理不过来
过滤条件输错没有任何提示	显示过滤语法错误，Wireshark会置灰，但新手容易忽略	观察过滤输入框是否为绿色，绿色才代表语法正确
pcapng文件打不开	版本过旧或文件损坏	用tshark尝试读取， tshark -r file.pcapng

8.2 抓包现场的几个实操技巧

抓包是在真实环境里干活，环境越复杂，越要提前想清楚。分享几个我自己的习惯：

• 先小后大 ：不确定抓包范围时，先用显示过滤抓一小段确认流量长什么样，再决定是否扩大抓取量。不要一上来就全量抓一整夜，那只会收获一个巨大且难以分析的文件。
• 标记关键时刻 ：抓包过程中按下Ctrl+M给当前包打标记，方便事后定位“问题发生的那个时间点”。比如复现问题时，在界面上选中当时那个请求，标记之后回头看非常方便。
• 善用tshark做初步分析 ：界面操作适合交互式查看，但做统计、批量取字段时，tshark比鼠标快得多。举个例子：

1. # 统计TCP重传率
2. tshark -r capture.pcapng -Y "tcp.analysis.retransmission" | wc -l
4. # 导出每个HTTP请求的URI和耗时
5. tshark -r capture.pcapng -Y "http.request" -T fields -e http.request.uri -e http.time

复制代码

• 保存小文件再分析 ：大文件在界面里操作会卡。先用显示过滤筛选出可疑流量，然后右键“导出分组 - 导出特定分组”，只保留问题相关的包，再在新窗口里专注分析。
• 忽略背景噪音 ：抓包文件里往往有大量的mDNS、SSDP、ARP请求，不是目标问题，果断过滤掉。否则信息过载会让你看不清主干。

8.3 一次典型排查的过程复盘

有一个印象比较深的案例，某服务通过HTTPS调第三方支付接口，线上偶尔出现请求超时。服务端日志显示连接已建立，但读不到响应。我抓包后发现，TLS握手完成后，服务端发出的第一条应用数据迟迟没有返回，中间出现了几个TCP Keep-Alive包。问题就出在第三方网关的负载均衡器上，它在TLS结算后空闲了将近30秒才把请求转发到后端，而后端应用自身空闲超时设置太短，连接被关闭。这个例子说明，很多“网络问题”实际上不是丢包，而是应用超时配置和网络设备策略共同作用的结果。抓包能帮你看见整个链路，至于策略是谁配的，就需要跨团队沟通了。

9. 结个尾：抓包，本质上是对业务链路的尊重

学Wireshark这件事，上手并不难，一周足够把常用功能玩熟，但真正值钱的不是操作，而是“网络分层”的思维方式。抓到包之后你能不能回答“这个字段为什么会出现在这里”“为什么这个过程多了一个RTT”“这层是TCP干的还是应用层干的”，这些才是一个人的功力所在。

我自己用过一段时间之后最大的感受是，Wireshark可以帮你把很多“猜”变成“看”。服务端看日志、客户端看控制台，都有可能漏掉“中间人”视角的问题，而网卡上的原始数据包恰恰是最接近物理真相的。再加上Wireshark自带统计工具和分析能力，只要熟练一点，日常百分之八十的连通性、性能、协议问题都能独立定位到具体环节。

如果你刚接触Wireshark，我的建议是别急着学冷门的协议分析，先拿自己本机的HTTP请求练手，把过滤、追踪流、解密这几件事玩顺了，再逐步扩大到TCP性能分析、DNS排查、TLS握手排查。希望这篇教程能帮你少走一些弯路。