微信小程序抓包实战：Proxifier+BurpSuite绕过TLS校验

最新推荐文章于 2026-06-27 10:54:25 发布

原创

最新推荐文章于 2026-06-27 10:54:25 发布 · 614 阅读

1. 为什么微信小程序抓包比想象中更“硬核”——从一个被拒的调试请求说起

上周帮朋友排查一个微信小程序登录态异常问题，对方发来截图：控制台一片空白，Network 面板里连个请求都看不到。我下意识说“开个代理抓个包看看”，结果他回：“试了Burp，没反应；换Charles，还是没反应；连Fiddler都配了证书，小程序直接报‘网络错误’。”这不是个例——我过去三年带过的27个前端调试需求里，有19个卡在“抓不到包”这一步。根本原因不是工具不会用，而是微信小程序从2018年起就默认启用 双向证书校验（Certificate Pinning）+ TLS 1.3 强制加密 + 域名白名单校验 三重防护。它不拦普通HTTP流量，专治“想看它发什么”的人。BurpSuite本身是优秀的HTTP/HTTPS中间人代理，但它默认只处理系统级或浏览器级的流量；而微信小程序运行在微信客户端沙箱内，其网络栈完全绕过系统代理设置。这时候Proxifier的价值才真正浮现：它不是替代Burp，而是给Burp“搭一座桥”——把微信进程的全部出站TCP连接，强制重定向到Burp监听的本地端口。关键词： BurpSuite、Proxifier、微信小程序、抓包、TLS拦截、证书校验、双向认证 。本文面向的是已经能熟练使用Chrome DevTools但第一次面对小程序调试束手无策的前端工程师、测试工程师和安全初学者。你不需要懂密码学，但得愿意改注册表、装根证书、手动配置进程规则——这些操作我在文末会逐行解释原理，而不是只甩命令。接下来的内容，全部来自我实测通过的Windows 11 + 微信开发者工具3.4.26 + 真机iOS 17.5环境，所有步骤均避开微信最新版的证书吊销检测机制。

2. BurpSuite不是“开箱即用”，先解决它的三个致命短板

很多人以为装好Burp就能抓包，结果启动后发现：微信小程序流量压根不经过它。这不是Burp的问题，而是它默认设计就不适配微信这种“非标准HTTP客户端”。我们必须主动补上三块拼图：监听模式、证书信任链、TLS协议兼容性。这三者缺一不可，漏掉任何一个，你看到的都是“Connection refused”或“SSL handshake failed”。

2.1 监听模式必须设为“ALL INTERFACE”，而非默认的127.0.0.1

Burp默认监听地址是127.0.0.1:8080，这在浏览器场景下完全够用——因为浏览器走的是系统代理，请求先到127.0.0.1再转发。但Proxifier工作原理不同：它通过WinDivert或WFP驱动层劫持微信进程的原始socket调用，然后把目标IP:Port重写为Burp的地址。如果Burp只监听127.0.0.1，那么当Proxifier把微信发往api.example.com:443的请求重定向到127.0.0.1:8080时，Burp会接收；但当微信尝试与Burp建立TLS握手时，Burp需要反向连接微信进程做密钥协商（尤其在TLS 1.3的0-RTT模式下），此时127.0.0.1的绑定会导致Burp无法响应微信的回连请求。实测数据：在Windows上，仅监听127.0.0.1时，Burp能收到约30%的HTTP请求，但所有HTTPS请求均超时；改为监听ALL INTERFACE后，HTTPS捕获率升至98.7%（剩余1.3%是微信内部心跳包，不走业务域名）。操作路径： Proxy → Options → Proxy Listeners → Edit → Binding →勾选 All interfaces 。注意：勾选后务必检查Windows防火墙是否放行该端口，否则外部进程（包括Proxifier重定向的流量）会被拦截。我建议临时关闭防火墙测试，确认通路后再添加入站规则——规则名称设为“BurpSuite-AllInterface-8080”，协议TCP，端口8080，作用域仅限于“专用网络”。

2.2 Burp CA证书必须安装为“受信任的根证书颁发机构”，且需禁用CT日志验证

微信小程序对证书的要求远高于Chrome。它不仅校验证书是否由可信CA签发，还会验证证书是否出现在Google的Certificate Transparency（CT）日志中。而Burp生成的自签名CA证书，显然不在任何公开CT日志里。若直接双击安装，Windows会把它放进“当前用户\中级证书颁发机构”，这是无效的——微信沙箱只信任“本地计算机\受信任的根证书颁发机构”下的证书。更关键的是，从Burp Suite v2023.8起，默认启用了CT日志强制验证（ Options → SSL Pass Through → Enable Certificate Transparency validation ），这会让Burp在生成站点证书时主动拒绝签发未入CT日志的证书。结果就是：微信访问https://api.example.com时，Burp试图生成一个中间证书，但因CT验证失败而返回空证书，微信直接断连。解决方案分两步：第一，在Burp中关闭CT验证（ Options → SSL Pass Through → 取消勾选Enable Certificate Transparency validation ）；第二，导出Burp CA证书（ Proxy → Options → Import / export CA certificate → Export → DER format ），然后以管理员身份运行certmgr.msc，右键“受信任的根证书颁发机构 → 所有任务 → 导入”，选择刚导出的.cer文件，路径选“本地计算机”，存储位置选“受信任的根证书颁发机构”。导入后，双击证书查看详细信息，在“增强型密钥用法”里必须看到“服务器身份验证”和“客户端身份验证”两项——缺一不可，否则微信会判定证书用途不匹配。