Wireshark抓包全攻略：从安装到攻防分析的实战指南

刚入行做网络排障那会儿，我对Wireshark抓包这件事一直有种又爱又恨的感觉。爱的是它能把网络里那些看不见摸不着的报文变成一行行肉眼可见的数据，真是排查问题的最后一根救命稻草；恨的是，刚打开软件那一刻，满屏滚动、不断刷新的包让人直接懵掉，根本不知道从哪看起。后来跟着项目踩了不少坑，逐渐摸清了Wireshark抓包的逻辑和攻防分析的思路，才发现这工具的强大远不止"看一下数据包"这么简单。这篇东西我不打算按官方文档给你念一遍菜单，而是按我自己从入门到实战总结出来的一套路径来写：从装好环境、抓到第一包，到能熟练用过滤器定位问题，再到站在攻防视角识别异常流量。适合刚接触抓包、想系统入门的同学，也适合已经在用但总觉得效率不够高的人。

1. 装好Wireshark之前，这几件事不做会后悔

1.1 安装时的三个关键勾选项

Wireshark本身安装很简单，真正容易出问题的是安装过程中那几个附加组件的勾选。我用过的版本从3.4到4.2都有，安装逻辑基本一致，主要注意三处。

第一，安装到选择"Additional Tasks"这一步时，会询问是否安装Npcap或者让它调用已有的WinPcap。现在的新版本Windows平台默认推荐Npcap，一定要勾上。Npcap是Windows下抓包的底层驱动，Wireshark只是上层图形界面，没有这个驱动，打开软件后根本看不到网卡列表。很多"Wireshark看不到本地网卡"的问题，八成都是这一步没装对。

第二，安装过程中会问是否安装USBPcap。如果你后续有USB抓包分析的需求，建议顺手装上；如果只是抓普通网络包，不装也不影响。USBPcap是独立于网卡抓包的，作用是捕获USB总线上的数据流量。像调试某些USB外设协议、分析U盘或键鼠的通信内容时会用到，日常场景优先级不高。

第三，自动更新建议关掉。Wireshark大版本更新频率不算低，但抓包分析工具最重要的是稳定可复现。很多时候你刚熟悉一个版本的界面和过滤器语法，升级后弹窗、菜单变了一轮，反而打断工作流。我个人的习惯是装一个稳定版用到项目结束，需要新功能才手动升级。

Linux下的安装倒没什么坑，Ubuntu/Debian系直接sudo apt install wireshark。注意安装过程中Debian系会弹一个对话框问你是否允许非root用户抓包，选"是"的话，普通用户需要把自己加入wireshark组：

bash复制sudo usermod -aG wireshark $USER

改完组之后要重新登录一次才生效。macOS的话用Homebrew安装是最省事的，brew install --cask wireshark会一并把ChmodBPF这个权限组件装上，否则非root用户会提示权限不足，抓不到包。

1.2 找不到本地网卡？先查这三处

装完软件打开Wireshark，主界面会列出当前机器所有可用网卡。如果列表是空的，或者只看到"Adapter for loopback traffic capture"这样的回环适配器而看不到有线网卡，按这个顺序排查。

第一步，确认Npcap服务是否在运行。Windows下以管理员身份打开命令行，执行：

bash复制sc query npcap

如果显示STATE不是RUNNING，那说明安装时驱动没生效，最简单的方法是卸载后重新安装Wireshark，这次务必勾选Npcap。

第二步，检查是否用了管理员权限。Wireshark在Windows下抓包需要管理员权限，否则Npcap不会暴露网卡给它。这个现象非常典型——普通用户打开软件，网卡列表空空如也；右键以管理员身份运行，网卡全都出来了。不用怀疑，第一优先尝试这个操作。

第三步，确认是否开启了混杂模式。Wireshark默认情况下是开启混杂模式的，但在某些虚拟网卡、无线网卡或者部分USB网卡上，驱动不支持混杂模式，Wireshark会提示"该网卡不支持混杂模式"或者列表里有网卡但抓不到包。这时候进入"Capture Options"，把"Enable promiscuous mode on all interfaces"取消勾选试试。注意取消混杂模式后，网卡只会收到发给自己或者广播、组播的包，不再接收交换机泛洪过来的其他流量，抓包范围会收窄。

1.3 抓包前必须打开的"混杂模式"到底在开什么

