这是一个坑比较多的指令。它的处理阶段比location处理晚，虽然可以写在location中，但如果rewrite别的location，那么上一个location中尚未处理的add_header就会丢失。比如：

}

并没有a1这个头吧？这就是一个坑！

另一个坑就是一开始说的重复的问题，比如我希望给一个内容设置content-type，但是由于全局有设置一个default_type，所以就重复了。

default_type'text/plain';

}

解决的办法当然有很多比如对这个location将default_type置空，或者干脆不用add_header，直接针对这个location修改default_type。

最后一个大坑就是对错误页面无法生效，这也是在中有明确定义的。比如下面这个例子：

add_headercontent-typeapplication/json;

}

我希望响应一个json，然而由于状态码是404，所以这里的add_header并不会生效。

虽然这个例子可以用default_type来解决问题，但如果是其它头呢？比如access-control-allow-origin要怎么办？那么除了使用lua或其它第三方模块来解决之外就无解了。nginx当然也意识到了这个问题，所以文档中也说了在1.7.5版本之后支持一个叫always的参数。虽然nginx自己解决了这个问题，但基于1.6.2的tengine就要呵呵了。

以上就是nginx配置add_header的坑怎么解决的详细内容，更多请关注主机测评网其它相关文章！