Nginx 위치 매칭 예시 공유-JS 튜토리얼-php.cn

이 글에서는 주로 Nginx 위치 매칭 예시를 공유합니다. 팀이 프런트엔드와 백엔드를 분리하고 있기 때문에 일상 업무에서는 프런트엔드가 Nginx와 노드 계층을 맡습니다. . 이전에는 위치 일치 규칙에 대해 잘 몰랐습니다. 위치 일치 방법을 이해하는 데 도움이 되기를 바랍니다.

문법 규칙

location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

로그인 후 복사

문법 규칙은 매우 간단합니다. location 키워드, 선택적 수정자, 일치할 문자, 중괄호 안에 수행할 작업이 옵니다. location关键字，后面跟着可选的修饰符，后面是要匹配的字符，花括号中是要执行的操作。

修饰符

= 表示精确匹配。只有请求的url路径与后面的字符串完全相等时，才会命中。
~ 表示该规则是使用正则定义的，区分大小写。
~* 表示该规则是使用正则定义的，不区分大小写。
^~ 表示如果该符号后面的字符是最佳匹配，采用该规则，不再进行后续的查找。

匹配过程

对请求的url序列化。例如，对%xx等字符进行解码，去除url中多个相连的/，解析url中的.，..等。这一步是匹配的前置工作。

location有两种表示形式，一种是使用前缀字符，一种是使用正则。如果是正则的话，前面有~或~*修饰符。

具体的匹配过程如下：

首先先检查使用前缀字符定义的location，选择最长匹配的项并记录下来。

如果找到了精确匹配的location，也就是使用了=修饰符的location，结束查找，使用它的配置。

然后按顺序查找使用正则定义的location，如果匹配则停止查找，使用它定义的配置。

如果没有匹配的正则location，则使用前面记录的最长匹配前缀字符location。

基于以上的匹配过程，我们可以得到以下两点启示：

使用正则定义的location在配置文件中出现的顺序很重要。因为找到第一个匹配的正则后，查找就停止了，后面定义的正则就是再匹配也没有机会了。
使用精确匹配可以提高查找的速度。例如经常请求/的话，可以使用=来定义location。

示例

接下来我们以一个例子来具体说明一下匹配过程。

假如我们有下面的一段配置文件：

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /user/ {
    [ configuration C ]
}

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

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

로그인 후 복사

请求/精准匹配A，不再往下查找。

请求/index.html匹配B。首先查找匹配的前缀字符，找到最长匹配是配置B，接着又按照顺序查找匹配的正则。结果没有找到，因此使用先前标记的最长匹配，即配置B。

请求/user/index.html匹配C。首先找到最长匹配C，由于后面没有匹配的正则，所以使用最长匹配C。
请求/user/1.jpg匹配E。首先进行前缀字符的查找，找到最长匹配项C，继续进行正则查找，找到匹配项E。因此使用E。

请求/images/1.jpg匹配D。首先进行前缀字符的查找，找到最长匹配D。但是，特殊的是它使用了^~修饰符，不再进行接下来的正则的匹配查找，因此使用D。这里，如果没有前面的修饰符，其实最终的匹配是E。大家可以想一想为什么。

请求/documents/about.html匹配B。因为B表示任何以/开头的URL都匹配。在上面的配置中，只有B能满足，所以匹配B。

location @name的用法

@用来定义一个命名location。主要用于内部重定向，不能用来处理正常的请求。其用法如下：

location / {
    try_files $uri $uri/ @custom
}
location @custom {
    # ...do something
}

로그인 후 복사

上例中，当尝试访问url找不到对应的文件就重定向到我们自定义的命名location（此处为custom）。

值得注意的是，命名location中不能再嵌套其它的命名location。

URL尾部的`/`需不需要

关于URL尾部的/有三点也需要说明一下。第一点与location配置有关，其他两点无关。

location中的字符有没有/都没有影响。也就是说/user/和/user是一样的。
如果URL结构是https://domain.com/的形式，尾部有没有/都不会造成重定向。因为浏览器在发起请求的时候，默认加上了/。虽然很多浏览器在地址栏里也不会显示/

