前两周接了个 App 对接的活，代理一开，对方 App 直接连不上网------典型的证书绑定（SSL Pinning）。折腾下来把 Android 证书绑定抓包的路数理清了：它跟普通 HTTPS 抓包的关键区别在"不换证书"，下面按步骤过一遍。
大概率是这几种情况之一：
- 代理抓包时 App 直接断网，请求全失败
- 证书装好了，App 的请求还是密文
- 拿到明文还不够，要改包重放
先讲原理：证书绑定是 App 在代码里固定了服务端的证书或公钥，请求时自己校验，不信任系统证书链。代理抓包靠替换证书解密，一换就被 App 认出来------所以表现是"装了证书也解不开"或"一开代理就断网"。解法都绕开"换证书"这个动作。
绑定的实现有两种：固定证书本身，或固定公钥。固定公钥的更麻烦------证书换不换它不关心，只认公钥指纹，代理哪怕装上证书也过不了校验。Android 上常见的绑定框架和原生加密组件都在覆盖范围内，后面第四步的去 Pin 正是针对它们。
第一步：识别是不是证书绑定
判断方法看两个现象：一是代理开启后 App 请求全部失败或一直转圈；二是系统证书装好后，这个 App 的流量依然是密文或直接报错。两个现象同时出现，基本可以断定做了证书绑定。验证方式：换一个没做绑定的 App 抓包，流量正常，对比之下问题就定位在这个 App 上。
容易误判的情况：证书根本没装对也表现相似。区分方法：先确认系统里代理证书已装好、信任已开启，再做上面两个现象的判断------证书环境没问题还断网，才是绑定的问题。
第二步：不换证书的整机抓包
证书绑定管得住"换证书"，管不住"不换"。整机抓包从网卡层取流量、自动解密，全程不做中间人、不装证书------App 校验的是它自己内置的证书，整机抓包根本没碰证书，所以绑定形同虚设。操作：在 TraceEagle 里选设备、选网卡（默认 Wi-Fi）、开抓，流量自动解密直接看明文。Android 上这条路还顺带绕开了高版本系统"不信任用户证书"的问题。验证方法：开抓后让 App 产生请求，列表里直接出现明文记录，方法、URL、状态码齐全------全程没装证书，绑定却没拦住，说明这条路对它有效。
第三步：应用层抓包，从内部取明文
整机抓包覆盖大多数 App；个别做了绑定又用自带加密组件的，在 TraceEagle 里切应用层抓包：从 App 内部直接取明文，证书绑定、自定义加密都拦不住。指定目标三种方式：从已装 App 列表选、填包名或进程名、留空抓当前前台 App。取不到时打开"socket 流量"开关兜底，换一条更底层的路取数据。验证方法：应用层开抓后只操作那个 App，它的请求单独出现，点开是明文；解不出时再开 socket 流量开关重试。
第四步：要改包重放，走代理加去 Pin
前三步解决"看"，要"改"就得走代理------而代理恰恰是绑定校验的战场。这时用 TraceEagle 的"解除证书绑定"：选中目标 App 暂停它的绑定校验，让它信任代理证书，恢复联网、能被代理解密。Android 上需要已 root 设备；想抓启动初期的请求勾"重启目标"；多进程应用开"自动处理子进程"。处理结果实时反馈：成功会告诉你处理了几个目标；碰到不常见的网络组件会明确提示，不会让你干等。注意：去 Pin 只是让 App 愿意信任代理证书，解密仍由代理完成。
提醒：去 Pin 覆盖大多数主流应用和常见绑定框架；用 Go、Rust 编写的程序或桌面 Java 程序不适用去 Pin------它们如果读取系统证书，直接把证书装进信任库即可，不用去 Pin。
四条路的关系再收一下：第二步和第三步是主力，覆盖绝大多数场景；第四步只在需要改包重放时才用。先想清楚自己要"看"还是"改"，再决定走到哪一步。
Android 证书绑定抓包的关键是不跟它抢证书：整机抓包不碰证书，应用层抓包从内部取，只有要改包时才让代理和去 Pin 上场------按需选，一次到位。
证书绑定挡的是"换证书"，不挡"不换"和"从内部读"。先整机抓包，个别顽固 App 用应用层，要改包时代理加去 Pin------四步下来，绑定只是多花一步的时间，拦不住排查本身。绑定这一关，Android 和 iOS 表现不同：Android 的证书信任分用户层和系统层，配合已 root 设备，解法比 iOS 更直接。Android 证书绑定抓包，选对方法比折腾证书快得多。