Tutorials

使用 Fiddler 检查 CaptchaAI API 流量

自动化 Python 所有 CAPTCHA 类型
作者 CaptchaAI 中文团队
发布时间 May 31, 2026
使用 Fiddler 检查 CaptchaAI API 流量
特色图片不可用

日志里只有一行 ERROR_ZERO_BALANCE，可账户明明有余额；或者 token 提交后一直显示无效，代码却查不出哪里错了——这种时候，光看程序打印的日志远远不够，得直接抓包，看清 in.php 和 res.php 之间到底发生了什么。

Fiddler 会完整记录你的代码和 CaptchaAI API 之间的每一次请求和响应，包括真实的请求体、响应头和耗时，把"服务端到底返回了什么"摆在你眼前，而不是靠猜测。以下场景特别适合直接抓包：API 报错但代码日志信息很少；任务提交后像是卡住了，分不清是网络超时还是服务器没收到；token 注入后一直显示无效，怀疑是内容或编码问题；怀疑请求根本没有经过预期的代理；或者频繁遇到限流，需要看清请求的时间分布和 429 出现的规律。

配置 Fiddler 抓取 HTTPS 流量

第一步：开启 HTTPS 解密

Fiddler 本质上是一个本地代理，用来拦截 HTTPS 流量。要看到 CaptchaAI API 的真实请求体，必须先开启 HTTPS 解密。在 Fiddler Everywhere 中，打开 Settings → HTTPS，启用 "Capture HTTPS traffic"，出现提示时安装 Fiddler 根证书，再到操作系统的证书存储中信任该证书。Fiddler Classic（Windows） 的路径略有不同：进入 Tools → Options → HTTPS，勾选 "Decrypt HTTPS traffic"，然后点击 "Actions" → "Trust Root Certificate"。

第二步：让代码走 Fiddler 的代理

Fiddler 监听在 127.0.0.1:8866（Fiddler Everywhere）或 127.0.0.1:8888（Fiddler Classic）。

Python（requests）：

import requests

proxies = {
    "http": "http://127.0.0.1:8866",
    "https": "http://127.0.0.1:8866",
}

# Submit CAPTCHA task through Fiddler
response = requests.post(
    "https://ocr.captchaai.com/in.php",
    data={
        "key": "YOUR_API_KEY",
        "method": "userrecaptcha",
        "googlekey": "SITE_KEY",
        "pageurl": "https://example.com",
        "json": 1,
    },
    proxies=proxies,
    verify=False,  # Required for Fiddler's self-signed cert
)
print(response.json())

JavaScript（Node.js + axios）：

const axios = require("axios");
const HttpsProxyAgent = require("https-proxy-agent");

const agent = new HttpsProxyAgent("http://127.0.0.1:8866");

async function submitTask() {
  const response = await axios.post(
    "https://ocr.captchaai.com/in.php",
    new URLSearchParams({
      key: "YOUR_API_KEY",
      method: "userrecaptcha",
      googlekey: "SITE_KEY",
      pageurl: "https://example.com",
      json: 1,
    }),
    {
      httpsAgent: agent,
      proxy: false, // Disable axios default proxy handling
    }
  );
  console.log(response.data);
}

submitTask();

注意： verify=False（Python）会关闭对 Fiddler 拦截证书的 SSL 校验，只应在调试阶段使用——上线前务必删除这一行。

如果你的团队在国内网络环境下开发，访问 Google 托管的 reCAPTCHA 相关资源本身就可能不稳定。遇到超时或加载缓慢时，先用 Fiddler 确认到 ocr.captchaai.com 这条链路是否正常，再单独排查 reCAPTCHA 前端资源的连通性——两者的故障原因完全不同，混在一起排查会浪费时间。

只看 CaptchaAI 请求：设置过滤规则

繁忙的会话里请求很多，加一条过滤规则，只留下 CaptchaAI 相关的部分。Fiddler Everywhere 里点击 Filters 选项卡，添加规则 Host → contains → ocr.captchaai.com，再应用过滤器即可。Fiddler Classic 则是点击 Filters 选项卡，勾选 "Use Filters"，在 "Hosts" 下选择 "Show only the following Hosts"，输入 ocr.captchaai.com。设置完成后，会话列表里就只剩 CaptchaAI API 的请求了。

查看请求与响应内容

提交请求 in.php：该看什么

捕获到一次任务提交后，在 Fiddler 里重点检查这几项：Headers 面板中 Content-Type 应为 application/x-www-form-urlencoded；请求体里确认 key、method、googlekey/sitekey、pageurl 都正确；响应体成功时应返回 {"status":1,"request":"TASK_ID"}；响应码 200 代表成功，403 说明密钥有问题，429 则是触发了限流。

轮询请求 res.php：该看什么

轮询结果时，请求体里应有 key、action=get、id=TASK_ID、json=1；响应体在处理中显示 CAPCHA_NOT_READY，成功后变成 {"status":1,"request":"TOKEN"}；两次轮询之间的时间间隔——应保持在 5 秒以上。

常见响应与错误码速查

Fiddler 里看到的现象 说明
请求体里 googlekey 为空 上游页面的 sitekey 提取失败
响应：{"status":0,"request":"ERROR_WRONG_USER_KEY"} API key 无效
响应：{"status":0,"request":"ERROR_ZERO_BALANCE"} 账户余额不足
响应：{"status":0,"request":"ERROR_NO_SLOT_AVAILABLE"} 服务器繁忙——稍后重试
完全没有响应（超时） 网络或代理阻断了连接
429 状态码 请求过于频繁——放慢轮询速度

用断点拦截并修改请求

