nginx location 테스터 — 그 블록이 이기는 이유

nginx location 매칭: 빠른 답변

nginx location 블록이란?

# From the nginx documentation. Which block serves each request?
server {
    location = /                   { }   # A
    location /                     { }   # B
    location /documents/           { }   # C
    location ^~ /images/           { }   # D
    location ~* \.(gif|jpg|jpeg)$  { }   # E
}

#   /                        -> A   exact match, search ends here
#   /index.html              -> B   no regex matched, longest prefix used
#   /documents/document.html -> C   longer prefix than B
#   /images/1.gif            -> D   ^~ won the prefix stage, regex skipped
#   /documents/1.jpg         -> E   regex beats the longer prefix C

# The last two lines are the whole lesson: identical-looking prefixes
# behave differently because only one of them carries ^~.

주요 기능

이 질문에 답하는 다른 방법

nginx location 매칭 예제

location /documents/  ·  location ~* \.(gif|jpg|jpeg)$  ·  GET /documents/1.jpg

~* \.(gif|jpg|jpeg)$ wins

location /uploads/  ·  location ~ \.php$ { fastcgi_pass ... }  ·  GET /uploads/evil.php

~ \.php$ wins — the upload lands in the interpreter

location ^~ /a/  ·  location /a/b/  ·  location ~ \.php$  ·  GET /a/b/x.php

~ \.php$ wins — the ^~ never applied

location /static  ·  location /static/  ·  GET /staticfoo

/static wins

location ~ ^/a  ·  location ~ ^/a/b/c$  ·  GET /a/b/c

~ ^/a wins; ~ ^/a/b/c$ is unreachable

location /a/  ·  location /b/  ·  GET /a/b%2F..%2Fzz

$uri becomes /a/zz, so /a/ wins

nginx location 테스터 사용법

1. 1

   server 블록 붙여넣기

   server 블록 전체를 넣어도 되고, 따져 보려는 location 블록만 넣어도 됩니다. 중첩 location도 인식하며 원래 줄 번호를 유지하므로 표가 내 파일과 맞아떨어집니다.

2. 2

   요청 URI 입력하기

   퍼센트 인코딩과 쿼리 문자열을 포함해 네트워크로 들어오는 그대로의 경로를 입력하세요. 표 위의 세 줄이 매칭 전에 어떻게 정규화되는지 보여줍니다.

3. 3

   승자를 읽고, 그다음 패자를 읽기

   판정 카드가 선택된 블록과 한 줄짜리 이유를 알려 줍니다. 그 아래 판정 표는 나머지 모든 블록에 대해 어느 단계에서 왜 탈락했는지 설명합니다.

4. 4

   진단 확인하기

   앵커가 없는 정규식, 끝 슬래시가 빠진 접두사, 정규식 패턴을 달고 있는 ^~, 도달 불가한 중복, PHP 정규식으로 도달 가능한 업로드 디렉터리가 모두 보고됩니다.

5. 5

   정확한 상태 공유하기

   링크 복사는 설정과 URI를 URL 프래그먼트에 인코딩하므로 동료가 내가 보고 있는 화면을 그대로 엽니다. 프래그먼트는 서버로 전송되지 않습니다.

흔한 nginx location 실수

location ^~ /a/ { }
location /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ~ \.php$

location ^~ /a/ { }
location ^~ /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ^~ /a/b/

location /static { root /var/www; }
# also serves /staticfoo and /static-backup

location /static/ { root /var/www; }
location = /static { return 301 /static/; }

location ~ ^/api { }
location ~ ^/api/v2/users$ { }
# the second is unreachable

location ~ ^/api/v2/users$ { }
location ~ ^/api { }

location ^~ "\.php$" { deny all; }

location ~ \.php$ { deny all; }

location /search?q= { }
# never matches anything

location /search {
    if ($arg_q = "") { return 400; }
}

nginx location 테스터로 할 수 있는 일

운영에 나가기 전에 설정 점검하기

수정했지만 아직 배포하지 않은 server 블록의 라우팅을 따져 보세요. 여기서 잡히는 장애는 특정한 형태의 URI에서만 드러나는 종류이고, 리로드 후 스모크 테스트가 놓치기 딱 좋은 종류이기도 합니다.

규칙이 왜 멈췄는지 알아내기

돌던 정규식이 이제 돌지 않는다면 거의 항상 순서의 피해자입니다. 무언가가 먼저 매칭됐거나 그 위에 ^~ 가 생겼습니다. 표는 그 블록을 도달 불가로 표시하고 요청을 가져간 블록의 이름을 알려 줍니다.

업로드나 미디어 디렉터리 감사하기

업로드 실행 형태를 재현하는 프리셋을 불러온 다음 자신의 경로를 넣어 보세요. 쓰기가 허용된 디렉터리 안에서 PHP 정규식이 요청을 가져가고 있다면 진단이 그 사실과 두 블록의 이름을 알려 줍니다.

리뷰 코멘트를 근거로 마무리하기

링크 복사는 정확한 설정과 URI를 URL 프래그먼트에 담습니다. 그것을 풀 리퀘스트에 넣으면 우선순위를 둘러싼 말싸움이 누구나 다시 돌려볼 수 있는 판정 표로 바뀝니다.

선택 알고리즘 가르치기

