先说结论：Turnstile 是嵌在网页里的人机验证组件，保护的是某个表单或操作；“5秒盾”是 Cloudflare 在边缘网络拦在整个网页前面的质询页，保护的是整站或指定路径的访问。 Turnstile 通过后产出一个 token，网站后端必须拿它去 Cloudflare 校验；5秒盾通过后，Cloudflare 边缘节点直接写入 cf_clearance Cookie，源站不需要写任何校验代码。
两者经常被统称为“Cloudflare 验证”。在排障或做自动化时把它们混为一谈，最常见的后果就是选错处理方式：明明遇到的是整页拦截，却去找 sitekey 拿 token，拿到了也没地方用。
“5秒盾”具体指什么
“5秒盾”是国内的俗称，来源于 Cloudflare 早期 I'm Under Attack Mode 的等待页：访客打开网站时先看到“正在检查浏览器”，大约等几秒后才跳转到真实页面。
现在 Cloudflare 的整页质询更多由 WAF 规则、Bot 防护等触发，以 Managed Challenge 等质询页（Challenge Pages）的形式出现；Under Attack mode 依然存在，开启后会对所有访客显示质询。所以今天说的“5秒盾”并不一定真要等 5 秒：有时一闪而过，有时需要勾选复选框，有时会反复出现。它的本质没变，还是 在访客拿到网页内容之前做的一次边缘层检查。
核心差异对照
| 维度 | Turnstile | 5秒盾（整页质询） |
|---|---|---|
| 防护层级 | 页面内组件 | Cloudflare 边缘网关 |
| 触发时机 | 页面已正常加载，在登录、注册、提交等操作时触发 | 请求到达源站之前，拿不到页面 HTML |
| 呈现方式 | 页面里的小部件，可以是可见复选框、非交互模式或不可见模式 | 全屏过渡页，网站原有内容和导航都看不到 |
| 通过后的凭证 | 短效 token（表单字段通常是 cf-turnstile-response） | cf_clearance Cookie |
| 谁来校验 | 网站自己的后端调用 Siteverify API | Cloudflare 边缘节点自行判断并放行 |
| 是否依赖 Cloudflare 代理 | 不需要，没接 Cloudflare CDN 的网站也能用 | 需要，站点必须由 Cloudflare 代理 |
凭证机制：差异最大、也最容易出错的地方
Turnstile 的 token 是“一次性门票”。 前端组件完成验证后生成 token，随表单一起提交。按 Cloudflare 文档，token 有效期为 300 秒，而且只能校验一次。网站后端要把它发到 Siteverify 接口（https://challenges.cloudflare.com/turnstile/v0/siteverify），根据返回结果决定是否接受这次提交。这带来两个实际影响：
- 网站后端没有做 Siteverify 校验的话，Turnstile 实际上起不到保护作用。自有站点排障时应该先检查这一点。
- token 过期或已经用过都会校验失败。对自动化来说，拿到 token 后要尽快提交，不能缓存下来重复使用。
5秒盾的 Cookie 是“会话通行证”。 质询通过后，Cloudflare 在响应里写入 cf_clearance，之后同一会话的请求带着它就会被边缘直接放行。它和发起请求的访客环境相关联：Cloudflare 文档要求质询由发起请求的同一访客环境完成。如果后续请求换了出口 IP、User-Agent，或者丢了 Cookie，就可能被再次质询，也就是常说的 challenge loop（质询死循环）。
现场怎么判断遇到的是哪一种
按下面的顺序检查，一般一两分钟就能分清：
- 能不能看到网站原本的内容？ 页面、导航都在，只有表单旁边多了一个验证框，基本就是 Turnstile。整个页面被替换成等待或验证界面，就是整页质询。
- 看第一个 HTML 响应。 整页质询的响应状态码常见 403 或 503，页面标题常见“Just a moment...”，请求参数里也常能看到
__cf_chl前缀。Turnstile 页面的主响应一般是正常的 200，页面中会加载challenges.cloudflare.com/turnstile/v0/api.js，并在元素上带有data-sitekey。 - 看通过后得到了什么。 表单里多出
cf-turnstile-response字段的是 Turnstile；浏览器里多出cf_clearanceCookie、随后自动跳转到真实页面的是整页质询。
有一个陷阱要注意：整页质询页里也可能出现一个“确认您是真人”的复选框，外观和 Turnstile 很像。 所以不能只凭复选框判断，要结合第 1、2 步看它是不是出现在目标页面内部。另外，同一个网站也可能两者都有，例如先过一次整页质询，进入登录页后再遇到 Turnstile。这时要分成两个环节分别处理。
对测试和自动化的不同影响
自有站点的 QA：优先用官方机制
在自己的站点上跑 CI 回归时，多数情况下用不到付费识别服务：
- Turnstile：Cloudflare 提供测试用的 sitekey 和 secret（例如固定通过、固定失败），测试环境换上这些密钥，就能稳定覆盖通过和失败两条分支。
- 整页质询：可以在 Cloudflare 里给测试流量配置跳过规则，或者测试环境不开 Under Attack mode，这比在 CI 里处理质询要稳定得多。
只有需要做接近生产的真实联调，或者在获授权的公开数据工作流里处理对方站点的验证时，才需要考虑外部识别服务。
真实联调时两者的任务完全不同
处理 Turnstile，核心输入是页面的 sitekey 和页面 URL，有时还有 action、cData 等参数。识别服务返回的是 token，你需要在有效期内把它回填到表单并提交。最终是否被接受，由目标站点后端的 Siteverify 结果决定。
处理整页质询，目标不是拿到一个可以回填的字符串，而是 在同一会话中拿到 cf_clearance 并用它继续访问。所以代理出口、User-Agent 等环境信息要和后续请求保持一致，Cookie 也要在后续请求中持续携带。很多“拿到了 Cookie 还是被拦”的问题，根源是环境前后不一致，不一定是识别环节失败。
无论哪种，都要把三个结果分开统计：识别服务返回了结果、目标站点接受了结果、业务流程真正完成了。 只看第一项，很容易误判整条链路的可用性。
在 NexCaptcha 中如何对应
NexCaptcha 官网把 Cloudflare Turnstile 和 Cloudflare Challenge 列为两类不同的支持类型，统一走任务模式：用 createTask 提交任务，再通过 getTaskResult 轮询或 webhook 回调取结果。接入前先按上面的方法确认目标页面属于哪一类，再按官网当前说明逐项核对对应的任务类型名称和必填参数。对整页质询，还要确认代理、UA 等参数要怎样和后续请求保持一致。
正式切量之前，建议用小流量跑一轮对照，分别记录返回率、目标站点接受率和业务完成率，同时关注延迟分布。具体的评估方法可以参考验证码识别 API 怎么选：从类型核对到小流量对照的六步判断。支持类型、价格和工程师联系方式见 NexCaptcha 官网。
