如果你做过APP调试或SDK集成测试，可能会有这种经历：
- 明明配置好了代理和证书，还是抓不到真机请求；
- 模拟器测试一切正常，一上真机请求就"消失"；
- Fiddler/Charles 连接正常，但没有任何HTTPS流量；
- 封装SDK网络行为根本无法验证；
这些"抓不到包"的时刻，是移动端调试中最让人崩溃的场景之一。尤其是涉及 HTTPS 请求、双向认证、APP安全策略，常规工具很容易失效。
本文不打算介绍"怎么用抓包工具"，而是深入探讨：
- 为什么真机HTTPS抓包越来越难？
- 哪些抓包原理注定会"失灵"？
- 如何用 Sniffmaster + 多工具组合，解决无法抓包的根本问题？
抓不到HTTPS，是技术趋势决定的
在过去几年，为了用户数据安全，大部分主流服务端和SDK提供商都采用了以下安全策略：
强制 HTTPS 传输
- 明文HTTP全面淘汰；
- 全站开启TLS加密；
- APP与服务端所有通信必须加密；
HTTPS Pinning（双向证书验证）
- 客户端内置证书公钥指纹；
- 中间人证书一律拒绝握手；
- 防止伪装服务器劫持数据；
请求封装隐藏
- 统一封装如 OkHttp/NSURLSession；
- 使用 Native 模块/自研网络组件；
- 请求代码无法通过日志输出查看；
限制代理或系统抓包机制
- 禁用系统代理；
- 检测抓包行为（如检测Charles/Fiddler）；
- 使用 QUIC/TCP/Socket 自建链路规避 HTTP 协议；
我们团队遇到的抓包失败场景
- 微信授权SDK请求日志为空，抓不到流；
- iOS 真机连接 Charles，HTTPS 全部 handshake failed；
- 安卓真机设置代理但无请求流出现；
- Fiddler 抓到部分请求，但封装SDK请求全空；
- mitmproxy 成功劫持，但SDK检测证书返回错误码；
为什么传统工具在真机场景里抓不到？
| 工具 | 原理 | 弱点 |
|---|---|---|
| Fiddler | 基于HTTP代理 | 必须走系统代理，不能处理Pinning |
| Charles | 类似Fiddler | 证书信任链被Pin校验拒绝 |
| mitmproxy | 脚本级代理 | 证书替换容易被检测 |
| Proxyman | UI好、原理同Charles | 不能突破封装和双向认证限制 |
| Wireshark | 底层抓包 | 能看见流量但看不懂HTTPS内容 |
它们共同的软肋是：基于代理、依赖证书注入、需要中间人劫持机制。而在 Pinning 和封装SDK面前，它们"无能为力"。
Sniffmaster 是怎么解决的？
插线真机，无需设置代理
只需将 iOS 或 Android 真机连接电脑，Sniffmaster 会直接从USB口监听网络接口。
不需要安装任何证书
绕过了系统信任链，天然不被Pin机制阻断。
支持识别封装请求
能看到App发出的所有TCP/HTTPS/UDP数据流，哪怕SDK自己建了Socket连接也能抓到。
支持爆破双向Pin验证
这是很多其他抓包工具完全做不到的一点，Sniffmaster 可以解密双向验证下的HTTPS流量。
我们现在如何组合工具调试网络问题？
| 场景 | 工具组合 | 使用说明 |
|---|---|---|
| 模拟器调试 | Charles + Postman | 基础开发阶段调试 |
| 接口容错验证 | mitmproxy + Postman | 脚本模拟错误、字段缺失 |
| 真机SDK调试 | Sniffmaster + Wireshark | 真实抓包 + 协议解密 |
| 构建包验证 | Sniffmaster + Charles | 验证上线包参数一致性 |
| 网络层失败 | Wireshark + curl | DNS、TCP握手排查 |
总结：要想抓得准，得用对工具
抓不到包，并不是"你操作失误"，也不是"设备有问题"，而是你面临的技术环境已经变化。
Charles/Fiddler 依然好用，但更多是针对传统Web服务或开发初期模拟器场景。
而在现实工作中，你需要能在以下条件下工作的工具：
- 真机；
- HTTPS 加密；
- 无Root越狱；
- 不修改APP代码；
- 不依赖系统代理；
- 能筛选具体APP抓包；