提到混杂模式，很多新手会把它理解成"监听一切流量"。严格来说，混杂模式（Promiscuous Mode）是指让网卡把物理链路上收到的每一个数据包都交给上层处理，而不仅仅是目的MAC地址与自己匹配的帧。在有线以太网+交换机环境下，交换机通常会根据MAC地址表把单播帧精确转发到目标端口，开了混杂模式并不意味着你就能看到整个局域网的所有通信。真正能"看全所有流量"的场景是：直连Hub（现在基本绝迹）、ARP欺骗后的双向流量转发、端口镜像、或者无线网卡的监听模式。

搞清楚这个边界很重要，因为很多人在虚拟机里做抓包实验，发现宿主机和其他虚拟机的流量看不到，就开始怀疑工具坏了。其实不是你操作有问题，是网络环境决定了你看不到。理解这个原理之后，再去想攻防分析里"为什么只抓到一部分包"就顺理成章了。

2. 先搞懂Wireshark怎么把一条网络请求变成你能看懂的一堆包

2.1 主界面五块区域的阅读顺序

第一次打开Wireshark开始抓包，屏幕上会不断刷出新的数据包记录。很多人在这里就卡住了，不知道该看哪个字段。我建议你按五块区域的顺序来理解界面。

最顶部是菜单栏和工具栏，包括开始/停止抓包、打开文件、保存文件等操作；接着是显示过滤器输入框，这是整个抓包分析里最高频使用的输入位置，输入规则后回车，下面的列表会立刻过滤出符合条件的包；中间最大的是数据包列表窗格，每一行代表一个包，按照抓取时间排序，包含序号、时间、源地址、目的地址、协议、长度、信息等列；再往下是数据包详情窗格，点选列表里的任意一个包，这里会以树状结构展示该包从物理层到应用层的完整解析结果；最下面是数据包字节窗格，以十六进制和ASCII两种形式显示这个包的原始字节内容。

实战里最常见的阅读顺序是：先通过过滤器定位到某个会话相关的包，然后在列表里从上往下看交互过程，选中某个包后在详情窗格里看协议字段的具体取值，有必要时再到字节窗格里确认原始数据。

2.2 颜色规则一眼识别协议类型

Wireshark默认给不同的协议分配了不同的颜色，比如TCP包通常是浅紫色，HTTP请求是绿色，DNS是浅蓝色，ARP是黄褐色。这些颜色不是随便涂的，目的是让你在满屏数据包中一眼看出流量构成。比如你抓了一个网页访问过程的包，如果看到大片绿色，说明这里面的HTTP明文流量占主导；如果全是大面积的TCP紫色，那可能传输层重传、乱序等异常占了很大比重。

颜色规则是可以自定义的，在"View → Coloring Rules"里可以新增、修改。我个人建议不要大改默认规则，但在做特定协议分析时可以临时加一条高亮规则，比如把所有包含"SYN"标志且无ACK响应的TCP包标成红色，这对快速识别扫描行为很有用。具体做法是在显示过滤器中输入tcp.flags.syn==1 && tcp.flags.ack==0，然后在Coloring Rules里新建一条规则绑定这个过滤表达式，再给你的规则选一个醒目的前景色。

2.3 三种过滤器别搞混：捕获过滤器/显示过滤器/着色规则

Wireshark里"过滤器"这个词其实是三个完全不同的东西，初学者混淆它们会导致很多莫名其妙的"我明明过滤了但没效果"的困惑。

捕获过滤器（Capture Filter）是在开始抓包前设置的，它决定哪些包被真正记录到文件里。底层是BPF（Berkeley Packet Filter）语法，比如host 192.168.1.1表示只抓这个IP的流量，port 80表示只抓80端口的流量。它的特点是过滤发生在驱动层面，没被放行的包Wireshark根本没机会看到。优势是省资源、抓大流量时文件不会爆炸；劣势是如果你漏掉了什么，只能重新抓。

显示过滤器（Display Filter）是在抓包过程中或抓包完成后对已捕获的数据包进行筛选显示，它不影响原始抓包文件，只是让你"只看想看的"。语法是Wireshark自定义的，比如ip.addr == 192.168.1.1、tcp.port == 443、http。这是日常分析主力，也是下面要重点讲的。

着色规则（Coloring Rules）则是给满足条件的包上颜色，本质是"视觉过滤器"。它不减少显示数量，只是让特定类型的包更容易被注意到。三者使用场景完全不同，别搞混。

3. 显示过滤器才是Wireshark的核心生产力：常用规则与实战组合

3.1 从"一条请求"到"一条规则"的翻译思路

