Cloudflare 与人机验证

Readori 不提供通用“绕过”。合法流程是在来源需要时展示真实 WKWebView，让用户完成站点 挑战，然后同步短期 Cookie 并重新执行原请求。

挑战信号检测

判断“这是不是一个人机验证/挑战页”是靠匹配响应体和错误信息里的关键词，不是靠状态码 （很多挑战页本身返回 200）。当前识别的关键词包括（不区分大小写）：

cloudflare、cf-chl、cf-turnstile、challenge-platform、challenges.cloudflare.com
verifying you are human、just a moment、captcha、hcaptcha、ddos-guard
cf_chl_opt、cf_chl_tk、cloudflare ray id、/probe.js

命中任意一个都会把这次请求标记为“需要交互”而不是普通失败；批量验证时这类来源会单独 归类，不会被当成“规则失效”重复重试。写自己的检测逻辑（比如判断某个自建反爬系统）时， 思路一致：挑一两个该挑战页面几乎不会出现在正常响应里的独有字符串，而不是笼统地用 状态码或响应体长度判断。

状态机要求

1. 检测挑战页/登录页信号；
2. 相同 source+challenge 合并，避免重复弹窗；
3. 不同请求 FIFO；
4. 用户完成后检查目标 DOM/URL，而非固定 sleep；
5. 同步 Cookie；
6. 只重试原请求一次或受限次数；
7. 关闭/超时取消精确 waiter。

批量验证中不弹出成百上千个窗口；需要交互的来源单独分类。不得伪造 challenge success、 收集账号密码或把长期 Cookie 写入公共书源。