Nginx中Location有什么用，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序開發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了南崗免費建站歡迎大家使用！

正文

Syntax: 語法	location [ = | ~ | ~* | ^~ ] uri { ... } location @name { ... }
Default: 默認(rèn)	—
Context: 使用場景/語境	server, location

Sets configuration depending on a request URI. 基于請求uri的配置規(guī)則

The matching is performed against a normalized URI, after decoding the text encoded in the “%XX” form, resolving references to relative path components “.” and “..”, and possible compression of two or more adjacent slashes into a single slash. 匹配針對從"%xx"格式的文本解碼之后的正常的uri生效，解析相對路徑引用 "." 和 ".."，以及將兩個或更多的相鄰的斜杠壓縮成單斜杠。

A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified with the preceding “~*” modifier (for case-insensitive matching), or the “~” modifier (for case-sensitive matching). To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.

Location 可以用前綴字符串定義，或者正則表達(dá)式。正則表達(dá)式前面帶有 ~* 修飾 (大小寫不敏感匹配) ，或者 ~ 修飾 （大小寫敏感匹配）. 為了找到和一個給定的請求相匹配的location，nginx 首先檢查 帶了前綴字符串的location(也叫前綴location). 在它們當(dāng)中，擁有最長的匹配前綴的location將被選中并被記錄下來。然后按照在配置文件中的先后順序，依次檢查正則表達(dá)式。正則表達(dá)式的搜索會在第一個匹配的時候終止，然后相應(yīng)的配置將被使用。如果沒有命中正則表達(dá)式，則會使用之前被記錄下來的前綴location。

location blocks can be nested, with some exceptions mentioned below.

location 模塊可以被嵌套，以下是一些例外情況:

For case-insensitive operating systems such as macOS and Cygwin, matching with prefix strings ignores a case (0.7.7). However, comparison is limited to one-byte locales. 對于大小寫不敏感的操作系統(tǒng)，例如macOS和Cygwin，匹配前綴字符串會忽略一個大寫(0.7.7版本). 然而，比較被限制在單字節(jié)的地方。

Regular expressions can contain captures (0.7.40) that can later be used in other directives. 正則表達(dá)式可以包含匹配，這些匹配可以在后續(xù)其他指令中被用到的。(0.7.40版本)

If the longest matching prefix location has the “^~” modifier then regular expressions are not checked. 如果最長的匹配到的前綴location帶有 ^~ 修飾符，那么正則表達(dá)式將不會被檢查。

Also, using the “=” modifier it is possible to define an exact match of URI and location. If an exact match is found, the search terminates. For example, if a “/” request happens frequently, defining “location = /” will speed up the processing of these requests, as search terminates right after the first comparison. Such a location cannot obviously contain nested locations.

同時，使用 '=' 修飾符可能定義一個精準(zhǔn)匹配的uri和location. 如果找到了一個精準(zhǔn)匹配，那么查詢就會終止。例如，如果一個 '/' 請求經(jīng)常出現(xiàn)，那么定義 'location = /' 將加快處理這些請求的速度，因為搜索會在第一次比較之后就結(jié)束。這種location很顯然不能包含嵌套的location.

In versions from 0.7.1 to 0.8.41, if a request matched the prefix location without the “ =” and “ ^~” modifiers, the search also terminated and regular expressions were not checked.

在 0.7.1 到 0.8.41 的版本中，如果一個請求命中了 不含有 '=' 或 '^~' 修飾符的前綴location，搜索也會終止，且正則表達(dá)式不會被檢查到。

Let’s illustrate the above by an example: 讓我們用一個例子來展示以上的內(nèi)容:

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

The “/” request will match configuration A, the “/index.html” request will match configuration B, the “/documents/document.html” request will match configuration C, the “/images/1.gif” request will match configuration D, and the “/documents/1.jpg” request will match configuration E.

'/' 請求將會匹配到 配置A (精準(zhǔn)匹配)

'/index.html' 請求將匹配到 配置B （沒有命中精準(zhǔn)匹配，沒有命中前綴匹配，也沒有命中正則匹配，最后命中默認(rèn)匹配）

'/documents/document.html' 請求將命中 配置C （沒有命中精準(zhǔn)匹配，命中了前綴匹配 /documents/，繼續(xù)查找正則匹配，沒有命中，使用前綴匹配）

