nginx关于add_header的坑及解决

在Nginx的配置中，add_header是一个常用的指令，用于在HTTP响应头中添加自定义的头部信息。然而，这个看似简单的指令在实际使用中却隐藏着不少坑。本文将为大家揭示这些坑，并提供相应的解决方案。

一、add_header的坑

1. 重写限制：虽然很多文档声称add_header可以覆盖响应头，但实际上它并不能重写具有特殊含义的头部，如Content-Length、Content-Type、Date、Server等。这些头部由Nginx内部处理，并且通常不允许通过add_header来重写。
2. 继承与覆盖：add_header的配置在Nginx中是有继承性的。如果在一个作用域内没有定义add_header，那么它会继承上一个作用域的配置。但是，如果在当前作用域内定义了add_header，那么它会覆盖继承的配置。这一点在使用时要特别注意。
3. 处理顺序：add_header的处理阶段比location处理晚，这意味着如果在location中进行了rewrite，那么上一个location中尚未处理的add_header可能会丢失。
4. 不支持错误页面：在低版本的Nginx中，add_header还不支持在错误页面中使用。这是一个比较常见的问题，需要特别注意。

二、解决方案

1. 避免重写特殊头部：对于具有特殊含义的头部，如Content-Length、Content-Type等，不要尝试使用add_header来重写它们。
2. 明确配置：在每个需要add_header的作用域内都明确配置它，以避免继承导致的覆盖问题。
3. 注意处理顺序：在使用rewrite和add_header时，要注意它们的处理顺序，确保add_header在rewrite之后执行。
4. 升级Nginx版本：如果需要在错误页面中使用add_header，那么可以考虑升级Nginx到支持该功能的版本。在Nginx 1.7.5及以后的版本中，可以通过添加always参数来确保add_header在错误页面中也生效。