断点会在请求真正发出前暂停它，让你在发送前修改参数。Fiddler Everywhere 中依次进入 Rules → Add Rule，匹配条件设为 URL contains ocr.captchaai.com/in.php，动作选择 "Pause before sending"。Fiddler Classic 则可以走 Rules → Automatic Breakpoints → Before Requests，或者直接在 QuickExec 输入框里敲 bpu ocr.captchaai.com。

请求暂停时，你可以检查请求体确认所有参数是否正确，修改 method、googlekey 或 pageurl 测试不同取值的效果，点击 "Run to Completion" 放行发送修改后的请求，再查看响应确认改动是否解决了问题。不改代码，只靠断点就能验证某个参数值是不是故障根源，这个方法很省时间。

重放与手动构造请求

一键重放失败请求

请求失败之后，右键点击失败的会话，选择 Replay → Reissue Requests，Fiddler 会用完全相同的请求头和请求体再发一次。需要带着修改重放时，右键选择 Edit in Composer，改好参数后点击 Execute 即可。这样就能在不重启应用的情况下验证修复方案是否有效。

不写代码，直接用 Composer 造请求

用 Fiddler 的 Composer，可以从零构造 CaptchaAI 请求：

提交任务：

POST https://ocr.captchaai.com/in.php
Content-Type: application/x-www-form-urlencoded

key=YOUR_API_KEY&method=userrecaptcha&googlekey=SITE_KEY&pageurl=https://example.com&json=1

轮询结果：

GET https://ocr.captchaai.com/res.php?key=YOUR_API_KEY&action=get&id=TASK_ID&json=1

只是想确认 API 本身是否正常时，这比写代码测试快得多。

性能分析与导出会话

用时间轴定位慢在哪一步

Fiddler 的 Timeline 视图会显示每个请求的耗时构成：DNS 解析正常应在 50ms 以内，超过 500ms 说明 DNS 有问题；TCP 连接正常在 100ms 以内，超过 1000ms 提示网络有问题；TLS 握手正常在 200ms 以内，超过 1000ms 多半是证书相关问题；in.php 的服务器响应正常在 500ms 以内，超过 2000ms 说明服务器拥塞；res.php 的响应正常在 200ms 以内，超过 1000ms 就属于异常，需要检查任务状态。

导出 .har 会话，联系 CaptchaAI 支持

需要把调试数据发给 CaptchaAI 支持团队时，在 Fiddler 中选中相关会话，依次 File → Export Sessions → Selected Sessions，选择 HTTPArchive (.har) 格式导出。导出后先从文件里删除你的 API key，再发送：

Find and replace your actual API key with "REDACTED" in the .har file

抓不到包？先看这份排查表

问题 原因 处理方式
Fiddler 完全没有流量记录 代码没有真正走 Fiddler 的代理 把代理地址设为 127.0.0.1:8866（Everywhere）或 8888（Classic）
SSL 证书报错 Fiddler 根证书未被信任 重新安装 Fiddler 证书，并加入受信任的根证书列表
响应体显示乱码 响应内容被压缩了 打开工具栏里的 "Decode" 按钮（或 Rules → Remove All Encodings）
断点不触发 过滤规则或匹配条件不对 确认 URL 模式与 ocr.captchaai.com 完全匹配
有流量记录，但响应体是空的 Content-Length 不匹配，或是流式响应 点击该会话，等待完整响应加载完毕

常见问题

抓包会不会拖慢验证码识别速度？

几乎不会。Fiddler 因为多了一次本地代理跳转，每个请求大概只增加 1–5 毫秒延迟，相比验证码本身 10–60 秒的识别耗时可以忽略不计。需要注意的是，Fiddler 面板显示的时间戳，是 Fiddler 收到数据的时间，不是你代码发出请求的那一刻——做精确计时分析时要把这个偏差考虑进去。

Fiddler 抓不到任何 CaptchaAI 请求，是哪里没配对？

最常见的原因是代码根本没有走 Fiddler 的代理——先检查 proxies 参数是否正确设成了 127.0.0.1:8866（Fiddler Everywhere）或 8888（Fiddler Classic）。其次确认 Fiddler 的根证书已经安装并加入了受信任的根证书列表，否则 HTTPS 流量不会被解密显示。

浏览器里跑的验证码流程，也能用 Fiddler 看到吗？

可以。把浏览器的代理也指向 Fiddler，就能看到从小部件加载、挑战获取到 token 提交的完整链路，不只是纯 API 调用。这对排查前端和 API 衔接处的问题特别有用。

公司网络访问 Google 相关资源不稳定，会影响用 Fiddler 排查 reCAPTCHA 流量吗？

会。如果本地网络到 Google 托管资源的连通性本身就不稳定，抓包只会如实反映这个连接问题（超时、DNS 解析慢），而不是 CaptchaAI API 的问题。遇到这种情况，先确认 ocr.captchaai.com 这条线路是否正常，再单独排查 reCAPTCHA 前端资源的加载情况，两类问题不要混在一起看。

Fiddler、Charles、mitmproxy 该怎么选？

三者都能做 HTTPS 抓包分析。Fiddler Everywhere 跨平台、界面友好，适合日常调试；Charles 在 macOS 上体验更成熟；mitmproxy 命令行友好，适合写进 CI 脚本做自动化校验。排查 CaptchaAI API 问题时，选团队最熟悉的那一款就够了，抓包的基本原理是一样的。

延伸阅读

下一步

错误信息足够清晰，调试才能快——从 CaptchaAI 开始，等你需要更细粒度的请求级排查时，再打开 Fiddler。

该文章已禁用评论。