Nginx的add_header指令實例分析

本篇內容介紹了“Nginx的add_header指令實例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

前言

大家都知道，nginx配置文件通過使用add_header指令來設置response header。

用curl查看一個站點的信息，發現返回的頭部與想象中的不一樣：

http/2 200
date: thu, 07 feb 2019 04:26:38 gmt
content-type: text/html; charset=utf-8
vary: accept-encoding, cookie
cache-control: max-age=3, must-revalidate
last-modified: thu, 07 feb 2019 03:54:54 gmt
x-cache: miss
server: cloudflare
...

主站點在nginx.conf中配置了hsts等header：

add_header strict-transport-security "max-age=63072000; preload";
add_header x-frame-options sameorigin;
add_header x-content-type-options nosniff;
add_header x-xss-protection "1; mode=block";

但響應頭部沒有這些header。除了常規的header，僅出現了一個配置配置在location中的header x-cache。

第一印象是cdn過濾了這些header？于是找cloudflare的文檔，沒發現會對這些進行處理。轉念一想，cdn過濾這些干啥啊？吃飽了撐的啊？他們又不搞zheng審那一套！

問題轉移到nginx的配置上。打開google搜索”nginx location add_header”，果然發現不少槽點。點開官網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指令。

“Nginx的add_header指令實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！