在 Nginx 的 ngx_http_proxy_module 的使用说明中,有对 X-Accel-Redirect 的描述:

“X-Accel-Redirect” performs an internal redirect to the specified URI;

本文就简单的描述一下在某种特殊场景下 X-Accel-Redirect 的使用。

需求

在实际业务中,需求是在一堆限制条件中,达到某个目的。我这里将复杂的业务特性都去掉,最简化的描述一下。

  1. 有个前端 OpenResty 服务,称为 A,一个后段 OpenResty 服务,称为 B。请求从 A 代理到 B。
  2. 一般情况下,请求在服务 A 中的访问日志,记录在正常日志文件 logs/access.log 里。
  3. 如果后端服务 B 响应为 403,且包含了一个值为 1 的特定的响应头 Invalid-Domain,则该请求在服务 A 中的访问日志,记录在特定日志文件 logs/invalid_domain.log 里。

这里面有一个需要注意的地方:

后端服务 B,其响应 403 的时候,有两种情况,一种是根据业务逻辑,包含值为 1 的特定的响应头 Invalid-Domain,而其他情况的 403 响应中会添加一些其他的正常的响应头,在通过 A 访问时,这些正常的头部不能有缺失。

方案一

最简单的实现方式,是在服务 A 中使用 error_page,最简化的完整配置如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
events {
}

http {
    # 模拟 后端服务 Server B, 这里为了简化, 让其永远返回 403.
    # 在请求带了参数 invalid_domain 为 1 时, 添加额外的响应头 Invalid-Domain.
    # 其他情况下, 添加响应头 Valid-Domain.
    server {
        listen 8081;
        location / {
            access_log logs/server_b.log;
            header_filter_by_lua_block {
                if ngx.var.arg_invalid_domain == "1" then
                    ngx.header["Invalid-Domain"] = "1"
                else
                    ngx.header["Valid-Domain"] = "1"
                end
                ngx.exit(403)
            }
        }
    }

    # 模拟前端服务 Server A.
    server {
        listen 8082;
        access_log logs/access.log;
        location / {
            proxy_pass http://127.0.0.1:8081;
            proxy_intercept_errors on;
            error_page 403 = @check_invalid_domain;
        }
        location @check_invalid_domain {
            internal;
            if ($upstream_http_invalid_domain = "1") {
                access_log logs/invalid_domain.log;
            }
            return 403;
        }
    }
}

分别使用参数 invalid_domain=1 和不带参数去访问服务 A,会发现访问日志的生效是满足需求的。但有一个容易忽略的地方:当不带参数访问时,后端服务 B 的响应头 Valid-Domain 由于 error_page 带来的内部跳转被去掉了。

这看起来不是什么大事,但我这份配置只是为了演示而极端简化过的,在实际业务中,Valid-Domain 头代表着复杂各异的定制化需求,被去掉是肯定不行的。

问题的焦点,在于我们要同时判断后端响应头和响应状态码,但 error_page 指令中无法对响应头进行组合逻辑判断,所以需要到 error_page 目标 location 中做进一步判断,于是就导致了我们上面说的正常 403 时响应头 Valid-Domain 头的丢失。

方案二

我们再来梳理一下逻辑,看看解决问题的思路。

首先,响应 403 且带有 Invalid-Domain=1 响应头的请求,因为要定制化 log 路径,是需要一个内部跳转到一个新的 location 中去的,即 location @check_invalid_domain 是必须要引入的。可能有人会说,直接用 if 条件组合来定制 access_log 是不是也可以。第一,我个人非常不喜欢 Nginx 的 if 指令,甚至整个 rewrite 模块我都不喜欢使用;第二,由于要判断后端响应码和响应头,这个时候 if 是不管用的,因为它的阶段太靠前。

引入 location @check_invalid_domain 后,所有的 403 响应都会跳转到该 location,而如前所述,业务中的 403 分为两类,有一类的后端响应头是不能丢失的。所以,如果一定要使用这种方案,我们要在 location @check_invalid_domain 中,将后端的响应头再添加进去,在实际业务中,这块会涉及到整个业务框架的部分,可能会很复杂。

那我们再换个思路,能不能在进入 location @check_invalid_domain 之前,就做好响应头的判断,在 location @check_invalid_domain 中,只配置访问日志。但同样如前所属,error_page 无法做组合逻辑,所以似乎路又堵死了。

这时,我们再来看一下 X-Accel-Redirect 头,就会惊喜的发现,它恰好是干这个的。本质上只有 Server B 才真正知道 403 的各种情况,那么只要在需要 Server A 修改访问日志时,加一个 X-Accel-Redirect 头来通知 Server A 做内部跳转就好了,起到一种精确制导的效果,而非将这些逻辑判断交给前端 Server A。

配置如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
events {
}

http {
    # 模拟 后端服务 Server B, 这里为了简化, 让其永远返回 403.
    # 在请求带了参数 invalid_domain 为 1 时, 添加额外的响应头 Invalid-Domain.
    # 其他情况下, 添加响应头 Valid-Domain.
    server {
        listen 8081;
        location / {
            access_log logs/server_b.log;
            header_filter_by_lua_block {
                if ngx.var.arg_invalid_domain == "1" then
                    ngx.header["X-Accel-Redirect"] = "@check_invalid_domain"
                    ngx.header["Invalid-Domain"] = "1"
                else
                    ngx.header["Valid-Domain"] = "1"
                end
                ngx.exit(403)
            }
        }
    }

    # 模拟前端服务 Server A.
    server {
        listen 8082;
        access_log logs/access.log;
        location / {
            proxy_pass http://127.0.0.1:8081;
        }
        location @check_invalid_domain {
            internal;
            access_log logs/invalid_domain.log;
            return 403;
        }
    }
}

可以看到,与前一版的区别,只有 3 个地方:

  1. 后端 Server B 在适当的时候增加 X-Accel-Redirect 响应头。
  2. 前端 Server A 的配置,去掉 error_page,由响应头 X-Accel-Redirect 在 nginx 的内部处理逻辑来自行做内部跳转。
  3. 内部跳转的目标地址只需要修改访问日志路径。

方案三

真正最灵活的方案,是修改一下 Nginx 的代码,将 access_log 的配置由静态配置改成每请求动态配置,并提供 lua 接口来给业务层调用,这样压根就不需要做内部跳转,代码改起来也不复杂,但实际操作中,能用已有的功能较好的满足需求就已经足够了。