정규표현식 적용 NGINX 테스트 방법
이 포스터에서는 NGINX 정규표현식 테스트 방법에 대해 자세히 알아보기 전에 먼저 NGINX의 location 및 map에서 정규식을 사용하는 방법에 대해 논의해 보겠습니다.
목록
1. 정규표현식 이란 ?
2. 정규표현식 의 Locations
3. 정규표현식 의 Maps
4. 정규표현식 테스터
5. Location page 예
6. Map Page 예
7. 결론
1. 정규표현식 이란 ?
NGINX와 함께 사용할 정규식(regex)을 작업하는 동안 실제 NGINX 구성 내에서 정규표현식 을 쉽게 테스트할 수 있는 방법에 대한 아이디어를 얻었습니다. (정규식 테스트는 NGINX Open Source 및 NGINX Plus에서 동일하게 작동하며 읽기 쉽도록 이 포스트에서는 NGINX를 간단히 언급하겠습니다.)
정규표현식에 대한 지원은 NGINX의 강력한 기능 중 하나이지만, 정규표현식을 정기적으로 사용하지 않는 경우 정규표현식은 복잡하고 올바르게 이해하기 어려울 수 있습니다. NGINX는 location, map, rewrite 및 server name과 같은 구성의 여러 부분에서 정규표현식을 허용합니다. 여기에 설명된 테스터는 location 및 map의 정규식을 위한 것입니다.
대부분의 정규식에 적합한 다른 무료 온라인 정규식 테스터가 있지만 NGINX는 웹 애플리케이션에 최적화된 일부 비표준 단축키를 사용합니다. 예를 들어 표준 정규식에서와 같이 URI에서 슬래시(/)를 이스케이프할 필요가 없습니다. 또한 맵에서 정규식을 사용할 때 일치를 기반으로 설정할 값을 지정합니다. 다른 정규식 테스터를 사용하면 정규식을 수정하거나 맵의 경우 어떤 값이 설정될지 유추해야 할 수 있습니다. 또한 실제 환경에서 실제 정규식 엔진으로 정규식을 테스트할 수 있는 것이 항상 좋습니다.
참고 :
NGINX는 PCRE(Perl Compatible Regular Expressions)를 사용하며 이 포스트은 NGINX와 정규식 모두에 대한 기본적인 이해를 가정합니다. 정규식을 구성하는 방법을 설명하는 것은 이 포스의 범위를 벗어나며 그렇게 하는 방법에 대한 의견 및 추가 질문에 답변할 수 없는 점을 유감스럽게 생각합니다.
테스터는 두 가지 컨텍스트(map{}
블록 및 HTTP location{}
블록)에서 정규표현식을 처리하며 아래에는 각 경우에 정규표현식이 작동하는 방식에 대한 간략한 설명이 있습니다. NGINX가 모든 컨텍스트에서 정규식을 처리하는 방법을 설명하는 것은 이 포스트의 범위를 벗어납니다. 다음 문서를 참조하십시오.
- 상태 확인 :
- HTTP – nginxstore.com
- TCP – nginxstore.com
- UDP – nginxstore.com
- location{} 블록 – nginxstore.com
- map{} 블록 – nginxstore.com
- URI rewrites – nginxstore.com
- 가상 서버 이름 – nginxstore.com
테스터는 의도적으로 가능한 한 간단하게 설계되었으며 map 및 HTTP location에 대한 실제 NGINX 정규식 엔진을 사용하여 사용자가 작성한 대로 정규식을 테스트하는 한 가지 목적을 충족하도록 설계되었습니다. 결과적으로 작동하는 NGINX 구성을 생성하려면 최소한의 정보만 제공하면 됩니다. 기능(예: 테스트 전에 정규식 유효성 검사)을 추가할 계획이 없습니다. 이는 단순성의 기본 원칙을 위반하기 때문입니다. 물론 버그를 수정하게 되어 기쁩니다. GitHub의 issue 탭에 제출해 주세요.
2. 정규표현식 의 Locations
NGINX location{}
블록의 정규표현식은 다음과 같은 형식입니다.
location regex {
#...
}
예를 들어, 다음 정규식이 포함된 location{} 블록은 /test/myapp/hello.php 및 /myapp/hello.php와 같이 myapp/filename.php로 끝나는 URI가 있는 모든 PHP 요청을 처리합니다. 물결표(~*) 뒤의 별표는 일치 시 대소문자를 구분하지 않도록 합니다.
location ~* /myapp/.+\.php$ {
#...
}
NGINX 및 regex 테스터는 location{} 블록에서 location 캡처 그룹을 지원합니다. 다음 예에서 첫 번째 그룹은 PHP 파일 이름 앞의 모든 항목을 캡처하고 두 번째 그룹은 PHP 파일 이름을 캡처합니다.
location ~* (.*/myapp)/(.+\.php)$ {
#...
}
URI /myapp/hello.php의 경우 $1 변수는 /myapp으로 설정되고 $2는 hello.php로 설정됩니다. NGINX는 이름이 지정된 캡처 그룹도 지원합니다.
location ~* (?<begin>.*myapp)/(?<end>.+\.php)$ {
#...
}
이 경우 $begin 변수는 /myapp으로 설정되고 $end는 hello.php로 설정됩니다.
정규식 테스터는 이름이 지정된 캡처 그룹을 지원하지만 출력에서 위치 캡처 그룹처럼 취급하여 이름이 아닌 서수(ordinal numbers)를 표시합니다.
3. 정규표현식 의 Maps
정규식을 사용하는 NGINX map{} 블록은 다음 형식입니다.
map variable-to-test variable-to-set {
regex1 value-to-set-if-match;
regex2 value-to-set-if-match;
#...
regexN value-to-set-if-match;
default value-to-set-if-no-match;
}
예를 들어 이 map{} 블록은 URI($uri 변수에 기록된 대로)가 .php로 끝나는 경우 변수 $isphp를 1로 설정하고, 그렇지 않은 경우(대소문자 구분) 0으로 설정합니다.
map $uri $isphp {
~\.php$ 1;
default 0;
}
map의 경우 NGINX 및 정규식 테스터는 위치 및 이름이 지정된 캡처 그룹을 모두 지원합니다.
예를 들어, 다음 맵은 둘 다 $fileext 변수를 파일 확장자 값으로 설정하며 이 예에서도 $1로 캡처됩니다.
map $uri $fileext {
~*.+\.(.+)$ $1;
default '';
}
그리고 이 예에서 $ext로:
map $uri $fileext {
~*.+\.(?<ext>.+)$ $ext;
default '';
}
http{} 및 stream{} 컨텍스트 모두에서 map{} 블록에 정규식 테스터를 사용할 수 있습니다. map의 구문과 동작이 두 컨텍스트에서 동일하기 때문입니다. 그러나 map이 stream{} 컨텍스트에 있는 경우 테스터 출력의 map{} 블록만 사용할 수 있습니다. 자세한 내용은 아래 참고를 참조하십시오.
4. 정규표현식 테스터
정규식 테스터는 NGINX 및 NGINX Unit이 설치된 Docker 컨테이너에서 구현됩니다. NGINX Unit은 PHP 페이지의 두 가지 변형을 제공합니다. 하나는 location{} 블록의 정규식용이고 다른 하나는 map{} 블록의 정규식용입니다. 두 페이지는 사용자에게 서로 다른 입력을 요구합니다.
- Location page:
- 정규식
- 대소문자 구분
- URI
- Map page:
- 정규식
- 대소문자 구분
- 테스트할 값(지시문에 대한 첫 번째 매개변수인 변수 값
map
) map
지시문 의 두 번째 매개변수로 지정된 변수에 설정할 값
정보를 제공한 후 테스트 버튼을 클릭합니다. 테스터는 필요한 NGINX 구성 파일을 생성하고 구성이 다시 로드되며 정규식 테스트 요청이 전송됩니다. 그런 다음 결과가 표시되고 일치 항목이 있는지 여부를 나타냅니다. 그렇다면 Location Tester 페이지에는 캡처 그룹의 값이 표시되고 Map Tester 페이지에는 맵에서 설정한 값이 보고됩니다.
5. Location page 예
이 예는 URI /myapp/hello.php에 대한 정규식 (.*myapp)/(.+\.php)$의 대소문자를 구분하지 않는 테스트 결과를 보여줍니다.

