很多人第一次遇到带 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 暴力抓包：获取真实请求
- 数据流抓包：确认连接行为
- 代理抓包（必要时）：验证哪些请求仍走系统代理
每个工具都解决一部分问题，而不是期待某一个工具解决所有问题