你有没有经历过这种夜晚：手机连着Fiddler（圈内常称FD）或Charles，SSL代理配了，证书也装了，信任开关也打开了，结果目标App一启动，Charles里弹出一排No required SSL certificate was sent，所有请求全是红叉或unknown。你搜遍教程，装justtrustme，把CA证书塞进系统证书目录，折腾到凌晨两点，总算抓到几个包，结果目标App更新了一个版本，校验逻辑一变，又全废了。
我后来做接口分析时，基本不再走代理抓包这条路了。原因很简单：HTTP代理 + SSL证书 + 绕过证书校验，是一条处处被动的链路。我更推荐换一个思路——直接在目标App的进程里做Hook，在网络库的函数内部把Request对象和Response对象直接拿出来。对淘宝这类安全级别较高的应用，“直达函数内部”能绕开绝大多数代理层和证书层的麻烦，这套方法也适用于其他加固过的App接口调试。这篇文章会完整讲清楚原理、环境准备、核心Hook脚本，以及从Charles/Fiddler切换过来最容易踩的坑，适合做Android逆向调试、接口分析、App兼容性开发的读者参考。
1. 传统抓包工具的三座大山：代理、证书、证书校验绕过
先别急着写代码，我们得先搞清楚一个核心问题：为什么Charles/Fiddler这套方案用起来这么难受？因为它的链路是一条完整的中转链路，任何一个环节出问题，结果都是“抓不到包”。
1.1 代理方案的天然缺陷
Charles和Fiddler的工作原理本质上都是HTTP中间人代理。手机把Wifi代理设置为电脑的IP和端口，所有HTTP请求先到代理工具，代理工具再转发给真实服务器。要看到明文请求和响应，代理工具还必须做一次TLS中间人解密。
这个模型有几个绕不过去的痛点。
第一，代理是“全局”的。一旦设置了Wifi代理，App里所有网络请求都会走代理通道，包括一些长连接、WebSocket、推送通道。很多App的网络库对代理状态很敏感，检测到系统代理存在时，会直接拒绝工作或者切换到直连通道，于是你看到的永远是空列表。
第二，代理模式对非HTTP流量基本无效。比如QUIC、UDP、自研二进制协议，走了代理也没法被Charles正常解析。你在Charles里看到一堆“CONNECT”请求，那些往往是TLS隧道，根本看不到里面的内容。
第三，代理层存在性能损耗。手机所有流量绕行到电脑，遇到大文件传输、视频流播放时，Charles经常卡死崩溃，实测体验很差。
所以代理方案的问题是结构性的，不是你配置得不够仔细，而是这条路本身就脆弱。
1.2 SSL证书信任链条带来的连环坑
代理要做TLS解密，就必须让App信任代理工具生成的根证书。这一环是传统抓包最折磨人的地方。
Android这边，7.0之后系统默认不信任用户安装的CA证书，只信任系统证书。你把Charles的证书装成“用户证书”，App里很多流量依然报SSL连接错误或trust anchor for certification path not found。想彻底解决，要么root后把证书文件改名为hash值塞进/system/etc/security/cacerts/，要么走Magisk模块方案。每次系统更新、证书过期，都要重新来一遍。
iOS这边也是类似。描述文件装好之后，还要在“设置-通用-关于本机-证书信任设置”里手动打开完全信任开关。很多人漏了这一步，结果抓包工具显示证书已安装，实际请求全部Handshake失败。
更麻烦的是，很多App并不信任系统CA。它们内置了自己的证书校验逻辑，这种做法通常叫SSL Pinning。服务端下发的公钥或证书指纹被写死在App代码里，代理工具伪造的证书在那一瞬间就被否决了。你看到的报错五花八门，但根源都是同一个：App根本不认你的CA。
1.3 justtrustme们的宿命
于是社区里出现了justtrustme经典思路：用Xposed模块Hook掉系统的TrustManager、OkHttp的CertificatePinner这些校验点，让App无条件信任用户CA。理论上这确实能打通SSL Pinning。
但这条路也有尽头。justtrustme这类工具强烈依赖Xposed框架，而新版本Android对Xposed越来越不友好，不少App也加入了Xposed检测，检测到你开了框架，直接闪退或功能降级。就算Xposed能用，App只要发一个版本，把网络库换成自研的Native层实现，不再走Java层的TrustManager，这些模块瞬间失效。
总结一下就是：Charles链路是“代理—证书—绕过校验”三位一体，你在跟App的开发团队打地鼠，他们每加固一次，你就要重新折腾一遍。这就是我决定换方案的根本原因。
2. 为什么“在函数里取数据”比“在链路上截流量”更稳
既然代理链路上到处是雷，那就干脆别在链路上截了。换个思路：代码里的网络请求，最终一定会落到某个Java对象上，比如OkHttp的Request、Response，或者HttpURLConnection的某个方法。我们直接把Hook点放在这些对象产生的函数内部，在源头把数据读出来。
2.1 一句话说清Hook原理
Frida是一个动态插桩工具，它能把一段JavaScript脚本注入到目标App的进程里，运行时修改Java方法的实现、读取方法的参数和返回值。对网络调试来说，你要做的事情很简单：找到网络中某个关键的构建函数，Hook它，在函数执行前后拿到Request和Response对象。
用生活化的类比：Charles这种代理抓包，相当于你在快递转运中心偷偷拆包裹，看完再原样封好；而Frida Hook，相当于你直接跟发货仓库的打包员串通好了，货物一出库，他就把快递单和货品清单复印一份给你。后者当然更直接，也更不容易被发现。
2.2 它天然免疫的几类问题
- 不再需要中间人代理，所以App的代理检测策略直接失效。
- 不再需要安装和信任任何证书，所以Android 7+系统证书限制、iOS证书信任开关，全部与你无关。
- 不需要绕过SSL Pinning，因为你压根不去解密TLS流量，你拿的是App代码内部已经解密好的业务对象。
- 不影响长连接和UDP流量，因为你不是在网络层转发，只是在业务对象创建时看一眼。
这套方案本质上把“网络抓包”变成了“内存对象观测”，规避了传统方案里最难缠的几个环节。
2.3 一个必须提前知道的技术边界
但我也得泼一盆冷水。Hook方案有一个重要的适用边界：它只能覆盖Java层的网络栈。
如果目标App的网络请求是经过OkHttp、HttpURLConnection这些Java层框架发送的，那么Hook效果非常好。但像淘宝这类大型App，很多核心接口跑在自研的Native网络栈上，底层是长连接、私有协议，根本没走Java层的Request/Response对象，这种请求用Hook方案也拿不到。
实际使用中，我通常把它当作一个“Java层网络请求的显微镜”，而不是“万能抓包器”。抓H5页面接口、小程序容器请求、部分普通业务接口，这套方案非常好使；少数核心Native接口抓不到，那就换别的专业方案，这是工具边界，不必神话。
3. 环境准备：一台能用Frida的设备，不用装任何证书
Hook方案最大的成本不是安装配置，而是准备一台合适的调试设备。好消息是，你不需要再折腾证书了。
3.1 设备选择与基础要求
建议首选Android模拟器，雷电、夜神、MuMu都行，版本选Android 7到Android 12之间。模拟器最大的优势是root简单，frida-server注入几乎不会遇到权限问题，快照功能还能随时还原系统状态。真机也可以，但要求设备已root，并且不建议拿主力机试，因为目标App可能会对运行环境做检测，而且注入操作有一定概率导致App崩溃，最好准备一台专用调试机。
USB连接电脑后，先用adb devices确认设备在线。模拟器一般通过adb connect 127.0.0.1:端口连接，真机用USB线并开启USB调试。
3.2 安装frida-server与客户端工具
电脑端需要Python环境，安装frida工具链：
pip install frida-tools然后从Frida官方GitHub Release页面下载对应架构的frida-server。模拟器通常是x86或x86_64，真机一般是arm64。下载后推送到设备：
adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server adb shell /data/local/tmp/frida-server &另开一个终端窗口验证：
frida-ps -U如果能看到设备上的进程列表，说明frida-server运行正常。注意，frida-server的版本必须和电脑端frida核心库版本一致，pip install frida-tools装的是最新版，那就下载对应最新版的server文件。版本不一致会出现unable to communicate with frida-server之类的报错。
3.3 两套方案的环境清单对比
| 项目 | Charles/Fiddler 方案 | Hook 方案 |
|---|---|---|
| 代理服务器 | 需要 | 不需要 |
| 用户CA证书 | 需要 | 不需要 |
| 系统证书目录修改 | 通常需要 | 不需要 |
| Xposed模块 | 可能需要 | 不需要 |
| 代理检测规避 | 困难 | 天然免疫 |
| 对Java层网络栈 | 通用但不稳定 | 稳定且直观 |
| 核心工具 | Charles/Fiddler + 证书 + 模块 | frida-server + JS脚本 |
这张表只是我的个人体验。传统方案可能两小时配置，用起来依然战战兢兢；Hook方案首次配置半小时，之后每次换目标App，只需要改包名和Hook点，基本能做到开箱即用。
4. Hook脚本实战：拿到OkHttp的Request与Response完整内容
环境准备好之后，最核心的就是写Hook脚本了。大多数Android App的网络请求都基于OkHttp，所以我的默认Hook点是OkHttp的Request$Builder.build()和Response$Builder.build()。这两个方法一个是请求对象的构建出口，一个是响应对象的构建出口，只要网络库走OkHttp，请求和响应100%会经过它们。
4.1 先跑通最小脚本：只看URL和Method
不要一上来就写大而全的脚本，先跑通最简版本，验证Hook链路是否通畅。新建hook_req.js：
Java.perform(function () { var RequestBuilder = Java.use('okhttp3.Request$Builder'); RequestBuilder.build.implement(function () { var req = this.build(); console.log('[REQ] ' + req.method() + ' ' + req.url().toString()); return req; }); });启动目标App时用spawn模式，让App从启动开始就注入：
frida -U -f com.example.app -l hook_req.js-f表示启动一个新的App进程，-l指定脚本路径。如果看到控制台不断输出[REQ] GET/POST xxx，说明Hook成功。
这里有个小坑：很多教程用frida -U 包名直接附加已运行的进程，但这样会错过App启动阶段的早期网络请求。建议调试网络时优先用-f模式从冷启动开始抓取。
4.2 完整脚本：把Header、Response Code和Body全部打出来
最小脚本跑通后，再升级到完整版。完整脚本要解决两个问题：看清楚请求的完整信息，以及拿到响应体。响应体的读取是重点，直接resp.body().string()会把body流消费掉，导致App后续拿到空body，所以必须用source().buffer().clone()先复制一份，再读取复制出来的缓冲区。
Java.perform(function () { var Long = Java.use('java.lang.Long'); var RequestBuilder = Java.use('okhttp3.Request$Builder'); RequestBuilder.build.implement(function () { var req = this.build(); try { console.log('\n========== REQUEST =========='); console.log('[REQ] ' + req.method() + ' ' + req.url().toString()); console.log('[REQ-HEADER]\n' + req.headers().toString()); } catch (e) { console.log('[REQ-ERR] ' + e); } return req; }); var ResponseBuilder = Java.use('okhttp3.Response$Builder'); ResponseBuilder.build.implement(function () { var resp = this.build(); try { var req = resp.request(); if (req == null) return resp; console.log('\n========== RESPONSE =========='); console.log('[RESP] ' + resp.code() + ' ' + req.method() + ' ' + req.url().toString()); console.log('[RESP-HEADER]\n' + resp.headers().toString()); var body = resp.body(); if (body != null) { var source = body.source(); source.request(Long.MAX_VALUE.value); var buffer = source.buffer().clone(); var content = buffer.readUtf8(); if (content.length > 0) { console.log('[RESP-BODY] ' + content); } } } catch (e) { console.log('[RESP-ERR] ' + e); } return resp; }); });这个脚本覆盖了请求方法、URL、请求头、响应状态码、响应头和响应体。对于日常接口调试，这些信息已经足够定位绝大多数问题。
4.3 请求体为什么不能无脑打印
细心的读者会发现，我上面的脚本里没有打印Request的Body。这不是疏漏，而是有意为之。
RequestBody.writeTo()是OkHttp真正发送请求内容时才会调用的方法。如果你在Hook里提前调用body.writeTo(buffer)把请求体读出来，某些类型的RequestBody内部状态会被消耗掉，之后OkHttp真正发送时，请求体可能变成空内容，或者直接抛异常。这种问题极其隐蔽，你不容易联想到是自己Hook脚本把请求搞坏了。
我的经验做法是：优先打印URL、Header和响应体，这些已经能覆盖90%的调试需求。如果确实要看请求体，先判断body类型，对于okio.Buffer这类可重复读取的，可以安全复制读取；对于流式body，不要轻易尝试。你可以额外用下面的代码段单独打印常见Buffer类型的请求体：
var body = req.body(); if (body != null) { var contentType = body.contentType(); var length = body.contentLength(); console.log('[REQ-BODY-META] type=' + contentType + ' len=' + length); }先看类型和长度，再决定要不要冒险读取，这是长期实践中比较稳妥的策略。
4.4 实测中的输出样式
跑起来之后，控制台大概是这种感觉：
========== REQUEST ========== [REQ] POST http://192.168.1.10:8080/api/order/list [REQ-HEADER] Content-Type: application/json User-Agent: okhttp/3.12.1 X-Sign: abc123 ========== RESPONSE ========== [RESP] 200 POST http://192.168.1.10:8080/api/order/list [RESP-HEADER] Content-Type: application/json Date: Tue, 08 Apr 2025 10:00:00 GMT [RESP-BODY] {"code":0,"data":[{"id":1,"name":"test"}]}拿这个输出和Charles的报文对比，会发现信息完整度并不差，而且不用处理那一堆证书告警。特别是遇到400 Bad Request或者request header is too large这种服务器直接拒绝的响应时，Hook方案能清楚看到服务器返回的原始内容，而不像代理方案那样只给你一个笼统的错误页。
5. 适配“安全级别较高的App”时的真实细节
现在方案跑通了，但现实世界比干净Demo复杂得多。目标App不会老老实实让你用标准包名找到okhttp3.Request$Builder。混淆、加固、多ClassLoader、网络库版本差异，这些都是绕不开的细节。
5.1 类名被混淆时怎么找Hook点
大型App通常开启ProGuard混淆，网络库类名可能被改成a.b.c这种短名，直接Java.use('okhttp3.Request$Builder')会直接抛ClassNotFoundException。
这时候不要硬写类名，而是先枚举已加载的类，看看目标环境里网络库的真实类长什么样。可以在脚本里加一段扫描逻辑：
Java.perform(function () { Java.enumerateLoadedClassesSync().forEach(function (clsName) { if (clsName.indexOf('okhttp') !== -1 && clsName.indexOf('Request') !== -1) { console.log(clsName); } }); });如果目标App启动后没找到，可能是类还没加载。这时候可以先用frida -U -f 包名启动，在App里多触发几个界面，再执行扫描。找到真实类名后，把脚本里的Java.use参数替换成扫描结果即可。
如果被混淆得面目全非，连okhttp关键词都搜不到，那大概率是多ClassLoader搞的鬼，继续看下一节。
5.2 多ClassLoader导致ClassNotFoundException
很多大型App使用插件化架构或自研容器，不同的业务模块由不同的ClassLoader加载。你在默认ClassLoader下找不到类，但类其实已经被某个插件ClassLoader加载了。
解决办法是遍历所有ClassLoader，逐个尝试解析目标类。使用Java.ClassFactory.get(loader)为每个ClassLoader创建独立的类工厂，再从工厂里解析Hook点：
Java.enumerateClassLoaders({ onMatch: function (loader) { try { var factory = Java.ClassFactory.get(loader); var RequestBuilder = factory.use('okhttp3.Request$Builder'); RequestBuilder.build.implement(function () { var req = this.build(); console.log('[REQ] ' + req.method() + ' ' + req.url().toString()); return req; }); } catch (e) { // 这个loader里没有目标类，跳过 } }, onComplete: function () { console.log('[*] classloader scan done'); } });注意，这段脚本要在所有ClassLoader都加载完毕后执行才有效。最简单的方式是在Java.perform里包一个setTimeout，延迟几秒再扫描。虽不优雅，但实际调试中够用。
5.3 不同OkHttp版本和不同网络库的差异
常规App用的OkHttp版本五花八门，有3.x、4.x，但包名一直都是okhttp3，主要类的Hook点基本稳定。少数老App还在用com.squareup.okhttp（OkHttp 2.x），这时候类名要改成com.squareup.okhttp.Request$Builder，脚本逻辑不用变。
如果目标App压根不用OkHttp，而是用系统自带的HttpURLConnection，那可以Hook它的核心实现类。Android系统内部把HttpURLConnection也实现成了一套OkHttp，常用Hook点有：
com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream()com.android.okhttp.internal.huc.HttpURLConnectionImpl.getOutputStream()com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode()
不回原始Java类的问题，最笨也最有效的办法还是枚举已加载类，按关键词过滤，再根据扫描结果定Hook点。
5.4 非Java网络层：Hook方案也有边界
再强调一遍本章开头提到的边界：Android App如果走的是自研Native网络栈，比如基于Chromium net库、QUIC、自研长连接协议，那么Java层Hook方案完全无能为力。
以淘宝为例，很多核心接口并不是走OkHttp。你Hookokhttp3.Request$Builder能看到的，往往是H5页面里发出去的Ajax请求、部分小程序容器的业务请求，以及一些基础REST接口。真正核心的Native请求，还是得借助其他更底层的调试手段，或者干脆使用目标App自身的调试接口、日志开关。这不是Hook方案的问题，而是这个场景本身就超出了Java层Hook的能力范围。
6. 从Charles/Fiddler切过来容易踩的错误与排查
最后讲几个我在切换方案过程中实际踩过的坑。这些错误在Charles时代也经常遇到，但在Hook方案下会以不同形式出现，容易让人误判。
6.1request header is too large：不一定是Hook脚本的问题
很多读者第一次跑脚本，看到控制台刷出request header is too large，第一反应是脚本把Header打太多次导致异常。其实这个错误是服务器返回的，意思是请求头的体积超过了服务器/网关的容量限制。
通常是因为Cookie、Authorization、自定义Header顺带塞了一堆元数据，整体超过8KB甚至16KB。Charles时代这个问题不明显，因为代理工具可能帮你裁剪或你压根看不到原始Header大小。Hook方案直连服务器，原始Header原样发送，问题反而更容易暴露。
排查时先看[REQ-HEADER]输出，统计Header总长度；如果确实过大，精简业务侧的冗余Header，或者调整服务端网关限额。
6.2connection failed: error sending request与代理残留
这个错误在Charles时代很常见，原因往往是你手机Wifi代理还开着，但Charles已经退出，或者代理端口被占用。切换到Hook方案后，系统代理理论上不再需要设置，但如果你之前在代码里、或者通过某些网络库显式设置了Proxy，请求依然会尝试走代理，然后报error sending request。
我的排查顺序是：
- 确认系统Wifi代理已关闭，手动设置过代理的改为“无”。
- 在App代码的OkHttpClient初始化处Hook
Proxy相关方法，看看是否有代码显式设置了代理。 - 用Hook脚本查看请求真正连接的IP和端口，判断是直连还是走了某个代理。
Hook方案下你拿到的Request对象里带着完整的URL和Header，有没有走代理其实很容易看出来。
6.3400 Bad Request、stream disconnected before completion这类服务器报错
用Charles抓包时，这类错误信息往往被工具自身的错误页遮挡，真实响应体丢失。用Hook方案，Response$Builder.build()会在服务器响应到达的第一时间把Response对象交给你，[RESP] 400之后紧跟着的就是服务器返回的错误详情body。
这其实是我最推荐的定位方式：一旦看到非2xx状态码，立刻从[RESP-BODY]读取错误信息，大多数情况下服务器会把失败原因写在响应体里。
| 错误类型 | 可能原因 | 排查建议 |
|---|---|---|
| 400 Bad Request | 请求参数或Header格式错误 | 重点看参数签名和Content-Type |
| stream disconnected before completion | 上游服务器提前断开连接 | 看是否超时、body过大、网关配置 |
| request header is too large | Header体积超限 | 精简Header或调整网关限额 |
| connection failed | 代理残留或网络不通 | 关闭代理，检查DNS和IP连通性 |
6.4 从“黑盒抓包”到“白盒定位”的思维转变
用Charles久了，很容易形成一种思维定式：抓不到就是证书问题，报错就是代理问题。Hook方案逼着你换个角度思考——你不再是一个站在门外偷听的旁观者，而是直接坐在网络库的构造函数旁边看数据的人。
这意味着你的调试习惯也要跟着变。以前是“开代理—看列表—筛选域名—看报文”，现在是“启动App—看控制台—按关键词过滤—定位到具体方法调用”。刚开始可能不太习惯，但用顺手之后，你会发现定位一个接口参数问题的速度比之前快很多，因为你不只看到了流量，还看到了这个流量是从哪个函数、哪条业务逻辑发出来的。
我自己现在保留了一台旧Android手机专门做调试机，系统里干干净净，没有任何证书，也不设代理，只跑一个frida-server。日常给App做Java层接口分析，绝大部分需求都能在这台机器上完成。如果你正被Charles的证书问题折腾得头疼，不用硬刚代理层了，把这篇文章里的脚本改成你自己的目标包名，先跑通一次，你会回来感谢这个思路的。
