Nginx Lua模块基于代理与访问头重定向失败问题排查

1. 原生if指令失效的原因 #

你用的$http_x_user_access_flag是Nginx的请求头变量（前缀http_表示从客户端请求头中读取），但你实际要判断的是上游服务返回的响应头拼接后的值，客户端请求里根本不会携带这个头，所以if条件永远不成立，自然不会触发重定向。

2. rewrite_by_lua_block失效的原因 #

rewrite_by_lua_block运行在Nginx的rewrite阶段，这个阶段发生在proxy_pass之前——上游服务还没处理请求，自然没有返回任何响应头，所以ngx.resp.get_headers()根本拿不到X-User-Access-Flag的值，判断逻辑无法触发。

3. header_filter_by_lua_block报错的原因 #

header_filter_by_lua_block运行在响应头过滤阶段，此时Nginx已经开始向客户端发送响应头了。HTTP协议规定，响应状态码必须在响应头之前发送，一旦响应头开始传输，就无法再修改状态码（重定向需要返回3xx状态码），所以此时调用ngx.redirect()会报错，但修改响应头是允许的（因为响应头还在构建/发送过程中，未完全结束）。

既然proxy_pass之后无法再触发重定向，那我们需要提前发起子请求获取上游的保护状态，在主请求的access阶段（权限验证阶段）完成判断和重定向。

具体配置示例 #

假设上游服务有一个轻量接口（比如/api/check-access）可以直接返回用户的保护状态（或者你可以复用原接口，但要避免重复处理业务逻辑），配置如下：

server {
    # 其他基础配置...

    # 在access阶段发起子请求，获取上游的保护状态
    access_by_lua_block {
        local params = ngx.req.get_uri_args()
        -- 如果已经带了limit参数，直接跳过
        if params["limit"] then
            return
        end

        -- 发起子请求到上游的权限校验接口
        local res = ngx.location.capture("/proxy-to-upstream-check", {
            method = ngx.HTTP_GET,
            -- 传递原请求的必要头信息（比如用户身份头）
            headers = ngx.req.get_headers()
        })

        -- 拼接你需要的判断字符串（和原add_header的逻辑一致）
        local userinfo = ngx.var.userinfo -- 假设这个变量已经在之前定义
        local upstream_protection = res.headers["X-Doc-Protection"] or ""
        local user_access_flag = userinfo .. (params["limit"] or "") .. upstream_protection

        -- 判断是否需要重定向
        if user_access_flag == "isprotected" then
            local delimiter = ngx.var.is_args == "" and "?" or "&"
            local new_url = ngx.var.request_uri .. delimiter .. "limit=true"
            return ngx.redirect(new_url, 302)
        end
    }

    # 定义子请求的上游代理
    location /proxy-to-upstream-check {
        internal; # 只允许内部子请求访问，禁止外部直接调用
        proxy_pass http://your-upstream-server/api/check-access; # 替换为你的上游接口
        proxy_pass_request_body off; # 如果是GET请求，不需要传递请求体
        proxy_set_header Content-Length "";
        # 传递原请求的必要头信息
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # 主请求的代理配置
    location / {
        proxy_pass http://your-upstream-server;
        # 原有的add_header配置
        add_header X-User-Access-Flag $userinfo$arg_limit$upstream_http_x_doc_protection;
    }
}

关键说明 #

• access_by_lua_block运行在rewrite之后、proxy_pass之前，此时可以发起子请求获取上游状态，且还能触发重定向（因为响应头还未发送）。
• internal指令确保子请求的location只能被Nginx内部调用，不会暴露给外部用户。
• 如果你的上游接口无法单独提供权限校验，可以复用原接口，但要注意避免重复处理业务逻辑（比如通过传递特殊头让上游跳过复杂处理，只返回权限状态）。

备选方案：使用proxy_intercept_errors配合error_page（仅适用于上游返回特定状态码的场景） #

如果上游服务会针对无权限用户返回特定状态码（比如403），可以用以下配置：

location / {
    proxy_pass http://your-upstream-server;
    proxy_intercept_errors on; # 允许Nginx拦截上游的错误状态码
    error_page 403 = @redirect-to-limited;
    add_header X-User-Access-Flag $userinfo$arg_limit$upstream_http_x_doc_protection;
}

location @redirect-to-limited {
    if ($arg_limit = "") {
        return 302 $scheme://$http_host$uri?limit=true;
    }
    # 如果已经带了limit参数，返回上游的403响应
    return 403;
}

这个方案不需要Lua，适合上游能返回明确错误状态码的场景。

内容的提问来源于stack exchange，提问作者Trouble