Nginx 서버 및 위치 블록 선택 알고리즘 이해하기

튜토리얼

소개

Nginx는 세계에서 가장 인기 있는 웹 서버 중 하나입니다. 고부하 및 다수의 동시 클라이언트 연결을 성공적으로 처리할 수 있으며, 웹 서버, 메일 서버 또는 리버스 프록시 서버로 기능할 수 있습니다.

이 가이드에서는 Nginx가 클라이언트 요청을 처리하는 데 영향을 미치는 일부 배경 정보를 논의할 것입니다. 이러한 아이디어를 이해하면 서버 및 위치 블록을 설계하는 데 대한 추측을 줄일 수 있으며, 요청 처리가 예측할 수 없어 보이는 것을 덜 예상할 수 있습니다.

Nginx 블록 구성

Nginx는 서로 다른 콘텐츠를 제공하기 위한 구성을 논리적으로 블록으로 나누어 계층 구조로 구성합니다. 클라이언트 요청이 발생할 때마다, Nginx는 어떤 구성 블록을 사용하여 요청을 처리해야 하는지 결정하는 과정을 시작합니다. 이 결정 과정에 대해 이 가이드에서 논의할 것입니다.

우리가 논의할 주요 블록은 server 블록과 location 블록입니다.

A server block is a subset of Nginx’s configuration that defines a virtual server used to handle requests of a defined type. Administrators often configure multiple server blocks and decide which block should handle which connection based on the requested domain name, port, and IP address.

A location block lives within a server block and is used to define how Nginx should handle requests for different resources and URIs for the parent server. The URI space can be subdivided in whatever way the administrator likes using these blocks. It is an extremely flexible model.

Nginx가 요청을 처리할 서버 블록을 결정하는 방법

Nginx는 관리자가 별도의 가상 웹 서버 인스턴스로 작동하는 여러 서버 블록을 정의할 수 있도록 허용하므로, 요청을 충족시키기 위해 이러한 서버 블록 중 어떤 것을 사용할지 결정하는 절차가 필요합니다.

이를 위해 Nginx는 최적의 일치를 찾기 위해 사용되는 확인된 시스템을 통해 이를 수행합니다. 이 과정 중에 Nginx가 주로 신경 쓰는 주요 서버 블록 지시문은 listen 지시문과 server_name 지시문입니다.

listen 지시문을 구문 분석하여 가능한 일치 항목 찾기

먼저 Nginx는 요청의 IP 주소와 포트를 살펴봅니다. 이를 각 서버의 listen 지시문과 일치시켜 요청을 해결할 수 있는 서버 블록의 목록을 작성합니다.

listen 지시문은 일반적으로 서버 블록이 응답할 IP 주소와 포트를 정의합니다. 기본적으로 listen 지시문을 포함하지 않은 모든 서버 블록은 0.0.0.0:80의 청취 매개변수를 가집니다(root 사용자가 아닌 일반 사용자가 Nginx를 실행하는 경우 0.0.0.0:8080으로 설정됩니다). 이렇게 하면 이러한 블록이 포트 80의 모든 인터페이스에서 요청에 응답할 수 있지만, 이 기본값은 서버 선택 프로세스에서 큰 의미가 없습니다.

listen 지시문은 다음과 같이 설정할 수 있습니다:

  • IP 주소/포트 조합.
  • A lone IP address which will then listen on the default port 80.
  • A lone port which will listen to every interface on that port.
  • 유닉스 소켓의 경로.

마지막 옵션은 일반적으로 서로 다른 서버 간에 요청을 전달할 때만 영향을 미칩니다.

