人机验证

默认策略

01MVP 模板默认不强制开启 CAPTCHA。大多数早期产品先靠接口限流、短信/邮箱频率限制、登录态校验和支付回调签名就够了；没有真实攻击时，不要在登录、发验证码和购买流程前增加等待。

后台提供三个运行模式：

同一时间只会启用一个 provider。选择 Local PoW 时不会加载 Turnstile；选择 Turnstile 时也不会运行 Local PoW。

建议把 Turnstile 当作攻击期和高风险动作的保护，不要当作全站默认门槛。

情况	建议
普通访问、反馈、购买流程正常	不开 Turnstile，保留应用限流
注册、登录、验证码发送开始出现批量失败	只在对应动作开启 Turnstile 或 Local PoW
短信费用异常上涨	降低短信接口限流，同时开启 CAPTCHA
登录撞库明显	登录失败计数、2FA、Cloudflare WAF、CAPTCHA 一起用
全站正在被 L7 攻击	优先 Cloudflare WAF / Under Attack，CAPTCHA 只保护具体动作

中国用户访问 Turnstile 脚本可能感知到额外延迟。面向中国用户的站点，可以平时用 Local PoW 或关闭 CAPTCHA，攻击时再临时切到 Turnstile。

管理员进入 /admin/security，在「登录人机验证」里选择：

后台只保存当前模式，密钥仍通过环境变量配置。未配置密钥的 provider 会显示为不可用，避免误开启后导致登录流程失败。

Local PoW 的作用是让批量请求变贵。前端请求一个短期 challenge，浏览器在 Web Worker 中计算答案，提交表单时把 token 一起发给服务端。服务端验证签名、过期时间、action 和计算难度。

它不是完整风控，也挡不住真人操作或大规模算力，但很适合给注册、登录、短信验证码发送这类入口增加一点批量成本。

默认会复用 BETTER_AUTH_SECRET 签名 challenge。如果你想单独隔离 CAPTCHA secret，可以配置：

CAPTCHA_LOCAL_POW_SECRET=change-me

难度建议在后台 /admin/security 调整，默认值是 10。移动端用户多时保持 10；遇到明显批量攻击时可以临时调到 12，风险解除后再降回来。

如果还没有后台设置，系统会使用下面这个环境变量作为兜底：

CAPTCHA_LOCAL_POW_DIFFICULTY=10
CAPTCHA_LOCAL_POW_TTL_SECONDS=120

Local PoW 只是提高批量请求成本，不应该替代接口限流、审计日志和业务权限校验。

Turnstile 不需要维护额外服务，只要在 Cloudflare 创建站点并配置两个密钥：

TURNSTILE_SECRET_KEY=0x4AAAAAAA...
NEXT_PUBLIC_TURNSTILE_SITE_KEY=0x4AAAAAAA...

可选加固：

TURNSTILE_TIMEOUT_MS=5000
TURNSTILE_ALLOWED_HOSTNAMES=example.com,www.example.com
TURNSTILE_EXPECTED_ACTION=login

TURNSTILE_SECRET_KEY 是服务端密钥，不要暴露给前端，也不要提交到 Git。

Cap 是一个自托管 CAPTCHA 方案，也采用 proof-of-work 思路。它的 Standalone 模式需要你额外部署一个 Cap 服务，通常还要配套 Valkey/Redis，并让网站前端访问这个 Cap 实例。

这对有自托管偏好的团队是可行方案，但对模板读者来说维护成本偏高，所以 01MVP 只在文档中说明，不把 Cap Standalone 接入默认代码路径。

适合考虑 Cap Standalone 的情况：