譯：

Syntax:location?[?=?|?~?|?~*?|?^~?]?uri?{ ... }``location?@name?{ ... }

Default:	—
Context:	server,?location

依據請求的URI進行配置。

在對以"%xx"形式的文本解碼，對相對路徑".“和”…"的格式化和兩個或多個相鄰斜杠壓縮為單個斜杠后的規范URI執行匹配。

一個location可以被定義為一個前綴字符串或者一個正則表達式。正則表達式通過前綴"_{*"（忽略大小寫）或者"}"（大小寫敏感）修飾，在這些位置中，最長前綴字符串匹配的location會被選中和記住。然后會按照正則表達式在配置文件中出現的順序進行正則表達式的匹配。在第一個正則表達式匹配上就會終止，并且相應的配置會被使用。如果沒有匹配上正則表達式，前面記住的前綴字符串匹配的location的配置將會被使用。

location 塊是可以嵌套的，以下提到一些例外。

對于不區分大小寫的操作系統例如macOS和Cygwin，與前綴字符串匹配忽略大小寫。然而，比較被局限于一字節的環境。

正則表達式可以包含捕獲，捕獲的內容可以被用在之后的其他指令中。

如果匹配的最長的前綴字符串的location有“^~"修飾，之后的正則表達式檢查就不會進行了。

使用"=“修飾是定義一個嚴格匹配的URI和location。如果匹配上一個嚴格模式，搜索就會終止。例如，如果一個”/"請求經常發生，定義"location = /"將會快速處理這些請求。在第一個嚴格的location匹配上后就會終止搜索。這樣的location顯然不能包含嵌套location。

注：在0.7.1到0.8.41版本中，如果一個請求匹配了前綴字符串的location即使沒有"=“或者”^~"修飾，搜索也會停止并且正則表達式也不會檢查。

讓我們通過一個例子進行說明：

location = / {[ configuration A ] }location / {[ configuration B ] }location /documents/ {[ configuration C ] }location ^~ /images/ {[ configuration D ] }location ~* \.(gif|jpg|jpeg)$ {[ configuration E ] }

“/“請求將會匹配 configuration A，”/index.html"請求將會匹配configuration B，”/documents/document.html"請求將會匹配configuration C，"/images/1.gif"請求將會匹配configuration D，"/documents/1.jpg"請求將會匹配configuration E。

"@"前綴作為前綴定義的location。這樣的location不是用來處理常規請求的，而是用于請求重定向。它們也不能嵌套，也不能包含嵌套位置。

如果一個location通過前綴以斜杠結尾字符定義的，并且請求被 proxy_pass，fastcgi_pass，uwsgi_pass，scgi_pass，memcached_pass或grpc_pass之一處理，然后會執行特殊處理。在響應一個請求的URI等這個字符串但是沒有斜杠，一個永久重定向的cod 301將會返回請求的URI并且帶上斜杠。如果不想這樣，一個嚴格匹配的URI和location可以像這樣定義：

location /user/ {proxy_pass http://user.example.com; }location = /user {proxy_pass http://login.example.com; }

注意點

通過字符串定義的location是從URI的path的前面開始匹配的，這就是為什么總強調前綴字符串的原因，不是URI的path中有一部分匹配上就行，必須要從path的頭開始匹配，但是正則就沒有這個限制。

關于^~匹配上就不向后就不向后進行正則的匹配了。這里要注意的是要求 ^~ 匹配上，就是在進行字符串搜索的時候 ^~ 是要被記住的那個location，也就是匹配上的最長前綴的location。

參考

nginx文檔locaiton部分

總結

以上是生活随笔為你收集整理的【译】nginx关于location部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。