요청을 보낼 서버 블록을 결정할 때 Nginx는 다음 규칙을 사용하여 listen 지시문의 구체성에 따라 먼저 결정을 시도합니다:

  • Nginx는 모든 “불완전한” listen 지시문을 디폴트 값으로 누락된 값으로 대체하여 각 블록을 해당 IP 주소와 포트로 평가할 수 있도록 번역합니다. 이러한 번역의 예는 다음과 같습니다:
    • listen 지시문이 없는 블록은 0.0.0.0:80의 값을 사용합니다.
    • 포트가 없는 IP 주소 111.111.111.111로 설정된 블록은 111.111.111.111:80이 됩니다.
    • IP 주소가 없는 포트 8888으로 설정된 블록은 0.0.0.0:8888이 됩니다.
  • 그런 다음 Nginx는 요청과 가장 일치하는 서버 블록 목록을 수집하려고 시도합니다. 이는 기능적으로 0.0.0.0을 사용하여 IP 주소를 일치시키는 블록이 특정 IP 주소를 나열하는 일치하는 블록이 있는 경우 선택되지 않음을 의미합니다. 어쨌든 포트는 정확하게 일치해야합니다.
  • 가장 구체적으로 일치하는 것이 하나뿐인 경우 해당 서버 블록이 요청을 제공하는 데 사용됩니다. 동일한 수준의 일치하는 여러 서버 블록이있는 경우 Nginx는 해당 서버 블록의 server_name 지시문을 평가하기 시작합니다.

Nginx가 listen 지시문의 동일한 수준의 일치하는 서버 블록을 구분해야 할 때에만 server_name 지시문을 평가하는 것이 중요합니다. 예를 들어, example.com이 192.168.1.10의 포트 80에 호스팅되는 경우, example.com에 대한 요청은 항상 예시의 첫 번째 블록에서 제공됩니다. 두 번째 블록의 server_name 지시문에도 불구하고.

server {
    listen 192.168.1.10;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

동일한 구체성으로 두 개 이상의 서버 블록이 일치하는 경우 다음 단계는 server_name 지시문을 확인하는 것입니다.

일치 항목 선택을 위한 server_name 지시문 구문 분석

다음으로, 동일한 구체적인 listen 지시문을 가진 요청을 더 평가하기 위해 Nginx는 요청의 Host 헤더를 확인합니다. 이 값은 클라이언트가 실제로 접근하려고 했던 도메인 또는 IP 주소를 포함합니다.

Nginx는 여전히 선택 대상인 각 서버 블록 내의 server_name 지시문을 확인하여 찾은 값에 대한 최적의 일치를 시도합니다. Nginx는 다음 공식을 사용하여 이러한 블록을 평가합니다:

  • Nginx는 먼저 요청의 Host 헤더의 값과 정확히 일치하는 server_name을 가진 서버 블록을 찾으려고 합니다. 이를 찾으면 해당 블록이 요청을 제공하는 데 사용됩니다. 정확한 일치가 여러 개인 경우, 첫 번째 것이 사용됩니다.
  • 정확한 일치를 찾을 수 없는 경우, Nginx는 그 다음으로 구성에서 이름의 시작 부분에 와일드카드(구성에서 이름이 *로 시작함으로 표시됨)를 사용하여 일치하는 server_name을 가진 서버 블록을 찾으려고 합니다. 이러한 블록을 찾으면 해당 블록이 요청을 제공하는 데 사용됩니다. 여러 일치가 있는 경우, 가장 긴 일치가 요청을 제공하는 데 사용됩니다.
  • 선행 와일드카드를 사용하여 일치하는 항목을 찾을 수 없는 경우, Nginx는 구성에서 *로 끝나는 서버 이름을 사용하여 일치하는 server_name을 가진 서버 블록을 찾습니다. 이러한 블록을 찾으면 해당 블록이 요청을 제공하는 데 사용됩니다. 여러 일치가 있는 경우, 가장 긴 일치가 요청을 제공하는 데 사용됩니다.
  • server_name을 정규 표현식을 사용하여 정의한 서버 블록은 후행 와일드카드를 사용하여 일치하는 항목이 없는 경우에 Nginx가 평가합니다(이름 앞에 ~가 표시됨). “Host” 헤더와 일치하는 정규 표현식이 있는 server_name이 요청을 처리하는 데 사용됩니다. 정규 표현식 일치가 없는 경우, Nginx는 해당 IP 주소 및 포트에 대한 기본 서버 블록을 선택합니다. 각 IP 주소/포트 콤보에는 구성에서 첫 번째 블록이거나 listen 지시문의 일부로 default_server 옵션을 포함하는 블록일 것입니다(이는 첫 번째 발견된 알고리즘을 무시할 것입니다). 각 IP 주소/포트 조합당 default_server 선언은 하나만 있어야 합니다.

예시

요청의 Host 헤더 값과 정확히 일치하는 server_name이 정의된 경우, 해당 서버 블록이 요청을 처리하기 위해 선택됩니다.

이 예에서 요청의 Host 헤더가 host1.example.com으로 설정된 경우, 두 번째 서버가 선택됩니다:

server {
    listen 80;
    server_name *.example.com;

    . . .

}

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

만약 정확한 일치가 없다면, Nginx는 시작 와일드카드가 들어맞는 server_name을 확인합니다. 와일드카드로 시작하는 가장 긴 매치가 요청을 충족시키는 데 선택됩니다.

이 예에서 요청이 Host 헤더가 www.example.org라면 두 번째 서버 블록이 선택됩니다:

server {
    listen 80;
    server_name www.example.*;

    . . .

}

server {
    listen 80;
    server_name *.example.org;

    . . .

}

server {
    listen 80;
    server_name *.org;

    . . .

}

시작 와일드카드로 일치하는 것을 찾을 수 없으면, Nginx는 식의 끝에 와일드카드를 사용하여 일치하는지 확인합니다. 이 시점에서 와일드카드로 끝나는 가장 긴 매치가 요청을 제공하기 위해 선택됩니다.

예를 들어, 요청의 Host 헤더가 www.example.com으로 설정된 경우, 세 번째 서버 블록이 선택됩니다:

server {
    listen 80;
    server_name host1.example.com;

    . . .

}

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name www.example.*;

    . . .

}

