웹사이트 검색

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

소개

Nginx는 세계에서 가장 인기 있는 웹 서버 중 하나입니다. 동시 클라이언트 연결이 많은 높은 부하를 성공적으로 처리할 수 있으며 웹 서버, 메일 서버 또는 역방향 프록시 서버로 작동할 수 있습니다.

이 가이드에서는 Nginx가 클라이언트 요청을 처리하는 방법을 결정하는 비하인드 스토리 세부 정보에 대해 설명합니다. 이러한 아이디어를 이해하면 서버 및 위치 블록을 설계할 때 추측을 피하고 요청 처리를 덜 예측할 수 있게 만들 수 있습니다.

Nginx 블록 구성

Nginx는 다양한 콘텐츠를 제공하기 위한 구성을 계층 구조에 있는 블록으로 논리적으로 나눕니다. 클라이언트 요청이 있을 때마다 Nginx는 요청을 처리하는 데 사용할 구성 블록을 결정하는 프로세스를 시작합니다. 이 결정 프로세스는 이 가이드에서 논의할 내용입니다.

우리가 논의할 주요 블록은 서버 블록과 위치 블록입니다.

서버 블록은 정의된 유형의 요청을 처리하는 데 사용되는 가상 서버를 정의하는 Nginx 구성의 하위 집합입니다. 관리자는 종종 여러 서버 블록을 구성하고 요청된 도메인 이름, 포트 및 IP 주소를 기반으로 어떤 연결을 처리해야 하는지 블록을 결정합니다.

위치 블록은 서버 블록 내에 있으며 Nginx가 부모 서버의 다양한 리소스 및 URI에 대한 요청을 처리하는 방법을 정의하는 데 사용됩니다. URI 공간은 관리자가 이러한 블록을 사용하여 원하는 방식으로 세분화할 수 있습니다. 매우 유연한 모델입니다.

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

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

이는 가능한 최상의 일치를 찾는 데 사용되는 정의된 검사 시스템을 통해 수행됩니다. 이 프로세스 중에 Nginx가 관련된 주요 서버 블록 지시문은 listen 지시문과 server_name 지시문입니다.

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

먼저 Nginx는 요청의 IP 주소와 포트를 확인합니다. 각 서버의 listen 지시문과 비교하여 요청을 해결할 수 있는 서버 블록 목록을 작성합니다.

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

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

  • IP 주소/포트 콤보.
  • 기본 포트 80에서 수신할 단일 IP 주소.
  • 해당 포트의 모든 인터페이스를 수신하는 단일 포트.
  • Unix 소켓의 경로.

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

