nginx -t는 통과했는데 응답 헤더가 사라졌다: 상속과 always

서버 공통 설정에 헤더를 추가했는데 특정 경로에서만 보이지 않는다면 설정 파일에서 해당 문자열을 찾는 것만으로는 원인을 알기 어렵다. 실제 응답을 만드는 location과 응답 상태에 따라 결과가 달라지기 때문이다. 이번에는 네 개의 작은 경로를 가진 Nginx를 별도로 띄워 어느 경우에 헤더가 사라지는지 비교했다.

검사 성공과 응답 정책 충족은 다르다

실험 설정은 nginx -t 종료 코드 0으로 문법 검사를 통과했다. 서버 공통 범위에는 X-Content-Type-Options: nosniff를 설정했다. /inherited는 자체 add_header 없이 200, /overridden은 다른 이름의 헤더를 추가하고 200, /error는 404를 반환했다. /fixed는 두 헤더를 그 location에 명시하고 always를 붙여 404를 반환했다.

server {
    # listen 등은 내려받을 수 있는 전체 설정에 포함
    add_header X-Content-Type-Options nosniff;
    location = /inherited { return 200 'inherited'; }
    location = /overridden {
        add_header X-Lab-Route local;
        return 200 'overridden';
    }
    location = /error { return 404; }
    location = /fixed {
        add_header X-Lab-Route local always;
        add_header X-Content-Type-Options nosniff always;
        return 404;
    }
}

네 경로는 같은 Nginx 프로세스에서 순서대로 GET 요청했다. /inherited에는 nosniff가 있었고 /overridden에는 없었다. /error에서도 없었지만 /fixed의 404에는 있었다. HTTPS, CDN, 애플리케이션 프레임워크를 거치지 않았으므로 이 차이를 만드는 요소를 Nginx의 작은 설정 안으로 좁힐 수 있었다.

첫 번째 조건: 현재 범위에 add_header가 있는가

Nginx 공식 문서의 기본 상속 규칙은 현재 설정 단계에 add_header가 없을 때 상위 단계의 add_header를 물려받는 것이다. /overridden에 추가한 X-Lab-Route는 nosniff와 이름이 다르지만, 이 location에 자체 add_header가 생겼다는 조건은 같다. 이름이 겹치는 헤더만 교체된다고 생각하면 표의 결과를 예상하기 어렵다.

하위 location의 add_header에 always만 붙이면 상위 헤더도 돌아올까요? 2026년 10월 25일 별도 루프백 Nginx 1.18.0에서 세 경로를 모두 404로 만들었습니다. 상위 nosniff always만 물려받은 경로에는 nosniff가 있었지만, 하위에 X-Lab-Route만 always로 선언한 경로에서는 nosniff가 없었습니다. 두 헤더를 하위에 명시하고 always를 붙인 경로에서만 둘 다 나왔습니다. always의 상태 코드 조건과 add_header의 기본 상속 조건은 별개라는 추가 관찰입니다. 운영 Nginx 설정이나 서비스는 바꾸지 않았습니다. 세 경로의 실제 응답·버전·전체 실험 설정 · 자기 루프백 프로세스만 쓰는 재현 코드

두 번째 조건: 오류 응답에도 붙이는가

add_header는 always가 없을 때 지정된 상태 코드에서만 헤더를 추가한다. 실험의 /error는 상위 선언을 물려받는 구조였지만 404라서 nosniff가 나오지 않았다. /fixed에서는 해당 location에 헤더를 명시하고 always를 붙여 404에서도 보이게 했다. 상속 문제와 응답 상태 조건을 분리해서 수정한 셈이다.

이 결과는 모든 헤더에 always를 기계적으로 붙이라는 뜻이 아니다. 예를 들어 오류 응답을 오래 저장하는 캐시 정책을 의도 없이 추가하면 다른 문제가 생길 수 있다. 각 헤더를 어느 경로와 상태에서 보내려는지 먼저 정하고, 실제 응답이 그 정책을 따르는지 비교해야 한다.

버전을 확인하고 수정 방식을 고른다

이 실험은 원자료에 기록한 Nginx 1.18.0에서 수행했다. 공식 문서에는 1.29.3부터 사용할 수 있는 add_header_inherit도 나오지만 여기서는 사용하지 않았다. 최신 문서의 구문이 현재 서버에서 지원된다고 가정하지 말고 nginx -v로 설치 버전을 확인한다. 이 글의 재현 스크립트는 기존 시스템 설정을 reload하지 않는다.

실제 사이트에서는 대표 응답을 나눠 검사한다

# 주소는 자신의 검사 대상으로 바꾼다. -D -는 헤더 출력, -o는 본문 저장 위치다.
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://example.com/known-missing-page
curl -sS -D - -o /dev/null https://example.com/assets/existing.css

정상 HTML 하나만 확인하면 404나 정적 자산에만 적용된 차이를 놓칠 수 있다. 위 명령의 없는 페이지는 실제로 없는 주소인지 확인하고, CSS는 실제 존재하는 주소를 선택한다. 리디렉션을 따라가는 옵션을 넣지 않았으므로 301이 보이면 Location 목적지를 별도로 검사해야 한다.

공개 주소에 프록시가 있다면 원본 응답과 공개 응답이 같은지 구분해야 한다. 이번 관찰은 루프백 원본만 대상으로 했기 때문에 Cloudflare나 다른 CDN이 헤더를 변경하는 동작을 측정하지 않았다. 원본 확인이 끝난 뒤 실제 독자가 접근하는 주소에서도 필요한 응답을 확인하는 것이 다음 단계다.

python3 lab-nginx-boundaries.py --output new-observations.json