와일드카드 일치가 발견되지 않으면, Nginx는 정규 표현식을 사용하는 server_name 지시문과 일치하도록 시도합니다. 첫 번째 일치하는 정규 표현식이 요청에 응답하기 위해 선택됩니다.

예를 들어, 요청의 Host 헤더가 www.example.com으로 설정된 경우, 두 번째 서버 블록이 요청을 충족시키기 위해 선택됩니다:

server {
    listen 80;
    server_name example.com;

    . . .

}

server {
    listen 80;
    server_name ~^(www|host1).*\.example\.com$;

    . . .

}

server {
    listen 80;
    server_name ~^(subdomain|set|www|host1).*\.example\.com$;

    . . .

}

위의 단계 중 어느 것도 요청을 충족시키지 못하면, 요청은 일치하는 IP 주소와 포트에 대한 기본 서버로 전달됩니다.

매치하는 위치 블록

Nginx가 요청을 처리할 서버 블록을 선택하는 과정과 유사하게, Nginx는 또한 요청을 처리하기 위해 서버 내의 어떤 위치 블록을 사용할지 결정하는 데 사용되는 알고리즘을 갖추고 있습니다.

위치 블록 구문

Nginx가 요청을 처리할 위치 블록을 결정하는 방법을 다루기 전에 위치 블록 정의에서 볼 수 있는 일부 구문을 살펴보겠습니다. 위치 블록은 서버 블록(또는 다른 위치 블록) 내에 존재하며 요청 URI(도메인 이름 또는 IP 주소/포트 다음에 오는 부분)를 처리하는 방법을 결정하는 데 사용됩니다.

일반적으로 위치 블록은 다음과 같은 형태를 취합니다:

location optional_modifier location_match {

    . . .

}

위의 location_match은 Nginx가 요청 URI를 어떻게 확인해야 하는지 정의합니다. 위의 예에서 수정자의 존재 또는 미존재는 Nginx가 위치 블록과 일치하는 방법에 영향을 미칩니다. 아래의 수정자는 관련 위치 블록이 다음과 같이 해석되도록 합니다:

  • (없음): 수정자가 없으면 위치가 접두사 일치로 해석됩니다. 이는 주어진 위치가 일치 여부를 결정하기 위해 요청 URI의 시작 부분과 일치하는지 확인합니다.
  • =: 등호가 사용되면 요청 URI가 주어진 위치와 정확히 일치하는 경우 이 블록이 일치로 간주됩니다.
  • ~: 만약 틸다 수정자가 존재한다면, 이 위치는 대소문자를 구분하는 정규 표현식 일치로 해석됩니다.
  • ~*: 틸다와 별표 수정자가 사용된 경우, 위치 블록은 대소문자를 구분하지 않는 정규 표현식 일치로 해석됩니다.
  • ^~: 캐럿과 틸다 수정자가 존재하고, 이 블록이 최상의 비정규 표현식 일치로 선택된 경우, 정규 표현식 일치가 일어나지 않습니다.

위치 블록 구문을 설명하는 예시

