검사한 파일과 서비스가 읽는 파일부터 맞추기
nginx -t 성공 뒤 화면이 그대로라면 같은 검사를 반복하기 전에 검사 대상과 실행 대상을 비교합니다. systemd로 관리하는 서버에서는 아래 읽기 전용 명령으로 실행·reload 명령을 볼 수 있습니다. 컨테이너나 수동 실행 환경이라면 해당 실행 명령과 설정 경로를 확인해야 합니다.
systemctl show nginx -p ExecStart -p ExecReload
nginx -V후보 파일의 문법을 검사한 것과 실행 중인 master에 반영한 것은 다릅니다. 펀치블로그의 격리 실험에서도 올바른 후보 검사는 종료 코드 0이었지만 적용 전 응답은 config-v1이었습니다. 해당 임시 프로세스에 반영한 뒤에야 config-v2가 나왔습니다. 반영 완료의 기준을 신호 명령의 성공이 아니라 바꾸려던 응답으로 정해야 합니다.
한 개의 정상 URL로 끝내지 않는 확인표
| 확인 대상 | 볼 항목 | 잘못됐을 때 좁힐 범위 |
|---|---|---|
| 기존 정상 문서 | 상태·본문·기대한 헤더 | server_name, root, 적용 대상 |
| 실제 존재하는 CSS 파일 | 본문 형식과 Content-Type | 자산 location과 파일 경로 |
| 없는 글·없는 CSS | 의도한 404와 오류 본문 | try_files와 error_page |
| 캐시 경로 | 공개 응답과 원본 상태·갱신 시각 | 저장본 재사용 조건 |
| 압축 경로 | 요청 Accept-Encoding과 Content-Encoding | 응답 형식·압축 조건 |
예를 들어 정상 HTML에서는 보이던 헤더가 CSS에서 빠진다면 전역 설정만 읽지 말고 자산을 처리하는 location을 확인합니다. 헤더 상속 실험은 그 범위를 분리합니다. 원본이 실패하는데 공개 응답이 200이면 캐시가 저장본을 반환했을 수도 있습니다. 각각의 판단 근거가 달라서 재시작 한 번으로 묶어 해결하려 하지 않습니다.