iOS 抓包痛点始终存在：问题不是"抓不抓"，而是"怎么抓"
很多开发者都遇到过这样的情况：
- "接口没有返回，连日志都没打出来"
- "模拟器正常，真机无法请求"
- "加了 HTTPS 双向认证，抓不到了"
- "明明设置了 Charles，还是看不到请求"
问题不是工具不行，而是用错了工具或工具搭配方式。iOS 抓包从来都不是单点操作，而是链路策略组合行为。
本文围绕抓包流程的几个关键点，逐个拆解每类工具的适合场景。
抓包流程中的关键问题节点
我们将 iOS 抓包过程拆成五个阶段：
| 步骤 | 目的 | 工具推荐思路 |
|---|---|---|
| ① | 请求是否真的发出了？ | Sniffmaster / Wireshark |
| ② | 请求是否经过了 TLS 握手？ | Wireshark / Sniffmaster |
| ③ | 内容是否加密/解密成功？ | Charles / mitmproxy / Sniffmaster |
| ④ | 请求参数是否正确？ | Charles / Proxyman / mitmproxy |
| ⑤ | 服务端响应行为是否异常？ | mitmproxy / Burp Suite |
工具一览与实际角色定位
1. Charles
- 角色： 请求内容确认器
- 强项： GUI 界面，易读易改
- 使用限制： 遇 Pinning 接口抓不到
- 适用： 快速验证参数、Header、接口路径是否符合预期
2. Sniffmaster
- 角色： 真机真实流量"解码器"
- 强项： 无需越狱、支持绕过 Pin、解密 HTTPS、App 粒度抓包
- 使用限制： 初次使用需掌握连接机制
- 适用： iOS 真机调试、生产 App 行为复现、安全环境调试
3. mitmproxy
- 角色： 条件控制型"中间人"
- 强项： 支持脚本构造场景、模拟请求超时/失败
- 使用限制： 不适合 GUI 党，命令行门槛高
- 适用： API 测试、Token 流失模拟、异常路径验证
4. Wireshark
- 角色： 传输链路还原器
- 强项： 可分析 DNS、TLS、TCP 重传等网络底层状态
- 使用限制： 无法直接解析 HTTPS 明文
- 适用： 排查握手失败、丢包、连接断开等网络异常
5. Proxyman
- 角色： Charles 的"mac 原生优化版"
- 强项： 操作体验流畅、证书配置引导清晰
- 使用限制： 同样无法应对认证加固应用
- 适用： 需要长期调试或 GUI 交互体验更佳者
6. Burp Suite
- 角色： 安全逻辑测试工具
- 强项： 中间人攻击模拟、身份伪造、请求变形
- 使用限制： 学习成本高，非开发者易出错
- 适用： 安全测试、红队演练、权限边界测试
推荐组合搭配策略（实用指导）
| 场景 | 工具组合建议 |
|---|---|
| 抓不到 HTTPS 请求 | Sniffmaster + Wireshark |
| 请求能抓到但内容是乱码 | Charles + 检查证书是否信任 |
| App 无响应 / 服务器无日志 | Sniffmaster + mitmproxy |
| 双向认证接口需要验证过程 | Sniffmaster + Postman |
| 模拟 403 / Token 过期请求 | mitmproxy + 脚本模拟失败响应 |
| 网络断连 / TLS 握手失败 | Wireshark + 抓握手过程 + 错误分析 |
总结：选择工具的三个核心标准
- 你想抓哪一层？
- App 行为：Sniffmaster
- 接口结构：Charles / Proxyman
- 网络异常：Wireshark
- 你能接受多复杂的流程？
- 快速抓包：Charles / Sniffmaster
- 深度构造场景：mitmproxy / Burp Suite
- 你是否面临 HTTPS Pin 或双向认证？
- 是：只有 Sniffmaster 提供非入侵解决路径
- 否：代理工具足矣