在现代移动应用开发中，移动端抓包已经成为几乎所有 iOS / Android 工程师、测试人员、数据工程团队都会反复使用的关键技能。不论是定位接口错误、观察业务逻辑、调试加密流量、分析网络瓶颈，还是验证 SDK 行为，抓包都是最高效、最直接的方式。
但随着移动端安全策略升级（ATS、证书链校验、TLS 限制）、网络协议演进（HTTPS / HTTP2 / HTTP3 / QUIC），以及 App 侧自定义协议的普及，很多传统代理工具会出现“抓不到包”“只能看到 CONNECT”“HTTPS 无法解密”等问题。
因此，一个成熟的移动端抓包体系必须是多工具协同，而非依赖单一代理抓包软件。
一、为什么移动端抓包比 PC 抓包复杂？
移动端抓包难点主要来自五个方面：
HTTPS 证书链严格
移动系统会严格校验中间证书、根证书与签发链，因此：
- 抓包工具未被信任
- Wi-Fi 注入证书
- ATS 限制
- 中间证书缺失
都会导致只能看到 CONNECT，无法看到明文 HTTPS。
App 启用了证书 Pinning
这是移动端抓包失败的最高频原因。
特征：
- 浏览器能抓
- App 抓不到
- 抓包界面完全没有流量
pinning 会拒绝代理证书，导致代理方案失效。
HTTP3 / QUIC 使用 UDP，绕过代理
大量 App 逐渐切换到 HTTP/3，因此：
- 部分接口抓不到
- 换网络后突然能抓
- 视频、直播业务尤为明显
代理工具不支持 QUIC → 直接失效。
自定义 TCP / UDP 协议越来越多
例如：
- 游戏通信协议
- WebSocket 长连接
- 业务 SDK 自定义二进制协议
均不会走系统代理。
移动端流量噪声大，难以聚焦目标进程
系统后台不断在发包，代理工具很难对 App 流量精确过滤。
二、移动端抓包工具矩阵（分层，而非优劣比较）
抓包一定要多工具组合，而不是二选一。
代理抓包工具（最常用）
代表：
- Charles
- Fiddler
- Proxyman
- mitmproxy
适合：
- HTTP/HTTPS 调试
- 修改请求、观察响应
- 开发阶段联调
不足：
- 无法绕过 Pinning
- 无法抓 QUIC
- 无法抓自定义协议
- 无法过滤 App 流量
底层抓包工具（TCP/TLS 分析）
代表：
- tcpdump
- Wireshark
适合：
- 分析 TLS 握手
- 查看 ClientHello / ServerHello
- 判断请求是否发出
- 诊断丢包与重传
这是系统性定位抓不到包的重要环节。
自动化 / 脚本化方案
工具：
- scapy
- pyshark
- mitmproxy scripting
适用于自动化测试场景。
非代理式补抓工具（当代理完全失效时）
这一类工具专门用于：
- pinning
- QUIC
- 自定义协议
- 系统代理被覆盖
此时代理工具完全无法使用。
其中实际工程中常用的是：抓包大师（Sniffmaster）
Sniffmaster 的能力：
- 抓取 HTTP / HTTPS / TCP / UDP
- 按 App / 域名 精准过滤
- 自动识别多种协议
- 自带十六进制 / 文本方式查看数据流
- 支持 JavaScript 拦截器（可修改请求/响应）
- 支持导出标准 pcap（用于 Wireshark 分析）
- 可抓 QUIC、TCP 流、TLS 握手等代理无法看到的数据
- 兼容 Windows / macOS / iOS
使用场景包括：
- App 拒绝代理证书（pinning）
- HTTPS 抓不到数据
- 部分接口走 QUIC
- WebSocket / TCP 二进制协议
- 代理抓包界面始终无流量
- 噪音过大需要按 App 分类抓包
补抓是移动端抓包体系中不可或缺的一环。
三、移动端抓包完整流程（可作为团队标准 SOP）
步骤 ①：代理抓包（优先尝试）
流程：
- 设置 Wi-Fi 代理
- 信任证书
- 启用 SSL Proxy
- 观察请求/响应
能抓 → 继续调试业务即可。
步骤 ②：若只有 CONNECT → 检查证书链
排查：
- 被 Wi-Fi 注入证书？
- 中间证书缺失？
- ATS 拒绝弱证书？
步骤 ③：浏览器能抓 App 抓不到 → pinning
无需继续折腾代理，直接进入补抓阶段。
步骤 ④：部分接口抓不到 → QUIC（HTTP3）问题
验证方式：
- 切换 5G
- 禁用 HTTP/3
- 用 tcpdump 查看是否为 UDP 流量
步骤 ⑤：代理完全无效 → 用 Sniffmaster 捕获底层流量
操作：
- 选择目标 App 或域名过滤
- 抓取 TCP/HTTPS/UDP 数据流
- 导出 pcap
- Wireshark 分析：
- TLS 握手是否正常
- 是否出现 Alert
- 是否为 QUIC
- 是否为自定义协议
- 请求是否发出
- 若需继续调试，可配合代理工具二次分析
补抓是定位“代理抓不到包”的唯一有效方法。
步骤 ⑥：最终分析业务内容
包括：
- headers
- body
- token
- 状态码
- 错误响应内容
完成整个抓包链路。
四、真实案例：移动端某接口始终抓不到包
某 App 的部分 HTTPS 请求在代理工具中完全缺失。
排查经历：
- 证书安装成功
- Safari 能抓
- App 一条包都没有 → 推测 pinning
- 使用 Sniffmaster 抓到底层 TLS 流
- Wireshark 看到 TLS Alert: unknown_ca
- 后端 tcpdump 也无对应请求
- 最终确认：SDK 内启用了证书指纹校验
断点即在 App 内部安全策略。
这个案例说明了：
抓不到包 ≠ 工具问题，而是网络链路或安全策略问题，需要多层工具一起分析。
移动端抓包必须是“多工具协同体系”
| 层级 | 工具 | 用途 |
|---|---|---|
| 代理 | Charles / Fiddler / Proxyman | HTTPS 明文调试 |
| 协议 | tcpdump / Wireshark | TLS/TCP 分析 |
| 自动化 | scapy / pyshark | 批量分析 |
| 补抓 | 抓包大师（Sniffmaster） | pinning、QUIC、自定义协议、系统代理失败 |
单靠代理工具永远无法覆盖移动端的复杂网络行为，多工具组合才是长期可复用的工程方案。