수정자
- =는 정확히 일치함을 의미합니다. 요청된 URL 경로가 다음 문자열과 정확히 동일한 경우에만 조회가 발생합니다. 🎜
- 🎜~는 규칙이 정규식을 사용하여 정의되고 대소문자를 구분함을 의미합니다. 🎜
- 🎜~*는 규칙이 정규식을 사용하여 정의되고 대소문자를 구분하지 않음을 의미합니다. 🎜
- 🎜^~는 기호 뒤의 문자가 가장 일치하는 경우 이 규칙이 사용되며 후속 검색이 수행되지 않음을 의미합니다. 🎜
🎜일치 프로세스🎜🎜는 요청된 URL을 직렬화합니다. 예를 들어 %xx와 같은 문자를 디코딩하고, URL에서 연결된 여러 /를 제거하고, URL에서 ., 를 구문 분석합니다. .등 이 단계는 매칭을 위한 사전 작업입니다. 🎜🎜location에는 두 가지 표현 형식이 있습니다. 하나는 접두사 문자를 사용하는 것이고 다른 하나는 정규식을 사용하는 것입니다. 일반일 경우 앞에 ~ 또는 ~* 수식이 붙습니다. 🎜🎜구체적인 매칭 과정은 다음과 같습니다. 🎜🎜먼저 접두사 문자를 사용하여 정의된 위치를 확인하고, 가장 긴 매칭 항목을 선택하여 기록합니다. 🎜🎜완전히 일치하는 위치, 즉 = 수식자를 사용하는 위치가 발견되면 검색을 종료하고 해당 구성을 사용하세요. 🎜🎜그런 다음 정규식을 사용하여 정의된 위치를 순서대로 검색하세요. 일치하면 검색을 중지하고 정의된 구성을 사용하세요. 🎜🎜일치하는 정규 위치가 없으면 이전에 기록된 가장 긴 일치 접두사 문자 위치가 사용됩니다. 🎜🎜위의 일치 프로세스를 기반으로 다음 두 가지 통찰력을 얻을 수 있습니다. 🎜
1. 🎜정규 표현식을 사용하여 정의된 위치가 구성에 나타나는 순서 파일은 매우 중요합니다 . 일치하는 첫 번째 정규 패턴이 발견된 후 검색이 중지되고 정의된 후속 정규 패턴이 다시 일치할 가능성이 없기 때문입니다. 🎜
2. 🎜정확한 일치를 사용하여 검색 속도를 높이세요. 예를 들어 /를 자주 요청하는 경우 =를 사용하여 위치를 정의할 수 있습니다. 🎜
🎜예제🎜🎜다음으로 예시를 통해 매칭 과정을 자세히 설명하겠습니다. 🎜🎜다음 구성 파일이 있다고 가정해 보겠습니다. 🎜rrreee🎜/를 요청하여 A를 정확하게 일치시키고 더 이상 검색하지 않습니다. 🎜🎜B와 일치하도록 /index.html을 요청하세요. 먼저 일치하는 접두사 문자를 검색하고 일치하는 가장 긴 구성 B를 찾은 다음 일치하는 일반 규칙을 순서대로 검색합니다. 결과를 찾을 수 없으므로 이전 태그에서 가장 오랫동안 일치하는 구성 B가 사용됩니다. 🎜🎜C와 일치하도록 /user/index.html을 요청하세요. 먼저 가장 오래 일치하는 C를 찾습니다. 나중에 일치하는 정규 패턴이 없으므로 가장 오래 일치하는 C가 사용됩니다.
요청 /user/1.jpg가 E와 일치합니다. 먼저 접두사 문자를 검색하여 가장 긴 일치 항목 C를 찾은 다음 일반 검색을 계속하여 일치 항목 E를 찾습니다. 그러니 E를 사용하세요. 🎜🎜요청 /images/1.jpg가 D와 일치합니다. 먼저 접두사 문자를 검색하고 가장 긴 일치 항목 D를 찾습니다. 다만, 특별한 점은 ^~ 수식자를 사용하고 더 이상 후속 정규 매칭 검색을 수행하지 않으므로 D를 사용한다는 점이다. 여기서 이전 수식자가 없으면 최종 일치는 실제로 E입니다. 왜 그런지 생각해 볼 수 있습니다. 🎜🎜요청 /documents/about.html이 B와 일치합니다. B는 /로 시작하는 모든 URL이 일치한다는 의미이기 때문입니다. 위의 구성에서는 B만 만족할 수 있으므로 B가 매칭된다. 🎜🎜위치 @name🎜🎜@ 사용은 이름이 지정된 위치를 정의하는 데 사용됩니다. 주로 내부 리디렉션에 사용되며 일반 요청을 처리하는 데는 사용할 수 없습니다. 사용법은 다음과 같습니다: 🎜rrreee🎜위의 예에서 URL에 액세스하려고 시도했지만 해당 파일을 찾을 수 없으면 사용자 정의 이름이 지정된 위치(여기에서는 사용자 정의)로 리디렉션됩니다. 🎜🎜이름이 지정된 위치는 다른 이름이 지정된 위치를 중첩할 수 없다는 점에 유의할 가치가 있습니다. 🎜🎜URL 끝의 /가 필요한가요? 🎜🎜URL 끝의 /에 대해 설명해야 할 세 가지 사항이 있습니다. 첫 번째 점은 위치 구성과 관련이 있으며 나머지 두 점은 이와 관련이 없습니다. 🎜
1. 🎜위치의 문자에 /가 포함되어 있는지 여부는 영향을 미치지 않습니다. 즉, /user/와 /user는 동일합니다. 🎜
2. 🎜URL 구조가 https://domain.com/ 형식인 경우 끝에 /가 있는지 여부 리디렉션이 발생하지 않습니다. 브라우저가 요청을 시작할 때 기본적으로 /를 추가하기 때문입니다. 많은 브라우저에서는 주소 표시줄에 /가 표시되지 않습니다. Baidu를 방문하면 이를 확인할 수 있습니다. 🎜
3. URL 구조가 https://domain.com/some-dir/인 경우. 끝에 /가 없으면 리디렉션이 발생합니다. 규칙에 따르면 URL 끝에 있는 /는 디렉터리를 나타내고, /가 없으면 파일을 나타냅니다. 따라서 /some-dir/에 액세스하면 서버는 자동으로 이 디렉터리로 이동하여 해당 기본 파일을 찾습니다. /some-dir에 액세스하면 서버는 먼저 some-dir 파일을 찾습니다. 파일을 찾을 수 없으면 some-dir를 디렉터리로 지정하고 <code>/some-dir/로 리디렉션한 다음 이 디렉터리로 이동하여 기본 파일을 찾으세요. 귀하의 웹사이트가 이와 같은지 테스트해 볼 수 있습니다. https://domain.com/some-dir/。尾部如果缺少/将导致重定向。因为根据约定，URL尾部的/表示目录，没有/表示文件。所以访问/some-dir/时，服务器会自动去该目录下找对应的默认文件。如果访问/some-dir的话，服务器会先去找some-dir文件，找不到的话会将some-dir当成目录，重定向到/some-dir/，去该目录下找默认文件。可以去测试一下你的网站是不是这样的。
总结

location的配置有两种形式，前缀字符和正则。查找匹配的时候，先查找前缀字符，选择最长匹配项，再查找正则。正则的优先级高于前缀字符。

正则等查找是按照在配置文件中的顺序进行的。因此正则等顺序很重要，建议越精细的放的越靠前。

使用=精准匹配可以加快查找的顺序，如果根域名经常被访问等话建议使用=

요약

위치 구성에는 접두사 문자와 정규 표현식의 두 가지 형식이 있습니다. 일치 항목을 검색할 때 먼저 접두사 문자를 검색하고 가장 긴 일치 항목을 선택한 다음 일반 패턴을 검색합니다. 일반 문자는 접두사 문자보다 우선순위가 높습니다.

정기 검색은 구성 파일에 있는 순서대로 수행됩니다. 따라서 정규식의 순서가 매우 중요합니다. 더 자세한 정규식을 먼저 배치하는 것이 좋습니다. 정확한 일치를 위해 =를 사용하면 검색 순서가 빨라질 수 있습니다. 루트 도메인 이름에 자주 액세스하는 경우 =를 사용하는 것이 좋습니다.