到了 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”
  • 只勾选目标应用
  • 再触发网络行为

这样可以直接把注意力集中在业务请求上,而不是在成百上千条系统日志中查找目标接口。
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