譯：
| 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。