요청을 보낼 서버 블록을 결정할 때 Nginx는 먼저 다음 규칙을 사용하여 listen 지시문의 특이성을 기반으로 결정을 시도합니다.

  • Nginx는 각 블록이 IP 주소와 포트로 평가될 수 있도록 누락된 값을 기본값으로 대체하여 모든 "불완전한\ listen 지시문을 변환합니다. 이러한 변환의 몇 가지 예는 다음과 같습니다.\n
    • listen 지시문이 없는 블록은 0.0.0.0:80 값을 사용합니다.
    • 포트가 없는 IP 주소 111.111.111.111로 설정된 블록은 111.111.111.111:80
      • 이 됩니다.
    • IP 주소 없이 8888 포트로 설정된 블록은 0.0.0.0:8888
      • 이 됩니다.

    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이 있는 서버 블록을 찾습니다. /코드> 구성에서). 하나가 발견되면 해당 블록이 요청을 처리하는 데 사용됩니다. 일치 항목이 여러 개 발견되면 가장 긴 일치 항목이 요청을 처리하는 데 사용됩니다.
    • 후행 와일드카드를 사용하여 일치하는 항목이 없으면 Nginx는 정규식(이름 앞에 ~로 표시됨)을 사용하여 server_name을 정의하는 서버 블록을 평가합니다. "Host\ 헤더와 일치하는 정규 표현식이 있는 첫 번째 server_name은 요청을 처리하는 데 사용됩니다.
    • 일치하는 정규 표현식이 없으면 Nginx는 해당 IP 주소 및 포트에 대한 기본 서버 블록을 선택합니다.

    각 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이 있는지 확인합니다. 요청을 이행하기 위해 와일드카드로 시작하는 가장 긴 일치 항목이 선택됩니다.

    이 예에서 요청에 www.example.org의 Host 헤더가 있는 경우 두 번째 서버 블록이 선택됩니다.

    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 또는 <와 같은 요청 URI에 응답하기 위해 다음 위치 블록을 선택할 수 있습니다. 코드>/사이트/index.html:

    location /site {

    . . .

}

    정확한 요청 URI 일치를 보여주기 위해 이 블록은 항상 /page1과 같은 요청 URI에 응답하는 데 사용됩니다. /page1/index.html 요청 URI에 응답하는 데 사용되지 않습니다. 이 블록이 선택되고 인덱스 페이지를 사용하여 요청이 이행되면 요청의 실제 핸들러가 될 다른 위치로 내부 리디렉션이 발생합니다.

    location = /page1 {

    . . .

}

    대소문자를 구분하는 정규식으로 해석되어야 하는 위치의 예로, 이 블록은 /tortoise.jpg에 대한 요청을 처리하는 데 사용될 수 있지만 /FLOWER.PNG<에 대한 요청은 처리할 수 없습니다. /코드>:

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

    . . .

}

    위와 유사한 대소문자를 구분하지 않는 일치를 허용하는 블록이 아래에 나와 있습니다. 여기서 /tortoise.jpg 및 /FLOWER.PNG는 이 블록에서 처리할 수 있습니다.

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

    . . .

}

    마지막으로 이 블록은 최상의 비정규식 일치로 결정된 경우 정규식 일치가 발생하지 않도록 합니다. /costumes/ninja.html에 대한 요청을 처리할 수 있습니다.

    location ^~ /costumes {

    . . .

}

    보시다시피 수정자는 위치 블록을 해석하는 방법을 나타냅니다. 그러나 이것은 Nginx가 요청을 보낼 위치 블록을 결정하는 데 사용하는 알고리즘을 알려주지 않습니다. 이에 대해서는 다음에 살펴보겠습니다.

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

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

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

    • Nginx는 모든 접두사 기반 위치 일치(정규 표현식을 포함하지 않는 모든 위치 유형)를 확인하는 것으로 시작합니다. 전체 요청 URI에 대해 각 위치를 확인합니다.
    • 먼저 Nginx는 정확히 일치하는 항목을 찾습니다. = 수정자를 사용하는 위치 블록이 요청 URI와 정확히 일치하는 것으로 확인되면 이 위치 블록이 즉시 선택되어 요청을 처리합니다.
    • 정확한(= 수식어 사용) 위치 블록 일치 항목이 없으면 Nginx는 계속해서 정확하지 않은 접두사를 평가합니다. 주어진 요청 URI에 대해 가장 긴 일치 접두사 위치를 찾은 다음 다음과 같이 평가합니다.\n
      • 가장 일치하는 접두사 위치에 ^~ 수정자가 있는 경우 Nginx는 즉시 검색을 종료하고 이 위치를 선택하여 요청을 처리합니다.
      • 가장 긴 일치 접두사 위치가 ^~ 수식어를 사용하지 않는 경우 검색 초점을 이동할 수 있도록 일치 항목이 Nginx에 잠시 동안 저장됩니다. .

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

      접두사 위치는 일반적으로 가장 길고 가장 구체적인 일치 항목을 기준으로 선택하지만 첫 번째 일치 위치가 발견되면 정규식 평가가 중지된다는 점도 중요합니다. 즉, 구성 내의 위치 지정은 정규식 위치에 대해 막대한 영향을 미칩니다.

      마지막으로, 가장 긴 접두사 일치 내의 정규식 일치는 Nginx가 정규식 위치를 평가할 때 "줄을 건너뜁니다\는 점을 이해하는 것이 중요합니다. 이들은 순서대로 다른 것보다 먼저 평가됩니다. 매우 유용한 Nginx 개발자인 Maxim Dounin은 이 게시물에서 선택 알고리즘의 이 부분에 대해 설명합니다.

      위치 블록 평가는 언제 다른 위치로 이동합니까?

      일반적으로 요청을 처리하기 위해 위치 블록이 선택되면 요청은 해당 시점부터 해당 컨텍스트 내에서 전적으로 처리됩니다. 선택한 위치와 상속된 지시문만 형제 위치 블록의 간섭 없이 요청 처리 방법을 결정합니다.

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

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

      • 색인
      • try_files
      • 재작성
      • error_page

      간단히 살펴보겠습니다.

      index 지시문은 요청을 처리하는 데 사용되는 경우 항상 내부 리디렉션으로 이어집니다. 정확한 위치 일치는 알고리즘 실행을 즉시 종료하여 선택 프로세스의 속도를 높이는 데 자주 사용됩니다. 그러나 디렉토리인 정확한 위치 일치를 만들면 실제 처리를 위해 요청이 다른 위치로 리디렉션될 가능성이 높습니다.

      이 예에서 첫 번째 위치는 /exact의 요청 URI와 일치하지만 요청을 처리하기 위해 블록이 상속한 index 지시문은 내부 리디렉션을 시작합니다. 두 번째 블록:

      index index.html;