두 개의 레퍼런스 표는 가리켜 보일 수 있는 정적이고 크롤링 가능한 자료이며, 프리셋 칩은 서버를 망가뜨리지 않고도 각 함정을 보여 줍니다. 특히 ^~ 예제는 논쟁을 빠르게 끝내는 편입니다.

nginx location 선택은 어떻게 이뤄지나

정규화는 어떤 location을 살펴보기도 전에 일어난다

URI는 퍼센트 디코딩되고 . 과 .. 세그먼트가 해석되며 반복된 슬래시가 합쳐지고, 그러고 나서야 location이 선택됩니다. 디코딩된 %2F 는 진짜 구분자가 되어 그 해석에 참여하므로 /a/b%2F..%2Fzz 는 /a/zz 로 매칭됩니다. 디코딩된 문자 셋은 예외로 문자 그대로 남습니다. %25, %23, %3F 이며, /a%3Fx=1 의 경로에 물음표가 있고 쿼리 문자열이 비는 이유가 이것입니다. 여기서 + 는 공백이 아닙니다. %20 만 공백입니다. 루트 위로 올라가는 경로 이동과 잘못된 이스케이프는 둘 다 매칭이 시작되기 전에 400으로 거부됩니다.

접두사 길이가 결정하고, 설정 순서는 결정하지 않는다

매칭되는 모든 접두사 location을 비교해 가장 긴 것이 이깁니다. 파일에서 처음에 나오든 마지막에 나오든 상관없습니다. 비교는 경로 세그먼트가 아니라 문자 단위이므로 /static 은 /staticfoo 에 매칭됩니다. 승자는 곧바로 쓰이지 않고 기억됩니다. 정규식 단계가 아직 그것을 뒤집을 수 있기 때문입니다.

^~ 는 정규식을 억제할 뿐, 우선순위를 올리지 않는다

이 수식자는 이미 길이로 이긴 접두사에 대해서만 확인됩니다. 더 긴 일반 접두사도 매칭된다면 그쪽이 대신 기억되고 정규식 단계는 평소대로 돕니다 — ^~ 블록은 그 요청에 아무런 영향이 없습니다. 중첩된 location에 ^~ 를 두어도 바깥 레벨에 선언된 정규식으로부터 보호되지 않으며, 자기 블록 안에 중첩된 정규식은 결코 억제하지 않습니다.

정규식은 파일 순서로 돌고 첫 매칭이 탐색을 끝낸다

nginx는 정규식 location을 작성된 순서대로 유지하며 정렬하지 않습니다. 구체성, 길이, 앵커링은 어느 것이 먼저 시도되는지에 아무 영향도 주지 않으므로, 넓은 패턴 아래에 놓인 정밀한 패턴은 죽은 설정입니다. 매칭된 정규식 location 안으로도 내려가므로 그 안에 중첩된 location은 그다음에 탐색됩니다.

PCRE와 ECMAScript는 같은 언어가 아니다

nginx는 UTF 모드도 멀티라인 모드도 없이 PCRE로 location 정규식을 컴파일하므로, 패턴은 바이트 단위로 동작하고 ^ 는 URI 시작에만 앵커됩니다. 한 가지 차이는 보안 무게가 있습니다. PCRE의 $ 는 끝에 붙은 개행 바로 앞에서도 매칭되므로, %0A 로 끝나는 URI는 JavaScript 엔진이라면 거부했을 상황에서도 여전히 \.php$ 를 만족합니다. 이 동작은 여기서 그대로 흉내 내어 보고됩니다. 파일 확장자에 기댄 규칙을 빠져나가는 알려진 수법이기 때문입니다.

nginx location 모범 사례

쓰기 가능한 디렉터리는 일반 접두사가 아니라 ^~ 로 보호하기

업로드를 받는 디렉터리에는 location ^~ /uploads/ 가 필요합니다. 그래야 정규식 단계가 저장된 파일을 인터프리터에 넘길 수 없습니다. 일반 접두사는 같아 보이지만 같지 않습니다.

디렉터리 접두사에는 끝 슬래시 붙이기

/staticfoo 와 /static-backup 까지 같은 블록이 서비스하기를 일부러 원하는 게 아니라면 location /static 대신 location /static/ 로 쓰세요. 슬래시 없는 경로도 처리해야 한다면 location = /static 을 따로 추가하면 됩니다.

정규식은 구체적인 것부터 넓은 것 순으로 배치하기

첫 매칭이 이기므로 넓은 패턴이 정밀한 패턴 위에 있으면 정밀한 쪽은 도달 불가가 됩니다. 정규식 수를 적게 유지하고 순서를 의도적으로 두는 편이, 나중에 겹침을 따지는 것보다 유지보수가 쉽습니다.

경로 접두사를 매칭하려는 정규식에는 앵커 붙이기

location ~ /admin 은 URI 안 어디에서든 찾으므로 /public/admin/x 에도 매칭됩니다. 시작을 뜻한다면 ~ ^/admin 이라고 쓰세요. 끝에만 앵커를 두는 것은 확장자 라우팅에서는 정상이고 올바릅니다.

순서를 바꿨다면 라우팅을 다시 확인하기

블록을 옮기는 일은 접두사에는 안전하지만 정규식의 동작은 바꿉니다. 줄 순서만 바꾼 diff는 리뷰에서 무해해 보이므로, 영향받는 URI를 다시 돌려보는 것이 가장 값싼 확인 방법입니다.

nginx location 테스터 자주 묻는 질문