Nginx结合Lua实现动态鉴权静态分发，核心是在access_by_lua阶段拦截校验权限（如token、角色、路径），通过则放行至alias/proxy_pass，否则返回403/401；须用OpenResty、避免content_by_lua破坏zero-copy性能，并采用异步cosocket、共享字典缓存等保障高并发安全高效。
利用 Nginx 结合 Lua 实现动态鉴权后的静态资源分发，核心在于：在请求到达静态文件前，用 Lua 拦截并校验权限（如 token、角色、路径白名单等），校验通过则放行至本地或代理的静态服务，否则返回 403 或跳转。关键不是“加个 Lua 脚本”，而是把鉴权逻辑嵌入 Nginx 请求生命周期的正确阶段，并确保不破坏静态文件的高效处理特性。
1. 确保环境支持：OpenResty 是首选
Nginx 官方版不内置 Lua 支持，需使用 OpenResty（基于 Nginx + LuaJIT + 大量 Lua 库的发行版）。安装后可通过 nginx -V 2>&1 | grep -o with-http-lua-module 验证模块存在。
- 避免手动编译 nginx + lua-nginx-module，易出兼容问题
- 推荐使用 OpenResty 官方包（deb/rpm）或 Docker 镜像
openresty/openresty:alpine - Lua 脚本默认放在
/usr/local/openresty/nginx/lua/或自定义目录，需在配置中用lua_package_path声明
2. 在 access_by_lua* 阶段执行鉴权逻辑
静态资源分发通常走 location /static/ 这类路径。鉴权必须发生在内容处理前，且不能影响 Nginx 的 zero-copy 文件发送能力，因此应使用 access_by_lua_block 或 access_by_lua_file —— 它运行在 access phase，早于 content phase（即 try_files、alias 等指令执行前）。
- 不要用
content_by_lua*：会接管响应体生成，丧失 Nginx 原生 sendfile 高效性 - 示例片段：
location /static/ { access_by_lua_block { local jwt = require "resty.jwt" local auth = require "my_auth_module" <pre class='brush:php;toolbar:false;'> if not auth.check_access(ngx.var.uri, ngx.var.http_authorization) then ngx.exit(403) end } alias /var/www/static/; expires 1h; add_header X-Content-From "Nginx+Lua";}
- 鉴权函数建议分离为独立 Lua 文件（如
lua/auth.lua），便于复用和测试
3. 鉴权逻辑设计要点
动态鉴权不是简单比对密码，需兼顾安全性、性能与可维护性：
-
Token 解析与校验：优先用
resty-jwt验签、检查 exp、aud；避免手写 base64 解码或硬编码密钥 -
权限上下文缓存：若从 Redis 查询用户角色，用
resty-lock防击穿，用lua_shared_dict缓存高频权限（如接口级白名单），TTL 控制在秒级 -
路径级细粒度控制：例如
/static/reports/只允许 admin，/static/public/免鉴权 —— 可在 Lua 中用string.match或前缀表匹配 - 拒绝时保持语义清晰：401（未认证）、403（已认证但无权）、404（隐藏资源存在性）按场景返回，勿全用 403
4. 静态资源路径与性能兼顾
鉴权通过后，仍要让 Nginx 以最优方式服务文件：
- 继续使用
alias或root+try_files，不改用content_by_lua*读文件再输出 - 开启
sendfile on、tcp_nopush on、tcp_nodelay on等内核级优化 - 大文件（如视频）可配合
lua-resty-sendfile实现断点续传支持，但普通静态资源无需介入 - 若静态资源在远端（如对象存储），鉴权后用
proxy_pass转发，并设置proxy_cache减轻源站压力
不复杂但容易忽略：鉴权脚本里的任何阻塞操作（如同步 HTTP 请求、未设 timeout 的 Redis 查询）都会拖垮整个 Nginx worker。务必用 cosocket 异步调用，设好超时与降级策略。
