手机抓包听起来就是把数据截下来看两眼但真上手你会发现同样叫抓包工具和工具之间隔着一道分水岭有的装在手机里直接在设备本地捞流量有的则是让手机把流量交给电脑上的工具来过一遍。标题里那句“装手机上的和抓手机的是两条不同的路”算是把这件事说到点子上了。这篇文章主要面向移动端开发、测试、接口联调和网络排查的同学把两条路的工具清单、HTTPS 解密原理、高频踩坑点一次讲透看完你至少能判断我当前这个需求到底该走哪条路该选哪个工具。1. 两类抓包的第一性原理包在哪里产生就在哪里捞1.1 设备端抓包的底层视角手机上的流量从应用进程产生后会经过系统网络栈、无线网卡最后才进入基站或者 Wi-Fi 路由器。设备端抓包就是在“流量还没离开手机”的时候把它截获下来。典型代表是在 Android 上跑 tcpdump把网卡上经过的原始数据包全部保存成 pcap 文件再用 Wireshark 做协议分析。这种路线的最大优势是“全”。不管你走的是 HTTP、HTTPS、DNS、TCP、UDP 还是自定义二进制协议只要网卡上出现过它就能抓到。缺点也很明显普通 App 权限不够tcpdump 必须拿到 root 或者 adb root 权限才能工作而且出来的是最原始的字节流如果流量是 HTTPS 加密的你还得再走一步解密分析单靠 tcpdump 是看不到明文 HTTP 请求内容的。1.2 代理端抓包的转发视角代理端抓包是另一种思路手机上的 Wi-Fi 设置里填一个 HTTP 代理地址把所有 HTTP/HTTPS 请求先发到电脑上的抓包工具工具记录完再帮手机转发到真实服务器。Fiddler、Charles、Burp Suite、Whistle、Reqable 都是这个路线的代表。这种方式抓到的包已经“过了一道手”工具可以解析 HTTP 层的请求行、Header、Body还能做断点修改、重放、mock 响应。对日常接口联调来说这是效率最高的方案。但它有个天然局限只有应用愿意走系统代理你才能抓到如果应用自己不走代理或者用的是 UDP/QUIC 这类不经过 HTTP 代理的协议代理端就无能为力了。1.3 两条路经常要配合用很多新手以为这两条路只能选一个实际工作中它们经常叠着用。比如我用 Charles 抓不到某个 App 的请求怀疑它没走系统代理这时我会先在手机上用 tcpdump 抓一份 pcap 看底层出包情况确认流量确实存在、也确实没走代理再针对性处理。再比如代理工具导出 pcap 或调用 Wireshark 分析也是常见的组合玩法。所以我的建议是别把“装手机上的”和“抓手机的”对立起来它们解决的是不同层面的问题。底层排障用设备端业务联调用代理端两者各管一段组合起来才完整。2. 设备端流派tcpdump、HttpCanary、Reqable、LSPosed 与蓝牙抓包2.1 tcpdump Wireshark最传统的组合Android 上抓原始包绕不开 tcpdump。真机需要 root模拟器相对简单很多模拟器支持 adb root直接就能跑。基本命令是这个样子adb shell tcpdump -i any -s 0 -w /sdcard/capture.pcap-i any表示抓所有网卡-s 0表示抓完整包不要截断-w是写入文件。抓一段时间后 CtrlC 结束再把文件拉出来adb pull /sdcard/capture.pcap然后用 Wireshark 打开可以看到完整的 TCP 会话、DNS 查询、TLS 握手帧。Wireshark 的 Follow TCP Stream 功能可以把某个 TCP 流里的数据拼出来看如果流量是明文 HTTP那直接就能看到请求和响应。这个组合最接近“原教旨主义”抓包缺点是命令行的门槛和 pcap 分析的学习曲线确实劝退了不少人。2.2 App 形态的本地抓包工具HttpCanary 与 Reqable如果你不想在命令行里折腾Android 上有图形化的本地抓包工具老牌的是 HttpCanary。它可以直接装在手机上以抓包器身份接管应用流量界面里能按域名、按协议分组也能看 JSON 请求体。但要注意Android 7.0 之后系统默认不信任用户安装的 CA 证书很多 App 的 HTTPS 流量它解不开需要 root 权限把它的证书装进系统证书区或者配合调试包使用。Reqable 是近几年用得比较多的新工具桌面端和移动端都有。移动端 App 可以不打日志直接抓包也支持通过 root 模式安装证书到系统区省掉不少手工敲命令的步骤。它对 HTTP/1.1、HTTP/2、WebSocket 的支持比较完整界面也更现代。如果你只是想在真机上快速验证一个请求长什么样Requeable 比 tcpdump 友好得多。2.3 LSPosed 与调试 Hook解决“证书校验”的最后一公里设备端路线里还有一个特殊流派通过 Xposed 框架的模块去 hook 目标应用跳过证书校验。LSPosed 是这类框架里目前维护最活跃的一个配合 JustTrustMe 之类的模块能让应用在调试环境下不校验抓包工具的 CA 证书。这样代理工具就能直接解密 HTTPS 请求省去 root 后移动系统证书的麻烦。但这里要强调一个边界这种手段只建议用在自己有权测试的 App 上比如你所在团队的 App、你有授权做安全评估的测试对象。它的价值在于验证 App 的证书校验逻辑是否可靠或者帮开发者在 debug 环境排查问题。不是我自己的 App、没有授权的情况下乱 hook这就是越界行为。2.4 蓝牙抓包容易被忽略的另一类设备流量手机抓包还包括蓝牙流量。Android 开发者选项里有一个“开启蓝牙数据包日志”打开后系统会把蓝牙 HCI 层的数据记录成日志文件路径通常在/sdcard/btsnoop_hci.log。把这个文件拉出来用 Wireshark 按 btsnoop 格式打开就能看到蓝牙配对、广播、GATT 通信的细节。如果要抓 BLE 广播和连接包的协议层数据光靠手机日志不够通常还要配硬件比如 Nordic 的 nRF Sniffer 配合 Wireshark 使用。这一支相对小众你做 TWS 耳机、智能手环、蓝牙外设联调的时候才会用到。如果只是抓 HTTP 接口蓝牙抓包基本用不上知道有这条路就行。3. 代理端流派Fiddler、Charles、Burp、Whistle、Proxyman 的横向对比3.1 代理抓包的工作前提代理端工具再多核心套路都是一样的手机和电脑连同一个局域网手机 Wi-Fi 代理设为电脑的局域网 IP 加工具端口然后工具开始接收并转发请求。区别主要体现在默认端口、HTTPS 解密配置、附加功能断点、mock、脚本、团队协作和跨平台表现上。以三个最常见的工具为例Fiddler 老牌但主要面向 Windows默认监听 8888Charles 在 macOS 生态里口碑很好默认监听 8888Burp Suite 是安全测试标配默认监听 8080。还有 WhistleNode.js 写的规则系统非常灵活适合前端工程师做 mock 和转发。Proxyman 则是 macOS 上体验流畅的后来者。下面这个表格可以帮你快速建立印象工具主要平台默认端口HTTPS 解密核心优势适合人群FiddlerWindows8888支持老牌、插件多、脚本调整方便Windows 开发/测试CharlesmacOS/Windows/Linux8888支持界面直观、断点功能顺手、iOS 生态友好客户端开发和联调Burp Suite跨平台8080支持拦截修改、Repeater、Intruder 等安全测试功能安全测试、渗透评估Whistle跨平台8899支持规则配置灵活、mock/转发能力强前端、Node.js 开发者ProxymanmacOS/iOS自定义支持原生体验好、自动化支持强iOS 开发者ReqableWindows/macOS/Linux/移动端自定义支持API 调试抓包一体、中文友好接口联调、混合场景3.2 Fiddler 与 Charles联调场景里的主力如果你在 Windows 上做 Android 或 H5 的接口联调Fiddler 几乎是必选项。它启动后会自动设置系统代理不需要手填省很多事。抓 HTTPS 前记得打开 HTTPS 解密开关首次会生成根证书然后让手机安装这个证书就行。Fiddler 的断点修改请求、AutoResponder 做本地 mock都是很实用的日常功能。Charles 对 macOS 用户更友好界面干净抓包列表按域名树形展示找请求比 Fiddler 清晰。它对 iOS 真机有一整套引导流程打开 Help - SSL Proxying - Install Charles Root Certificate on a Mobile Device手机上设置代理后访问 chls.pro/ssl 就能下载证书。Charles 的另一个优点是 Breakpoints 功能可以拦截请求前后两端改完再放行联调秒变人肉 mock server。3.3 Burp Suite安全测试视角的选择如果你不是单纯联调而是想看请求能不能被篡改、参数有没有校验、接口有没有越权风险那 Fiddler 和 Charles 都差点意思Burp 才是正解。Burp 的 Proxy 模块不仅能抓包还能在请求发出去之前截住手动改完再转发Repeater 可以直接重放请求Intruder 可以做参数枚举和 fuzz。社区版免费对个人测试学习完全够用。Burp 抓包手机流量时同样需要先让手机信任它的 CA 证书。手机浏览器访问 http://burp 就能下载证书比 Charles 还方便一点。但 Burp 的界面和概念对新手有点重上手曲线比 Fiddler 高所以非安全场景我不太推荐第一天上手就选它。3.4 为什么别把每个工具都装一遍一个坑我踩过电脑上 Fiddler、Charles、Burp 挨个装手机代理换来换去最后抓不到包时根本分不清是哪个工具占用端口、哪个证书没装对。工具之间其实是竞争关系每个都有自己的一套 CA 证书和代理端口混着用很容易出幺蛾子。我的建议是日常联调固定一个主力工具安全测试再切 Burp。比如 Windows 上就 Fiddler 或 Reqable 二选一macOS 上就 Charles 或 Proxyman 二选一。临时需要换工具时先把上一个工具的代理和系统代理设置关干净再开下一个能省掉一半的玄学问题。4. HTTPS 解密的拦路虎证书信任链和 Android 7 的坑4.1 HTTPS 抓包为什么默认是一堆乱码HTTPS 抓包最常见的现象是包能抓到但看到的全是 CONNECT 请求没有具体 URL 和 Body。因为 HTTPS 是先做 TLS 握手再传输加密数据代理工具默认只能看到加密后的内容。要想看到明文必须做“中间人解密”让手机信任抓包工具的根证书工具用这个根证书临时签发一个目标域名的证书给手机同时对服务器保持自己的连接在中间完成解密和转发。这个过程用生活类比就是你打电话给客服实际上中间坐了个翻译他把你的话翻译给客服再把客服的话翻译给你但他要能同时获得双方的信任才能拿到通话内容。这个“信任”就靠安装根证书完成。证书没装、没启用、或 App 不信任翻译就插不进去。4.2 证书安装的四个平台细节Windows 上安装 Fiddler 或 Charles 的根证书比较简单工具导出 cer 证书文件双击后选择“安装证书”放在“受信任的根证书颁发机构”下即可。macOS 则是在钥匙串里双击证书把“信任”选项设为“始终信任”这一步很多人漏掉导致抓包时一直提示证书不受信任。Android 侧明文步骤是设置 - 安全 - 加密与凭据 - 安装证书 - CA 证书选择下载下来的 cer/pem 文件。iOS 侧下载描述文件后先到通用 - 描述文件里安装再到“关于本机”里的证书信任设置中打开完全信任开关。这个开关是 iOS 特有的二次确认非常容易漏漏掉的结果就是明明装了证书HTTPS 还是解不开。4.3 Android 7 用户证书与系统证书的差距这里要说一个最核心的 Android 坑Android 7.0 之后系统将证书分成了“用户证书”和“系统证书”普通 App 默认只信任系统证书不信任用户通过设置安装的证书。也就是说你把抓包工具证书装进了“用户”区Chrome 浏览器能正常解密但大部分 App 依然会报证书错误抓包依旧是 CONNECT 黑盒子。解决办法有三条。第一条是 root 后把用户证书移到系统证书目录需要用 openssl 把 cer 转成系统证书格式命令比较繁琐推荐直接用 Magisk 模块或 Reqable 的 root 模式自动导入。第二条是让开发配合改 App 的 networkSecurityConfig在 debug 构建里允许信任用户证书这是最干净的方式但不适合测试别人家的 App。第三条就是前面提到的用 LSPosed 模块 hook 掉证书校验属于调试兜底手段。4.4 顺手给安全提个醒抓包工具本质上是中间人安装它的根证书等于把自己的信任链交了出去。在自己测试机上折腾没问题但别在公共 Wi-Fi 环境随便给别人发证书也别下载来路不明的证书文件。测试做完我习惯把手机代理关掉、证书删掉电脑上不用的代理工具也退出既保护自己也避免干扰别人联调。5. 特定场景抓包小程序、Flutter、模拟器和流媒体流量5.1 微信小程序抓包的常规路径小程序抓包是热词里出现频率很高的需求。最简单的办法是用微信开发者工具它的 Network 面板可以直接看到小程序的请求详情不需要任何代理配置。但如果要抓真机上的小程序就需要把手机代理指向电脑了。实际操作中微信本身对代理支持还算好但小程序的 request 域名校验严格如果证书没装到系统区HTTPS 依然解不开。一个可靠的做法是先在电脑上把 Charles 或 Burp 的证书装到手机系统证书区再打开小程序这样大部分请求能看到明文。如果还不行优先怀疑是微信内部对某些接口走了独立网络通道或者走了 WebSocket需要到抓包工具的 WebSocket 面板里找。5.2 Flutter/Dio 为什么经常抓不到包Flutter 是另一个高频抓不到包的来源。Dio 底层是 Dart 自带的 HttpClient在 Android 上不一定走系统 Wi-Fi 代理这就导致你明明设置了 Charles 代理Dio 的请求还是像空气一样消失。网上“flutter dio 如何抓包”的帖子多就是因为这个。如果你有项目源码可以在调试阶段用 HttpOverrides 配置代理或者给 Dio 的 HttpClientAdapter 指定代理地址这是最干净的方案。如果只是黑盒测试那就别死磕代理了回到设备端用 tcpdump 抓原始包或者用 Reqable 这类支持透明拦截的工具更省事。5.3 模拟器里的抓包配置模拟器抓包有两种常见方式。一种是把模拟器当成普通 Android 设备在 Wi-Fi 设置里手动修改代理另一种是直接用 adb 命令写全局代理adb shell settings put global http_proxy 192.168.1.10:8888这样即使模拟器界面没有入口也能强制走代理。抓完记得清掉adb shell settings delete global http_proxy模拟器还有一个好处Windows 宿主机上可以用 Wireshark 直接抓虚拟网卡的流量看到模拟器整体的网络行为。加上模拟器通常自带 root系统证书安装比真机容易所以复杂抓包场景我经常先用模拟器复现再上真机验证。5.4 流媒体和视频类 App 的包特征网课、视频类 App 的抓包需求也很多这类流量的特征非常明显拉起播放时主要是 HTTPS 请求里面能解析出 CDN 地址、视频分片格式、防盗链参数等很多工具支持按域名过滤找到媒体文件地址。比如分析 m3u8 列表、ts 分片请求时代理抓包完全可以胜任。但要注意如果视频走了 DRM 保护加密内容在设备端解码代理和 tcpdump 都只能看到加密外壳看不到原始视频数据。这时候不要被“能抓包”三个字误导先判断它是不是 DRM 保护内容再决定是否值得投入时间。5.5 没有 Wi-Fi 时adb reverse 走 USB 通道最后分享一个很实用的技巧手机和电脑不在同一网段或者公司 Wi-Fi 隔离严没法互访时可以先用 USB 线连接手机和电脑再用 adb 反向端口转发adb reverse tcp:8888 tcp:8888然后把手机代理地址设成 127.0.0.1:8888流量就会通过 USB 通道转发到电脑上的抓包工具。这个方法的优点是不依赖局域网稳定性和速度都比 Wi-Fi 好特别适合 USB 直连调试的场景。唯一要注意的是 adb reverse 在部分模拟器和旧版 Android 上支持不完整用之前先确认 adb 版本。6. 抓包失败排查路线从一张白纸到完整链路6.1 先从明文 HTTP 验证链路遇到“抓不到包”我第一步不是检查证书而是先找个明文 HTTP 网站比如随便打开一个 http 开头的页面看代理工具里有没有流量。如果 HTTP 流量都看不到说明代理链路根本没通查证书是浪费时间。这一招能快速把问题范围缩小到“链路问题”和“解密问题”两大类。链路问题常见原因包括手机与电脑不在同一网络、代理 IP 写错、端口没放开、电脑防火墙拦截、代理工具没有正常监听。我踩过最蠢的一次坑是 Charles 换了新电脑后默认监听 127.0.0.1只允许本机访问手机当然连不上。后来在 Proxy Settings 里把监听地址改成局域网地址才解决。6.2 只有 CONNECT 看不到明文证书信任问题如果 HTTP 明文正常HTTPS 只能看到 CONNECT那就是证书信任环节的问题。先确认工具端 HTTPS 解密开关有没有打开再确认手机有没有安装对应的根证书最后确认 iOS 有没有在“证书信任设置”里打开完全信任。按这个顺序排查能解决七成以上问题。剩下三成就要考虑 App 是否信任用户证书。如果你在 Android 7 以上系统测试而且目标 App 是 release 包大概率是这里卡住。最简单的验证方法是用一个普通浏览器打开一个 HTTPS 网站浏览器能解密、App 解密不了那就可以断定不是证书安装问题而是 App 信任策略的问题。我之前帮人排查过一个案例同一个手机Chrome 能抓 HTTPS某银行 App 不行网上搜了很多“证书失效”的方案都没用。后来发现那 App 不仅设置了 SSL Pinning还只信任系统证书。最后是让开发出 debug 包临时信任用户证书才抓到的。所以遇到金融类、支付类、登录类 App 抓不到包优先怀疑 Pinning别折腾证书安装方向了。6.3 系统时间和时钟不同步也会导致抓包失败还有一个冷门坑手机系统时间不准确会导致证书验证时判断“证书已过期”或“尚未生效”。代理抓包工具的根证书一般有效期内但 TLS 校验收的是绝对时间手机时间差了十几分钟就可能失败。我遇到过同事手机时间快了一小时折腾了半下午最后对时就好了。遇到抓包失败时顺手看一眼手机时间尤其是有频繁重启、换电池、长时间关机的设备。这个原因虽然简单但藏在各种复杂问题里不容易想到。6.4 Wireshark / Pyshark 抓不到包时的处理用 Wireshark 抓包时如果发现列表空空如也先看网卡选对没有。抓无线网卡经常选成了虚拟网卡或蓝牙网卡分组列表自然没东西。如果是 Linux 服务器抓包tcpdump 没输出大概率是权限不够前面要加 sudo或者当前用户不在 wireshark 用户组里。Pyshark 抓不到包也属于同类问题它在底层调用 tshark/dumpcap需要管理员权限启动网卡捕获或者要确保 Wireshark 安装时勾选了命令行工具组件。很多人装了 Wireshark但没勾选“附加工具”Pyshark 就找不到 tshark报错说命令不存在。重新安装时补上这个组件就能解决。7. 没有万能工具只有合适分工我的选型经验7.1 按角色选工具而不是按工具逆推场景如果你做移动端业务开发主力建议是 Reqable 或 Fiddler。Reqable 桌面端和移动端打通接口联调、mock、导出文档都有界面现代Fiddler 在 Windows 上生态成熟网上教程多报错搜起来容易。如果你是 iOS 开发者Proxyman 或 Charles 用起来更顺对 iOS 的证书引导、断点调试都做了优化。如果你做安全测试或接口权限验证那必须上 Burp Suite。Burp 的拦截后修改、重放、fuzz 能力是普通抓包工具比不了的。但千万别拿 Burp 做日常 H5 静态调试它的界面和操作逻辑并不适合快速查看请求效率和 Fiddler 差不少。7.2 按流量类型选路线而不是按习惯选路线工具选完了还有一个更底层的判断这个流量到底走不走系统代理。普通 HTTP/HTTPS 请求、WebSocket走代理没问题DNS 查询、UDP 游戏包、QUIC/HTTP3、部分 Flutter 请求代理设备经常看不到。这时候别硬刚代理切换到 tcpdump Wireshark 看原始包反而能更快定位。我个人的实践习惯是先花两分钟判断目标流量的大致协议特征。App 是原生网络库还是 Flutter是普通业务接口还是音视频流是局域网通信还是公网请求判断完之后选路线基本不会走弯路。7.3 两条路我都日常维护但从来不让它们打架最后分享一个工作流经验电脑上我只会保留一个代理抓包工具长期运行其他工具按需临时启动。手机和电脑的端口、代理地址我会固定下来比如代理端口固定用 9999避免每次重新填。tcpdump 的命令也会存成一段脚本需要时直接改文件名就能跑。这个项目做到后面最深的体会是抓包工具本身不难学难的是理解流量路径和信任链。把“流量从哪来、往哪去、谁解密、谁信任”这四件事想明白无论工具怎么换代你都能第一时间找到正确的抓法。遇到抓不到的包别急着换工具先问自己一句这条路真的对得上这个场景吗