显示过滤器看起来语法复杂，其实思路非常简单：你心里想过滤什么，就用对应的协议字段去表达。 比如你想看某个IP的所有流量，那就是ip.addr == 1.2.3.4；想看某个端口，那就是tcp.port == 8080；想看HTTP POST请求，用http.request.method == "POST"。这些字段不是凭空记的，Wireshark在输入过滤器时会有自动补全和字段提示，你写一个http.后面就会列出所有HTTP相关字段，非常方便。

实践中我经常用组合表达式来定位一个"会话"。比如排查某台服务器访问另外一个数据库的慢请求，我关心的过滤条件可能是：

text复制ip.addr == 192.168.10.20 && tcp.port == 3306

这条规则会同时把源IP或目的IP是该地址、且源端口或目的端口是3306的包都列出来。注意ip.addr == A && ip.addr == B在Wireshark里不一定表示"源IP是A且目的IP是B"，因为它会对每一个包分别检查源地址和目的地址字段，只要有一个字段匹配就算true。要精确表示源和目的关系，得用ip.src == A && ip.dst == B。这是一个非常经典的坑，我见过不少人用ip.addr组合条件过滤出了跨越两个不同会话的包，然后分析半天发现数据对不上。

3.2 BPF捕获过滤器与显示过滤器语法对比表

为了更直观，我把一些常见需求和两种过滤器的写法放一起对比，遇到的时候直接查表抄作业就行。

这张表的重点在于：能用显示过滤器做到的，尽量不要用捕获过滤器。 因为显示过滤器不影响原始数据，你随时可以改条件重新筛选，而捕获过滤器在抓包那一刻就决定了数据范围，事后想补看漏掉的流量只能重抓。只有在流量极大、机器资源有限、或者明确知道只需要某类数据的情况下才设置捕获过滤器。

3.3 追踪TCP流：把几十个包还原成一次完整交互

当你在数据包列表里看到一大串TCP包时，要读懂它们的业务逻辑，最高效的方法不是一个个点开看，而是右键任意一个包，选择"Follow → TCP Stream"。Wireshark会把属于同一个TCP连接（四元组：源IP、源端口、目的IP、目的端口）的所有包按时间顺序重组，然后把TCP载荷拼接成完整的应用层数据。这一个功能就把一次HTTP请求从建连到发送数据再到断开的全部过程还原在你眼前。

TCP Stream界面里，你可以直接看到请求原文和响应原文。比如服务端返回了一个报错，你不需要去每个分片包里找，直接在Stream里就能看到完整的返回内容。对HTTP这种明文协议尤其方便。如果是HTTPS流量，且你没有配置TLS解密密钥，TCP Stream里的内容会是乱码，因为载荷被加密了。

顺带提一个习惯：我每次分析一个应用问题时，都会先把关注的会话"Follow TCP Stream"一遍，把业务层的内容先看懂，再回到协议层去看TCP的Seq/Ack、重传等机制。这样"业务-协议"两个视角对照起来，很多疑难问题都是这么定位的。

4. 协议分析入门实操：TCP三次握手、HTTP和DNS拆解

4.1 三次握手的seq/ack到底在记什么账

很多教材讲三次握手喜欢画简图，实际在Wireshark里你把过滤条件设为tcp.flags.syn == 1 and tcp.flags.ack == 0或干脆在列表里找到三个连续的TCP包，会看到这样一幕：

第一个包，客户端发送SYN包，标志位SYN=1，此时Sequence Number是一个随机初始值，比如1000，它代表"我的数据流从1000号开始编号"。第二个包，服务端返回SYN=1, ACK=1，此时的Acknowledgment Number是1001，含义是"我已经收到了你那边到1000为止的字节，请你从1001开始发下一个字节"，同时服务端也带上自己的随机Sequence Number，比如5000，表示"我这边数据从5000开始"。第三个包，客户端回复ACK=1，Acknowledgment Number是5001，告诉服务端"我收到了你到5000为止的字节"。

这就是Seq和Ack的记账逻辑。每次传输数据，Seq都会累加已发送的字节数，Ack则告诉对端"我期望的下一个字节编号"。你在Wireshark详情窗格里选中一个TCP包，展开TCP头部，把Sequence Number和Acknowledgment Number对应到这条链路里看，整个传输过程就清晰了。后面你分析TCP重传、乱序、零窗口的时候，本质都是看Seq和Ack之间的关系是否对得上。

4.2 HTTP请求慢在哪里：从握手看响应耗时

