到了 2026 年，抓包已经不只是配个代理、装个证书这么简单。
应用的网络形态变得更复杂，系统服务、跨平台框架、SDK 内嵌网络栈、证书绑定、双向 TLS，这些都会直接影响抓包
在这种背景下，选择抓包工具之前，更重要的是现在要抓的，到底是 App 里发出的请求，还是设备和网络之间更底层的通信？
代理型抓包工具，仍然是第一点，但不是只有这一点
Charles / Fiddler：验证网络是否经过系统代理
在调试一个新项目时，我仍然会先打开代理型工具。
做的事情很具体：
- 启动 Charles 或 Fiddler
- 配置手机或模拟器的 Wi-Fi 代理
- 安装并信任 HTTPS 证书
- 触发应用网络请求
这一阶段并不是为了“完整抓包”，而是确认：
- 请求是否走系统网络
- 是否被代理层感知
如果请求能显示在工具中，说明网络路径是开放的；如果完全没有数据，说明问题不在代理配置本身。
当代理工具失效时，问题可能发生在更低层
在下面这些场景中，代理工具会直接失效：
- App 内部启用了 SSL Pinning
- 使用自定义 TLS 或第三方 SDK
- Flutter / Unity / React Native 内嵌网络实现
- iOS App 来自 App Store，证书不可控
此时反复检查证书信任状态，并不会改变结果，需要切换抓包思路。
直接在手机上抓包，绕过代理路径的直接方案
抓包大师（Sniff Master）：从设备层获取 HTTPS 数据
在 iOS 场景下，如果目标是看到真实的请求体和响应内容，我会直接在手机上抓包。
使用抓包大师时，操作路径非常明确：
- 通过 USB 连接 iPhone
- 确认设备已解锁并信任电脑
- 启动抓包大师，选择对应设备
- 进入 HTTPS 暴力抓包功能
整个过程不需要配置 Wi-Fi 代理，也不需要在手机上手动安装证书。
选择 App，避免系统流量干扰
在设备级抓包中，系统服务会产生大量请求。
抓包大师提供了 App 级筛选：
- 在抓包界面点击“选择 App”
- 只勾选目标应用
- 再触发网络行为
这样可以直接把注意力集中在业务请求上，而不是在成百上千条系统日志中查找目标接口。
抓到数据却看不到 Body？这是证书签名问题
2026 年依然存在一个现实问题：
- App Store 下载的 App 默认加密
- 未使用开发证书签名
在这种情况下，即使使用设备级抓包，也只能看到：
- 请求 URL
- 请求 Header
而请求体和响应体是空的。
解决方式并不复杂，但需要多一步操作：
- 获取目标 App 的 IPA
- 使用 iOS 开发证书重新签名
- 安装重签后的 App
- 重新启动抓包
完成后，HTTPS 数据即可完整解析。
结合拦截器工具，验证接口行为
在抓到数据之后，很多调试并不是“看请求”，而是验证行为。
抓包大师的拦截器使用场景
在 HTTPS 代理抓包界面中打开拦截器：
- 设置需要拦截的 URL 规则
- 在请求阶段修改参数
- 或在响应阶段替换返回内容
例如：
- 人为修改返回状态码，观察 App 错误处理逻辑
- 替换接口返回数据，验证 UI 是否存在依赖假设
这种验证方式比日志打印更直接，也更接近真实异常场景。
跨平台项目中的抓包工具组合
在 2026 年的实际项目中，很少只用一个工具：
- 代理工具用于确认网络路径
- 手机抓包工具用于获取真实数据
- 拦截器用于验证业务分支
工具之间是协作关系，而不是替代关系。
参考链接：https://www.sniffmaster.net/tutorial/zh/2/2.html