접두사 일치의 예로, 다음 위치 블록이 /site, /site/page1/index.html, 또는 /site/index.html와 같은 요청 URI에 대해 응답하기 위해 선택될 수 있습니다:

location /site {

    . . .

}

정확한 요청 URI 일치의 시연을 위해, 이 블록은 항상 /page1과 같은 요청 URI에 응답하기 위해 사용됩니다. 이 블록은 /page1/index.html 요청 URI에 응답하지 않습니다. 이 블록이 선택되고 요청이 인덱스 페이지를 사용하여 충족되는 경우, 다른 위치로 내부 리디렉션이 발생하여 요청의 실제 핸들러가 될 것입니다:

location = /page1 {

    . . .

}

위치를 대소문자를 구분하는 정규 표현식으로 해석해야 하는 예로서, 이 블록은 /tortoise.jpg 요청을 처리하는 데 사용될 수 있지만 /FLOWER.PNG에 대해서는 사용되지 않을 수 있습니다:

location ~ \.(jpe?g|png|gif|ico)$ {

    . . .

}

A block that would allow for case-insensitive matching similar to the above is shown below. Here, both /tortoise.jpg and /FLOWER.PNG could be handled by this block:

location ~* \.(jpe?g|png|gif|ico)$ {

    . . .

}

마지막으로, 이 블록은 정규 표현식 일치가 최상의 비정규 표현식 일치로 결정되면 발생하지 않도록 합니다. 이 블록은 /costumes/ninja.html 요청을 처리할 수 있습니다:

location ^~ /costumes {

    . . .

}

보시다시피, 수정자들은 위치 블록이 어떻게 해석되어야 하는지를 나타냅니다. 그러나 이것은 Nginx가 요청을 어떤 위치 블록으로 보낼지 결정하는 알고리즘을 우리에게 알려주지 않습니다. 다음에 이어서 설명하겠습니다.

Nginx가 요청을 처리하기 위해 사용할 위치를 선택하는 방법

Nginx는 서버 블록을 선택하는 방식과 유사하게 요청을 처리할 위치를 선택합니다. 이는 주어진 요청에 대해 가장 적합한 위치 블록을 결정하는 프로세스를 실행합니다. 이 프로세스를 이해하는 것은 Nginx를 신뢰할 수 있고 정확하게 구성할 수 있는 중요한 요구 사항입니다.

우리가 위에서 설명한 위치 선언 유형을 염두에 두면, Nginx는 요청 URI를 각 위치와 비교하여 가능한 위치 컨텍스트를 평가합니다. 이를 다음과 같은 알고리즘을 사용하여 수행합니다:

  • Nginx는 먼저 모든 접두사 기반 위치 일치(정규 표현식을 포함하지 않는 모든 위치 유형)를 확인합니다. Nginx는 각 위치를 완전한 요청 URI와 비교합니다.
  • 먼저 Nginx는 정확한 일치를 찾습니다. 요청 URI와 정확하게 일치하는 위치 블록을 사용하는 경우(= 수정자 사용), 이 위치 블록이 즉시 요청을 처리하는 데 선택됩니다.
  • 정확한(수정자가 =인) 위치 블록 일치가 없는 경우 Nginx는 비정확한 접두사를 평가하기 위해 이동합니다. 주어진 요청 URI에 대해 가장 긴 일치하는 접두사 위치를 찾고 다음과 같이 평가합니다:
    • 가장 긴 일치하는 접두사 위치에 ^~ 수정자가 있는 경우, Nginx는 즉시 검색을 종료하고 이 위치를 선택하여 요청을 처리합니다.
    • 가장 긴 일치하는 접두사 위치가 ^~ 수정자를 사용하지 않는 경우, 일치는 잠시 Nginx에 의해 저장되어 검색의 중점을 변경할 수 있습니다.
  • 최장 일치 접두사 위치가 결정되고 저장되면 Nginx는 정규 표현식 위치(대소문자 구분 및 구분 없음)를 평가합니다. 최장 일치 접두사 위치 내부에 정규 표현식 위치가 있는 경우 Nginx는 이를 정규 표현식 위치 체크 목록의 최상단으로 이동시킵니다. 그런 다음 Nginx는 정규 표현식 위치와 순차적으로 일치하려고 시도합니다. 첫 번째 정규 표현식 위치가 요청 URI와 일치하면 즉시 요청을 처리하기 위해 선택됩니다.
  • 요청 URI와 일치하는 정규 표현식 위치가 없으면 이전에 저장된 접두사 위치가 요청을 처리하기 위해 선택됩니다.