6. Map Page 예
이 예는 /myapp/hello.php 값에 대한 정규식 .+\.(?<ext>.*)$의 대소문자를 구분하지 않는 테스트 결과를 보여줍니다. 이때 이름이 지정된 캡처 그룹 $ext는 설정할 값입니다.

참고: map이 stream{} 컨텍스트에 있는 경우 구성 출력에서 map{} 블록만 사용할 수 있습니다. server{} 블록은 stream{} 컨텍스트에서 지원되지 않는 location{} 블록을 포함하고 있기 때문에 유효하지 않습니다.
7. 결론
NGINX 구성이 매우 짧고 단순하다는 것을 알 수 있습니다. 힘든 작업은 사용자가 입력한 값을 기반으로 필요한 NGINX 구성 파일을 생성하고, NGINX를 다시 로드하고, NGINX에 요청을 보내고, 결과를 표시하는 PHP 페이지에서 수행됩니다.
정규식 테스터를 직접 사용해 볼 수 있습니다. 모든 코드는 GitHub 리포지토리(https://github.com/nginxinc/NGINX-Demos/tree/master/nginx-regex-tester)에서 사용할 수 있습니다.
정규식 테스터를 쉽게 시작하고 실행할 수 있도록 필요한 모든 파일이 포함되어 있습니다. Docker 이미지를 빌드하고 컨테이너를 빌드하려면 다음을 실행하십시오.
$ docker-compose up -d
그런 다음 브라우저에서 http://Docker-host/regextester.php로 이동하십시오.
정규식을 사용할 때 테스터가 도움이 되고 NGINX의 기능, 유연성 및 단순성을 확인 수 있기를 바랍니다.
프로덕션급 NGINX인 NGINX Plus를 사용해 보려면 지금 무료 30일 평가판을 시작하거나 당사에 연락하여 사용 사례에 대해 문의하십시오.
또한 NGINX에 대한 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.
댓글을 달려면 로그인해야 합니다.