location = /exact {

    . . .

}

location / {

    . . .

}

      위의 경우 첫 번째 블록에 실행을 유지해야 하는 경우 디렉터리에 대한 요청을 만족시키는 다른 방법을 생각해 내야 합니다. 예를 들어 해당 블록에 대해 잘못된 index를 설정하고 autoindex를 켤 수 있습니다.

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

location  / {

    . . .

}

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

      처리 위치를 재평가할 수 있는 또 다른 인스턴스는 try_files 지시문을 사용하는 것입니다. 이 지시어는 Nginx에게 이름이 지정된 파일 또는 디렉토리 집합이 있는지 확인하도록 지시합니다. 마지막 매개변수는 Nginx가 내부 리디렉션을 만들 URI일 수 있습니다.

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

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

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

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

      위치 블록 통과로 이어질 수 있는 또 다른 지시문은 rewrite 지시문입니다. rewrite 지시문과 함께 last 매개변수를 사용하거나 매개변수를 전혀 사용하지 않을 때 Nginx는 재작성 결과를 기반으로 새로운 일치 위치를 검색합니다.

      예를 들어 재작성을 포함하도록 마지막 예를 수정하면 try_files 지시문에 의존하지 않고 요청이 두 번째 위치로 직접 전달되는 경우가 있음을 알 수 있습니다.

      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/hello에 대한 요청은 처음에 첫 번째 위치 블록에 의해 처리됩니다. /hello로 다시 작성되고 위치가 검색됩니다. 이 경우 첫 번째 위치와 다시 일치하고 평소와 같이 try_files에 의해 처리됩니다. 아무 것도 발견되지 않으면 (사용하여 위에서 논의한 try_files 내부 리디렉션).

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

      301 또는 302 상태 코드를 보낼 때 return 지시문과 관련된 상황이 발생합니다. 이 경우의 차이점은 외부에서 볼 수 있는 리디렉션의 형태로 완전히 새로운 요청이 발생한다는 것입니다. redirect 또는 permanent 플래그를 사용할 때 rewrite 지시문에서도 이와 동일한 상황이 발생할 수 있습니다. 그러나 외부에서 볼 수 있는 리디렉션은 항상 새로운 요청으로 이어지기 때문에 이러한 위치 검색은 예상치 못한 일이 아닙니다.

      error_page 지시문은 try_files에 의해 생성된 것과 유사한 내부 리디렉션으로 이어질 수 있습니다. 이 지시문은 특정 상태 코드를 만났을 때 발생해야 하는 일을 정의하는 데 사용됩니다. try_files가 설정된 경우 해당 지시문이 요청의 전체 수명 주기를 처리하므로 이 명령은 실행되지 않을 가능성이 높습니다.

      다음 예를 고려하십시오.

      root /var/www/main;

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

location /another {
    root /var/www;
}

      모든 요청(/another로 시작하는 요청 제외)은 /var/www/main에서 파일을 제공하는 첫 번째 블록에서 처리됩니다. 그러나 파일을 찾을 수 없는 경우(404 상태) /another/whoops.html로의 내부 리디렉션이 발생하여 결국 두 번째 블록에 도달할 새로운 위치 검색으로 이어집니다. 이 파일은 /var/www/another/whoops.html에서 제공됩니다.

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

      결론

      Nginx가 클라이언트 요청을 처리하는 방식을 이해하면 관리자의 작업이 훨씬 쉬워질 수 있습니다. 각 클라이언트 요청에 따라 Nginx가 선택할 서버 블록을 알 수 있습니다. 또한 요청 URI를 기반으로 위치 블록이 선택되는 방법을 알 수 있습니다. 전반적으로 Nginx가 다른 블록을 선택하는 방식을 알면 Nginx가 각 요청을 처리하기 위해 적용할 컨텍스트를 추적할 수 있습니다.