很多年前我在一个项目上遇到过一件很典型的事：系统上线后偶尔出现页面白屏，开发说后端接口响应正常，运维说服务器 CPU、内存都没压力，网络组更是一口咬定链路没告警。三方僵持了大半天，最后有人提议在客户端上开 Wireshark 抓 30 秒数据包。结果只看了三个信息——DNS 响应时间、TCP 重传次数、HTTP 状态码，问题就清楚了：其中一个后端节点的网络延迟偶尔会飙到两秒以上。从那之后我对"抓包是最直接的真相"这句话深信不疑。
这篇内容面向完全没接触过 Wireshark 的人，也面向用过一段时间但只会看个大概的朋友。我会按我自己的上手路径来写：先弄明白它到底在抓什么，再讲安装配置，然后重点说过滤器的用法，接着是 TCP 连接分析，最后用一个"网页打不开"的真实场景串联整个流程，末尾补充一些进阶技巧和踩坑经验。整篇走的是实操路线，每个步骤都解释清楚为什么这么做，这样你拿到任何环境下都能自己举一反三。
1. 抓包背后发生的事：帧、接口与混杂模式
1.1 一个数据包从应用到网线的完整旅程
不要一上来就开软件点开始，先花五分钟搞清楚 Wireshark 抓到的到底是什么，否则后面分析时会一直犯迷糊。
你在浏览器里输入一个网址并回车，产生的是应用层数据（HTTP 请求）。这串数据向下经过操作系统内核的协议栈：TCP 层给它加上源端口、目的端口和序列号，封装成 TCP 段；IP 层再加上源 IP、目的 IP，封装成 IP 包；到了数据链路层，再包上一层以太网帧头，里面写着源 MAC 地址和下一跳 MAC 地址。最后这个完整的以太网帧，才由网卡变成电信号或无线信号发到线路上。
Wireshark 抓到的就是这个最底层的以太网帧，也就是物理链路上真实跑过的数据。正因为它工作在数据链路层，所以它能看见的协议非常全：从二层的 ARP，到三层的 IP、ICMP，再到四层的 TCP、UDP，以及更上层的 HTTP、DNS、TLS，全部被包在一个个帧里。这也是它能作为"全栈排障工具"的根本原因。
这个过程里有一个关键点：Wireshark不做任何加密和解密（除非你后面配置了解密密钥），它只是把网卡收到的字节原样记录下来，然后根据协议规范把字节段拆解成"源端口、目的端口、标志位、载荷"这种人类能看懂的结构。所以你看到的每一个字段，都是从原始数据里解析出来的，不是我编的。
1.2 Wireshark 在哪个位置"旁听"
这里要澄清一个常见误区：Wireshark 不是路由器，也不是交换机的管理系统，它不能拦截所有经过网络的数据包。它在你一台机器的网卡上工作。
传统网卡有个特点：正常情况下，它只会把发给自己的帧收上来，和自己无关的帧直接丢弃。但抓包软件需要"听"到更多的数据，这时候就要启用网卡的混杂模式（Promiscuous Mode）。开启之后，网卡会把经过它的每一个帧都先拷贝一份交给抓包驱动，再由 Wireshark 展示。
那问题来了：现在的交换机是"按需转发"的，不会把每个包都广播到所有端口。哪怕你开了混杂模式，也只能抓到两种流量：发往本机的、本机发出的，以及在冲突域里广播的。如果你需要分析另一台机器的流量，得在交换机上配置端口镜像，把目标端口的流量复制一份到你的抓包端口，或者在那台机器上直接抓。这一点在规划抓包位置时要想清楚，不然很容易出现"明明在抓，什么都抓不到"的现象。
Wireshark 能带的协议不只是传统以太网上的 IP/TCP。只要接口类型支持，它也能捕获 USB 总线数据、蓝牙报文、802.11 无线帧等。日常做网络分析时，你基本只关心基于以太网的 IP 协议族，但如果做无线调试或 USB 设备调试，Wireshark 同样是利器，这个后面简单提。
1.3 它能解决什么问题，解决不了什么问题
从实战角度来看，Wireshark 的价值集中在四个场景：
故障排查：网页打不开、视频卡顿、数据库连接超时、文件传输中断，这些现象背后到底是 DNS 解析失败、TCP 握手被防火墙丢弃、还是应用层迟迟不返回，抓包一看便知。
性能分析：延迟高时，能区分是网络传输耗时还是服务器处理耗时；通过重传率、重复 ACK、窗口大小变化，能推断链路质量和接收端处理能力。
安全分析：异常扫描、暴力破解、外联可疑 IP、DNS 隧道等行为，都会在流量特征中露出痕迹，很多岗位的应急响应第一步就是抓取并分析流量。
协议学习与开发调试：学生和新手通过观察三次握手、HTTP 请求响应格式、TLS 握手过程，比看十遍教科书都直观；做网络协议开发的工程师，也离不开抓包来验证自己的实现是否正确。
但也要说清楚 Wireshark 的边界。它是被动分析工具，不是主动测试工具，它不会帮你发起请求，也不能直接修改流量（改包测试请用 Scapy 或专门的流量发生器）。它看不到加密内容，TLS 加密的载荷在没有密钥时只是乱码。它也无法捕获已经被网卡硬件卸载处理掉的数据，比如某些校验和、分段重组，这点后面案例会提到。
2. 安装环节最容易走偏的几步：版本、驱动与首启配置
2.1 版本选择与下载原则
Wireshark 的官方网站是 wireshark.org，下载页面会同时提供 Windows、macOS 和源代码包。版本上，建议直接选当前最新的稳定版。Wireshark 的发布频率很高，新版本不仅修正了很多解析器 bug，还会及时更新对新协议的支持。老版本偶尔会出现某个协议字段解析异常，甚至解析器崩溃，这会直接影响分析判断。
Linux 发行版一般也自带 Wireshark，但软件源里的版本往往偏旧。如果只是学习，直接用发行版源里的版本没任何问题；如果是要研究较新的协议，或者分析 Windows 10/11 上的某些专有协议，建议下载官方 Linux 安装包或自己编译最新版，不过编译依赖较多，对新手不太友好，多数情况下源里的版本够用了。
下载时还有一个容易忽略的点：看清平台的安装包版本，Windows 用户选 64 位安装包，macOS 用户注意从 Apple Silicon 对应的安装包获取。安装全程默认配置即可，不需要额外选装其他组件。
2.2 Npcap 驱动的安装与取舍
Windows 上安装 Wireshark 时，安装向导会提示你安装Npcap，这是 Wireshark 在 Windows 平台工作的核心驱动，负责从网卡抓取原始帧。绝大多数情况下，你只需要勾选"Install Npcap"并一路 Next 就能正常工作。
安装界面里有几个选项值得认真对待：
"Support raw 802.11 traffic"这个选项如果勾选，在无线网卡上可以抓到带 802.11 管理帧的原始无线数据，对做 Wi-Fi 协议分析很有用。缺点是它要求重启系统，且部分无线网卡驱动不支持，会长期显示"没有设备"。我个人的建议是：如果你不确定自己是否需要分析无线管理帧，不勾选，减少很多麻烦。
"Restrict Npcap to admin-only access"默认勾选。它会限制 Npcap 只允许管理员权限的进程访问抓包接口，普通用户运行 Wireshark 时需要以管理员身份运行，否则看不到接口或抓不到包。追求省事的可以把这行去掉，让普通用户也能抓包；但安全性会降低，按实际场景取舍即可。
Npcap 是一个内核级驱动，会插入操作系统协议栈，存在极小概率与某些安全软件、接入客户端产生冲突。如果你发现安装 Wireshark 后系统出现异常蓝屏或网络不稳定，可以先卸载 Npcap 验证是不是它导致的。这类问题准确说不是 Wireshark 本身的锅，而是内核驱动之间的兼容性问题，遇到时别慌，按"先卸载验证、再逐项排查"的方法走就能定位。
macOS 用户不需要装 Npcap。Wireshark 安装包会附带两个辅助工具：ChmodBPF 用于调整抓包权限，Wireshark 的 Install 包会自动配置好。Linux 用户需要确认自己有没有抓包权限，要么用 root 运行，要么把用户加入wireshark组，通常安装后系统会给出提示。
2.3 打开软件后的第一件事：时间显示与名字解析
第一次打开 Wireshark 的欢迎界面，会看到一张网卡列表，每张网卡后面会弹跳动条，显示实时流量速率。这时如果双击网卡，就会直接开始抓包，但突然涌进来的大量颜色各异的数据包很容易让新手不知所措。
我的建议是：抓包前先把几个基础设置改掉。
第一个是时间显示格式。默认显示的是"自这次抓包开始后经过的秒数"，看单个包还好，做多包延迟分析时非常不方便。我习惯改成"自上一个数据包经过的秒数"。这样相邻两条报文之间的耗时能直接读出来。设置路径在 View → Time Display Format，勾选 "Seconds Since Previous Captured Packet"。如果是分析跨长时间段的故障，也可以切到 "Time of Day"，方便和日志时间对齐。
第二个是名字解析。Wireshark 默认会尝试解析 MAC 地址厂商、IP 地址对应的主机名、端口对应的服务名。解析功能在多数情况下是贴心的，比如看到80就显示http，能省不少查询时间。但主机名解析依赖 DNS，如果一个包连到一个解析慢的 DNS，整个显示会卡住。常见做法是：保留 MAC 解析和端口解析，关掉 IP 解析，避免分析时出现可疑的延迟。
第三个是界面布局。Wireshark 主界面从上到下分四块：过滤器栏、数据包列表、数据包详情、数据包字节。左侧边栏是"显示过滤器表达式"快捷区和"捕获过滤器"管理区，底部是状态栏及专家信息警告入口。记清楚这四个区块，后面找东西才不会到处乱翻。
2.4 权限与设备选择：抓不到包时先查这里
Linux 和 macOS 上，最常遇到的报错是There are no interfaces on which a capture can be done，也就是看不到任何网卡。这一般不是软件坏了，而是权限不够。解决方法是把当前用户加入抓包组，比如 Debian/Ubuntu 上是wireshark组，执行sudo usermod -aG wireshark 你的用户名后重新登录；或者临时用 sudo 启动 Wireshark。Windows 上则是确认当前用户属于管理员组、或者 Npcap 驱动安装正常。
接口选择方面，无线网卡和虚拟网卡多的时候，容易出现"双击第一块网卡，抓了半天全是无用包"的情况。正确做法是看欢迎页里哪块网卡的跳动条有实时速率，再结合任务管理器确认这块网卡的名称对应 CPU 还是网卡。你也可以在抓包页面的 Capture → Options 里一次性选择多个接口，但新手不建议，流量太杂会干扰验证链路。
3. 一切操作的基础：捕获过滤器与显示过滤器的正确用法
3.1 两类过滤器最容易被混为一谈
Wireshark 里有两种过滤器，名字相近但原理完全不同，很多人用混了，结果总是"该抓的没抓到，不该抓的抓了一大堆"。
捕获过滤器（Capture Filter）：在开始抓包之前设置，它工作在驱动层面，直接在采集数据时就丢弃不匹配的包。它的作用是减少存储，只保留你关心的流量，适合在流量巨大、磁盘空间有限的场景下使用。语法基于 BPF（Berkeley Packet Filter），是 libpcap 的标准过滤表达式。
显示过滤器（Display Filter）：在抓包进行中或抓包结束后使用，它只是隐藏不匹配的包，原始数据并没有被删除。它是一个功能强大的筛选引擎，可以按任何解析字段过滤，比如http.response.code == 500、tcp.window_size < 1000。语法是 Wireshark 自己的一套字段表达式。
一个常见的错误是：在显示过滤器栏里输入host 192.168.1.1，发现完全没反应，因为host是 BPF 语法，不是显示过滤器语法。反过来，在捕获过滤器栏里输入http.request也会报错，因为那是显示过滤器的写法。两者的使用位置和语法体系完全独立，一定要分清楚。
3.2 捕获过滤器：BPF 语法只要记四件事
BPF 语法虽然支持很复杂的表达式，但日常使用中你只需要记住四类：
按主机过滤：
host 192.168.1.1：只抓与 192.168.1.1 通信的包not host 192.168.1.10：排除某个本机无关的噪声源
按端口过滤：
port 80：抓 80 端口流量port 53：抓 DNS 流量tcp port 443：只抓 TCP 的 443 端口
按网段过滤：
net 192.168.0.0/24：抓整个内网网段的流量
组合表达式：
host 10.0.0.5 and tcp port 8080host 10.0.0.5 and not port 53：排除 DNS 的干扰
组合时用and、or、not，需要复杂逻辑时记得加括号。例如：
(host 10.0.0.5 or host 10.0.0.6) and tcp port 8080这个括号很容易被忽略，不写括号的话and的优先级会改变整个含义。捕获过滤器一旦写错，任务直接失败，因为数据已经丢了，没法回头补。所以我的习惯是：能少抓不少抓，先抓大范围再过滤。
3.3 显示过滤器：Wireshark 自己的查询语言
显示过滤器才是 Wireshark 的核心操作，真正撑起"分析"二字的，绝大多数时候靠它。
语法核心是"字段 + 操作符 + 值"，例如：
ip.addr == 192.168.1.1tcp.port == 80http.request.method == "GET"dns.qry.name contains "example"
Wireshark 的字段非常多，不需要全记，掌握几个规律就能举一反三：
操作符：
==：等于，完全匹配!=：不等于>、<、>=、<=：比较数值contains：包含子串，常用于域名、URL 等字符串字段matches：正则匹配，适合复杂条件
逻辑组合：
and、or、not，以及括号。
常用的几个通用字段：
| 含义 | 显示过滤器 |
|---|---|
| 任意 IP 地址 | ip.addr == 1.2.3.4 |
| 任意 TCP 端口 | tcp.port == 443 |
| 只看 HTTP 请求 | http.request |
| 只看 HTTP 错误响应 | http.response.code >= 400 |
| 只看 DNS | dns |
| 只看 TCP SYN 包 | tcp.flags.syn == 1 |
| 只看重传包 | tcp.analysis.retransmission |
| 只看某个 TCP 流 | tcp.stream == 0 |
注意ip.addr和ip.src/ip.dst的区别。ip.addr是"源 IP或目的 IP"，ip.src只匹配源地址。一个新手常犯的错误：想把某个 IP 作为源地址过滤，结果用了ip.addr，把目标也带进来了，数据包列表多出一倍。想表达"确切方向"时，务必使用ip.src、ip.dst、tcp.srcport、tcp.dstport。
3.4 提高效率的三个操作习惯
第一个习惯：活用右键菜单。在任意一个包上点右键，选择 "Apply as Filter → Selected"，Wireshark 会自动把这个包的关键字段转成显示过滤器，省去手动输入字段名的麻烦。比如你在某个 TCP 包详情里选中tcp.stream的字段值，右键 Apply as Filter，马上就能筛出这个连接的所有包，比手敲快得多。
第二个习惯：保存常用过滤器。在过滤器栏输入一串条件后，点左侧的加号或 Save 按钮，可以给它命名保存。我自己的过滤器库里长期存着这几个：http.request、tcp.analysis.flags、dns.time > 0.1、tls.handshake.type == 1。下次打开直接在过滤条件下拉框里选，不需要重新输入。
第三个习惯：临时禁用过滤器。分析过程中经常要在"全量包"和"某个过滤结果"之间来回切。点一下过滤器栏左侧的开关（盾牌图标），可以在启用和禁用当前过滤之间切换，非常方便，不用把过滤器内容清掉重写。
4. 把三次握手对应到数据包列表：TCP 连接怎么看懂
4.1 三次握手的包长什么样
TCP 是面向连接的协议，连接建立必须先完成三次握手。在 Wireshark 里，这三次交换表现为四条信息：
客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK。如果用相对序列号表示（Wireshark 默认），数据包列表看起来是这样：
- 第 1 个包：源端口 50000，目的端口 80，标志 SYN，
Seq=0 - 第 2 个包：源端口 80，目的端口 50000，标志 SYN+ACK，
Seq=0，Ack=1 - 第 3 个包：源端口 50000，目的端口 80，标志 ACK，
Seq=1，Ack=1
新手容易困惑的是序列号。为什么三次握手里序号都是 0、1 这样的整数？因为 Wireshark 默认显示的是相对序列号，它把每个 TCP 连接的起始序列号当 0 处理。这样在分析应用交互时清晰直观，不用面对几亿个随机起始数字。如果你需要看真实的绝对序列号，去 Preference → Protocols → TCP 里把 "Relative sequence numbers" 取消勾选，包列表里的序列号就会恢复成实际值。绝大多数场景不需要关掉相对序列号，实现排障分析用相对值更方便。
4.2 怎么精确地筛出"所有能代表握手"的包
只筛 SYN 标志最强的条件：tcp.flags.syn == 1。这条过滤器会同时命中 SYN 和 SYN+ACK 两种包，也就是把三次握手的"前两步"都筛出来，第 3 步 ACK 因为SYN位是 0，不会被包含。
如果你只看纯粹的 SYN 包（不包含 ACK 标志），用：
tcp.flags.syn == 1 and tcp.flags.ack == 0只看 SYN+ACK（说明服务端同意建立连接），用：
tcp.flags.syn == 1 and tcp.flags.ack == 1如果你关心的是一次失败连接，那就找 SYN 重传：客户端发出 SYN 后，迟迟没收到 SYN+ACK，就会按退避算法重复发送 SYN。Wireshark 会将后续 SYN 标记为TCP Retransmission，所以筛tcp.analysis.retransmission and tcp.flags.syn == 1，就能快速定位"握不上手"的尝试。
4.3 重传、乱序与窗口：从颜色和 Expert Info 入手
数据包列表里各种颜色不是随手染的，它们代表 Wireshark 协议分析引擎的判断。第一次上手，你只需要记住四条：
黑色或淡红色背景：TCP 重传，即相同序列号的数据被再次发送，意味着网络丢包或延迟导致超时。排查网络质量时，这是第一关注对象。
浅蓝背景：TCP 乱序（Out-of-Order），包到达顺序错乱，通常由多路径路由、负载均衡或链路延迟抖动导致。轻微乱序影响不大，大量乱序会导致接收端缓冲区等待，性能下降明显。
红色背景（类似坏包标记）：校验和错误、TCP 快速重传（Dup ACK）等，需要展开具体看。
黑色带 R 标志：Reset（RST），连接被强制中断。RST 包往往意味着某一边"不想继续了"，可能是程序崩溃、端口关闭、防火墙拦截，都是问题信号。
不要只靠颜色判断，打开底部状态栏的Expert Info（或者 Analyze → Expert Info）可以看到 Wireshark 把出现的问题按严重程度分类：Error（错误）、Warning（警告）、Note（提示）、Chat（消息）。这是分析大型 pcap 的快捷入口。它不会替你得出结论，但会帮你把可疑的包圈出来，省去在几万个包里肉眼扫描的时间。
4.4 断开过程与半开连接
连接断开同样是标志位驱动的。正常断开时，主动方发 FIN，对端回 ACK 后也发 FIN，最后主动方回 ACK，这样完成四次挥手。在 Wireshark 里筛tcp.flags.fin == 1就能看到所有发过 FIN 的包。
如果连接没有正常关闭，而是直接出现 RST，Wireshark 会用黑色标记。有次我做应用迁移，发现新程序启动后总是有大量 RST 连接，排了半天才意识到是新版本的 TCP 连接超时参数设置得太短，服务端还没来得及响应，客户端已经主动把连接关了。这个排查过程中 Wireshark 显示的"RST 发送方和接收方的 IP"直接告诉我，主动断开方是客户端而不是服务端，方向一确定，就省了一半排查时间。
5. 实战复盘："网页打不开"的完整链路拆解
5.1 场景与抓包准备
假设有这样一个小场景：某员工反映访问内部 OA 系统http://oa.internal.example.com特别慢，有时候直接超时，其他同事用着正常。按照"先复现、再抓包、后下结论"的原则，在出问题的电脑上操作。
抓包前的准备一下子理清：
- 确认接口：打开 Wireshark 欢迎页，选择当前电脑接入的网络接口（是有流量的那个，不是断开状态的虚拟网卡）。
- 提前写好显示过滤器，或者至少规划好捕获过滤器。我习惯先开一个宽泛的捕获过滤器：
host oa.internal.example.com or port 53。为什么带上 53？因为一次网页访问的第一步往往是 DNS 解析，而 DNS 默认走 UDP 53 端口，如果漏掉 DNS，整个链路就少了一段关键数据。 - 确认浏览器缓存已清理，或者直接用无痕窗口，避免命中本地缓存而根本不发请求。
- 准备好之后先点开始捕获，然后再去浏览器里输入网址，这样能保证抓到完整过程，而不是等页面加载完了才想起来开始抓。
大约抓到几条或几十条包之后，停止捕获。数据不要太多，修典型问题几十秒的包往往就能看出端倪。
5.2 第一步：先看 DNS 有没有"落地"
打开抓包结果之后，我习惯先从 DNS 看起。DNS 是访问流量的第一跳，它的快慢直接决定整个页面访问是否顺利。
在显示过滤器里输入dns.qry.name contains "oa.internal.example.com"，把与这个域名相关的 DNS 查询和响应全部筛出来。
这里要看三件事：
有没有查询包：如果完全没有 DNS 查询包，说明请求根本没发出去，或者是操作系统缓存、浏览器缓存直接命中了，本地都没查询。这种情况要怀疑客户端配置。
有没有响应包：有查询无响应，说明 DNS 服务器不可达或响应被防火墙丢弃。需要 ping DNS 服务器、检查系统网络连接。
响应时间多长：选中 DNS 响应包，详情里有[Time]字段，表示从查询发出到响应返回的耗时。局域网内部 DNS 通常应该在几十毫秒以内；超过 1 秒明显异常，说明 DNS 服务器性能差或链路有问题。
在这个示例里，我假设 DNS 响应时间为 280ms，属于"能解析但偏慢"的情况，不是根因。那接着往下看 TCP。
5.3 第二步：TCP 连接是否建成
浏览器在拿到 IP 后，下一步就是和服务器建立 TCP 连接。把显示过滤器切成ip.addr == 目标IP加上tcp.port == 80。
重点查三次握手完成度。
一种比较常见的失败模式是：客户端连续发出多次 SYN，服务端始终没有回应。包列表里会看到数个 SYN 包被标记为 "TCP Retransmission"。这说明要么目标服务器 IP 根本不对（访问的域名解析到故障节点）、要么防火墙在悄悄丢弃入站 SYN、要么服务端程序没有在监听这个端口。你可以再看一下 SYN 重传目标端口，如果目标端口和服务端监听端口对不上，那就是连接到了错误的服务。
另一种模式是：三次握手正常完成，SYN、SYN+ACK、ACK 都在，但接下来 HTTP 请求迟迟没发出去。这通常是浏览器侧或代理设置问题。
在这个示例中，三次握手是正常的，SYN、SYN+ACK、ACK 完整出现，时序紧凑，没有重传。问题在更上面。
5.4 第三步：HTTP 响应慢在哪里
既然 TCP 建连没问题，那注意力就放到 HTTP 层。过滤器直接用http.request，可以看到浏览器发出去的请求。再配合http.response，看服务端返回的状态码和耗时。
这里我最常看的是两个时间点：
请求发出到收到第一个响应包的时间。这个时间差反映的是服务器实际处理请求的时间。如果这个时间很长，比如超过 2 秒，那瓶颈就在应用服务端，而不是网络。查服务器日志、数据库连接、中间件配置，方向就对了。
响应数据和 ACK 的交互过程。如果服务器处理很快，但响应数据在网络上缓慢到达，Wireshark 里会看到响应包之间的间隔很大，或者伴随 TCP 窗口变小、零窗口、重传等情况，说明网络链路或服务器 TCP 参数有问题。
这个示例里，我看到的实际情况是：HTTP 请求发出后，整整等了 1.8 秒才看到第一个 TCP 数据段携带响应，但接下来剩余响应在几十毫秒内全部到达。这就是典型的"服务器处理慢"，网络本身没拖后腿。日志侧再查，果然发现后端节点对某个共享存储的读超时导致请求排队。
5.5 用 Statistics 和 Follow TCP Stream 全程复核
单独看几步之后，我习惯再从全局工具入口复核一遍，避免只看到片段。
Statistics → Protocol Hierarchy会按协议栈展示各层流量占比。如果 DNS 和 TCP 建的包数量少得可怜，而 ARP 包高居榜首，大概率是抓包位置选错了；如果 HTTP 响应包大量占比，说明页面内容大头在数据传输阶段。
Statistics → Conversations（会话列表）按 IP 维度列出两端之间的流量字节数和包数。它能快速找出"流量最大的一对 IP"，判断是否是预期中的客户端到服务器连接。万一有意外，比如某台机器在向外发大量数据，这里一眼就能发现。
Follow TCP Stream（右键任意一个 TCP 包 → Follow → TCP Stream）会把这条 TCP 连接的所有载荷按顺序拼起来，还原出完整会话内容。HTTP 明文场景下，直接能看到请求头和响应头，比逐个包翻半天高效太多。有次我排查接口返回数据格式错误，就是用这个功能定位到响应 JSON 在传输中出现了截断，再回头查分片和重组。
这个功能也适用于明文协议调试，比如 SMTP、FTP、数据库协议，只要没加密，多长的会话都能一起还原出来。用完后记得关闭这个视图，因为数据包列表会自动跳到那个流的第一个包，容易打乱你的分析思路。
6. 进阶工具、长期抓包与那些年踩过的坑
6.1 命令行版 tshark，掉线也能抓
Wireshark 适合交互式分析，但如果是线上环境需要长时间抓包，或者只能在远程服务器上执行，图形界面就不够用了。它的命令行版本tshark会是你长期抓包的最佳搭档。
基础用法：
tshark -i eth0 -f "host 10.0.0.5 and tcp port 8080" -w dump.pcapng这条命令里：
-i eth0指定接口-f指定捕获过滤器（BPF 语法）-w将原始包写入文件
在抓完之后，还可以用命令行的显示过滤器条件重新筛选已有文件：
tshark -r dump.pcapng -Y "http.response.code >= 500" -T fields -e ip.src -e http.response.code-r读取 pcap 文件，-Y指定显示过滤器表达式，-T fields -e表示只输出你指定的字段。这种用法在批处理几十个 pcap 文件时非常省力，配合脚本可以自动统计每个文件里的错误状态码数量。
同一台机器上 tshark 和 Wireshark 共享相同的解析引擎和过滤器语法，你不用担心两边风格不一致。
6.2 长时间抓包用环形缓冲
直接把抓包 ran 在服务器上几个小时，不做任何文件策略，大概率会得到几十 GB 甚至上百 GB 的 pcap 文件，不仅占满磁盘，后续分析也会卡死。
两种方式解决：
第一种：用 Wireshark 的多文件功能。在 Capture Options 里勾选 "Use multiple files"，设置每个文件大小和文件数量。工作机制类似视频监控的滚动存储：写满一个文件就切换下一个，达到最大文件数后自动覆盖最旧的文件。适合持续保留最近 N 个小时的流量。
第二种：用 tshark 的环形缓冲参数。
tshark -i eth0 -w trace.pcapng -b filesize:102400 -b files:20-b filesize:102400表示每个文件到 100 MB 就切换-b files:20表示只保留最近 20 个文件，即滚动保留约 2 GB 数据
我一直推荐第二个方式，因为不用打开图形界面，而且可以配合nohup或 systemd 服务放到后台长期运行。抓完后把涉及的时间窗口对应的文件提取出来，再合并分析。
6.3 TLS 加密流量的本地解密技巧
现在大多数 Web 流量是 HTTPS，Wireshark 默认只能看到 TLS 握手，看不到 HTTP 内容。想分析本机应用与服务器之间的加密通信内容，有一个通用方法：让应用导出 TLS 会话密钥，再把密钥文件交给 Wireshark 解密。
具体步骤：
- 设置环境变量
SSLKEYLOGFILE=/tmp/tls_keys.log，Chrome、Firefox、curl 等程序支持这个变量，会把每个 TLS 会话的主密钥写入文件。 - 在 Wireshark 里打开 Preference → Protocols → TLS，在 "(Pre)-Master-Secret log filename" 一栏填入该日志文件路径。
- 重新发起访问并抓包，Wireshark 会自动用密钥解密 TLS 记录，HTTP 明文内容就会显示出来。
这个方法只适合分析你自己够得着的客户端流量，前提是你有权限设置应用的环境变量并访问密钥文件。它不能用来随便解析别人的加密流量，也没有这个能力——没有密钥，Wireshark 面对 TLS 加密数据就是一堆乱码，这不影响你分析握手过程本身，TLS 的证书、加密套件、协议版本照常可见。排查证书过期、TLS 握手失败、协议协商问题时，不依赖解密也能完成。
6.4 pcap 文件的管理与合并
长时间抓包后，文件会按时间切成多个。分析时需要把零散文件合并成一个连续文件，用到mergecap：
mergecap -w all.pcapng part1.pcapng part2.pcapngmergecap会按时间戳自动排序多个文件里的包，最终输出一个时间线完整的文件。它不会改变包内容，也不会丢失哪个包，只是把集合整理到一起。
如果某个文件太大，只想保留某段时间的包，可以用editcap：
editcap -A "2025-06-01 10:00:00" -B "2025-06-01 11:00:00" big.pcapng slice.pcapng-A是起始时间，-B是结束时间，按包上的时间戳切分。还有更常用的功能是基于显示过滤器提取包：
editcap -Y "tcp.port == 443" big.pcapng https_only.pcapng这个操作在处理大规模告警流量时特别有用：先按时间切片，再按协议过滤，缩小分析范围。
6.5 踩坑清单与我的习惯做法
最后一个部分，把我实际踩过的坑集中整理一下，每一个都对应一条实操建议。
网卡选错。有多块网卡的机器上，双击了没有流量的虚拟网卡，瞬间一堆空包。开始抓包前先看一眼欢迎页的速率跳动条，哪个接口活跃就选哪个；不确定时用tshark -D列出所有接口名称和序号。
忘记开混杂模式。正常上网时只抓自己这台机器的包影响不大，但如果想分析无线网络上的其他设备，没开混杂模式会什么都抓不到。Linux 下用tcpdump -i wlan0或 tshark 时需要在接口后加-p参数控制混杂模式；Windows 下 Npcap 默认对很多无线网卡启用混杂，但效果因驱动而异，别指望一定能听到所有无线设备。
校验和整出一堆假报警。新版网卡普遍支持校验和卸载（checksum offload），硬件负责计算 IP 和 TCP 校验和，Wireshark 看到的数据包校验和可能是"未计算"或"错误"的，于是标记一堆坏包。这不是真实网络错误。要验证可以看Checksum Status是否为unverified或bad。想做严格校验分析，需要在网卡配置里关闭相应的 offload 功能。
巨型帧和 TCP 分段卸载。启用 TSO/GRO 后，网卡驱动会把上层的大载荷一次性塞给协议栈，Wireshark 里就可能看到某个包本身极长，甚至超过以太网 MTU，还提示 "TCP segment of a reassembled PDU" 或 "IPv4 total length 大于 1514"。这也是卸载造成的假象，不是网络故障。分析应用层协议时可以不管，但涉及 MTU 排障时一定要关闭卸载功能再看真实情况。
时间戳不是发包时间。抓包文件里的时间戳是抓包主机收到该包的时间，不是包离开对端或到达对端的时间。跨多台设备对比时间差时，如果两端系统时间不同步，时间戳没有可比性。单机抓包分析时，相对时间就够用了。
只依赖图形界面。线上 Linux 服务器往往没有桌面环境，只会图形操作等于没法干活。把 tshark 的基本用法练熟，尤其是-r读取文件、-Y过滤、-T fields格式输出这组合拳，远程排障效率会高很多。
我的日常流程基本固定：发现问题后先明确要复现的场景和网络出口，然后开 tshark 抓包保存为 pcapng 文件，再用 Wireshark 打开文件逐步分析。一次抓包往往能同时解决"有没有问题、问题在哪一层、要不要找网络组"这三个问题，比让各方扯皮高效得多。
最后分享一下我的一个小习惯：每次排障结束，我会把关键截图、以及对应的二次过滤表达式存到自己的笔记里。团队后来再遇到相似问题，直接翻旧记录就能知道从哪里下手。希望这篇内容也能成为你笔记里的一部分。
