在移动开发和测试中，抓包几乎是必备技能。HTTP 协议（默认端口 80）下的抓包相对简单，数据是明文传输，代理工具即可直接查看。但随着 HTTPS（默认端口 443） 的普及，抓包难度显著增加，开发者常常遇到“只能看到 CONNECT 请求”的情况。

本文将从 HTTPS 的端口特性 入手，分析 iOS 抓包的难点，并介绍应对这些问题的常见工具和实践方案。

一、HTTPS 端口与抓包难点

1. 默认端口 443
   • HTTPS 通信几乎都通过 443 端口完成。
   • 在应用层之上，增加了 TLS 加密，通信内容不可直接读取。
2. 需要证书解密
   • 代理工具必须生成自签证书，安装在设备上，并在 iOS 的“证书信任设置”里手动启用信任。
   • 否则，即便抓取到 443 端口流量，也无法解密。
3. SSL Pinning 与双向认证
   • 许多 App 会校验证书指纹或要求双向 SSL 握手。
   • 一旦启用 Pinning，中间人代理证书会被拒绝，导致握手失败。
4. 流量混杂问题
   • 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。
• 适用场景：测试工程师构造异常请求、自动化回归。

三、实战应对策略

1. 普通 HTTPS 调试（443 端口）
   • 首选 Charles 或 Fiddler。
   • 确认证书安装并信任，开启 HTTPS 解密。
2. 测试异常场景
   • 使用 mitmproxy，通过 Python 脚本模拟延迟、丢包、错误码返回。
   • 适合测试人员在 CI/CD 环境中验证接口稳定性。
3. 协议层排查
   • 当应用频繁超时或握手失败时，用 Wireshark 分析 443 端口流量。
   • 配合 Sniffmaster 导出的 PCAP 文件，可以完整还原 TLS 握手过程。
4. 应对 SSL Pinning 或双向认证
   • 此类场景下，Charles/Fiddler/mitmproxy 全部失效。
   • 需要 Sniffmaster 直连 iOS，才能获取真实 HTTPS 数据。

四、工具选择总结

• HTTPS 端口（443）是抓包的核心入口：一旦证书或代理配置错误，流量无法解密。
• SSL Pinning 是最难点：传统代理几乎无能为力。
• 不同角色的工具组合不同：
  • 开发者偏向 Charles/Fiddler；
  • 测试工程师偏向 mitmproxy；
  • 安全工程师依赖 Sniffmaster + Wireshark。
• 最终结论：没有万能工具，只有合理组合。