很多人第一次接触抓包工具都是因为某个接口调不通、某个页面加载特别慢、或者某个 App 的请求莫名其妙失败了。面对 Wireshark、Fiddler、Charles 这三个名字新手很容易懵——它们到底有什么区别我到底该装哪个装完又该点哪里这篇文章不打算做那种功能罗列式的说明书我会从实际干活的角度把三个工具的定位、安装、抓包配置、手机抓包、弱网测试、HTTPS 解密这些最核心的场景串起来讲顺便把我这些年踩过的坑一并交代清楚。无论你是做前端、客户端、服务端还是刚入门测试只要能跟着操作一遍日常的抓包需求基本都能覆盖。1. 先把三兄弟的分工整明白再动手不迟很多教程上来就让你装软件、点开始结果你抓了一堆包却完全看不懂自己要找什么。我的建议是先花五分钟搞清楚这三个工具各自的脾气后面能少走很多弯路。1.1 Wireshark 管的是网卡Fiddler 和 Charles 管的是应用Wireshark 的核心工作方式是直接监听网卡上流动的数据包。它工作在比较底层的位置能看到的不仅仅是 HTTP/HTTPS还有 TCP、UDP、DNS、ARP、ICMP 等等你能想到的所有协议。它的价值在于全量和底层比如你怀疑某个服务端下发了异常数据、某个 TCP 连接反复重传或者某个 DNS 解析超时这类问题用 Wireshark 是最合适的。因为它根本不挑协议只要数据从网卡上过它基本都能捕获。Fiddler 和 Charles 的工作方式则完全不同。它们是代理模式在电脑上开启一个本地代理服务然后让系统的流量或者手机的流量经过这个代理。它的优势在于天然懂 HTTP/HTTPS 协议界面里直接按会话列表展示每个请求的 URL、状态码、耗时、请求头、响应体都清清楚楚。Fiddler 在 Windows 生态里更常见老牌且功能全面Charles 在 macOS 和移动端调试场景里口碑更好界面也更像 Mac 的风格。如果你把网络数据比作一条河Wireshark 是站在河边看整条河的水流能看到暗流涌动Fiddler 和 Charles 则更像是在河道上装了个闸口专门盯着某一段的船只HTTP 请求进出。两者不冲突很多时候甚至要配合使用——先用 Charles 缩小范围再用 Wireshark 深挖底层。1.2 常见场景下的选型建议从我接触过的项目经验看不同角色有不同的偏好这里给一个比较通用的选型参考场景首选工具原因分析 TCP 重传、网络延迟、丢包Wireshark底层数据完整自带流图和统计调试本地前后端接口Fiddler按会话展示清晰断点修改方便抓取 Android/iOS 手机 App 的 HTTPS 请求Charles手机代理配置直观证书安装流程成熟模拟弱网环境、延迟、限速Charles 或 Fiddler两者都支持降速模拟Charles 更顺滑分析某个进程/特定端口的流量Wireshark支持过滤器精准圈定目标流量抓取微信小程序、公众号 H5 页面Charles配合手机代理过滤规则简单当然这不是绝对的。比如有人用 Fiddler 也能把手机抓包玩得很溜有人用 Wireshark 分析 HTTP 也完全够用。只是从上手门槛 场景适配度来说上面这个选择在多数情况下是效率最高的。如果你还在纠结先装 Charles 和 Wireshark 这两个就足够覆盖 90% 的需求了。2. Wireshark 从安装到可视化分析一条龙实操Wireshark 是三个工具里最容易被新手劝退的因为打开之后界面密密麻麻全是数据包每个包长得都差不多。但只要掌握了过滤和几个核心视图它其实是排查疑难网络问题的大杀器。2.1 安装与抓包前的关键设置先说说安装。Wireshark 在官网下载对应系统的安装包即可Windows 安装时一路 Next 就行但需要注意一个细节如果要在 Windows 上抓取本地回环流量也就是本机访问本机服务的流量光凭默认的 Npcap 可能不够。Windows 的 loopback 流量默认不走网卡驱动而是走一个虚拟的适配器。Wireshark 安装的时候如果检测到 Npcap可以额外勾选安装Npcap Loopback Adapter我建议你勾上否则后面抓 localhost 的数据包经常是空的很容易让人怀疑人生。macOS 上安装则要先装一个叫 ChmodBPF 的启动项或者用 Homebrew 安装brew install --cask wireshark如果启动时提示没有权限访问网卡去系统设置里给 Wireshark 的终端父进程授予网络权限或者手动加载 ChmodBPF 即可。打开 Wireshark 之后你会看到一堆网卡接口列表。关键一步是选中正确的网卡。不要看到名字差不多的就随便选如果你连的是 Wi-Fi就选名字里带 Wi-Fi 或者 en0 的如果是插网线选 Ethernet。选错的话抓到的流量跟你想要的可能完全不在一个频道上。2.2 抓包与过滤过滤器的语法得这么学开始抓包之后数据包哗啦啦地滚。这时候最重要的技能就是缩小范围。Wireshark 的过滤器分两种抓包过滤器Capture Filter和显示过滤器Display Filter。我的经验是抓包过滤器尽量少用因为一旦设错漏掉了关键数据又要重新抓一遍显示过滤器是更安全的因为它只影响显示不影响原始数据。最常用的显示过滤器就这么几个# 只看 HTTP 请求 http # 只看某个 IP 的流量 ip.addr 192.168.1.100 # 只看某个端口的 TCP 流量 tcp.port 443 # 只看 DNS 查询 dns # 只看某个 TCP 流的完整会话 tcp.stream eq 1其中tcp.stream eq N是我用得最多的一个。当你双击任意一个 TCP 包选择右键菜单里的Follow TCP StreamWireshark 会把这次 TCP 连接里的所有数据拼起来给你看就能直接看到原始的 HTTP 请求头和响应体。如果响应体是 JSON 或者 HTML在流视图里还能自动高亮非常直观。这里有个容易踩的坑如果你过滤http却啥也看不到先确认一下这个请求是不是走 HTTPS 的。HTTPS 的流量被 TLS 加密了Wireshark 默认不会显示成 HTTP你得先配置 SSL key log或者开启解密功能。对于开发者来说更好的做法是让浏览器或应用导出 TLS 密钥然后在 Wireshark 的 Preferences - Protocols - TLS 里把密钥文件配进去。配置之后HTTPS 流量就能在 Wireshark 里解出明文 HTTP 了。2.3 用统计和着色功能快速定位问题Wireshark 的界面默认有不同颜色的行比如 TCP 重传是浅红色异常包是黑色正常 HTTP 请求是绿色的。其实不用刻意去记住这些颜色但遇到一片红的时候就要警惕了——大概率是网络质量不好。另外一个非常好用的功能是 Statistics 菜单。比如我想看某个时间段内有没有大量重传直接打开 Statistics - TCP Stream Graph - Time-Sequence Graph能直观看到 TCP 序列号的变化如果出现窗口锯齿波就说明有重传或者丢包。还有 Statistics - HTTP - Requests能看到所有 HTTP 请求的占比和耗时分布排查哪个接口拖慢了页面这种问题非常高效。我的习惯是先用显示过滤器圈定可疑 IP 或端口再用 Follow TCP Stream 把原始流量拉出来看最后用 Statistics 做整体判断。这一套组合拳下来十有八九能定位问题。3. Fiddler 的代理抓包与弱网测试实操Fiddler 在老牌 Windows 开发者和测试人员里口碑极好。它虽然是代理但胜在功能强、门槛低。Windows 上双击安装装完打开它默认就会接管系统代理浏览器的 HTTP/HTTPS 请求都能直接看到基本不用额外配置。3.1 Fiddler Classic 的安装与 HTTPS 解密设置Fiddler Classic 是老版本免费但一直在维护功能反而是很多人最喜欢的——简洁、稳定、够用。Fiddler Everywhere 是跨平台的新版本收费界面也更好看但免费版有流量限制。我的建议是如果你只是日常调试用 Fiddler Classic 就够了。打开 Fiddler 之后如果你的页面访问都正常但看到的是 CONNECT 请求那就需要开启 HTTPS 解密。路径是 Tools - Options - HTTPS - Decrypt HTTPS traffic勾选后按提示安装根证书。装完证书重启 Fiddler再访问页面就能看到完整的 HTTPS 请求内容了。这里有个常见问题开启解密后某些带证书校验的应用或浏览器会报证书错误。这是因为 Fiddler 用自己的根证书替换了原来的证书链。遇到这种情况你在浏览器里手动信任 Fiddler 的根证书即可但在手机或者独立 App 上就得看应用是否允许用户添加信任的证书。这也是后面讲手机抓包时最大的一个坎。3.2 Fiddler 的请求修改与断点功能Fiddler 很适合做接口测试和 mock 数据。比如我想测试某个接口在返回异常时的前端表现又不想真的去改服务端代码就可以用 Fiddler 的 AutoResponder 功能。左边的会话列表里选一个请求右键 - Save Response - 保存到文件然后修改文件内容再打开 AutoResponder 把https://example.com/api/user映射到那个修改后的文件前端再发请求时就会收到你伪造的响应。这个操作对前端联调非常实用堪称前后端联调神器。如果你需求更精细要修改请求内容再发出去用断点功能。在 QuickExec 命令行里输入bpu https://example.com/api回车后所有匹配这个 URL 的请求都会在发出去之前停在 Fiddler 里。此时你可以修改请求的 Header、Body然后点击 Run to Completion 把修改后的请求发送出去。再输入bpu不带参数即可取消断点。这个方式用来排查改了参数后服务端到底怎么处理非常直接。3.3 弱网测试的两种实现路径Fiddler 的弱网模拟也是测试同学的刚需。Fiddler 提供了两个限速方案在菜单 Rules - Performance - Simulate Modem Speeds 勾选这会模拟一种默认的 56k 拨号上网速度非常适合模拟极慢速网络。更精确的做法是自定义延迟脚本。按 F11 打开 FiddlerScript在OnBeforeRequest函数里加入一行oSession[request-trickle-delay] 300;表示每个请求发出前延迟 300ms。如果要在响应阶段加延迟就在OnBeforeResponse里加oSession[response-trickle-delay] 300;光这一招就能模拟出高延迟低带宽的场景比单纯勾选 Modem 精确得多。实际测试弱网下的超时逻辑、loading 状态、重试机制用 FiddlerScript 调整延迟是最方便的。4. Charles 的抓包配置与移动端调试Charles 是我个人最常用的工具尤其是做移动端调试时它的体验比 Fiddler 顺滑不少。Charles 支持 macOS、Windows、Linux唯一的问题是正常渠道需要付费授权。不过碰到那种二三十天的试用期限制很多人会去找破解版或者注册码这里我不太建议大家去折腾这些——毕竟买断价格不算贵而且用破解版一旦出了问题排查起来更闹心。不过如果你只是偶尔用一下试用版其实也够跑通基本流程。4.1 Charles 的安装、代理端口与 SSL 解密Charles 的默认代理端口是 8888。开启 SSL Proxying 是核心步骤菜单 Proxy - SSL Proxying Settings - 勾选 Enable SSL Proxying然后在 Location 里添加*和端口443表示解密所有 HTTPS 请求。配置完成之后如果你只是抓本机的浏览器流量基本已经能用了。但要想抓手机上的流量需要在手机上设置 Wi-Fi 代理手机和电脑连同一个局域网手机 Wi-Fi 设置里手动代理填上电脑的 IP 和端口 8888。注意电脑 IP 用ipconfigWindows或ifconfigmacOS查一下不要填成 127.0.0.1。手机连上代理之后Charles 会弹出一个允许连接的确认框点击 Allow 之后你就能在 Charles 的会话列表里看到手机上的所有 HTTP 请求了。这时候大家常说的打开 Charles 手机抓包其实核心就这三步连同一个 Wi-Fi、设置代理、允许连接。4.2 手机安装 Charles 证书并完成 HTTPS 抓包默认情况下手机上走了代理之后虽然 Charles 能看到 CONNECT 请求但看不到 HTTPS 的明文内容。要解密 HTTPS需要在手机上安装 Charles 的根证书手机浏览器访问http://chls.pro/ssl要在走代理的状态下访问。下载证书并安装。iOS 上安装后还要去 设置 - 通用 - 关于本机 - 证书信任设置 里把 Charles Proxy CA 的开关打开。Android 上如果是 7.0 以上的系统情况比较复杂。Android 7.0 之后App 默认不信任用户安装的 CA 证书只有系统证书才受信任。这意味着很多 App 即使装了 Charles 证书HTTPS 请求依然是密文显示。Android 上这个坑非常典型。如果你只是抓浏览器流量装证书就够了但抓某个 App 的 HTTPS 流量时发现全是 CONNECT不是 Android 系统限制问题就是 App 做了证书校验SSL Pinning。前者可以通过把证书安装为系统证书来解决但需要 root后者则要用到 Frida 之类的 Hook 手段绕过校验。这些属于进阶玩法普通开发调试场景不一定用得上真遇到再说。4.3 Charles 的限速、断点修改和重发功能Charles 的限速功能在 Proxy - Throttle Settings 里勾选 Enable Throttling然后设置带宽、延迟、丢包率。我通常设置一个 3G 网络预设模拟出 780kbps 的下载速度和 100ms 左右的延迟用来测接口超时和图片懒加载效果非常好用。注意 Throttle 要勾上 Only for selected hosts 或者全局按需调节。Charles 的断点修改和 Fiddler 的 AutoResponder 对应叫 Map Local在 Tools - Map Local 里配置。你可以把一个远程 URL 映射到本地 JSON 文件改完本地文件刷新页面就能生效非常适合 mock 数据。如果你要修改请求参数再放行可以右键某个请求选择 Breakpoints然后在 Charles 弹出的编辑框里改 Request 参数再 Execute。这个操作比 Fiddler 的断点更直观因为它会可视化地让你编辑每个字段。Charles 还有一个常用的重发功能选中任意请求右键 - RepeatCharles 会按照原始请求再发一次右键 - Repeat Advanced 可以设置循环次数。调试定时任务、压测接口或者不断复现线上 Bug 的时候这个功能能省不少事。5. 手机抓包失败的排查链路对症才能下药手机抓包是三个工具使用中最大的难点而且失败的场景五花八门。这里我把最常见的几条排查路径整理成一套思路遇到问题照着一层层摸至少能解决九成的情况。5.1 配置层面证书、代理与网络的三层检查很多人手机抓包失败第一反应就是工具不行其实绝大多数是配置层面的问题。我自己排查时习惯按下面这个顺序走代理是否生效用手机浏览器访问http://www.baidu.com然后看 Charles/Fiddler 里是否出现新的会话。如果没有八成是代理没配对。检查手机和电脑是否同一网段是不是连的同一个 Wi-Fi有的公司网络有 AP 隔离设备间互相访问不了代理端口是否一致。证书是否装好浏览器访问http://chls.pro/ssl能弹出证书安装说明就说明代理通了。iOS 上证书信任开关没开也是常见的漏网之鱼。HTTPS 是否解密如果能看到请求但 Content 是密文说明 SSL Proxying 的配置没生效。Charles 里要检查 SSL Proxying Settings 有没有加*:443Fiddler 里要检查 Decrypt HTTPS traffic 是否勾选。这三层排查能解决 80% 的问题剩下的就进入协议层面的硬骨头了。5.2 协议层面App 的证书校验与双向认证当你确认代理和证书都没问题但某个 App 的 HTTPS 请求仍然解密不了大概率是 App 做了证书校验或双向认证。证书校验SSL Pinning是客户端内置了服务端的公钥或证书指纹发现证书不对就断开连接。这种情况下 Charles/Fiddler 用自己证书替换的招数全会失效。要绕过 SSL Pinning常见路线有几种使用 Frida objection 脚本进行运行时 Hook。用 Magisk 模块在系统层替换 CA 证书。如果只是想看个大概也可以直接在手机上装抓包软件如 HttpCanary、Reqable 之类的非代理抓包方案。不过我不太建议为了绕过 SSL Pinning 而专门折腾 Frida除非你是真的做安全工作或者在逆向分析。大多数开发场景下与其想着怎么绕过校验不如让开发在 debug 包里关掉 SSL Pinning或者加一个白名单。这个成本远比后期疯狂逆向要低。我和我身边的同事基本都是这么干的。6. 三款工具的高频协作技巧各有各的舒服姿势单独讲完每个工具之后我想聊一下实际工作里如何把它们配合起来用一个完整的排查流程往往不是单靠某一个工具能搞定的组合使用的效率才是最高的。6.1 从 Charles 定位到 Wireshark 深挖的场景举个例子你发现 App 某个接口响应很慢先用 Charles 找到这个接口看它的耗时分布。如果发现耗时主要花在 TTFB服务器响应时间上那就是服务端慢如果 TTFB 很短但整个请求耗时很长可能出在传输阶段这时就轮到 Wireshark 出场了。Wireshark 里抓一段传输过程的包重点看 TCP 窗口大小、有没有重传、有没有 ZeroWindow 现象。如果看起来有大量重传说明网络链路有问题可能是 Wi-Fi 信号差、路由丢包也可能是运营商丢包。如果看到很多 ZeroWindow说明接收方应用处理不过来是应用层或者缓冲区设置的问题。这种Charles 定位、Wireshark 深挖的组合比单用任何一个工具都高效。6.2 用 Fiddler 和 Charles 做 Mock 数据的分工平时我做前端联调时会分情况选择工具如果服务端接口还没好但前端需要先渲染页面我用 Charles 的 Map Local 功能把接口响应映射到本地 JSON 文件。Charles 的映射支持正则替换比如/api/user/(\d)映射到/mock/user.json可以处理带路径参数的接口。如果服务端已经好了但我想临时改个响应看看边界情况用 Fiddler 的 AutoResponder 更方便它能直接编辑原始响应也可以自定义返回内容。如果只是想在浏览器里调试不需要动底层网络数据直接用 Chrome DevTools 就行完全没必要开代理工具。这里有个经验用 Map Local 或者 AutoResponder 时一定要记得勾选精确匹配或正则匹配的选项否则代理工具会过度匹配把所有请求都映射到同一个文件导致页面全乱。我刚开始用的时候经常犯这种低级错误调了半天才发现是通配符写太宽了。6.3 抓包安全边界这些红线千万别碰最后必须提一嘴安全合规的问题。抓包工具本身是无罪的但用在哪里、抓什么数据有明确的边界。比如抓取用户私密通讯内容、绕过付费系统、篡改支付接口这类行为性质就严重了。普通开发调试中我们应该只抓自己负责的应用、自己部署的服务并且在使用代理工具时注意不要保存涉及敏感信息的会话文件。我见过不少新手在调试时顺手把带手机号、身份证号的响应数据直接贴给同事或者发到群里这是非常不合适的。抓包是技术活也是责任活管好自己手里的数据比什么技巧都重要。写在最后回到文章开头的问题三个抓包工具到底怎么选我的答案已经很明显了——不同场景用不同的工具甚至组合使用。Wireshark 管底层网络Fiddler 管 Windows 下的 HTTP 调试Charles 管移动端抓包和可视化代理调试。这三板斧用熟了你在日常开发排查里基本没有搞不定的网络问题。最后再补充两句实操心得。第一抓包之前先把需求想清楚到底是要看协议层还是应用层这决定了你该选哪个工具也决定了你该开哪个视图别上来就撒网。第二代理工具的证书一旦安装到系统里它就是一把双刃剑平时不调试的时候建议把代理关闭免得电脑和手机上一堆流量都莫名其妙被解密。要是你刚开始折腾这些东西建议照着这篇文章把每个工具的配置流程都完整过一遍跑通一次再谈进阶。网络排查的很多东西光看不练是记不住的动手之后你才会发现原来那些看起来玄乎的网络问题大多数时候也就是几个配置项的事。