nginx 原生不支持人机验证，但可通过 error_page + 429 触发 js 验证页、结合签名 cookie 实现无后端闭环防护；也可用 ngx_waf 或 openresty 动态路由挑战，关键在 ip/ua/时间/签名四重绑定防复用。
直接在 Nginx 层实现人机验证（如验证码）需要借助外部服务或扩展模块，因为原生 Nginx 不支持生成图形/行为验证码、校验 token 或维护挑战状态。但可以通过轻量级、低侵入的方式把验证环节“前置”到请求处理早期，让自动化脚本卡在验证阶段，而真实用户无感或仅轻微交互。
用 error_page + 429 触发验证页面
这是最实用且无需 Lua 或第三方编译模块的方案。核心是：当请求超过速率阈值时，不直接拒绝（503/429），而是重定向或内嵌返回一个含验证码的 HTML 页面。
- 配置限流区域，例如按 IP 每秒最多 5 个请求：
limit_req_zone $binary_remote_addr zone=cc_limit:10m rate=5r/s; - 在 location 中启用限流，并指定超限时跳转到验证逻辑：
limit_req zone=cc_limit burst=10 nodelay;<br>error_page 429 = @captcha_challenge;
- 定义 @captcha_challenge：返回 Cloudflare Turnstile 或腾讯防水墙等轻量 JS 验证组件的 HTML 片段，不含后端依赖：
location @captcha_challenge {<br> add_header Content-Type "text/html; charset=utf-8";<br> return 200 '<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script><div class="cf-turnstile" data-sitekey="your_key"></div>';<br>}
脚本工具无法执行 JS、无法解析 token、更不会提交验证结果，自然被拦截；真实用户加载页面后完成一次点击即放行（可配合前端自动提交 + 后端校验 cookie 或 header 实现无缝续访）。
结合 Cookie 挑战做二次放行
单纯返回验证码页还不够——得让通过验证的用户后续请求免检。可在验证成功后，由前端 JS 设置一个带签名的 Cookie（如 verified=sha256(ip+ua+ts+secret)），Nginx 在后续请求中校验该 Cookie 是否合法。
- 在 server 块中添加校验逻辑：
if ($cookie_verified = "") { return 429; }<br>if ($cookie_verified !~ "^v[0-9a-f]{64}$") { return 403; } - 搭配
limit_req使用，只对未携带有效 verified cookie 的请求限流：limit_req zone=cc_limit burst=10 nodelay; # 仅作用于未验证用户
这种方式把“验证”和“放行”解耦，不依赖后端服务，Nginx 自身即可完成闭环，适合高并发静态资源或 API 入口防护。
用 ngx_waf 或 OpenResty 实现动态挑战路由
若需更高自由度（比如按 UA、Referer、请求路径差异化触发验证），推荐使用已封装好的模块：
- ngx_waf：开源 Nginx WAF 扩展，支持 CC 防护中配置“验证模式”，命中规则后可返回验证码页或跳转至指定 URL，还支持 IP 封禁、UA 黑名单等；
- OpenResty + lua-resty-challenge：用 Lua 动态生成时间戳签名 challenge、校验前端回传的 hash，甚至集成滑动验证逻辑，灵活性最强，但需部署 Lua 环境。
两者都可做到“首次访问挑战 → 验证通过写可信 Cookie → 后续请求跳过限流”，比纯静态配置更能适应复杂业务场景。
关键不在验证码本身多复杂，而在于让机器无法批量复用验证结果。IP 绑定、时间窗口、UA 关联、Cookie 签名缺一不可，否则攻击者照样能绕过。
