日常做开发的人，特别是和客户端接口打交道的同学，应该对“抓包”这件事不陌生。
调试登录流程、分析接口格式、排查错误返回、分析网络性能、甚至研究第三方 App 的数据通信……说到底，都绕不开“抓 HTTPS 包”这一步。
而这一步，正变得越来越难。
抓包为什么越来越难？
早几年，抓包是一件相对轻松的事。安装个 Charles、Fiddler，或者开个 mitmproxy，设好代理、装下证书就能抓个痛快。
但现在，各种防护机制一层套一层：
- App 开启了证书校验，连不上代理就拒绝联网
- 有些还上了 HTTPS 双向验证（Mutual TLS），客户端必须验证服务端证书外还要给服务器提供自己的一套证书
- 少数 App 甚至硬编码了 Pinning，不信任系统证书
Charles、Fiddler、mitmproxy 全部失灵。
于是我找遍了几乎能找到的所有工具。
工具盘点：每种都有一类适配人群
1. Charles
经典老牌，不多介绍。HTTP 抓得稳，HTTPS 要绕 Pin 就麻烦了。对 mac 用户友好，对 iOS 支持一般，证书注入限制多。
2. Fiddler
Windows 上用得多，功能强，但配置复杂。要设置代理、安装证书，有时连抓安卓包都觉得麻烦。
3. Wireshark
底层抓包利器，但不解密 HTTPS 意义不大。更多用在网络层调试，做协议分析不错。
4. mitmproxy
命令行党福音，Python 可编程。但对于图形化用户门槛高，部署中间人代理还是会遇到 Pin 限制。
5. Sniffmaster 抓包大师（一个偶然发现的小众工具）
某次调试一个 iOS 上的企业应用，客户反馈某个操作频繁失败，服务端日志里没有任何记录。
我一边抓 Charles，一边开 Fiddler，发现都抓不到这个 App 的 HTTPS 请求。
最后在一个讨论组里看到有人提到 Sniffmaster 这个跨平台的小工具，说插上线就能抓，没多想就试了下。
结果让我很惊讶：
- 插上 iPhone 设备，几秒内在软件界面看到所有请求
- 请求完整无缺，而且已经自动解密
- 双向 HTTPS 的请求也能看到内容
翻了下工具介绍，Sniffmaster 居然支持脚本编写，可以实时修改请求响应内容，有点像 mitmproxy + Charles 的结合。
实战体验：调试带 Pin 的 iOS HTTPS 接口
说个具体例子，我调试的是一个医疗 App，它对安全性要求极高：
- 强制 HTTPS，所有 HTTP 请求会直接被中间件拒绝
- 接口全量启用双向认证
- APP 内置了 SSL Pinning，如果不是特定证书链直接断联
传统代理全废。
而 Sniffmaster，因为是用设备连接的方式，绕过了系统信任链，可以无视 Pinning 行为直接拦截 TCP 流。
打开“拦截器”，我写了一段 JavaScript 修改接口返回数据，秒变测试环境状态。
同时它还能用来分析网络性能，显示请求链路耗时、TLS 握手时长、请求体大小等，UI 简单但很实用。
抓包工具没必要“一刀切”
每款工具都有其适配人群和场景：
- Charles、Fiddler 更适合日常 Web 调试
- mitmproxy 拿来写自动脚本抓分析包很合适
- Wireshark 用来排查底层 TCP 问题很专业
但像 iOS HTTPS + 双向认证这种“毒瘤场景”，只能靠专门的工具处理。
我不想说哪款工具一定最好，但 Sniffmaster 抓包大师确实在我最无助时解决了问题。
也许，有时候解决问题的关键不是“全能”，而是“刚刚好”。
如果你也在调试 iOS HTTPS 接口时卡住了，不妨多试试不同的方式。
不是每个工具都能解决所有问题，但合适的工具 + 合理的方式，可以让你少熬很多夜。
