location官方文檔：http://nginx.org/en/docs/http/ngx_http_core_module.html#location
Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default: —
Context: server, location
這個配置的設置依賴於請求的URL。
對規范化的URL進行匹配,文本解碼后使用"%xx"的格式進行編碼,解析由.和..組成的相對路徑,並且可能壓縮兩個或2個以上的斜杠到單一的斜杠。
location 可以被定義為一個前綴字符串,或者正則表達式.正則表達式使用~*(不區分大小寫) 或 ~(區分大小寫)被指定.
去查找location,匹配給到的請求.
nginx首先去檢查使用prefix strings(prefix location)定義的locations. </images/ 這種的屬於prefix string>
接着長的prefix strings被匹配記憶.
接下來 正則表達式被檢測,在配置文件中的順序去匹配
當搜索到第一個被匹配的正則表達式,將停止搜索,並且相應的配置項被應用
如果沒有正則表達式被匹配到,更早的被查找到的prefix location被使用.
location 塊是可以嵌套的,除了一下例外的情況:
不區分大小寫的操作系統像 Mac Os x 和cygwin,忽略了與prfix strings的匹配.可是比較限於1字節的語言環境(comparison is limited to one-byte locales)<翻譯不是很准確>
正則表達式可以包含捕獲,稍后用於其他指令
如果最長前綴匹配位置有"^~"修飾符那么不進行正則匹配.
同樣,使用"="修飾符,有可能定義一個URL和位置的精確匹配,如果精確匹配被發現,那么匹配結束.例如:如果"/"請求經常發生,定義了一個"location = /" 將加速這些請求的處理.在第一比較后搜索停止.這樣的位置顯然不能包含嵌套的位置.
在版本從0.7.1 到 0.8.41, 如果一個請求匹配到前綴位置 除了"=" 和"^~" 修飾符,搜索也終止和不進行正則匹配
讓我們舉個栗子:
location = / {
[ configuration A ]
}
location / {
[ configuration B ]
}
location /documents/ {
[ configuration C ]
}
location ^~ /images/ {
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
[ configuration E ]
}
"/" 請求會匹配配置文件A,
"/index.html" 匹配配置文件B
"/documents/documents.html" 匹配 C
"/images/" 匹配 D
"/images/1.jpd" 匹配 E
"@"前綴自定義了個location字符串.這樣的一個location不用於常規請求的處理,但是用於請求的重定向.他不能被嵌套,也不能包含嵌套location
如果一個location被定義為前綴字符串,結束符是個斜線"/",並且請求由proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, or memcached_pass他們中的一個來處理,那么進行特殊的處理.響應請求URI等於這個字符串,但是不包含最后的"/",代碼301永久重定向將被返回給請求添加斜線的URL.如果這不是你所希望的,一個URL精確的匹配和location被這樣定義:
location /user/ {
proxy_pass http://user.example.com;
}
location = /user {
proxy_pass http://login.example.com;
}