很多人第一次遇到带 PIN（证书绑定）或双向 TLS 验证的 App 时，都会卡在一个阶段，
代理证书装好了，Wi-Fi 代理也生效了，但请求就是消失了。

这并不是配置问题，而是网络路径已经发生了变化。

为什么 PIN + 双向验证会直接掐断代理抓包

在普通 HTTPS 代理抓包里，抓包工具本质上扮演的是 中间人 。
客户端信任系统证书 → 代理证书被接受 → TLS 能正常建立。

但一旦 App 做了下面任意一件事：

• 在代码里固定服务端证书或公钥
• 校验客户端证书（mTLS）
• 对证书链做额外校验

系统信任链这条路就不再成立。
这也是为什么 Charles、Fiddler 这类工具，在这些 App 上会直接变成什么都没有。

我一般不会一开始就纠结怎么绕过

在真实项目环境里，我很少一上来就研究 PIN 怎么绕。
我更关心的是： 有没有别的抓包方式，能先让我看到真实请求。

从代理切换到 HTTPS 暴力抓包，是一个明显的分水岭

在这类场景下，我会直接使用抓包大师的 HTTPS 暴力抓包 模式，而不是继续在代理模式上消耗时间。

这个模式有几个关键差异点：

• 不依赖系统代理
• 不需要在 iOS 上安装或信任证书
• 请求在更靠近 App 的位置被接管

这意味着，即使 App 开启了 PIN 或双向验证，也不会在 TLS 阶段把你挡在门外。

我实际操作时的完整准备流程

这里不是理论可行，而是我实际会照着走的一套流程。

设备准备阶段

• 用 USB 将 iPhone 连接到电脑，确保解锁、亮屏
• 第一次连接时，在手机上点“信任此电脑”
• Windows 下按提示安装 iOS 驱动，完成后重启抓包大师
• 按提示在手机上安装描述文件
• 如果是 iOS 17.4 及以后系统，按提示开启开发者模式

这些步骤看起来琐碎，但任何一步没完成，后面的暴力抓包都起不来。

进入 HTTPS 暴力抓包时，我会先观察一个状态

在设备列表中选中 iOS 设备后，我不会立刻点功能按钮，而是先看左下角：

• “高级管理服务”是否已经变成绿色
• 如果没有，手动点击启动，并确认系统权限提示是否弹出

这个状态没起来，暴力抓包界面再怎么点都只是空操作。

真正开始抓的时候，我会先限制范围

进入 HTTPS 暴力抓包模式后，我第一件事不是点“开始”，而是：

• 打开「选择 App」，只勾选目标应用
• 设置基本过滤条件，避免背景流量干扰

这样做的好处很直接：
当 App 发起请求时，你能清楚看到哪一条是它产生的，而不是被系统流量淹没。

能抓到 ≠ 什么都能看，这是很多人容易误解的地方

即便在暴力抓包模式下，也存在一个前提条件： App 是否使用 iOS 开发证书签名。

在我的实际经验中，常见情况是：

• 自签或重签 App：请求体、响应体都能看到
• App Store 原包或系统 App：只能看到 URL 和 Header

这不是工具限制，而是 iOS 的安全模型本身决定的。

当我只能看到 Header 时，仍然有价值的几件事

即便 body 不可见，我仍然会做几件判断：

• 请求是否命中预期域名
• Header 中是否携带特定标识
• TLS 建连是否成功、是否频繁重试

这些信息足以判断 App 是否在按预期工作，尤其在调试网络异常时非常有用。

如果确实需要完整内容，我会怎么处理

在需要完整请求体的情况下，我通常会：

• 获取目标 App 的 IPA
• 使用 iOS 开发证书重新签名
• 确保使用的是已脱壳版本

完成后，再通过 HTTPS 暴力抓包重新抓取。
这一步成本不低，但它是唯一稳定可控的路径。

在 PIN 和双向验证场景下，我常用的组合是：

• 抓包大师 HTTPS 暴力抓包：获取真实请求
• 数据流抓包：确认连接行为
• 代理抓包（必要时）：验证哪些请求仍走系统代理

每个工具都解决一部分问题，而不是期待某一个工具解决所有问题