기본적으로 Nginx가 접두사 일치보다 정규 표현식 일치를 우선시한다는 점을 이해하는 것이 중요합니다. 그러나 먼저 접두사 위치를 평가하여 관리자가 = 및 ^~ 수정자를 사용하여 위치를 지정함으로써 이 경향을 재정의할 수 있도록 합니다.

또한 접두사 위치가 일반적으로 가장 길고 가장 구체적인 일치를 기준으로 선택되는 반면, 정규 표현식 평가는 첫 번째 일치 위치가 발견되면 중단된다는 점을 주목하는 것이 중요합니다. 이는 정규 표현식 위치에 대해 구성 내 위치가 광범위한 영향을 미친다는 것을 의미합니다.

마지막으로, 일반적인 정규 표현식 일치 내에서 가장 긴 접두사 일치가 Nginx가 정규 표현식 위치를 평가할 때 “줄 바꿈”됨을 이해하는 것이 중요합니다. 이러한 것들은 다른 정규 표현식 일치가 고려되기 전에 순서대로 평가됩니다. 매우 유용한 Nginx 개발자인 Maxim Dounin은 선택 알고리즘의 이 부분을 이 게시물에서 설명합니다.

위치 블록 평가가 다른 위치로 이동하는 시점은 언제입니까?

일반적으로 요청을 처리할 위치 블록이 선택되면 요청은 그 지점부터 그 문맥에서 완전히 처리됩니다. 선택된 위치와 상속된 지시문만이 요청이 처리되는 방법을 결정하며 형제 위치 블록의 간섭 없이 처리됩니다.

이것은 예측 가능한 방식으로 위치 블록을 설계할 수 있도록 하는 일반적인 규칙이지만, 선택된 위치 내의 특정 지시문에 의해 새로운 위치 검색이 트리거되는 경우도 있음을 인식하는 것이 중요합니다. “하나의 위치 블록”규칙의 예외는 실제로 요청이 처리되는 방식에 영향을 미칠 수 있으며 위치 블록을 설계할 때 예상한 것과 일치하지 않을 수 있습니다.

이러한 유형의 내부 리디렉션으로 이어질 수 있는 일부 지시문은 다음과 같습니다:인덱스

  • 인덱스
  • try_files
  • 재작성
  • 에러_페이지

자세히 살펴보겠습니다.

인덱스 지시어는 요청을 처리하기 위해 사용되는 경우 항상 내부 리디렉션을 유발합니다. 정확한 위치 일치는 알고리즘의 실행을 즉시 종료하여 선택 프로세스를 가속화하는 데 자주 사용됩니다. 그러나 디렉토리에 정확한 위치 일치를 만드는 경우 요청이 실제 처리를 위해 다른 위치로 리디렉션될 가능성이 큽니다.

이 예에서 첫 번째 위치는 /exact의 요청 URI로 일치하지만 요청을 처리하기 위해 블록에서 상속된 인덱스 지시어가 두 번째 블록으로의 내부 리디렉션을 시작합니다.

index index.html;

location = /exact {

    . . .

}

location / {

    . . .

}

위의 경우 실제로 실행을 첫 번째 블록에 머무르게 하려면 디렉토리에 대한 요청을 충족시키는 다른 방법을 찾아야 합니다. 예를 들어 해당 블록에 무효한 인덱스를 설정하고 autoindex를 켤 수 있습니다.

location = /exact {
    index nothing_will_match;
    autoindex on;
}

location  / {

    . . .

}

이는 인덱스가 컨텍스트를 전환하지 않도록 방지하는 한 가지 방법이지만 대부분의 구성에 유용하지 않을 수 있습니다. 대부분 디렉터리에 대한 정확한 일치는 요청 재작성(이는 또한 새 위치 검색을 초래함)과 같은 것에 도움이 될 수 있습니다.

다음 구성을 고려하십시오:

위 예에서 /blahblah에 대한 요청이 있으면, 처음 위치가 먼저 해당 요청을 받습니다. 먼저 /var/www/main 디렉토리에서 blahblah라는 파일을 찾습니다. 파일을 찾을 수 없으면 blahblah.html이라는 파일을 찾습니다. 그런 다음 /var/www/main 디렉토리 내에 blahblah/라는 디렉토리가 있는지 확인합니다. 이러한 모든 시도에 실패하면 /fallback/index.html로 리디렉션됩니다. 이로 인해 다른 위치 검색이 트리거되어 두 번째 위치 블록에서 캐치됩니다. 이는 /var/www/another/fallback/index.html 파일을 제공합니다.

root /var/www/main;
location / {
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

rewrite 지시문도 위치 블록 패스 오프로 이어질 수 있습니다. rewrite 지시문에 last 매개변수를 사용하거나 매개변수를 전혀 사용하지 않을 때, Nginx는 리라이트 결과를 기반으로 새로운 일치하는 위치를 찾습니다.

예를 들어, 마지막 예제를 수정하여 리라이트를 포함하면, try_files 지시문을 사용하지 않고도 요청이 때로는 바로 두 번째 위치로 전달될 수 있음을 볼 수 있습니다:

위 예에서 /rewriteme/hello에 대한 요청은 처음 위치 블록에 의해 처음 처리됩니다. /hello로 재작성되고 위치가 검색됩니다. 이 경우, 다시 첫 번째 위치와 일치하여 try_files에 의해 보통 처리되며, 아무 것도 찾지 못하면(위에서 설명한 try_files 내부 리디렉션을 사용하여) /fallback/index.html로 되돌릴 수 있습니다.

root /var/www/main;
location / {
    rewrite ^/rewriteme/(.*)$ /$1 last;
    try_files $uri $uri.html $uri/ /fallback/index.html;
}

location /fallback {
    root /var/www/another;
}

그러나 /rewriteme/fallback/hello에 대한 요청이 있으면 다시 첫 번째 블록이 일치합니다. 다시 적용되는 리라이트는 /fallback/hello가 됩니다. 그런 다음 두 번째 위치 블록에서 요청이 처리됩니다.

error_page 지시문은 try_files가 만드는 것과 유사한 내부 리디렉션으로 이어질 수 있습니다. 이 지시문은 특정 상태 코드가 발생했을 때 어떻게 처리해야 하는지 정의하는 데 사용됩니다. 요청의 전체 라이프 사이클을 처리하는 try_files가 설정되어 있으면 이 지시문은 실행되지 않을 것입니다.

A related situation happens with the return directive when sending the 301 or 302 status codes. The difference in this case is that it results in an entirely new request in the form of an externally visible redirect. This same situation can occur with the rewrite directive when using the redirect or permanent flags. However, these location searches shouldn’t be unexpected, since externally visible redirects always result in a new request.

다음 예제를 고려해보십시오:

모든 요청( /another로 시작하는 것을 제외하고)은 첫 번째 블록에서 처리되며, 이 블록에서는 /var/www/main에서 파일이 제공됩니다. 그러나 파일을 찾을 수 없는 경우(404 상태), /another/whoops.html로 내부 리디렉션이 발생하여 결국 두 번째 블록에 도달합니다. 이 파일은 /var/www/another/whoops.html에서 제공됩니다. 

root /var/www/main;

location / {
    error_page 404 /another/whoops.html;
}

location /another {
    root /var/www;
}

보시다시피, Nginx가 새로운 위치 검색을 트리거하는 상황을 이해하면 요청을 할 때 볼 동작을 예측하는 데 도움이 됩니다.
결론

보시다시피, Nginx가 새로운 위치 검색을 트리거하는 상황을 이해하면 요청을 할 때 보게 될 동작을 예측하는 데 도움이 됩니다.

결론

Nginx가 클라이언트 요청을 처리하는 방식을 이해하면 관리자로서의 업무를 훨씬 수월하게 할 수 있습니다. 각 클라이언트 요청에 따라 Nginx가 어떤 서버 블록을 선택할지 알 수 있습니다. 또한 요청 URI에 따라 위치 블록이 어떻게 선택되는지 알 수 있습니다. 전반적으로 Nginx가 다양한 블록을 선택하는 방식을 아는 것은 Nginx가 각 요청을 제공하기 위해 적용할 컨텍스트를 추적할 수 있는 능력을 제공합니다.

Source:
https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms