在自有 QA 中诊断网络质量对 CAPTCHA 的影响

CAPTCHA 求解耗时忽快忽慢，很多团队先怀疑服务商，但瓶颈往往在出口网络。下面是一套可在自有 QA 环境复现的诊断方法。

安全范围： 本指南仅适用于你自有或经授权的 QA、staging 与预发布环境。内容覆盖针对你自己 CAPTCHA 集成的诊断、测试与可观测性模式 — 不涉及第三方站点或未授权流程。

网络质量怎么拖慢 CAPTCHA 求解

出口网络的丢包、抖动与时延会直接影响 CAPTCHA widget 的下发速度和求解耗时。诊断关键是把链路拆开——并行跑 200+ 个任务，分别记录 DNS、TCP 握手、TLS 建连、TTFB 与求解总耗时，而非只看最终耗时这一个数字。测试范围仅限自己的出口网络与 staging 环境。

国内网络访问 reCAPTCHA 的真实情况

reCAPTCHA 依赖 Google 托管脚本，从国内访问时首次 DNS 解析和 TCP 握手常有明显延迟——这跟集成代码本身无关。若 QA 测试机在国内网络，务必单独记录这段链路耗时，否则容易把网络可达性问题误判成求解慢。Cloudflare Turnstile 走 Cloudflare 边缘节点，跨境访问通常更稳定，两者基线耗时不可直接比较。

示例脚本：拆解每个阶段的耗时

下面这段脚本记录了一次 reCAPTCHA v2 求解请求从发起到拿到结果的总耗时，你可以在此基础上插入更细的分段计时。

import os, time, requests
API_KEY = os.environ['CAPTCHAAI_API_KEY']

def measure(sitekey, pageurl):
    t0 = time.time()
    r = requests.post('https://ocr.captchaai.com/in.php', data={
        'key': API_KEY, 'method': 'userrecaptcha',
        'googlekey': sitekey, 'pageurl': pageurl, 'json': 1,
    }).json()
    return time.time() - t0, r

在 QA backend 校验 token，怎么解读结果

拿到 token 后在自己的 endpoint 上完成校验，记录端到端耗时与 backend 状态码，确认波动出在网络链路还是 backend 处理。数字仅供参考，会随 CAPTCHA 类型、地区与负载变化。

常见问题排查

可观测性与检查清单

为每次 QA 运行生成结构化日志：token 耗时、HTTP 响应码、任务编号、队列深度。用 OpenTelemetry 以 correlation id 关联各段耗时，凭一个 id 重放场景，排查时间能减半。落地前请确认：

• 测试范围限定在自己的应用或经授权的资源。
• CaptchaAI key 存放在 CI secret 或 vault，不进代码库。
• 记录调用耗时与状态码，为瞬时错误配置带上限的幂等重试。

示例 QA 调用

下面是在自己的 staging 环境里，用 CaptchaAI 测试一个 CAPTCHA widget 的最小可用流程。

import os
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # 例如 https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']


def submit_qa_recaptcha() -> str:
    payload = {
        'clientKey': API_KEY,
        'task': {
            'type': 'NoCaptchaTaskProxyless',
            'websiteURL': QA_PAGE_URL,
            'websiteKey': QA_SITE_KEY,
        },
    }
    response = requests.post(
        'https://api.captchaai.com/createTask',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()['taskId']


def fetch_qa_result(task_id: str) -> dict:
    payload = {'clientKey': API_KEY, 'taskId': task_id}
    response = requests.post(
        'https://api.captchaai.com/getTaskResult',
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

常见问题

国内网络下，CAPTCHA 求解为什么经常更慢？

reCAPTCHA 的 Google 脚本从国内访问时首次 DNS 解析和握手容易变慢，属于网络可达性问题，不是求解耗时。建议单独记录链路耗时，再和求解耗时对比。

这套诊断流程会接触生产流量吗？

不会。示例假设 staging.example.com 或你自己的 QA 域名，请在 staging 副本里复现生产配置。

遇到瞬时错误应该怎么重试？

用带上限的指数退避做幂等重试，比如 1s、2s、4s。网络错误、5xx 和 ERROR_NO_SLOT_AVAILABLE 适合重试；持久性鉴权错误不应重试。

安全相关指南

• CaptchaAI 快速入门
• 授权 CAPTCHA QA 测试
• 自有表单的 endpoint 测试
• 浏览器失败但 API 通过的排查

在自己的环境里用 CaptchaAI 验证你的 CAPTCHA 集成。