Cloudflare 挑战页（5 秒盾）

Cloudflare 挑战页（5 秒盾） 是 Cloudflare 的反爬平台挑战（整页拦截）。整页被挡住，显示「正在检查您的浏览器…」或一个 Managed Challenge 界面，底部有一串 Ray ID。等几秒后自动跳转到目标页面 —— 「5 秒盾」这个俗称就是这么来的。**它挡的是整个页面，不是表单里的某个组件。**

也叫 5 秒盾（中文圈对 Cloudflare 挑战页的通称）。调用时 type 一律传 cloudflare_challenge。

正在查询可用性…$1.81 / 1K 次按成功计费，失败退款

接口规格

项目	值
type	`cloudflare_challenge`
必填参数	`website_urlproxy`
可选参数	`user_agent`
返回	一串 Cookie（`solution.cookie`）
怎么用这个解	带回请求的 Cookie 串（含 `cf_clearance`）
价格	$1.81 / 1K 次 —— 按成功计费，没解出来退款
厂商文档	Cloudflare 官方文档

参数去页面哪里取

下面全部是可以直接照做的定位方法 —— DOM 属性名、JS 全局变量名、script 上的 query 参数。

必填 website_url + proxy，可选 user_agent。不需要你去扒挑战脚本。

怎么确认是 Cloudflare 挑战

两个 Cookie（官方文档 Cloudflare Cookies 页）：

document.cookie.split('; ').filter(c => /^(cf_clearance|__cf_bm)=/.test(c))

· `cf_clearance` —— 通过挑战的凭证，这就是我们交付给你的东西。
官方标注它以 SameSite=None; Secure; Partitioned 下发。
· `__cf_bm` —— Bot Management / Bot Fight Mode 的评分 Cookie，
官方明写「expires after 30 minutes of continuous inactivity」。
再看响应头有没有 cf-ray 与 server: cloudflare。

⚠ 为什么 `proxy` 和 `user_agent` 都要一致

凭证同时绑定出口 IP 和 UA —— 任一不同，目标站会重新拦你。所以 proxy 必须是你后续要用的那个出口，user_agent 传了就要一直用它。

调用示例

一个端点解全部验证码类型 —— 换一种验证码只改 type 这一个字段。

请求

curl -X POST https://api.everyinfra.com/api/v1/captcha \  -H "Authorization: Bearer omg_你的KEY" \  -H "Content-Type: application/json" \  -d '{"type":"cloudflare_challenge","website_url":"<website_url>","proxy":"<proxy>"}'

响应

{  "solution": {    "cookie": "…"  },  "billing": { "charged": true, "credits": 130 }}

怎么确认目标站用的就是它

Cloudflare 边缘判定风险后返回挑战页，浏览器跑完 JS 检测（Cloudflare 官方称为 JavaScript detections）后拿到 **`cf_clearance`** Cookie。官方对它的描述是「stores the proof of challenge passed. It is used to no longer issue a challenge if present. **It is required to reach an origin server.**」—— 也就是说没有这个 Cookie 就到不了源站。

容易搞混的

⚠⚠ 与 Cloudflare Turnstile 不是一回事，这是中文圈最常见的混淆。 Turnstile 是站点主动放进表单里的小组件、交付一个 cf-turnstile-response token（type 传 turnstile）；这一条是 Cloudflare 在整页前面拦截、交付 cf_clearance Cookie（type 传 cloudflare_challenge）。官方文档也把两者分得很清楚：前者是应用层的一次性 token 需要你自己校验，后者是边缘 Cookie、对客户应用透明。判据：页面是整页被挡，还是表单里多了个组件。

去看 Cloudflare Turnstile 那一条 →

常见部署场景

任何开了 Cloudflare 且启用了 Bot Fight Mode / WAF 挑战规则的站点（覆盖面极广）
被攻击或被大量抓取后临时开启防护的站点
按地区、按 ASN、按 User-Agent 触发规则的站点 —— 同一个页面换个出口就可能不出现挑战

已知的坑

产出同时绑定出口 IP 和 UA，两者任一变了都要重新解。这是这条能力最常见的失败原因。

`__cf_bm` 30 分钟无活动就过期（官方数字），长时间空闲的会话要重新走一遍。

同一个 URL 换个出口可能根本不出现挑战 —— 挑战是按规则触发的，不是页面固有属性。所以「我这里能打开」不代表对方没上防护。

站点未启用 HTTPS 时，官方提示 cf_clearance 可能出问题。

产出绑定求解时的出口 IP 和 UA —— 两者任一不同，目标站都会重新拦你。所以 proxy 必须是你自己后续要用的那个出口

这条和 Turnstile 不是一回事：Turnstile 是页面里的小组件、交付 token；这条是整页拦截的 5 秒盾、交付 Cookie

常见问题