在 nginx 中通过 lua 实现动态路由,核心做法是在 location 块中使用 content_by_lua_block 指令执行 lua 代码,利用 openresty 提供的 api 读取请求参数或 header,查询后端服务列表或配置中心,然后调用 ngx.location.capture 发起内部子请求或直接使用 ngx.say 输出响应。这样做可以绕过静态配置,根据请求内容实时决定转发目标或生成动态内容。

如何配置 location 块以启用 Lua 处理逻辑
要在 Nginx 的 location 中运行 Lua 脚本,必须确保 Nginx 编译了 ngx_lua 模块(通常随 OpenResty 提供),并在对应的 location 块中添加 content_by_lua_block。该指令告诉 Nginx 在该位置接收到请求时,暂停标准的静态文件查找或反向代理流程,转而执行嵌入的 Lua 代码块。开发者只需将路由判断逻辑写在花括号内,即可实现对请求的动态控制。

server {
listen 80;
server_name example.com;
# 定义动态路由的 location
location /api/dynamic {
content_by_lua_block {
-- 获取请求中的 service_id 参数
local args = ngx.req.get_uri_args()
local service_id = args["service_id"]
if not service_id then
ngx.status = 400
ngx.say("Missing service_id")
return
end
-- 模拟根据 service_id 查找后端地址
local backend_map = {
["1"] = "http://backend-service-a:8080",
["2"] = "http://backend-service-b:8080"
}
local backend_url = backend_map[service_id]
if not backend_url then
ngx.status = 404
ngx.say("Service not found")
return
end
-- 发起内部子请求到选定的后端
local resp = ngx.location.capture(
"/proxy_target",
{ method = ngx.HTTP_GET, args = ngx.req.get_uri_args() }
)
-- 这里简化处理,实际应转发 resp.body
ngx.say("Routed to: " .. backend_url)
}
}
# 用于内部捕获的目标 location
location = /proxy_target {
internal;
proxy_pass http://localhost:9999;
}
}
上述配置中,/api/dynamic 是入口,content_by_lua_block 负责解析 service_id 并映射到具体后端。若未找到对应服务,直接返回 404;若找到,则通过 ngx.location.capture 将请求转发给内部定义的 /proxy_target,后者再代理到真实后端。这种结构清晰分离了路由逻辑与代理行为。
如何利用 Lua 变量实现基于 Header 的路由决策
除了 URL 参数,Lua 脚本还可以读取 HTTP Header 来实现更灵活的路灰发布或 A/B 测试路由。通过在 content_by_lua_block 中调用 ngx.req.get_headers(),可以获取如 X-User-Type 或 X-Version 等自定义头部信息,并根据这些值决定将请求导向哪个后端集群。这种方式无需修改客户端 URL,仅通过 Header 即可控制流量分发。

server {
listen 80;
server_name example.com;
location /api/versioned {
content_by_lua_block {
local headers = ngx.req.get_headers()
local user_type = headers["X-User-Type"]
local target_backend
if user_type == "beta" then
target_backend = "http://beta-cluster:8080"
else
target_backend = "http://stable-cluster:8080"
end
-- 设置自定义 Header 传递给后端
ngx.header["X-Routed-To"] = target_backend
-- 直接输出响应,模拟路由结果
ngx.say("Routing request for user type '" .. (user_type or "default") .. "' to " .. target_backend)
}
}
}
在此示例中,/api/versioned 位置检查 X-User-Type Header。如果值为 beta,则指向 beta-cluster,否则指向 stable-cluster。脚本通过 ngx.header 设置响应头,告知客户端路由去向,并通过 ngx.say 输出简要信息。这种方法适用于需要基于用户属性或版本标识进行动态分流场景,且完全在 Nginx 层完成,无需额外应用服务器参与路由决策。
当 service_id 不存在于映射表中时程序如何处理
在第一个示例程序中,如果请求携带的 service_id 不在 backend_map 中,程序会进入 if not backend_url then 分支,设置 HTTP 状态码为 404,并通过 ngx.say 输出 "Service not found" 字符串,随后调用 return 终止后续处理。这意味着请求不会转发到任何后端服务,而是直接由 Nginx 返回错误响应给客户端。











