静态资源服务集成 Lua 的关键是在 access_by_lua* 阶段前置鉴权等决策逻辑，避免在 content_by_lua_block 中接管响应体而破坏 Nginx 原生 sendfile 高效机制；需结合共享字典缓存、JWT 解析与路径白名单实现轻量校验。
静态资源服务集成 Lua 的关键，不是让 Lua 去读文件或生成内容，而是把鉴权、路由、缓存策略等决策逻辑“前置”到 Nginx 请求生命周期里，在不破坏原生高效机制的前提下注入动态能力。
必须用 access_by_lua* 阶段拦截
静态资源（如 /static/、/images/）通常由 alias 或 try_files 直接服务，性能依赖 sendfile 和 zero-copy。Lua 若放在 content_by_lua_block 里，会接管响应体生成，彻底绕过 Nginx 原生文件发送路径，大幅降低吞吐量。
- 正确做法：在 location 块中使用 access_by_lua_block 或 access_by_lua_file
- 该阶段运行在 rewrite 之后、content 之前，可读取请求变量（如 ngx.var.arg_token、ngx.var.http_authorization），执行校验，但不干预后续文件分发
- 校验失败直接调用 ngx.exit(403) 或 ngx.redirect("/login")；通过则自然进入 alias 指令流程
鉴权逻辑要轻量且可缓存
每次请求都查数据库或远程 API 会拖垮性能。真实场景中应结合共享字典与异步协作：
- 用 lua_shared_dict auth_cache 10m 缓存 token 解析结果或角色映射，设置 TTL（如 5 分钟）
- 解析 JWT 用 lua-resty-jwt 库，纯内存操作，毫秒级完成
- 路径白名单（如 /static/public/**）可硬编码跳过校验，避免无谓开销
- 若需实时状态（如用户被禁用），可在 access 阶段异步触发更新缓存，balancer 或 content 阶段只读缓存
避免影响静态服务的两个典型错误
很多配置看似合理，实则悄悄牺牲了性能：
- 别在 location 中写 content_by_lua_block 输出文件内容 —— 这会让 Nginx 放弃 sendfile，改用 read+write，CPU 和内存压力陡增
- 别用 set_by_lua_block 动态拼接 root 路径 —— root 指令不支持变量，强行用会导致配置加载失败或行为不可控
- 需要多租户隔离路径时，应提前规划好目录结构（如 /static/{tenant}/xxx），用正则 capture 提取 tenant 后做白名单校验，而非运行时拼接
完整示例：带 token 校验的静态资源服务
以下配置实现「有有效 token 才能访问 /static/private/ 下所有资源」：
http {
lua_shared_dict token_cache 5m;
<pre class="brush:php;toolbar:false;">server {
listen 80;
location ^~ /static/private/ {
access_by_lua_block {
local jwt = require "resty.jwt"
local cache = ngx.shared.token_cache
local auth_header = ngx.var.http_authorization
if not auth_header or not string.find(auth_header, "Bearer ") then
return ngx.exit(401)
end
local token = string.sub(auth_header, 8)
local cached = cache:get(token)
if cached == true then
return
end
local jwt_obj = jwt:verify_jwt_obj(token, { secret = "mykey" })
if not jwt_obj.verified then
return ngx.exit(403)
end
cache:set(token, true, 300) -- 缓存5分钟
}
alias /var/www/static/;
expires 1h;
add_header Cache-Control "public";
}
}}
