搞研发快十年，前前后后摸过几十个抓包工具。平时总有同事问我：做接口联调、APP调试、网络排障，到底用什么工具比较靠谱？这次干脆把我团队里真正用过的15个网络抓包工具整理出来，按照使用场景分类，每个都聊它适合干什么、有什么坑、值不值得学。无论你是前端、客户端、后端，还是运维、测试，这份清单应该都能派上用场。
1. 动手抓包之前，先把这三个概念搞清楚
1.1 抓包到底在抓什么：流量从“看得见”到“看不懂”
很多新手一上来就装Wireshark，结果看到满屏的TCP、UDP、TLS报文直接懵掉。抓包工具的本质，是把你设备网卡上经过的二进制数据包截获下来，再按协议栈从下往上“剥洋葱”。从网卡出去的每一段数据，先有以太网帧头，然后是IP头、TCP/UDP头、HTTP头，最后才是业务数据。
我习惯用一个比喻：抓包就像在快递转运中心看包裹。你不仅能看到包裹外面的快递单（IP和端口），还能撕开纸箱看到里面的商品（应用层数据）。但问题是，现在很多包裹外面套了一层加密的保险箱（TLS/HTTPS），工具帮你截下来之后，没钥匙就只能看到一堆乱码。所以真正决定抓包工具好不好用的，不是它能不能“看到包”，而是它能不能在你授权范围内“看懂包”。
1.2 为什么很多工具抓了包却看不懂：加密与明文的分水岭
HTTP时代抓包确实爽，全部是明文，一个Fiddler就能看穿所有请求。但2024年还在坚持纯HTTP的接口已经很少了，绝大部分线上流量都走了HTTPS，移动端App更是标配SSL Pinning（证书锁定）。这意味着即使你抓到了TLS加密包，也解不开里面的真实内容，除非你能把客户端的信任证书换成自己的中间人证书。
所以工具选型的第一条分水岭就出来了：你只需要在开发环境看接口，还是需要在生产环境做链路排障？开发环境可以上Charles、Fiddler这类代理抓包，因为它能“骗过”客户端，在本地完成HTTPS证书校验后再转发。但生产环境你没法改客户端证书，只能靠Wireshark、tcpdump先把加密流量抓下来做统计分析，比如看TCP重传、连接耗时、包大小，再结合服务端日志定位问题。
1.3 工具分类：先判断你要抓的是哪一层
我推荐工具从来不看下载量，而是先问三句话：你要抓的是HTTP/HTTPS接口，还是TCP/IP底层协议？你的目标是移动端、服务端还是桌面应用？你是在开发环境还是生产环境？
- 以HTTP/HTTPS业务接口为主，优先考虑代理类工具：Charles、Fiddler、mitmproxy、Whistle、Reqable。
- 以TCP/IP、DNS、TLS握手、重传分析为主，优先考虑协议分析工具：Wireshark、tcpdump、TShark。
- 只看本机网络连接和流量分布，优先考虑轻量监控工具：Sniffnet、Termshark。
- 做Web安全测试，绕不开Burp Suite：它既是抓包代理，也是请求改包重放的标准工业工具。
把这四个方向想清楚，后面15个工具才不会看起来大同小异。
2. 协议层与命令行工具：5个值得入门的
2.1 Wireshark：协议分析界的老大
要说抓包工具的元老，Wireshark排第二没人敢排第一。它的强大体现在两点：一是支持的协议数量夸张到上千种，从HTTP/2、gRPC、MQTT到工业总线协议都能解析；二是它有极其灵活的显示过滤器，你可以像写SQL一样组合条件，只显示满足条件的数据包。
我在服务器上排查问题时，最喜欢用它的“统计”功能：点开Statistics菜单，看“Conversations”能快速找到哪个IP对占了最多流量；“Flow Graph”可以看到连接建立和断开的时间线；配合“TCP Stream”可以一键重组出整个HTTP请求的完整内容。新版还支持了HTTP/3的QUIC解码，虽然在线通信里UDP的TLS解密依然麻烦，但至少能看到连接事件了。
实际用Wireshark有几个经验：第一，千万别在笔记本上开“混杂模式”瞎抓整个局域网，流量大到你根本看不完，直接按host 生产IP或port 443过滤；第二要理解“捕获过滤器”和“显示过滤器”的区别，捕获过滤器写在Capture Options里，是真正“过滤后再存储”，显示过滤器只是在已捕获的包里“筛选展示”，两者用错会导致要么抓太多、要么漏核心数据。我的习惯是先用捕获过滤器缩小范围，再用显示过滤器精确定位。
2.2 tcpdump：服务器上唯一靠谱的选手
服务器没有图形界面，也不方便装带GUI的软件，很多生产环境连编译工具链都没有。这种场景下tcpdump就是最稳的那个。它几乎是所有Linux发行版预装命令，用法也不复杂：
# 抓取本机网卡eth0上访问8080端口的流量，保存到文件 tcpdump -i eth0 -w /tmp/port8080.pcap port 8080 # 读取抓包文件，并打印简要信息 tcpdump -r /tmp/port8080.pcap -n | head -20这里需要强调一个容易踩的坑：tcpdump不带-w参数时，是直接往终端打印包信息的，但生产环境流量一大，终端会直接卡死。我建议任何正式排查，都先-w保存成pcap文件，之后再用tcpdump命令或者拉到本地用Wireshark分析。加-n参数是为了不解析域名，否则它会发起反向DNS查询，白白拖慢速度。
tcpdump还有一个好习惯是配合“环形缓冲”使用：-C 100 -W 10表示每个文件100MB、最多保留10个文件，抓到第10个后自动覆盖最老的，避免磁盘被打满。排查线上偶发问题时，我会让它在后台稳定抓几个小时，等到问题复现后只取对应时间段的文件来分析，这件事用其他带界面的工具反而做不到。
2.3 TShark：Wireshark的命令行形态
TShark本质上是Wireshark的命令行版，但它不是“Wireshark作品里的附带品”，而是每个脚本工程师的利器。同样是用命令行抓包，tcpdump只能做基础过滤，TShark却能直接解析应用层协议、统计HTTP状态码、导出JSON格式数据。
举个例子，我要统计一个pcap文件里所有HTTP请求的URL和状态码，一条命令就出来了：
tshark -r capture.pcap -Y "http.request" -T fields -e http.request.uri -e http.response.code这句命令的意义在于，wireshark能做的事，TShark也能在脚本化场景里做。平时写排查脚本时，我会先用tcpdump在故障机器抓10分钟包，保存成pcap文件，然后用TShark在本地跑各种分析，完全不用等Wireshark一点一点打开大文件。
TShark对大文件的处理也比Wireshark稳定，Wireshark打开超过2GB的pcap会非常卡，TShark直接走命令行批量处理反而更高效。如果你要做自动化监控，比如盯某个流量特征是否出现，TShark配合grep、awk就能组成一条非常轻量的报警流水线。
2.4 Termshark：给tcpdump套上“半图形”外壳
Termshark是一个比较小众的开源工具，本质上是用Wireshark的解析引擎，在终端里渲染出一个类Wireshark的界面。它支持通过方向键浏览包列表、展开每个包的协议树、查看TCP流内容，看起来就像在终端里种了一个随身携带的Wireshark。
它的价值在于：当你通过SSH登录远程服务器排查问题时，本地没有图形界面，X11转发又慢，但不能把大pcap文件来回拷贝的情况下，Termshark直接读取服务器上已有的包文件，用终端交互模式操作。体验虽然比不上原生Wireshark，但比tcpdump -r一行行翻日志强太多了。
安装也不麻烦，Linux和macOS都有包管理支持，Windows下可以通过WSL运行。我的使用场景一般是：先用tcpdump在服务器抓包，然后随手tshark或termshark打开看一遍，快速确认问题方向，再决定要不要把文件拉回本地做深度分析。
2.5 Sniffnet：轻量可视化的流量监控工具
Sniffnet是个年轻的开源项目，定位很清晰：不追求深度的协议解析，而是把本机所有网络连接的“实时概览”做得漂漂亮亮。它有图形界面，打开后能看到当前每分钟上下行的吞吐量、哪些远程IP占用了最多流量、哪个进程正在产生流量，还能把连接按端口分类排序。
它非常适合桌面开发场景：比如你怀疑某个后台进程在频繁上传数据，或者想快速确认本机当前有哪些TCP连接，Sniffnet两秒就能给出答案。它不像Wireshark那样把所有包都倒给你，而是先把“器材列表”整理成仪表盘给你看。它的局限在于，不能像代理类工具那样对HTTPS做中间人解密，也无法直接看到HTTP请求的body，所以更多是定位问题的第一步——先发现谁在通信，再决定要不要上Wireshark或Charles做下一步分析。
3. HTTP/HTTPS代理类抓包工具：6个主流选择
3.1 Charles：移动端调试的“老黄牛”
Charles是老牌代理抓包工具，macOS和Windows都有客户端，它的强项在于代理设置和证书管理都做得极其顺手。我最早用它抓iPhone上的App请求，流程简单到不需要看文档：电脑开Charles，手机Wi-Fi代理指向电脑端口8888，首次打开App时手机会提示安装Charles证书，装完就能在电脑上看到App发出的所有HTTP/HTTPS请求。
Charles的“Map Local”和“Map Remote”功能也很有用：前者可以把远端接口重定向到本地文件，方便前端在真实App环境里联调Mock数据；后者可以把一个域名代理到另一个环境，比如把线上API切到测试环境，不用改App代码。
它的界面布局十几年来变化不大，新用户可能觉得有点老，但稳定性确实可以。移动端开发团队如果只能买一个商业工具，我通常推荐Charles，因为它在断点调试、重复请求、模拟慢网络上做得成熟，功能看似基础，但对一线开发者是实打实提高效率。
3.2 Fiddler Everywhere：跨平台后的Fiddler家族
老Windows用户对Fiddler Classic应该不陌生，那是很多后端程序员第一个抓包工具。Fiddler Classic的局限也很明显，它只支持Windows，而且基于.NET Framework生态，新macOS上跑不了。Fiddler Everywhere就是官方出的跨平台版本，界面现代化，支持Windows、macOS、Linux，逻辑上依然保留Composer（手工构造请求）和Auto Responder（本地文件替换响应）这两大核心能力。
实际使用时，Fiddler Everywhere的“请求篡改”比Charles更直观：你选中一个会话，右键Breakpoint，就能在请求发出前改写Header或Body，再放行。这个能力在调试接口参数、模拟异常请求时非常有用。它的缺点是免费版有会话数量限制，适合个人日常调试用，公司团队重度使用还是需要付费订阅。
3.3 mitmproxy：可编程的中间人调试代理
mitmproxy是命令行中间人代理，Python生态的老牌项目。它最值钱的地方不是图形界面，而是“人人皆可脚本化”。你写一个Python插件，就能对每一个经过的请求执行自定义逻辑，比如自动替换token、修改Host、统计接口耗时。
它的三种交互界面，我简单说一下：mitmproxy是终端TUI界面，适合直接看请求；mitmdump是无界面模式，适合挂在后台跑脚本；mitmweb是内置的Web界面，适合不习惯终端的用户实时查看。三者共享同一个流量依赖，核心逻辑是一样的。
我经常用它做自动化接口录制：把App流量代理到mitmdump，配合一个几十行的Python脚本，把所有请求按“接口路径+响应格式”自动分类存成JSON，之后再交给测试团队去生成回归用例。这件事用Charles也能做，但要做到动态处理、批量输出，还是mitmproxy更方便。
3.4 Whistle：Node.js生态里的规则派
Whistle是国人写的一个基于Node.js的跨平台抓包调试工具，它最大的特色是“规则配置”能力极强。你可以在它的UI里写一组类似这样的规则：
# 将特定路径的请求代理到本地mock服务 https://api.example.com/v1/user /Users/mock/user.json这种基于域名和路径的映射，让它在前后端联调、多环境切换、Mock数据管理上非常高效。不需要改代码、不用发版，线上接口一键转发到本地，对调试线上问题也很有帮助。国内团队用它的很多，社区里有大量现成规则模板，新手遇到问题搜索解决方案也容易。
Whistle的性能在同级工具里不算顶级，流量特别大的时候界面会有一点卡顿，但日常开发和联调完全够用。它更适合个人开发者和中小团队的本地调试场景。
3.5 Reqable：新一代API调试与抓包一体工具
Reqable是近两年发展很快的新一代工具，它把HTTP调试客户端和抓包代理融合到一个软件里。也就是说，你既可以用它像Postman那样构造请求、管理接口文档，也可以启动内置代理模式抓手机App的包，一套工具覆盖多个场景。
相比Charles和Fiddler，Reqable的界面更现代，操作也更贴合新一代开发者的习惯，中文支持非常完善。它支持Windows、macOS、Android、iOS各端，还能在手机端直接运行轻量版抓包，后端联调、学生党学习HTTP协议都很方便。它的免费版本已经覆盖了大部分日常功能，重度使用才会需要Pro版。
我对这类“一体化”工具的评价一直是：它未必能做专利级深度分析，但胜在降低心智负担。日常办公场景，你装一个Reqable，抓包、改包、造请求、看响应全搞定，比装一排专业工具更舒服。
3.6 Proxyman：macOS上的清爽选择
Proxyman是专门为macOS/iOS设计的一款抓包工具，原生界面非常流畅，上一秒还在用快捷键切换Tab，下一秒就能在请求列表里用拼音模糊搜索接口。做iOS开发的同事常用它，因为它对流程：“iPhone连上Mac → 打开Proxyman → iPhone自动配置代理”这个链路优化得极好，基本是无感配置。
它的Scripting脚本能力也很强，用户可以写Swift或JavaScript脚本，在请求发出、响应返回时自动做改包处理。对于SwiftUI项目调试、iOS端HTTP缓存调试，Proxyman比Charles更贴合苹果生态。当然，如果你主力机型是Windows或Android，Charles或者Reqable可能更合适，Proxyman的跨平台支持相对有限。
4. 浏览器、移动端与安全测试专项工具：4个补充装备
4.1 Chrome DevTools Network：前端工程师的默认起点
严格来说DevTools不算第三方工具，但它是每个前端、客户端开发者每天点开最多的“抓包工具”。按F12打开Network面板，你能看到页面发起的每一个HTTP请求，包括请求URL、请求方法、状态码、耗时、请求头、响应体，还能模拟不同的网速条件。
它的Filter功能非常方便：按Fetch/XHR过滤出ajax请求，按Img过滤图片，按JS过滤脚本。最多人忽略的是“Preserve log”（保留日志）开关，默认不开启，页面一旦跳转就被清了。排查跳转类问题时，一定要记得打开这个开关。
Chrome DevTools在“分析前端接口耗时”这一块很直观，Timing标签会展示请求在等待、DNS解析、连接建立、TTFB等环节各自花了多少时间，这比抓包工具看pcap还高效。但它只能看到浏览器自己发出的请求，想看App流量还是得上代理工具。
4.2 Firefox DevTools Network：别小看Firefox的开发者工具
Firefox的开发者工具在很多方面比Chrome做得更细致，尤其体现在“编辑并重发”功能上，这个能力在旧版Chrome里并不明显。你在Network面板中右键一个请求，点击“编辑并重发”，可以直接改请求头、请求体并发出新请求，相当于一个内置的轻量接口调试器。
Firefox还有一个“复制为cURL”的功能，生成出来的cURL命令非常标准，在Linux下直接跑的一段工具，省去了手工构造请求的麻烦。对经常在终端里排查问题的人，这算一个隐藏技巧。
主流前端开发基本都在用Chromium系浏览器，但Firefox在隐私和扩展生态上有自己的优势。如果你需要对比不同浏览器的网络表现，重定向、多开、拆包对比这些场景，Firefox绝对值得常备。
4.3 HttpCanary：安卓手机上的本地抓包
HttpCanary是Android上很有名的抓包App，不需要电脑也能直接抓取手机上App的请求。对安卓开发者来说，这是一个随时可用的移动端调试工具，尤其是遇到“手机上某个接口报错，但电脑上复现不了”的情况，直接用HttpCanary在当前设备上抓包，非常方便。
它支持系统级代理抓包，也支持部分场景的HTTP/2解析，还可以导入导出pcap文件。但它的核心限制和所有手机端抓包工具一样，对高版本Android系统下App的证书信任机制很敏感。Android 7.0之后，很多App默认不信任用户安装的证书，抓出来依然是解密失败。这种情况下要配合Xposed或Frida，或者要求开发环境把networkSecurityConfig配置成允许用户证书，否则手机端直接抓包基本无解。
4.4 Burp Suite Community：授权安全测试的标准化工具
Burp Suite是Web安全测试领域的标配，它的Community版免费，足够日常抓包、改包、重放、测试越权等场景使用。你没看错，它也能抓包，而且比通用抓包工具增加了更多“攻击”向的能力，比如Intruder（暴力枚举参数）、Repeater（手工重放请求）、Decoder（编解码）。我一直强调，安全类工具只能在“授权范围内”使用，测试自己负责的系统、参加正规众测或参与渗透测试项目时，Burp Suite是绕不开的。
它通过内置的代理端口（默认8080）接收浏览器或客户端的流量，然后你可以逐个拦截请求，修改后放行。这个“拦截-修改-放行”的工作流，比Charles更细、更适合安全测试场景。Burp的扩展生态也很强大，各种插件让抓包后的自动化分析能力大幅提升。
5. 工具选型指南：这些场景到底该用谁？
| 核心场景 | 首选工具 | 备选工具 | 理由 |
|---|---|---|---|
| 前端页面XHR/接口调试 | Chrome DevTools Network | Firefox DevTools Network | 零配置，直接看请求详情和Timing |
| 移动端App接口联调 | Charles | Reqable、Proxyman | 代理安装证书简单，过滤、改包方便 |
| 服务端Linux环境排障 | tcpdump | TShark、Termshark | 无图形界面也能抓包，可脚本化 |
| 全链路协议级分析 | Wireshark | TShark | 协议解析最全，适合深度分析pcap |
| 快速查看本机连接情况 | Sniffnet | Termshark | 轻量、直观，秒级别看到连接概况 |
| Web安全测试（授权范围） | Burp Suite Community | mitmproxy | 拦截、改包、重放、注入一条龙 |
| 自动化接口录制/脚本改包 | mitmproxy | Whistle | Python脚本扩展，适合批量处理 |
这里我要多说一句：选型不是“选最牛的”，而是“选最不折腾的”。比如你只是调试一个网页登录接口，完全没必要先装Charles，浏览器F12就够了；当你在服务器上排查时，也别指望Charles，它没法装在没有图形界面的机器上。场景对了，工具才顺手。
6. 实战案例：用Charles抓一次手机App的HTTPS流量
6.1 准备工作
打开Charles后，默认它会监听本地端口8888。确认电脑和手机连在同一个Wi-Fi下，然后查看电脑的局域网IP，比如192.168.1.100。进入手机Wi-Fi设置，将代理改为“手动”，主机名填这个IP，端口填8888。此时电脑上Charles应该已经弹出一个提示框，问你是否允许这个连接，点Allow。
这一步看起来简单，但有个非常容易翻车的地方：Windows防火墙会拦截来自局域网其他设备的入站连接，第一次配置时一定要先允许Charles通过防火墙，否则手机端代理配好了也连不上。
6.2 安装证书与设置代理
在手机上用Safari或Chrome访问chls.pro/ssl，下载Charles根证书。iOS下载后需要到“设置-已下载描述文件”里安装，然后再到“设置-通用-关于本机-证书信任设置”里把Charles证书开关打开。Android则需要在“安全-加密与凭据-安装证书”里选择CA证书，可能还需要设置锁屏密码。
如果跳过了“证书信任设置”，你会发现抓包列表里全是TCP或TLS Close，看不到HTTP请求内容。这个步骤不是可选，是必须要做，很多新手在这卡住。
6.3 开始抓包，用Filter快速定位接口
配置完成后，随便点开App里的一个页面，Charles的会话列表里就会刷出一堆请求。此时用左下角的Filter输入关键词（比如接口路径或域名），能快速过滤出目标接口。点开一个请求，可以看到Request和Response两个标签页，Request里包含URL、Method、Headers、JSON Body，Response里能看到接口返回的数据。
如果响应内容是乱码，多半是接口启用了gzip或br压缩，Charles默认会自动解压缩，偶尔遇到特殊编码需要点击“Create LOCATION”或“Save Response…”手动处理。另外，实时抓包时会发现有些长连接或WebSocket消息不会立即出现在列表里，需要在会话列表空白处右键选择“Open SSL Proxying Settings”，确认HTTPS代理是开启的。
6.4 遇到SSL Pinning怎么办
如果你在手机上看App购物、聊天、支付这类对安全性要求高的App，装完证书后依然抓不到明文，多半是SSL Pinning在作祟。它意味着App代码里写死了“只信任指定的服务端证书”，Charles的中间人证书会被App判定为非法，从而直接断开连接。
正规解法是：在自己的测试包里，暂时关闭SSL Pinning验证，或者配置networkSecurityConfig允许调试证书；进阶方案是使用Frida写Hook脚本绕过证书校验，但这会涉及Root设备和代码注入，风险高、操作复杂，不是普通调试场景的首选。如果只是联调接口，我建议直接让后端开一个测试域名、测试环境证书，或者临时关掉该环境的强制Pinning，这样更省心。
7. 抓包路上最容易踩的5个坑
7.1 抓包工具一开，电脑上不了网
这是最经典的问题，成因大多是代理配置错误形成了循环。比如你把Charles或Fiddler的代理地址写成了它自身监听的端口，或者系统级代理没关闭，又叠加了浏览器插件代理，导致请求在代理链路里打转。处理方法：先关闭所有代理工具，重置Wi-Fi或刷新系统代理设置，再重新按顺序启动。
7.2 抓包文件太大，打开就卡死
Wireshark打开超过2GB的pcap文件会非常吃力，甚至直接崩溃。建议抓包时就用捕获过滤器缩小范围，先抓特定端口或特定IP；如果已经抓到超大文件，先用editcap -i 300把文件切割成5分钟的小文件，再用TShark导出CSV摘要，最后只针对需要的那一段导入Wireshark。
7.3 HTTPS抓不到明文，但证书明明装了
除了SSL Pinning外，还有一个常见情况是：你只给系统装了证书，但高版本Android或iOS平台要求App本身信任该证书。开发环境下可用networkSecurityConfig显式信任；测试环境最省事的方式是让后端临时关闭强制证书校验。另外，Chrome/Firefox浏览器偶尔也会因为证书链不完整报错，安装时务必勾选“完全信任CA证书”。
7.4 抓包工具会影响性能，线上环境慎用
抓包本身是有开销的，流量大时尤其明显。特别是打开Wireshark的“实时抓包+全量存储”，会把磁盘IO和CPU占满。线上排查时，我建议先tcpdump用环形缓冲停驻抓包，不到万不得已不搞全流量截获；抓完立刻停止，再进入分析流程，尽量缩短在业务链路上“插探针”的时间。
7.5 忽略时间戳，导致无法定位问题
排查线上问题必须先抓异常时间点的包，而不是凭感觉抓一段再来回翻。pcap文件里每一帧都有时间戳，配合Wireshark的统计功能可以看到“某时刻TCP重传率飙升”或“某请求的TTFB突然变长”。如果从头到尾没有记录系统时间，分析时连“问题发生在上午还是下午”都说不清，那这包就算白抓了。
最后再分享一个我自己的使用心得：工具选型没有万金油，大多数团队真正高频用的，其实就那两三个。我日常组合是“服务端问题用tcpdump + TShark，协议深挖用Wireshark，移动端联调用Charles，快速验证用Chrome DevTools，自动化录制用mitmproxy”。抓包工具真正考验的，从来不是谁装的工具多，而是你是否了解HTTP、TLS、TCP这些底层协议，以及能不能在最快时间内定位到“数据在哪一层出问题”。把这15个工具摸透一半，日常排查效率就能明显上升一个台阶。
