nginx的add_header及proxy_set_header命令有三个地方可以配置,分别是http,server,location。我们一般对其优先级的理解是location->server->http。

这没有错,但是这个优先级是指令级别的(不包括指令后面的参数),也就是说:假设在http和server内都有add_header,那么只有server内的生效,忽略http内的add_header,而不管在这两个地方配置新增的header是不是一样。

proxy_set_header也是一样的效果。所以个人推测有很多nginx指令可能都是这样的规则。

另个在同一级别也有坑,对于add_header,如果同一个域名的两个不同location加了不同的add_header,那么只有最后一个location内的生效。这个我没有亲测,详细的可以看下面的参考链接。

官网add_header的文档,有这样的描述(其他信息已省略):

There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.

注意重点在“These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level. ”。即:仅当当前层级中没有add_header指令才会继承父级设置。所以我的疑问就清晰了:location中有add_header,nginx.conf中的配置被丢弃了。

这是Nginx的故意行为,说不上是bug或坑。但深入体会这句话,会发现更有意思的现象:仅最近一处的add_header起作用。http、server和location三处均可配置add_header,但起作用的是最接近的配置,往上的配置都会失效。

但问题还不仅于此。如果location中rewrite到另一个location,最后结果仅出现第二个的header。例如:

location /foo1 {
add_header foo1 1;
rewrite / /foo2;
}
location /foo2 {
add_header foo2 1;
return 200 “OK”;
}

不管请求/foo1还是/foo2,最终header只有foo2:

尽管说得通这是正常行为,但总让人感觉有点勉强和不舒坦:server丢掉http配置,location丢掉server配置也就算了,但两个location在同一层级啊!

不能继承父级配置,又不想在当前块重复指令,解决办法可以用include指令。

参考:https://tlanyan.me/be-careful-with-nginx-add_header-directive/