Fiddler为何无法捕获小程序HTTPS请求？

Question

Fiddler 无法捕获小程序（如微信、支付宝）HTTPS 请求，核心原因在于**小程序运行在独立的安全沙箱中，强制启用证书固定（Certificate Pinning）且绕过系统代理设置**。微信等客户端在 Android/iOS 上不走系统全局代理（即使 Fiddler 已设为系统代理），而是直接使用自研网络栈（如腾讯的 XWeb/WeChat Net），跳过系统 HTTP 代理链；同时，其 HTTPS 请求会校验服务器证书公钥指纹，拒绝接受 Fiddler 的中间人（MITM）伪造证书，导致 TLS 握手失败或请求被静默丢弃。此外，iOS 上小程序还受 App Transport Security（ATS）和 Network Extension 限制，无法注入代理证书；Android 高版本（API ≥ 24）默认不信任用户安装证书。因此，Fiddler 即使配置正确、证书已安装，也无法解密或捕获其 HTTPS 流量——这不是配置问题，而是平台级安全机制的设计使然。

Answer 1

```html

一、现象层：Fiddler 显示“零流量”或 HTTPS 请求全部标记为 403/Failed

在 Windows/macOS 上配置 Fiddler 为系统代理（127.0.0.1:8888），安装根证书并启用 HTTPS 解密后，浏览器、Postman 流量可正常捕获，但微信/支付宝小程序界面完全无 HTTPS 请求记录——仅偶见少量 HTTP 302 或 DNS 类日志。此非代理未生效，而是请求根本未进入代理链路。

二、协议栈层：小程序绕过系统网络栈，直连 TLS 层

• Android：微信使用自研 XWeb Net 网络模块（基于 Chromium Net + 定制 socket 封装），不调用 HttpURLConnection 或 OkHttp，默认忽略 http.proxyHost 系统属性；
• iOS：小程序运行于 WKWebView 扩展容器内，但网络请求由 NSURLSession 经 WeChat Network Extension 调度，ATS 强制启用且禁用 NSAllowsArbitraryLoads；
• 二者均跳过 getprop net.http.proxy（Android）与 SCNetworkProxySettings（iOS）等系统代理查询路径。

三、安全机制层：证书固定（Certificate Pinning）深度固化

平台	Pin 对象	校验时机	失败行为
微信 Android	服务器证书 SPKI 指纹（SHA-256）	TLS handshake 后、HTTP 请求前	静默丢弃连接，不触发 onError 回调
支付宝 iOS	Leaf 证书 + 中间 CA 公钥哈希组合	NSURLSessionTaskDelegate didCompleteWithError	返回 NSURLErrorServerCertificateUntrusted，UI 无提示

四、证书信任层：OS 级证书策略形成双重封锁

Android 7.0+（API ≥ 24）应用默认仅信任 /system/etc/security/cacerts/ 下的系统证书，用户安装的 Fiddler 根证书位于 /data/misc/user/0/cacerts-added/，被微信/支付宝的 android:networkSecurityConfig 显式排除；iOS 12+ 引入 SecTrustSetAnchorCertificatesOnly(true)，强制忽略用户证书存储区（Keychain Access Group 隔离），且无法通过 Network Extension 动态注入。

五、沙箱隔离层：运行时环境强约束

graph LR
A[小程序宿主 App] --> B[独立 WebView 实例]
B --> C[受限 JSContext / WKScriptMessageHandler]
C --> D[Native Bridge 接口]
D --> E[XWeb Net / AlipayNet SDK]
E --> F[Raw Socket + BoringSSL]
F --> G[跳过 Proxy & TLS Stack Hook]

六、逆向验证层：实证分析确认绕过行为

1. 使用 adb shell ps | grep com.tencent.mm 查看进程网络线程，发现 net_thread_* 未绑定 SOCKS_PROXY 环境变量；
2. 在 iOS 设备启用 tcpdump -i any port 443，抓包显示小程序域名直连 IP，无 TLS Client Hello 发往 127.0.0.1；
3. 对微信 APK 反编译，定位 com.tencent.smtt.sdk.QbSdk 初始化逻辑中硬编码 setDownloadListener(null) 与 disablePlatformCertCheck() 调用——即主动关闭系统证书链校验入口。

七、工程解法层：可行替代方案矩阵

• 服务端镜像调试：在小程序 request URL 后追加 ?debug=1 触发后端日志透出（如微信云开发支持 cloud.callFunction({ debug: true })）；
• 客户端日志桥接：利用微信开发者工具「调试器 → Console」查看 console.log(wx.request) 参数快照（仅限开发版）；
• Root/Jailbreak 注入：Android 使用 Frida hook BoringSSL_SSL_do_handshake 获取明文；iOS 需越狱后 patch SecTrustEvaluate 并加载自定义证书库（法律与稳定性风险极高）；
• 合规白盒审计：申请微信「小程序安全检测平台」API 调用轨迹报告，或接入支付宝「开放平台诊断中心」获取全链路 traceId 日志。

八、架构启示层：从“抓包思维”转向“可观测性设计”

现代超级 App 已将网络栈下沉至 Native 层并实施多维加固：证书固定 + 自研协议 + 沙箱隔离 + 运行时校验（如微信的 NetGuard 模块每 30s 校验一次证书链完整性）。这意味着传统 MITM 工具失效本质是终端安全演进的必然结果——真正的解决方案不是破解 pinning，而是推动业务侧内置 X-Debug-Trace 头、OpenTelemetry SDK 或 W3C Trace Context 标准化埋点。

九、合规警示层：法律与风控边界不可逾越

根据《网络安全法》第27条及微信《小程序运营规范》第5.3条，未经许可对小程序通信进行中间人劫持、证书替换、内存注入等行为，可能构成“非法获取计算机信息系统数据罪”；企业级调试必须通过官方授权通道（如微信「体验版」+「调试基础库」白名单机制）实施，任何绕过签名验证的操作均导致账号封禁与法律追责。

十、演进趋势层：下一代调试范式的收敛方向

2024年起，微信/支付宝已试点「小程序 DevTools Remote Debugging Protocol」（基于 WebSocket 的双向信令通道），允许开发者工具直连真机小程序实例，暴露 Network.requestWillBeSent、Security.certificateError 等事件——该协议不依赖 TLS 中间人，而是由宿主 App 主动上报加密前原始请求体，标志着调试能力正从「被动嗅探」向「主动协同」范式迁移。

```