'/images/1.gif' 請求將命中 配置D (沒有命中精準(zhǔn)匹配，命中了前綴匹配 ^~ /images/，這個匹配帶了 ^~修飾符，不查找正則匹配，直接使用該前綴匹配)

'/documents/1.jpg' 請求將命中 配置E  (沒有命中精準(zhǔn)匹配，同時命中了 /documents 和 ~* \.(gif|jpg|jpeg)$，后面這個最長，被記錄下來，繼續(xù)查找正則匹配，沒有命中，使用之前記錄下的最長的前綴匹配，配置E。

The “@” prefix defines a named location. Such a location is not used for a regular request processing, but instead used for request redirection. They cannot be nested, and cannot contain nested locations.

'@' 前綴相當(dāng)于給一個location命了名. 這種location不會用來處理常規(guī)的請求，但是會用來請求重定向。它們不可以被嵌套，也不可以包含嵌套location.

If a location is defined by a prefix string that ends with the slash character, and requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass, then the special processing is performed. In response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended. If this is not desired, an exact match of the URI and location could be defined like this:

如果一個location用一個前綴字符串，并以一個斜杠\結(jié)束，且這些請求被 proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass 或者 grpc_pass中的一個處理，那么特殊的處理將被執(zhí)行。在響應(yīng) 帶有和這個字符串相等，但沒有最后的斜杠\ 的uri的請求時，會返回一個帶有301狀態(tài)碼的永久重定向 給請求的uri，并帶上最后的斜杠\。如果不希望這樣，可以對uri的精準(zhǔn)匹配以及l(fā)ocation定義如下: (這樣就不會跳轉(zhuǎn)301了)

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

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

總結(jié)

1, 語法

                修飾符(modifier)         
location  [ = | ~ | ~* | ^~ ]    uri    { ... } 

2, 分類

根據(jù)不同的修飾符可以分為兩大類
2.1 前綴location (prefix location)
2.1.1 無修飾符的普通location，例如 location /abc, location /abc/
2.1.2 帶=的精準(zhǔn)匹配location，例如 location =/abc
2.1.3 帶^~表示以某個常規(guī)字符串開頭的，非正則表達(dá)式location，例如 location ^~ /abc

2.2 正則表達(dá)式location (regular expressions location)
2.2.1 ~   區(qū)分大小寫的正則location
2.2.2 ~*  不區(qū)分大小寫的正則location

3, 匹配規(guī)則

3.1 nginx會首先檢查 前綴location

3.1.1 如果命中，擁有最長的匹配字符串的location將被選中并被記錄下來。

3.1.1.1 如果最長前綴匹配location的修飾符是^~時，就不會檢查正則location了，直接選擇該location為最終location。如果不是，則進(jìn)入下一步正則匹配。

3.1.2 如果沒有命中，則進(jìn)入下一步正則匹配。

3.2 如果存在正則location時，按照配置的先后順序(重要!)依次匹配URI。

3.2.1 如果找到匹配的正則location就不再繼續(xù)往下，并選擇該location作為最終的結(jié)果。

3.2.2 如果沒有找到匹配的正則location，則會使用之前被記錄下來的前綴location (如果有的話)。

3.3 如果存在精準(zhǔn)匹配location，且請求的uri跟其完全匹配，選擇該精準(zhǔn)匹配location作為最終的location。

4, 優(yōu)先級

精準(zhǔn)匹配 > ^~修飾符最長前綴匹配 > 正則匹配 > 無修飾符普通最長前綴匹配 > 通用匹配 /

5, 其他

注意，在同一個Server中，不能同時存在帶有相同字符串的 ^~ 修飾符前綴location 和 無修飾符普通前綴location，如下

server {
        listen 80;
        server_name www.test1.com;
        root /opt/wwwroot/test;

        location /fullpath {
                echo 'prefix fullpath with no modifier';
        }

        location ^~ /fullpath {
                echo 'prefix fullpath with ^~ modifier';
        }
}

如果這兩個同時打開，在 nginx -t 命令檢查nginx 配置時，會報 emerg 級別錯誤

2019/11/05 14:01:52 [emerg] 22355#22355: duplicate location "/fullpath" in /etc/nginx/sites-enabled/default:165

關(guān)于Nginx中Location有什么用問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。

網(wǎng)站題目：Nginx中Location有什么用
分享鏈接：http://vcdvsql.cn/article0/pdejio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、服務(wù)器托管、網(wǎng)站設(shè)計、自適應(yīng)網(wǎng)站、商城網(wǎng)站、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)