开发同学应该都遇到过这种情况：App 里排查一个接口问题，代理抓包工具配好了、证书也装了，流量却一条都抓不到，或者抓到全是密文，控制台还报着一堆握手失败的日志。去网上搜，答案都指向同一个词------SSL Pinning。这篇把证书固定到底是什么、为什么挡得住代理抓包，以及绕过它拿到明文有哪些路，一次讲清楚。
SSL Pinning 挡的是什么
代理抓包的核心是中间人：工具用自己的根证书动态签发目标域名的证书，客户端如果信任这个根证书，握手就能继续，工具在中间看到明文。SSL Pinning（证书固定）打破的正是这个信任链------App 在代码里写死了服务端证书的指纹、公钥或证书链，校验时不再只看"证书链是否可信"，而是要求"证书必须是我写死的那个"。代理签发的那张"假"证书，指纹对不上，校验直接失败，握手被拒。所以 pinning 不是"难抓"，是"这条路被从设计上堵死了"。
传统路线的代价
绕过 pinning 的传统做法是运行时 hook：用 Frida 这类工具挂进 App 进程，hook 掉证书校验函数（SSL_CTX_set_verify、SecTrustEvaluate 这一层），让校验直接返回通过。这条路有效，但条件苛刻：iOS 上要求越狱环境，Android 上要求 root，hook 脚本要跟着 App 版本迭代维护，还可能被 App 的反调试、完整性校验发现。公司内部排查一次接口问题，为它准备一套越狱设备加 Frida 环境，成本并不低。
换一条路：从应用内部直接取明文
不动校验逻辑，也能拿到明文------从应用内部直接取。抓包鹰 TraceEagle 的应用层抓包走的就是这条路：在程序内部、数据发送和接收的必经点上取数据，拿到的本来就是明文，根本不经过中间人，也就不存在"证书对不对得上"的问题。做没做 SSL Pinning 都不影响：pinning 校验的是握手环节的证书，应用层取数据发生在握手之后，校验已经过去了。代理和网卡都拿它没办法的目标，这条路能拿下。
实操：两个入口
TraceEagle 抓 pinning 目标有两个入口。想继续走代理路线，用"一键解除目标证书绑定"：把目标 App 的证书绑定处理掉，再按常规代理抓包，请求就能正常解密；不想动证书绑定的，直接选应用层抓包，指定目标程序，从内部取明文，适合证书绑定和自研加密都在的顽固目标。iOS 端三种方法免越狱，Android 端免装证书，同一个界面看解密结果。
什么时候用哪条
按场景选：只是临时看一眼某个接口，hook 路线不值得搭环境，应用层取明文最快；要长期维护一套抓包环境，解除绑定走代理更符合习惯；遇到自研加密、私有协议，代理解密不了，应用层取明文几乎是唯一选项。三种思路不是互斥的------同一台机器上，常规流量走代理、pinning 目标走应用层，互不干扰。