页面能打开、验证过不去，跟网速几乎无关。Cloudflare 的验证是一次判定，不是一次下载：它看你的出口 IP 信誉、看请求链路是否前后一致、看浏览器环境能不能正常跑完那段脚本。任何一环对不上，你就会看到勾选框转圈不停、Verifying you are human 不结束、刷新回到验证页，或者刚进对话几分钟又被弹回来。
这篇只讲网页端人机验证循环这一个症状。地区限制、unsupported_country 那类报错另见国内访问 ChatGPT；账号侧的 unusual activity、要求手机验证、账号被限制，属于风控处置，见AI 账号风控与出口 IP；网站整体打不开走开了代理网站打不开。本文不涉及任何绕过验证的手段。
先分清你看到的是哪一种验证
两种界面成因不完全一样，判读方式也不同。整页验证会占满窗口，文案通常是「Verifying you are human. This may take a few seconds.」，下面带一个错误码和 Ray ID；这是站点级的 Challenge Page，验证通过后会发一张 clearance cookie。嵌在页面里的小组件是 Turnstile，状态依次为「Verify you are human」→「Verifying...」→「Success!」，登录、注册、发消息这些动作前后最常出现。
页面上的错误码和 Ray ID 别急着关掉。Cloudflare 在 2026 年改版后把详细说明收进了页面里的排错弹窗，点开能看到具体是哪一类失败——比如设备时间不正确这种，弹窗会直接告诉你「必须把设备设为所在时区的正确日期与时间」。先读这句，比盲目换节点省时间。
四层成因，各有各的判断依据
| 层 | 典型表现 | 怎么判断 |
|---|---|---|
| 出口 IP 信誉 | 同一节点每次都要验证，且所有 Cloudflare 站点都要验证 | 换一个出口人少的节点，症状立刻缓解 |
| 验证中途 IP 跳变 | 点了勾选框，转一下又回到验证页；反复无数次 | 连续查 trace，出口 IP 不止一个 |
| DNS / TLS 链路 | 只有部分 AI 站要验证，其它站正常 | 域名解析结果与实际出口不一致 |
| 浏览器环境 | 换个浏览器或无痕窗口立刻正常 | 关扩展、对时、放行 cookie 后恢复 |
顺序不能颠倒。出口 IP 信誉是最常见的那一层：数据中心 IP 段、被几十个人共用的机场节点、历史上被拿去爬过数据的地址，落到判定引擎手里天然分数低。这类 IP 上你能做的很有限——不是把浏览器擦干净就能救回来，只能换出口。
验证中途 IP 跳变：最容易被忽略的那一层
验证的发起和提交必须来自同一个出口 IP。Cloudflare 官方文档把这点写得很直接：如果 Managed Challenge 的提交请求来自与下发时不同的 IP，这次提交无效，你可能会遇到验证循环（How Challenges work）。这一句解释了大量「点了半天点不过去」的案例：不是你点得不对，是提交时的身份已经换人了。
代理客户端制造这个条件太容易了，而且有两条不同的路径。一条是时间上的：
url-test 按间隔定时测速、fallback 在探测失败时顺位换人，只要这次探测赶在验证进行中，出口就在你点勾选框和结果回传之间换了；load-balance 更直接，本来就把不同连接摊到不同节点。这几种组的行为差异和该怎么配，见出口 IP 与账号风控。
另一条是空间上的，也更隐蔽：一次验证从来不只有一个请求。整页验证要拉脚本、回传结果、再重定向回原页面；Turnstile 组件的脚本来自 challenges.cloudflare.com，这个域名和 chatgpt.com、claude.ai 不是同一个后缀，按域名写的分流规则不会顺带把它带上。于是页面主体走了 A 节点、验证脚本走了 B 节点——你的出口 IP 一次都没「变」，但下发和提交确实来自两个地址，结果一样是循环。这也解释了为什么有人明明锁了单节点还是过不去：锁的是主站，没锁验证域名。
除了 IP，clearance 的有效性还和 User-Agent、TLS 指纹这类客户端特征绑在一起。这一层不是官方文档写明的，但方向一致：判定引擎认的是「解出验证的那个客户端」，不只是那个 IP。实践里的后果很具体——中途改 UA、伪装浏览器指纹，跟换 IP 是同一类破坏，下面浏览器那节会单独说。
五分钟判读：出口到底稳不稳
先做最有信息量的一步，把代理组临时改成手动选择、固定一个节点，然后在终端里连续查出口：
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E "^(ip|loc|sni)="
for i in 1 2 3 4 5 6; do
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep "^ip="
sleep 2
done判读标准很清楚：六次返回同一个 ip=，出口稳定，验证循环大概率不是跳变引起的，往 IP 信誉或浏览器那层走；出现两个及以上不同 IP，先修配置，别急着清 cookie。loc= 顺手告诉你出口落地在哪个国家，sni=encrypted 说明这条连接协商了 ECH。
再看一次响应头，确认这次到底是被下发了验证还是压根没通：
curl -sI https://chatgpt.com | grep -iE "cf-ray|cf-mitigated|^HTTP"出现 cf-mitigated: challenge，说明链路是通的、只是被要求验证，这时候去查节点延迟毫无意义。完全没有响应、或者超时，那是另一类故障，回到打不开网站那条路。
还有一个廉价的二分，两分钟能做完：用同一个节点、同一个浏览器，去访问几个别的也在 Cloudflare 后面的站点。所有站都要验证，问题在出口 IP 本身，这个节点的信誉分已经低到普遍触发验证，换出口是唯一有效动作；只有 AI 站要验证，说明出口没到黑名单级别，是这些站点自己的策略更严，换节点仍有收益，而且换同地区的另一个就够；换个浏览器或无痕窗口就好，问题在浏览器环境，跟节点完全无关，继续换节点是白费时间。
这三条结论对应三套完全不同的动作，所以别跳过这一步。很多人的一下午就消耗在「明明是扩展的问题、却在换第十五个节点」上。
Clash Verge 侧：验证域名必须和主站同组
怎么建一个固定出口的手动组、怎么用覆写让它不被订阅冲掉，出口 IP 与账号风控那篇已经写完，这里不重复。针对验证循环，要额外补的是域名清单本身——大多数人只把主站域名指进了固定组，页面主体和验证组件因此从两个出口出去。把下面这几行放进订阅右键的「编辑规则」prepend 区：
# 验证组件的宿主，Turnstile 脚本从这里加载
- DOMAIN-SUFFIX,challenges.cloudflare.com,AI-Fixed
# 页面主体与静态资源，缺一个就可能分流到别处
- DOMAIN-SUFFIX,chatgpt.com,AI-Fixed
- DOMAIN-SUFFIX,oaistatic.com,AI-Fixed
- DOMAIN-SUFFIX,oaiusercontent.com,AI-Fixed
- DOMAIN-SUFFIX,claude.ai,AI-Fixed
- DOMAIN-SUFFIX,claudeusercontent.com,AI-Fixed
challenges.cloudflare.com 是这份清单里最关键的一行。整页验证和 Turnstile 组件的脚本都从它加载，验证结果也从这条链路回传；它跟 chatgpt.com、claude.ai 不是同一个后缀，任何按域名分流的配置都不会顺带把它带过去。写完之后别忘了两件事：规则要排在订阅自带的大规则之前，否则匹配不到；老连接不会自己迁移，退出浏览器重开，或者在连接页把相关连接断掉，再刷验证页。
另一个常被忽略的细节是后台探测。验证进行中如果正好赶上一次定时测速，出口就可能被换掉。排验证问题时把这条链路上的自动切换关掉，或者至少把探测间隔放长、开 lazy: true 让空闲时不主动测速——只测你要用的那个组。
DNS 在这一题里只需要满足一个条件：解析结果和实际出口别打架。开着 fake-ip 时域名由 Clash 内部处理，通常没有额外问题；真正会出事的是系统 DNS、浏览器 DoH、Clash DNS 三条路同时开着，浏览器自己拿到一组 IP、Clash 又按另一套解析选路。排错期间只留一条路径，改完再逐个恢复。细节见fake-ip 与 DNS 和DNS 配置。
Tun 与系统代理的差别不是「谁更强」，是影响范围。只想让浏览器过验证，系统代理加固定节点的路径最短，出问题也最容易定位：浏览器的请求全从混合端口出去，一个组就管完了。Tun 接管整机，好处是桌面客户端一起进隧道（Claude Desktop 的情况见Claude.ai 与 Desktop），代价是命中面变大——同一批域名如果分散命中了不同的组，出口不一致的概率反而更高。Tun 下先在连接页确认这几个域名走的是同一个节点，再去怀疑 Cloudflare。基础说明见Tun 模式。
浏览器侧：能救回来的那部分
出口稳定了还在循环，才轮到这一层，而且它有明确的自查顺序。先开无痕窗口：无痕正常、常规窗口循环，问题在扩展或站点数据，不用继续猜。再对系统时间：设备时间偏几分钟就足以让验证令牌被判定过期，把「自动设置时间」关掉再打开是最快的修法。然后放行 cookie：clearance 记在 cookie 上，站点被禁 cookie、或者跨站 cookie 被全局拦掉，验证就永远存不下来，表现正是通过后立刻回到验证页。
扩展要挑着关。Cloudflare 明确说过，修改浏览器 User-Agent 值、或者改动 Canvas、WebGL 这类 Web API 的扩展不受支持——UA Switcher、CanvasBlocker、各种「反指纹」插件都在这一类里，社区里被反复确认为循环元凶。广告拦截和隐私扩展则可能直接拦掉验证脚本。另外别叠代理：浏览器里再挂一个 VPN 扩展，出口就变成两层，跳变概率翻倍。
清数据只清这一个站点就够，不用把整个浏览历史清空。地址栏左侧的锁图标里能进到该站点的 cookie 与站点数据，删完关掉标签页重开——别在同一个已经拿着坏 cookie 的页面上反复刷新，那个页面手里的状态本身就是坏的。
另外两个偶发但真实的原因。企业设备上的家长控制类软件、安全套件会做 HTTPS 拆包，改动 TLS 层的特征，表现和指纹插件一样；这类情况下把浏览器换掉没用，得先临时排除那个软件再对照。还有验证页被中间设备缓存的情况——你拿到的是一张过期的验证页，怎么点都不会通过，硬刷新（绕过缓存重载）比清 cookie 更对症。
边界：这篇不做的事
不教绕过人机验证，也不推荐任何自动过验证的插件、脚本或打码服务。那些方案的共同点是伪装成另一个客户端，一旦被识别，代价从更严格的验证一直到账号受限，而且第三方指纹伪装工具本身经常带恶意代码。
能做的事在另一侧：让出口固定、让浏览器环境正常、让请求链路前后一致，把「正常用户被误判」的概率降下来。反复试了三个不同地区的节点仍然过不去，就停手——那说明当前订阅的出口质量到顶了，换源或换节点组比继续拧开关有用，选源见怎么选机场、节点测速。客户端从下载中心获取。