nginx本身不支持js challenge，需借助openresty+lua或反向代理至专用挑战服务实现；其“无感知”指对正常用户延迟极低、无交互提示，但实际仍依赖客户端js执行与后端协同验证。
Js-Challenge 本身并不是 Nginx 原生支持的功能，Nginx 无法直接执行 JavaScript 或向客户端下发 JS 挑战脚本。所谓“在 Nginx 中利用 Js-Challenge 实现无感知抗爬”，实际是指通过 第三方模块（如 nginx-http-js-challenge）或反向代理配合外部服务（如 Cloudflare、自建挑战网关） 来达成类似效果。纯 OpenResty + Lua 可模拟轻量级 JS 挑战，但“无感知”需权衡用户体验与防护强度——真正零感知的 JS 挑战并不存在，只是对正常浏览器用户延迟极低、无交互提示。
依赖 OpenResty + Lua 实现简易 JS 挑战
标准 Nginx 不支持动态生成和校验 JS Challenge，必须升级为 OpenResty（集成了 Lua 和 lua-resty-core 等模块）。核心思路是：首次请求返回一段加密计算逻辑的内联 JS 脚本，客户端执行后回传 token，Nginx（Lua）验证结果有效性。
- 安装 OpenResty，启用
lua_shared_dict存储 challenge nonce 和过期时间 - 用
content_by_lua_block生成带哈希种子、时间戳、简单算术题（如a + b）的 JS 片段，并设置短时 Cookie（如jschid）标识已发挑战 - 后续请求检查 Cookie 和自定义 header（如
X-JS-Token），由 Lua 校验 token 签名与计算结果是否匹配 - 失败则重定向回挑战页或返回 429；成功则写入信任 Cookie（如
jsauth=valid），后续请求跳过挑战
借助 Nginx 作为反向代理对接专业挑战服务
更可靠的方式是让 Nginx 充当透明代理，将疑似机器人流量转发给专用 JS 挑战服务（如自建基于 Express + js-challenge 的网关，或商业 WAF）。
- 用
map指令或 Lua 脚本识别高风险 UA、请求频率、Header 缺失（如Accept-Language、Sec-Ch-Ua）等特征 - 匹配规则后，用
proxy_pass将请求转给挑战服务（例如http://challenge-svc/challenge?r=$request_uri） - 挑战服务返回 HTML+JS 页面，执行后携带解密 token 回调 Nginx 后端或独立验证接口；验证通过则由 Nginx 续发原始请求
- 注意透传真实 IP（
proxy_set_header X-Real-IP $remote_addr），避免挑战服务误判
“无感知”的关键设计细节
所谓无感知，是指普通用户刷新页面或点击链接时几乎无感，不弹窗、不跳转、不中断加载。这依赖于前端自动执行与后端快速协同：
- JS 挑战脚本体积控制在 5KB 内，使用内联 script 避免额外请求；计算逻辑用 Web Crypto API（如
SubtleCrypto.digest）提升可信度 - 首次挑战可配合
fetch()异步提交 token，主页面照常渲染；验证通过后再加载受保护资源（如通过动态src或 API 请求） - 信任状态建议用短期签名 Cookie（如 10 分钟）+ Redis 存储 session，避免被伪造；同时设置
SameSite=Lax和HttpOnly=false以便 JS 读取 - 对已通过挑战的 IP 或 User-Agent，可在 Nginx 层缓存信任标记（
lua_shared_dict），减少重复挑战
注意事项与局限性
JS Challenge 不是银弹，尤其面对高级自动化工具时防护能力有限：
- Puppeteer / Playwright 可无缝执行 JS，绕过基础挑战；需叠加行为分析（鼠标轨迹、Canvas 指纹、WebGL 渲染特征）才能提升门槛
- 搜索引擎爬虫（Googlebot、Bingbot）通常不执行 JS 或禁用 JS，可能被误杀——务必白名单主流爬虫 UA 并放行
/robots.txt、User-Agent匹配请求 - 移动端 WebView、老旧浏览器（IE）、无 JS 环境（curl、wget）会完全失效，需配置 fallback 机制（如验证码入口、限速响应）
- Nginx 层做太多 Lua 处理会影响吞吐量，高并发场景建议将挑战逻辑下沉到边缘节点或专用服务
