Nginx 설정 검사기
nginx.conf를 붙여넣어 nginx를 리로드하기 전에 문법 오류, 잘못 배치된 지시어, 흔한 보안 설정 실수를 찾아보세요.
여기에 .conf 파일을 드롭하거나, 위에 설정 텍스트를 붙여넣으세요.
모든 처리는 브라우저 안에서 이루어집니다 — 설정 내용은 어떤 서버로도 업로드되지 않습니다.
위에 nginx 설정을 붙여넣거나 샘플을 불러오면 검사 결과가 여기에 표시됩니다.
nginx의 실제 PCRE 엔진이 아닌 JavaScript의 정규식 엔진을 사용합니다 — 일반적인 패턴에서는 매우 비슷하지만, possessive quantifier나 atomic group 같은 PCRE 전용 기능은 동일하게 동작하지 않습니다.
운영 환경에 가기 전에 nginx 설정 실수 잡기
망가진 nginx.conf는 보통 두 가지 불쾌한 방식으로 모습을 드러냅니다. `nginx -t`가 알쏭달쏭한 줄 번호 오류와 함께 리로드를 거부하거나, 더 나쁘게는 `reload`가 새 설정이 디스크에서 망가진 채로 있는 동안 예전(정상) 설정을 메모리에 그대로 유지해서 다음 전체 재시작 때까지 아무 문제도 없는 것처럼 보이는 경우입니다. 둘 다 편집하는 동안 같은 종류의 실수를 더 일찍 잡으면 피할 수 있습니다.
가장 흔한 실제 nginx.conf 실수는 특별하지 않습니다. 세미콜론을 빠뜨리는 것입니다. nginx 문법은 줄바꿈이 아니라 `;`, `{`, `}`만 신경 쓰기 때문에, `;`가 빠져도 대부분의 최신 파서처럼 "12번째 줄: ;가 필요합니다" 같은 깔끔한 오류가 나지 않습니다. 대신 다음 지시어의 이름과 인수가 이전 지시어의 추가 인수로 조용히 흡수되어, 아래쪽에서 이상한 동작이 나타날 때까지 오류가 없을 수도 있습니다. 이 도구의 줄바꿈 휴리스틱은 새 줄에서 알려진 지시어 이름이 인수 목록 중간에 나타나는 이 패턴을 특히 눈여겨보고, 문의 티켓으로 번지기 전에 알려 줍니다.
지시어 위치는 두 번째로 흔한 함정입니다. `proxy_pass`는 `location`(또는 `if`) 블록 안에서만, `listen`/`server_name`은 `server` 안에서만 의미가 있습니다. 그런데 nginx 자체 파서는 더 넓은 의미에서 인식하는 지시어 이름이면 이상한 위치에 있어도 거부하지 않을 수 있고, 오류 메시지도 "잘못 중첩했다"가 아니라 nginx 내부의 지시어 목록을 가리킵니다. 이 검사기는 지시어와 컨텍스트의 대응표를 직접 확인하므로, 실수로 `http` 수준(`server`/`location` 밖)에 남은 `proxy_pass`도 "설정을 불러오지 못했습니다"가 아니라 정확한 줄과 함께 표시됩니다.
구문 외에도 작은 설정 선택 몇 가지가 보안에 큰 영향을 줍니다. `server_tokens`를 기본값(`on`)으로 두면 모든 응답 헤더와 기본 오류 페이지에 정확한 nginx 버전이 노출되어, 특정 버전의 CVE를 찾는 사람에게 공짜 정찰 정보를 주는 셈입니다. `return`/`rewrite`/`add_header`에서 원본 `$request_uri` 대신 URL 디코딩된 `$uri` 변수를 쓰면 일부 설정에서 공격자가 리디렉션 대상에 문자를 주입할 수 있습니다. 둘 다 평소 테스트에서는 눈에 띄는 문제를 일으키지 않으므로, 200줄짜리 설정을 눈으로 훑어서 발견하기보다 별도의 검사로 확인할 가치가 있습니다.
자주 묻는 질문
`nginx -t`를 대체하나요?
아니요. `nginx -t`는 서버에 실제로 설치된 nginx 빌드와 모듈을 기준으로 설정을 검사하는 유일한 도구이며, 리로드 전의 최종 확인입니다. 이 검사기는 구문 오류, 잘못된 지시어 위치, 몇 가지 보안상 위험 신호처럼 같은 종류의 실수를 nginx가 설치된 서버에 가기 전에 잡아 줍니다. 로컬에서 편집할 때, CI 단계에서, 아직 대상 서버에 셸 접근 권한이 없을 때 유용합니다.
보안 점검 목록이 완전한가요?
아니요. 오픈소스 nginx 설정 감사 도구인 Gixy에서 느슨하게 착안해 의도적으로 고른 소수의 검사(`server_tokens off;` 누락, `autoindex on;`, `$request_uri`가 더 안전한 곳에 쓴 `$uri`)만 다룹니다. Gixy나 전체 보안 감사를 대체하지는 않습니다.
정규식 테스터가 실제 nginx와 조금 다르게 동작하는 이유는 무엇인가요?
nginx의 `location ~`와 `location ~*` 매칭은 nginx 바이너리에 포함된 PCRE 라이브러리를 사용합니다. 이 도구는 브라우저에서만 실행되므로 JavaScript 내장 RegExp 엔진을 사용합니다. 일반적인 패턴에서는 둘이 매우 비슷하지만, 소유형 수량자나 원자 그룹처럼 PCRE에만 있는 기능은 여기서 같게 동작하지 않습니다.
내 설정이 브라우저 밖으로 나가나요?
아니요. 파싱, 검증, 두 시뮬레이터 모두 이 탭에서 순수 JavaScript로 실행됩니다. 업로드, 기록, 전송이 전혀 없으며, 페이지를 불러온 뒤 인터넷 연결을 끊어도 계속 동작합니다.