有一次排查一个接口偶发变慢的问题，前端反馈有时候页面要等10秒才有响应。我在服务器出口镜像口抓了包，过滤出该接口的TCP流，很快就定位到了问题不在应用逻辑，而在TCP握手阶段。

具体怎么看呢？数据包列表窗格里默认有一列Time，显示的是相对抓包起始时间。如果你想看两个包之间的时间差，可以在"Statistics → TCP Stream Graph → Time-Sequence Graph (tcptrace)"里画图，也可以直接在列表里选中两个关键的包，看它们的时间戳相减。比如握手的SYN包发出时间和SYN+ACK包到达时间差是0.15秒左右，说明网络延迟正常；如果这个差值波动到2秒甚至更大，就可能存在丢包重传或中间设备缓存问题。

我那次抓到的情况是：客户端连续发了好几个SYN重传，说明服务端根本没有应答。继续检查服务端网卡、iptables规则和监听端口，发现是应用进程在某个时刻锁死，导致TCP握手队列积压。这种问题如果不抓包，完全靠查日志要绕很大圈子。抓包的优势就在这里：它帮你把时间线精确到毫秒级，每一段耗时都被摊开在眼前。

4.3 DNS排查案例：域名解析慢到崩溃的定位过程

再分享一个DNS排查案例。某天线上反馈"打开网页转圈很久才出内容"，第一反应是服务器负载高或网络带宽满，但监控数据都正常。我用Wireshark在客户端抓包，过滤dns，发现每次浏览器发起域名解析请求之后，到收到DNS响应之间间隔了将近3秒。DNS查询本身触发了多次重发，说明UDP包的响应没有及时回来。

追踪DNS服务器的IP后，我用ip.addr == <DNS服务器IP>过滤出所有与该服务器的通信，进一步发现服务器对很多域名查询都返回超时，只有少数内部域名正常。最后查下来是DNS服务器本身的上游转发配置失效，子域名解析请求被路由到了一个不可达的递归服务器。给DNS服务器换了一个上游后问题消失。

DNS抓包分析里还有一个常见需求：根据已知IP反查它对应的域名解析记录。这需要你提前看这个IP被访问时产生的DNS查询。方法是将过滤器设为dns.a == <目标IP>或者dns.resp.addr == <目标IP>，就能找到当时返回这个IP的DNS响应包，从响应里就能看到对应的域名是什么。这在排查不明通信时很有用。

5. 攻防视角：从攻击者特征反推防御思路

5.1 端口扫描与SYN洪水特征：一眼识别

抓包分析在攻防场景里最常见的应用就是识别扫描行为。攻击者要打一台机器，第一步通常是端口扫描，而扫描行为在流量上留下的特征非常明显。

用Wireshark抓到一个网段的流量后，把过滤条件设为tcp.flags.syn == 1 && tcp.flags.ack == 0，统计一下哪些源IP在不同时间点对大量目的IP、目的端口发起了SYN请求，如果单个源IP在短时间内对同一目标的不同端口做全端口探测，扫描行为基本可以实锤。经典的SYN扫描是攻击者发一个SYN，如果收到SYN+ACK就说明端口开放，收到RST则说明端口关闭，整个过程没有完成完整的三次握手。这种包特征是：SYN包多、成对出现的SYN+ACK和RST也多，但几乎看不到后续业务数据。

SYN洪水攻击的流量特征则更进一步：攻击者发送大量SYN包但不回应第三次握手的ACK，导致目标服务器的半连接队列被塞满，合法用户无法建立新连接。在Wireshark里，你会看到数据包列表中有成千上万个来自不同伪造源IP的SYN包，且目的IP高度集中在同一台服务器上。

这两个场景不太可能同时出现，但特征都是SYN包密集。实战中防御方要做的是在流量入口设备上做SYN速率限制、源IP信誉检查，以及抓包确认是攻击还是误报。

5.2 暴力破解特征：从大量401/403看账户安全

暴力破解是另一种常见攻击行为。如果一台服务器开放了HTTP服务，登录接口被攻击者持续爆破，抓包层面的特征非常直白：同一个源IP对同一个URL发起高频HTTP POST请求，服务端连续返回401 Unauthorized或403 Forbidden，然后间隔一段时间再换一批源IP继续打。

我分析过一个内网系统的爆破告警，抓包五分钟内就收集到了几百个POST请求，全部指向/login。用Wireshark的"Statistics → HTTP → Request Methods"功能直接按请求方法聚合，POST请求数量巨大，再按源IP排序，发现大量来自同一网段的请求。进一步用http.request.method == "POST" && http.response.code == 401过滤，就得到了候选的失败登录序列。把这个序列的时间和频率做成表格，爆破的攻击源和节奏一目了然。

防御层面，针对这类流量最有效的不是一个个封IP，而是限制单IP的登录失败速率，并配合验证码机制。抓包的意义在于让你看清攻击者的真实规律，比如高频期、源IP分布、目标路径，而不是被告警系统的一堆报警淹没。

5.3 ARP欺骗与内网横向移动的抓包特征

内网攻防里ARP欺骗是经典招式。攻击者通过发送伪造的ARP应答报文，把受害者的流量引导到自己的机器上，实现中间人监听或流量篡改。抓包层面，ARP欺骗的特征是短时间内收到大量ARP应答包，而且同一IP对应到了多个不同的MAC地址。

在Wireshark里过滤arp，你会看到源IP不等于源MAC与实际IP对应关系的应答包。比如正常情况下，IP 192.168.1.1对应MAC 00:11:22:33:44:55，但抓包里出现了来自MAC 66:77:88:99:aa:bb也声称自己是192.168.1.1的ARP应答，这就是典型的欺骗信号。更高阶的检测方式是交叉验证IP-MAC对应表，Wireshark的"Statistics → Endpoints"里可以按IPv4地址和MAC地址分别统计，对照两个列表看是否有异常映射。

内网横向移动的特征也有迹可循。攻击者拿下一台机器后，会尝试访问其他内网主机的管理端口（如3389、22、445等）。如果你在内网核心交换机的镜像口抓包，看到某个不经常做远程登录的IP突然开始对大量内网地址发起这些端口的连接尝试，那就要高度警惕了。

5.4 HTTPS加密流量下"攻防分析"还能做什么

现在大部分业务已经上了HTTPS，攻击者的流量也普遍加密，这种情况下用Wireshark很难直接看到明文内容。有人会觉得加密之后就没办法做分析了，这个理解是不完整的。

加密流量分析的核心是"不看内容，看行为"。即使TLS流量无法解密，你仍然能通过以下指标判断异常：TLS握手失败率突然升高，可能说明有人在批量探测或重放；TLS ClientHello中的SNI字段是指定域名信息的，连接的目标域名列表本身就是重要的情报；证书信息可以从ServerHello里看到，异常的证书指纹很可能来自主动探测工具；TLS会话时长、流量上下行比例、包大小分布这些元数据，也能辅助判断是否有人在里面做长时间的数据窃取。

在有TLS解密需求的情况下，如果业务方持有服务端私钥，可以在Wireshark里配置"Protocols → TLS → RSA keys list"导入私钥实现解密；或者客户端环境可控时，设置SSLKEYLOGFILE环境变量导出会话密钥，Wireshark再用这个文件解密会话。注意这两个方法都涉及敏感信息保管，仅应在自己掌控的测试环境中做，生产环境请先走合规审批。我在做HTTPS接口调试时，最常用的是SSLKEYLOGFILE方式，它不需要服务端配合，只需要在浏览器启动前设置环境变量：

bash复制export SSLKEYLOGFILE=/tmp/tls_keys.log

然后在Wireshark的TLS协议设置里把这个文件路径填进去，重新抓包就能看到解密后的HTTP内容。这个方式对排查"HTTPS页面里某个资源加载失败"这类问题非常高效。

6. 大数据包分析：从几千个包里找到问题根因的方法

6.1 排查思路：先看专家信息，再看统计图

抓包文件几千个包是常态，几万几十万也不稀奇。面对这么大的数据量，一个个包翻是不现实的。我的固定套路是先看专家信息（Expert Info），找Wireshark主动标出的异常，再看统计图表，最后才回到列表逐包确认。

专家信息在"Analysis → Expert Info"里，Wireshark会自动把包分类为错误（Error）、警告（Warning）、注意（Note）、聊天（Chat）几个等级。比如TCP重传、乱序、重复ACK这类在网络质量分析里最关心的信息会直接列出来。如果专家信息里出现大量RST或重传，基本可以断定网络存在丢包或设备干预，不需要再看其他内容。

值得注意的是：Wireshark专家信息里的警告不一定都是问题。 在正常网络里，偶尔的重传或乱序是允许出现的，重点是看频率和密度。如果重传包数量占比超过1%，或者集中在某个时间段、某个会话里，那才值得深入排查。

6.2 IO图形与慢请求定位综合案例：接口响应变慢

