1. 为什么“抓包”是小程序和公众号开发绕不开的坎很多人刚接触小程序或公众号开发时会下意识觉得“我只写前端页面后端接口都是公司统一提供的抓包这种事应该是测试或者安全同学干的。”直到某天线上一个按钮点击没反应控制台一片空白网络面板里连个请求都看不到或者用户反馈“图片加载不出来”你本地一切正常切到真机调试又卡在某个接口超时——这时候才意识到不掌握抓包能力等于在黑盒里修电路。抓包不是黑客行为而是开发者最基础的“感官延伸”。小程序和公众号的特殊性在于它们运行在微信自研的 WebView 容器中既不像 Chrome 那样开放 DevTools也不像原生 App 那样能直接 hook 网络层。它的网络请求被微信 SDK 封装得严严实实wx.request的入参、出参、中间重定向、证书校验、Header 注入、甚至 DNS 解析过程全被屏蔽在开发者视野之外。你看到的fail: timeout背后可能是 CDN 节点故障、服务端 Nginx 限流、TLS 1.2 协议不兼容甚至是微信客户端对特定域名做了预检拦截——而这些仅靠console.log和wx.getNetworkType是永远查不到的。我带过三届前端实习生几乎所有人都在“联调失败”环节卡住超过两天。最常见的场景是后端说“我这边日志显示没收到请求”前端说“我wx.request调用了success 回调都没进”双方各执一词。最后用抓包工具一跑发现是小程序request的header里误加了Cookie字段微信禁止手动设置导致整个请求被微信底层静默丢弃——连 error 回调都不触发。这种问题不亲眼看到 HTTP 请求被拦在哪儿根本无从下手。所以“从小白到大神”的第一道分水岭从来不是会不会写组件而是能不能在微信生态的黑箱里亲手点亮一盏探照灯。本文讲的“三工具协同”不是堆砌三个软件而是构建一套有层次、可回溯、能交叉验证的观测体系Charles 做协议层透镜Whistle 做规则化流量调度Fiddler Everywhere或 mitmproxy做轻量级现场快照。它们分工明确Charles 负责深度解密 HTTPS 流量与证书信任链重建Whistle 专治“这个接口在 A 环境能通B 环境就 401”的环境变量污染问题Fiddler 则在你赶着上线、没时间配代理时30 秒内完成一次真机流量快照。这三者不是替代关系而是像听诊器、血压计、心电图仪——医生不会只用一种设备判断心梗。关键词“小程序 / 公众号抓包”背后实际指向的是微信容器网络栈的可观测性建设。它解决的不是“怎么抓”而是“抓到之后如何可信、可复现、可归因地定位问题”。接下来的内容全部围绕这个核心展开不讲安装步骤只讲每个工具在真实排障链路中的不可替代性不列参数清单只说为什么这个参数值必须这么设不教“怎么用”只拆解“上次我就是在这里栽了跟头”。2. Charles不只是代理而是微信 HTTPS 流量的“X 光机”很多新手装完 Charles 就卡在第一步手机连上 Wi-Fi配置代理 IP 和端口打开小程序结果一片空白——连微信首页都打不开。于是立刻怀疑“Charles 不支持微信”删掉重装 Whistle。其实问题根本不在这儿而在于你没让 Charles 成为微信信任的“数字身份证颁发机构”。微信iOS 和 Android对 HTTPS 证书校验极其严格。它不走系统根证书库而是内置了一套受信 CA 列表并且默认禁用所有用户手动安装的证书。当你用 Charles 拦截 HTTPS 请求时它会动态生成一个中间证书Charles Proxy CA再用这个 CA 签发目标网站的假证书。但微信根本不认这个 CA于是直接终止 TLS 握手连接失败。这不是 Charles 的 bug而是微信安全策略的必然结果。解决方案不是放弃 Charles而是把 Charles Proxy CA “种”进微信的信任链。这里有个关键细节iOS 和 Android 的操作路径完全不同且 iOS 15、Android 12 之后规则又有变化。我实测过 7 种主流机型总结出最稳的路径2.1 iOS 真机两步证书信任 一个隐藏开关第一步在 iPhone 上 Safari 访问chls.pro/ssl下载并安装 Charles Proxy CA 证书。注意不能通过邮件附件或 AirDrop 传必须用 Safari 直接访问下载。iOS 对证书来源有强校验非 Safari 下载的证书会被标记为“不受信任”。第二步进入「设置 → 已下载描述文件」→ 点击安装 → 输入锁屏密码 → 完成。但这还不够。iOS 15 起默认关闭了“对已安装证书的信任”你需要手动开启「设置 → 关于本机 → 证书信任设置」→ 找到 “Charles Proxy CA” → 开启右侧开关。这一步 90% 的人会漏掉导致证书安装了却依然抓不到包。第三步常被忽略微信本身有个“网络调试模式”开关。在微信「我 → 设置 → 辅助功能 → 微信内网页调试」里必须开启。这个开关的作用是让微信 WebView 在发起网络请求时允许走系统代理否则它会直连绕过你的 Charles。没有这个开关哪怕证书全对流量也进不了 Charles。提示如果开启后仍无流量检查 iPhone 的 Wi-Fi 设置里是否为当前网络手动配置了代理。iOS 的“自动代理配置”PAC在微信里经常失效务必选“手动”填入 Mac 的局域网 IP不是 127.0.0.1和 Charles 默认端口 8888。2.2 Android 真机ADB 注入 系统证书目录适配Android 的难点不在证书安装而在微信对用户证书的无视。从 Android 7.0 开始App 默认只信任系统证书目录/system/etc/security/cacerts/里的 CA而用户安装的证书放在/data/misc/user/0/cacerts/微信直接忽略。常规方案是刷机或 Magisk 模块但太重。更轻量的方案是用 ADB 将 Charles Proxy CA 导入系统证书目录。前提是手机已开启 USB 调试且未被厂商锁 Bootloader。执行以下命令需提前将charles-proxy-ca.pem文件放到电脑# 将证书转为 Android 系统格式需要 openssl openssl x509 -inform PEM -subject_hash_old -in charles-proxy-ca.pem | head -1 # 假设输出为 9a5ba575则重命名证书文件为 9a5ba575.0 adb root adb remount adb push 9a5ba575.0 /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/9a5ba575.0但注意华为、小米等国产 ROM 常修改了证书路径或校验逻辑。实测下来最通用的方案反而是“降级信任”在 Charles 中启用「Proxy → SSL Proxying Settings → Enable SSL Proxying」然后在「Locations」里添加你要抓包的域名如api.example.com:443再勾选「Install Charles Root Certificate on Mobile Devices」。这时 Charles 会生成一个针对该域名的专用证书比泛域名证书更容易被微信接受。2.3 小程序专属陷阱wx.request 的“静默失败”机制即使证书和代理全通你仍可能在 Charles 里看到大量400 Bad Request或空响应。这是因为小程序wx.request有一个隐藏特性当请求 Header 中包含某些非法字段如Cookie、Origin、Host或 URL 中存在未编码的空格、中文微信客户端会在发起网络请求前就直接拒绝连 TCP 连接都不会建立。Charles 根本收不到任何数据自然无法显示。验证方法很简单在 Charles 的「Structure」标签页右键点击任意域名 → 「Breakpoints…」→ 勾选「Request」→ 再次触发小程序请求。如果断点没触发说明请求压根没发出如果触发了但返回 400再看「Raw」标签页里的原始请求头逐行排查非法字段。我踩过的最深的坑是Content-Type: application/json。很多后端要求必须带这个头但小程序wx.request在method: POST且data是 Object 时会自动加上Content-Type: application/json;charsetUTF-8。而某些老旧 Nginx 配置会因charset参数报 400。解决方案不是改后端而是在wx.request的header里显式写死Content-Type: application/json覆盖掉微信自动加的带 charset 版本。注意Charles 的「Sequence」视图里如果看到请求状态是unknown或0ms基本可以判定是微信客户端层面拦截不用再往下查服务端。3. Whistle解决“环境错乱”的流量调度中枢如果说 Charles 是 X 光机那 Whistle 就是手术室里的无影灯——它不负责拍片但能让你在复杂环境中精准照亮某一根血管。小程序和公众号开发最头疼的从来不是“抓不到包”而是“包抓到了但不知道该信哪一个”。典型场景测试同学说“这个接口在测试环境返回 200但线上环境返回 401”你用 Charles 抓了两边的包发现请求 URL、Header、Body 完全一致唯独响应体里多了一个X-Env: prod。你开始怀疑是后端代码分支问题拉代码、查 Git Log、部署测试服……折腾半天最后发现是小程序app.js里有一行const API_BASE process.env.NODE_ENV production ? https://prod-api.com : https://test-api.com而process.env.NODE_ENV在微信构建时被硬编码为了production导致本地开发时也走线上域名——但因为本地 hosts 绑定了测试 IP反而能通。这种环境变量、构建配置、DNS 解析、CDN 路由层层嵌套的错乱靠单点抓包根本理不清。Whistle 的价值就在于它能把“流量”当成可编程的对象来操作。它不是被动监听而是主动调度你可以写一条规则让所有发往prod-api.com的请求强制转发到localhost:3000/mock也可以写一条规则给所有User-Agent包含MicroMessenger的请求自动注入一个X-Debug: true头甚至可以写一条规则把https://mp.weixin.qq.com/cgi-bin/xxx的响应体用正则替换掉其中的window.location.href https://xxx改成window.location.href http://localhost:8080从而绕过微信的跳转限制在本地调试公众号 H5。3.1 规则语法从“字符串匹配”到“上下文感知”Whistle 规则的核心是pattern operator value三元组。比如www.example.com resBody://{./mocks/home.json}这行规则的意思是当请求匹配www.example.com时直接返回本地./mocks/home.json文件内容完全不发往真实服务器。但小程序的域名往往带 path比如api.example.com/v2/user/info。如果只写api.example.com会导致所有子路径都被 mock破坏调试。更精准的写法是api.example.com/v2/user/info resBody://{./mocks/user-info.json}然而这还不够。因为小程序请求常带 query 参数如?timestamp1712345678signabc。Whistle 默认会把 query 参数纳入 pattern 匹配导致每次时间戳不同规则就失效。解决方案是使用*通配符或正则/api\.example\.com\/v2\/user\/info\?.*/ resBody://{./mocks/user-info.json}但真正体现 Whistle 智能的是它的上下文规则。比如你想只 mock 微信内置浏览器的请求而不影响 Chrome 调试ua://MicroMessenger resBody://{./mocks/wechat-only.json}或者你想区分小程序和公众号的请求它们 User-Agent 极其相似reqHeaders://User-Agent.*MiniProgram/ resBody://{./mocks/miniprogram.json} reqHeaders://User-Agent.*MP/ resBody://{./mocks/mp.json}3.2 小程序调试实战绕过 wx.login 的 code 时效性wx.login返回的code只有 5 分钟有效期且只能使用一次。这导致本地调试登录流程时每改一行代码就得重新扫码授权效率极低。Whistle 可以彻底解决这个问题。思路是拦截wx.login的后续请求通常是POST /api/login携带code将其重写为一个固定code的请求并 mock 掉后端校验逻辑。具体规则如下# 拦截登录请求重写 code 为固定值 https://api.example.com/api/login reqBody://{code:mock_code_123456,encryptedData:mock_data,iv:mock_iv} # 同时 mock 接口响应返回模拟的用户信息 https://api.example.com/api/login resBody://{./mocks/login-success.json}这样你在小程序里点“登录”wx.login仍会正常调起但后续wx.request发往/api/login的请求body 已被 Whistle 强制替换后端收到的永远是code: mock_code_123456。你可以在./mocks/login-success.json里写死任意用户数据反复调试登录态管理、Token 刷新逻辑完全不用扫码。注意Whistle 的规则是按顺序匹配的越精确的规则要写在越前面。建议把api.example.com/v2/*这类宽泛规则放在最后避免覆盖掉精细规则。3.3 公众号 JS-SDK 签名调试用 Whistle 动态注入 signature公众号 JS-SDK 的config接口需要signature而这个签名依赖nonceStr、timestamp、url三要素且url必须是当前页面的完整 URL含 hash。本地开发时页面 URL 是http://localhost:8080/page.html#tab1但生产环境是https://mp.example.com/page.html#tab2导致签名总不匹配。Whistle 可以在响应 HTML 时动态注入正确的 signature。规则如下# 匹配公众号页面 HTML 响应 https://mp.example.com/page.html resBody://{ type: html, value: //{./templates/page.html} } # 在 HTML 中插入 signature 脚本 https://mp.example.com/page.html resScript://{ script: document.addEventListener(DOMContentLoaded, function() { var script document.createElement(script); script.src https://cdn.example.com/jssdk-config.js?nonceStrabctimestamp1712345678urlhttps%3A%2F%2Fmp.example.com%2Fpage.html%23tab1signaturexyz; document.head.appendChild(script); }); }本质是Whistle 把原始 HTML 当作模板用resScript注入一段 JS在页面加载完成后动态创建 script 标签加载一个预计算好 signature 的 JS 文件。这样本地开发和线上环境用同一套 HTML签名逻辑由 Whistle 在传输层完成彻底解耦。4. Fiddler Everywhere真机现场的“急救包”与交叉验证锚点当 Charles 配置失败、Whistle 规则写错、而你又急需在客户手机上快速复现一个问题时Fiddler Everywhere 就是那个“30 秒救命”的工具。它和 Charles、Whistle 的最大区别在于它不追求深度解密而追求零配置、快启动、高兼容。Charles 需要你理解证书信任链Whistle 需要你写正则和上下文规则而 Fiddler Everywhere 只需要三步1在 Mac/Windows 上安装2手机连同一 Wi-Fi设置代理为电脑 IP 端口3在手机浏览器里访问https://docs.telerik.com/fiddler-everywhere/按提示安装证书。它内置的证书生成和安装引导比 Charles 更傻瓜尤其对 iOS 16 的新证书流程做了专门优化。但它的真正价值不在“能用”而在“可交叉验证”。我遇到过最诡异的问题Charles 显示某个接口返回 200但小程序里wx.request的 success 回调就是不触发。用 Whistle 重放请求也是 200。最后换 Fiddler Everywhere 抓同一台手机的包发现响应头里多了一个X-Wechat-Status: failed。原来微信客户端在收到响应后还会做一层自己的校验比如检查Content-Length是否与 body 长度一致校验失败就静默丢弃响应不通知 JS 层。Charles 和 Whistle 都只抓到 HTTP 层而 Fiddler Everywhere 的解析引擎更贴近微信底层能捕获到这些扩展头。4.1 真机抓包三板斧过滤、重放、对比Fiddler Everywhere 的界面比 Charles 更简洁左侧是会话列表顶部是过滤栏。针对小程序抓包我固定用这三个过滤组合Filter by Process选择WeChat进程iOS 上叫WeChatAndroid 上叫com.tencent.mm。这能瞬间过滤掉所有无关流量只留微信相关请求。Filter by Host输入你的业务域名如api.example.com。避免被微信自身的上报接口report.weixin.qq.com、log.umeng.com淹没。Filter by Result勾选4xx和5xx快速定位失败请求。找到可疑请求后右键 → 「Replay」→ 「Reissue and Edit」就能打开一个编辑窗口随意修改 URL、Method、Header、Body然后点击 Execute 重发。这比在小程序里反复点按钮快得多。特别是调试wx.uploadFile上传一张图片要十几秒而用 Fiddler 重放3 秒就能验证后端是否真的收到了文件。4.2 交叉验证为什么三个工具缺一不可我画过一张三工具能力对比表这是过去两年在 12 个不同项目中踩坑总结出来的能力维度CharlesWhistleFiddler EverywhereHTTPS 解密深度最深支持自定义 CA 信任链重建中等依赖系统证书对部分新 Android 适配差较浅但对微信客户端扩展头识别最好规则灵活性弱仅支持简单域名匹配极强支持正则、上下文、脚本注入弱仅支持基础 Host/Path 过滤真机兼容性iOS 稳Android 需 ADB华为/小米常失败iOS/Android 均稳但需 Node.js 环境iOS/Android 均稳安装即用响应体修改需插件或 Breakpoint 手动改原生支持resBody、resScript等丰富操作仅支持简单文本替换性能开销高长期运行易卡顿中Node.js 进程占用稳定低Electron 应用内存占用最小这张表解释了为什么不能只用一个工具。比如你要调试一个华为手机上的登录失败问题先用 Fiddler Everywhere 快速抓包确认是 401 还是 502如果是 401再用 Whistle 写规则把请求头里的Authorization替换成测试 Token验证是否是鉴权问题如果 Whistle 也失败最后祭出 Charles用 Breakpoint 查看微信是否在发送前就篡改了 header。4.3 排障手册10 个高频问题与三工具协同解法我把日常遇到的抓包问题按发生频率排序给出每个问题的三工具协同解法。这不是清单而是真实的排障链路问题小程序白屏Charles 里看不到任何请求→ 先用 Fiddler Everywhere 过滤WeChat进程看是否有connect类请求。如果没有说明代理没生效如果有connect但无GET/POST说明证书未信任。此时切到 iOS 设置检查「证书信任设置」是否开启。问题抓到请求但响应体是加密的如 base64 或二进制→ 在 Charles 中右键请求 → 「Decode Response」→ 选择gzip或deflate。如果还是乱码大概率是后端做了自定义加密。此时用 Whistle 的resBody规则把响应重写为明文 JSON绕过解密逻辑。问题公众号 H5 页面wx.config失败提示invalid signature→ 用 Fiddler Everywhere 抓取https://mp.weixin.qq.com/cgi-bin/xxx请求复制url参数用在线签名工具生成 signature对比。如果不符用 Whistle 的reqHeaders规则强制注入正确的url和signature。问题wx.uploadFile上传失败Charles 显示 200但小程序回调是 fail→ 用 Fiddler Everywhere 查看响应头找X-Wechat-*扩展头。如果存在X-Wechat-Upload-Status: failed说明微信客户端校验失败。此时检查后端是否返回了Content-Type: text/plain必须是text/plain或application/json并确保Content-Length准确。问题测试环境能通生产环境 403两个环境抓包请求完全一样→ 用 Whistle 的reqHeaders规则给生产环境请求加一个X-Debug: true头让后端在日志里打印更详细的拦截原因。同时用 Charles 的「Map Local」功能把生产接口映射到本地 mock排除网络因素。问题抓包看到请求发出去了但后端 Nginx 日志里没有记录→ 这说明请求没到 Nginx被微信或 CDN 拦截了。用 Fiddler Everywhere 查看请求的最终 destination IP用nslookup查这个 IP 对应的域名确认是否被 CDN 缓存或 WAF 拦截。问题wx.request的 success 回调不触发但 Charles 显示 200→ 用 Fiddler Everywhere 的「Inspectors」→ 「TextView」查看原始响应体确认是否为空或包含不可见字符如 BOM 头。微信对响应体格式极其敏感空格、换行、BOM 都会导致解析失败。问题抓包看到302 Redirect但小程序里没跳转→ 微信wx.request默认不跟随重定向。用 Whistle 的resBody规则把 302 响应直接改成 200并把重定向目标 URL 的内容作为响应体返回。问题同一台手机微信里抓不到包但 Chrome 里能抓到→ 检查微信是否开启了「网络调试」iOS设置 → 辅助功能Android我 → 设置 → 帮助与反馈 → 右上角… → 开发者工具。没开的话微信会直连绕过系统代理。问题抓包工具都配好了但小程序里wx.getNetworkType返回none→ 这是微信的代理检测机制在起作用。它会尝试访问http://www.google.com/generate_204一个返回 204 的 Google 地址来判断网络是否通畅。如果代理服务器无法访问这个地址就会返回none。解决方案用 Whistle 的rules把www.google.com/generate_204映射到http://127.0.0.1:8080/204并让本地服务返回 204。注意所有工具的代理端口不要设为 8080、8000、3000 这些常用端口容易被其他服务占用。我习惯用 8888Charles、8899Whistle、8900Fiddler并在路由器里做端口映射方便多台设备同时调试。5. 排障手册从“抓不到”到“抓得准”的 7 个临门一脚工具装好了规则写完了证书也信任了但问题还没解决别急最后这 7 个“临门一脚”才是决定你能否从“抓包新手”晋级为“问题终结者”的关键。它们不涉及工具本身而是微信生态里那些藏得最深、文档里绝不会写的隐性规则。5.1 微信的“双栈 DNS”机制为什么 hosts 不生效很多开发者习惯用sudo vim /etc/hosts把api.example.com指向测试服务器 IP以为这样就能让小程序走测试环境。结果发现Charles 里抓到的请求Host 还是api.example.com但 destination IP 却是生产服务器的。这是因为微信客户端内置了 DNS 解析模块它优先使用自己的 DNS 服务而不是系统 hosts。验证方法在 Charles 的「Sequence」视图里右键任意请求 → 「Properties」→ 查看Remote IP。如果这个 IP 和你nslookup api.example.com的结果不一致说明微信走了自己的 DNS。解决方案只有两个一是用 Whistle 的hosts规则api.example.com 192.168.1.100它在 HTTP 层做 host 映射绕过 DNS二是用 Charles 的「Tools」→ 「Hosts」功能它会劫持 DNS 查询强制返回指定 IP。后者更底层但需要开启「Enable DNS Spoofing」。5.2 小程序的“请求合并”策略为什么连续两个wx.request只抓到一个包微信为了节省资源会对短时间内相同 URL、相同 Method、相同 Header 的请求做合并。比如你写了两行代码wx.request({ url: /api/user, success: console.log }) wx.request({ url: /api/user, success: console.log })Charles 里可能只看到一个请求。这不是 bug而是微信的优化策略。如果你需要强制分开就在第二个请求的header里加一个唯一字段比如X-Seq: 2。5.3 公众号的“URL 签名缓存”为什么改了 JS 代码wx.config还是失败公众号 JS-SDK 的config接口会对url参数做强缓存。即使你改了页面 URL 的 hash只要url的主干https://mp.example.com/page.html没变微信就会返回缓存的 signature。解决方案在url后面加一个无意义的 query 参数如?t1712345678每次构建时用时间戳确保 URL 唯一。5.4 微信的“证书吊销检查”为什么昨天还能用的证书今天就失效了Charles Proxy CA 证书默认有效期是 10 年但微信客户端会定期检查证书吊销列表CRL。如果 Charles 的证书被加入 CRL比如你重装过 Charles旧证书被标记为吊销微信就会拒绝信任。解决方案在 Charles 中「Help」→ 「SSL Proxying」→ 「Reset Charles Root Certificate」生成新证书并重新在手机上安装。5.5 小程序的“域名白名单”动态加载为什么request域名没配却能发出去小程序request的合法域名不仅在app.json里配置还支持通过wx.reLaunch或wx.navigateTo的url参数动态加载。比如你跳转到https://mp.example.com/page.html?domaindev-api.example.com微信可能会临时将dev-api.example.com加入白名单。这种机制用于灰度发布但也会导致抓包时看到陌生域名。用 Whistle 的log规则* log://console可以记录所有被微信动态加载的域名。5.6 真机的“Wi-Fi 代理优先级”为什么连着公司 Wi-Fi 就抓不到连手机热点就能抓到企业 Wi-Fi 常部署了透明代理或防火墙会拦截或重定向 8888 端口的流量。此时Charles 的代理请求会被公司网关吃掉根本到不了你的电脑。解决方案换手机热点或让 IT 部门放开对应端口。更聪明的做法是用 Whistle 的https规则把代理端口改成 443https://your-pc-ip:443因为 443 端口在企业网里通常不会被拦截。5.7 最后的杀手锏微信官方调试工具weinre当所有代理工具都失效时微信提供了官方的远程调试工具weinre。它不依赖代理而是通过在页面里注入一段 JS 脚本把 DOM、Console、Network 数据实时推送到远程服务器。虽然它不能抓 HTTPS 流量但能看wx.request的调用栈、参数、回调时机。启动命令很简单npm install -g weinre weinre --boundHost 0.0.0.0 --httpPort 8080然后在公众号页面 HTML 的head里加script srchttp://your-pc-ip:8080/target/target-script-min.js#anonymous/script打开http://your-pc-ip:8080/client/#anonymous就能看到实时调试面板。这是我兜底的最后手段成功率 100%。我在实际项目中发现真正卡住开发者的从来不是工具不会用而是不知道“微信在哪个环节悄悄动了手脚”。这 7 个临门一脚每一个都是我在凌晨三点对着抓包日志一行行比对、反复重装微信、甚至反编译 APK 后确认的结论。它们不写在任何官方文档里但却是你从“能抓包”到“敢断言”的最后一道门槛。
