여기서는 멈추세요
- nginx -t가 실패하거나 활성 설정에서 변경 대상 server block을 확정하지 못하면 reload하지 않습니다.
- 설정 출력에 인증정보가 포함됐다면 외부 공유 전에 제거하고 파일 권한을 재점검합니다.
REQUEST ROUTING
NGINX 404·잘못된 사이트·리다이렉트 루프가 발생할 때
실제 Host와 listen 조합, server·location 선택과 root·try_files·rewrite 흐름을 활성 설정 기준으로 확인합니다.nginx 404wrong server blockredirect looprewrite or internal redirection cycletoo many redirects
환경NGINX Open Source · Ubuntu 22.04·24.04 LTS · HTTP/HTTPS virtual server
분류웹·보안
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
SITE_CONFIG.before-haru-change를 원래 위치에 복원하고 nginx -t가 통과한 경우에만 reload한 뒤 이전 응답을 재확인합니다.
담당자에게 전달할 자료
- 요청 URL과 상태 코드·Server·Location 헤더 전체 체인
- 민감정보를 제거한 nginx -T의 관련 server·location 구간
- 같은 시각의 access·error 로그와 변경 전후 curl 결과
BEFORE YOU START
이런 증상에서 시작합니다
- 기본 NGINX 페이지 또는 다른 사이트 노출
- 특정 경로만 404
- Too many redirects
- rewrite or internal redirection cycle
CHECK THE BRANCH
놓치기 쉬운 원인 분기
다른 사이트가 열림
Host가 server_name과 일치하지 않으면 해당 주소·포트의 default server가 요청을 처리할 수 있으므로 DNS보다 활성 listen 구성을 먼저 대조합니다.
특정 경로만 404
location 우선순위, root와 alias 차이, try_files의 마지막 대상과 실제 파일 권한을 확인합니다.
301·302가 반복
NGINX rewrite뿐 아니라 upstream이 인식하는 scheme·Host와 프록시 헤더를 확인하고 전체 Location 체인을 기록합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
클라이언트 응답과 리다이렉트 위치 기록
브라우저 캐시보다 curl로 상태 코드, Server와 Location 헤더를 확인합니다.
응답 헤더
curl -sv -o /dev/null https://example.com/path리다이렉트 체인
curl -sS -o /dev/null -D - -L --max-redirs 10 https://example.com/path결과 읽기
404를 어느 서버가 보냈는지, Location이 같은 두 URL 사이를 반복하는지 확인합니다.
다음 판단
요청한 scheme·Host·port·path와 각 응답 코드를 기록합니다.
조회시스템을 변경하지 않는 확인 단계
현재 로드된 NGINX 설정 검증
파일 하나가 아니라 include가 펼쳐진 활성 설정을 기준으로 확인합니다. 외부 공유 전 비밀값을 가립니다.
설정 문법
sudo nginx -t활성 설정 전체
sudo nginx -T라우팅 지시어 위치
sudo nginx -T 2>&1 | grep -nE 'listen|server_name|root|alias|location|try_files|rewrite|return'결과 읽기
같은 listen 주소·포트의 default_server, 중복 server_name과 실제 include 순서를 확인합니다.
다음 판단
요청을 받아야 할 server block과 location을 정확히 지정합니다.
조회시스템을 변경하지 않는 확인 단계
DNS를 우회해 Host 선택 재현
SERVER_IP를 실제 NGINX 주소로 바꿔 DNS·CDN과 NGINX 내부 선택 문제를 분리합니다.
HTTP Host 직접 시험
curl -sv --resolve example.com:80:SERVER_IP http://example.com/path -o /dev/nullHTTPS SNI 직접 시험
curl -sv --resolve example.com:443:SERVER_IP https://example.com/path -o /dev/null결과 읽기
직접 연결은 정상인데 일반 요청만 실패하면 DNS·CDN·LB 범위이고, 직접 연결도 잘못되면 NGINX server 선택 문제입니다.
다음 판단
server_name과 인증서 SNI, default server를 함께 대조합니다.
주의서버 부하나 권한을 고려할 단계
location·파일·rewrite 순환 확인
장애 요청을 한 번만 재현하고 같은 시각의 access·error 로그를 확인합니다.
최근 error 로그
sudo tail -n 120 /var/log/nginx/error.log최근 access 로그
sudo tail -n 120 /var/log/nginx/access.log정적 파일 경로 권한
namei -l /var/www/example/path결과 읽기
rewrite or internal redirection cycle은 잘못된 URI 재처리 흐름을 뜻합니다. error log의 location과 try_files 대상을 설정에 연결합니다.
다음 판단
바꿀 지시어 한 곳과 기대 상태 코드·Location을 정합니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
설정 백업·문법 검사 후 reload
SITE_CONFIG를 실제 변경 파일로 바꾸고 nginx -t가 실패하면 reload하지 않습니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
변경 파일 백업
sudo cp -a /etc/nginx/sites-available/SITE_CONFIG /etc/nginx/sites-available/SITE_CONFIG.before-haru-change설정 최종 검사
sudo nginx -t무중단 reload
sudo systemctl reload nginxHost 기준 재검증
curl -sv --resolve example.com:443:SERVER_IP https://example.com/path -o /dev/null결과 읽기
예상 server와 location에서 의도한 상태 코드가 나오고 redirect 횟수와 error log가 정상화되어야 합니다.
다음 판단
문제가 생기면 백업 파일을 복원하고 nginx -t 통과 후 다시 reload합니다.
PRIMARY REFERENCES
공식 문서
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.