有一次接口响应变慢的排查，抓包后数据量非常大，我直接在"Statistics → IO Graph"里画了一张5秒间隔的吞吐量曲线图，瞬间就发现了问题：整体流量每隔30秒会出现一个尖峰，峰值时间点与业务方反馈的响应超时时间完全吻合。这个规律在只看原始包列表时很难发现，一旦画成图，周期性异常就很显眼。

IO Graph的配置里可以自定义Y轴单位（包/秒、字节/秒）和过滤器，我通常叠两条曲线：一条是总的流量，一条是tcp.analysis.retransmission（重传）或http.response.time（HTTP响应时间）。如果总流量尖峰和重传尖峰同时出现，明显是传输路径问题；如果流量不高但HTTP响应时间很高，那就是应用层服务能力问题。两种情况的后续排查方向完全不同。

6.3 协议分级与端点统计的用法

"Statistics → Protocol Hierarchy"会按协议层级统计每个协议的包数和字节数。举例来说，如果里面显示TCP协议占比异常高，而HTTP只占一点点，说明抓到的流量里有很多TCP非应用层交互，比如大量重传或空ACK，这在性能分析里是个重要的提示信号。

"Statistics → Endpoints"则可以统计每个IP、每个MAC地址产生的流量总量。在做异常流量溯源时，直接用这个功能按字节数排序，最大的几个IP基本就是重点怀疑对象。如果某个从来没见过的IP突然排在流量榜首，那就该去查查它到底在跟谁通信、干什么了。

7. 高频问题排查与几个实在建议

7.1 Wireshark抓不到本地网卡

前面提过一部分，这里集中再说一次。最常见的三个原因：没有管理员权限运行、Npcap没装好、网卡驱动不支持。其中权限问题占了一半以上。Windows下一定用"以管理员身份运行"，Linux下确认用户加入了wireshark组并重新登录，macOS下确认ChmodBPF已加载。还有一个场景是抓本机回环流量，Wireshark在Windows下通常需要安装Npcap的Loopback Adapter支持，过滤条件设置ip.host == 127.0.0.1或直接用loopback作为捕获接口名。

7.2 抓包文件太大：环形缓冲区与文件切分

长时间抓包时，文件会迅速膨胀，几十GB的pcapng文件打开都困难。务实做法是用捕获选项里的多文件模式：设置每个文件5MB或50MB自动切分，同时限制总文件数量（比如最多保留10个文件），这样待分析的包永远在最新的小文件里。命令行下用dumpcap更省资源：

bash复制dumpcap -i eth0 -b duration:300 -b files:10 -w /path/to/capture.pcapng

这个命令每5分钟切一个新文件，最多保留10个文件。适合做夜间无人值守抓包。另外，如果只是要某个协议的数据，设置捕获过滤器port 80或port 443缩小范围，比事后慢慢过滤要省心得多。

7.3 和Fiddler、Charles这类代理抓包工具的定位差异

最后说下Wireshark和Fiddler、Charles这类工具的边界问题。Fiddler和Charles本质是代理服务器，它们只处理HTTP/HTTPS应用层流量，而且只抓经过代理的会话。它们的优势是界面更贴近"请求-响应"模型，修改请求参数、查看JSON、模拟慢速网络都很方便；Wireshark则是网卡层的通用抓包工具，对所有协议一视同仁，能看到TCP/UDP/DNS/ARP等任意报文。

我的建议是：分析Web接口调试优先用Fiddler或Charles，因为它们的HTTP展示更友好；涉及网络层问题、非HTTP协议、或者需要看TCP连接具体状态时回到Wireshark。两者不是替代关系，是互补关系。

8. 最后一条经验

如果有人问我抓包分析最重要的是什么，我的答案不是工具技巧，而是带着问题去抓包。漫无目的地打开Wireshark抓十分钟，抓到的只是一堆没意义的流量；但在抓包之前明确"我要定位什么问题、关心哪些IP、哪些端口、哪个时间段"，效率和准确性会高得多。实际操作中，我每次抓包前都会先写下问题描述、怀疑方向、需要关注的协议和过滤条件，分析完再对照原来的问题看是否聚焦。这习惯帮我少走了很多弯路。Wireshark本身的深度远不止本文这些，建议你完成基本操作后，再挑一个日常遇到的真实现象，比如一次网页打不开、一次网络变慢，亲手抓一次包，走一遍从过滤、定位、诊断到结论的完整流程。走完这一遍，比翻十遍教程都管用。