在移动开发和测试中，抓包几乎是必备技能。HTTP 协议（默认端口 80）下的抓包相对简单，数据是明文传输，代理工具即可直接查看。但随着 HTTPS（默认端口 443） 的普及，抓包难度显著增加，开发者常常遇到“只能看到 CONNECT 请求”的情况。
本文将从 HTTPS 的端口特性 入手，分析 iOS 抓包的难点，并介绍应对这些问题的常见工具和实践方案。
一、HTTPS 端口与抓包难点
- 默认端口 443
- HTTPS 通信几乎都通过 443 端口完成。
- 在应用层之上，增加了 TLS 加密，通信内容不可直接读取。
- 需要证书解密
- 代理工具必须生成自签证书，安装在设备上，并在 iOS 的“证书信任设置”里手动启用信任。
- 否则，即便抓取到 443 端口流量，也无法解密。
- SSL Pinning 与双向认证
- 许多 App 会校验证书指纹或要求双向 SSL 握手。
- 一旦启用 Pinning，中间人代理证书会被拒绝，导致握手失败。
- 流量混杂问题
- iOS 系统会在后台产生大量 HTTPS 请求（iCloud、系统更新、广告服务等）。
- 开发者调试时容易被噪声流量淹没。
二、常见抓包工具对比
1. Charles
- 优点：跨平台，界面直观，支持 HTTPS 解密和规则过滤。
- 缺点：需要 Wi-Fi 代理配置；无法绕过 SSL Pinning。
- 适用场景：日常接口调试。
2. Fiddler
- 优点：Windows 用户常用，支持流量拦截与修改。
- 缺点：默认不解密 HTTPS；在 iOS 场景下配置繁琐。
- 适用场景：Web 服务或 PC 应用调试。
3. Sniffmaster（抓包大师）
- 优点：
- USB 直连 iOS 设备，无需 Wi-Fi 代理。
- 自动解密 HTTPS，可绕过 SSL Pinning 与双向认证。
- 支持仅抓取指定 App，避免噪声流量。
- 拦截器支持 JavaScript 修改请求/响应。
- 可导出 PCAP 文件，结合 Wireshark 深度分析。
- 缺点：需要额外安装客户端。
- 适用场景：高安全 App 调试、安全研究。
4. Proxyman
- 优点：macOS 原生应用，UI 现代化，体验优于 Charles。
- 缺点：功能与 Charles 高度重叠；受 Pinning 限制。
- 适用场景：Mac 用户的日常调试。
5. Wireshark
- 优点：底层协议分析神器，能捕获 TCP/UDP/TLS 握手数据。
- 缺点：无法直接解密 HTTPS；对新手不友好。
- 适用场景：分析握手失败、丢包、网络延迟等问题。
6. mitmproxy
- 优点：命令行工具，可通过 Python 脚本实现自动化和异常模拟。
- 缺点：无 GUI，学习曲线较高；同样无法解决 Pinning。
- 适用场景：测试工程师构造异常请求、自动化回归。
三、实战应对策略
- 普通 HTTPS 调试（443 端口）
- 首选 Charles 或 Fiddler。
- 确认证书安装并信任，开启 HTTPS 解密。
- 测试异常场景
- 使用 mitmproxy，通过 Python 脚本模拟延迟、丢包、错误码返回。
- 适合测试人员在 CI/CD 环境中验证接口稳定性。
- 协议层排查
- 当应用频繁超时或握手失败时，用 Wireshark 分析 443 端口流量。
- 配合 Sniffmaster 导出的 PCAP 文件，可以完整还原 TLS 握手过程。
- 应对 SSL Pinning 或双向认证
- 此类场景下，Charles/Fiddler/mitmproxy 全部失效。
- 需要 Sniffmaster 直连 iOS，才能获取真实 HTTPS 数据。
四、工具选择总结
| 调试场景 | 推荐工具组合 |
|---|---|
| 常规 HTTPS 抓包（443 端口） | Charles / Fiddler |
| 自动化测试、异常模拟 | mitmproxy + Python 脚本 |
| 协议分析（握手失败、延迟排查） | Wireshark + Sniffmaster |
| 高安全应用（Pinning、双向认证） | Sniffmaster（USB 直连解密） |
| Mac 用户优化体验 | Proxyman |
- HTTPS 端口（443）是抓包的核心入口：一旦证书或代理配置错误，流量无法解密。
- SSL Pinning 是最难点：传统代理几乎无能为力。
- 不同角色的工具组合不同：
- 开发者偏向 Charles/Fiddler；
- 测试工程师偏向 mitmproxy；
- 安全工程师依赖 Sniffmaster + Wireshark。
- 最终结论：没有万能工具，只有合理组合。