DNS를 바꿨는데 /socket만 예전 주소를 사용하면 현재 location의 proxy_pass 형태부터 확인합니다. hostname이 있다는 사실과 런타임 DNS 재해석을 사용한다는 사실은 다릅니다. resolver 지시문 하나가 모든 리터럴 upstream을 자동 갱신시키는 것도 아닙니다.
버전과 설정 형태를 함께 읽기
upstream resolve 문서는 공유 메모리 zone과 resolver 조건을 설명하며, 1.27.3 이전에는 이 기능이 상용 제공 범위였음을 명시합니다. 이번 서버의 nginx -v는 1.24.0이므로 최신 upstream 예제를 버전 확인 없이 복사할 수 없습니다.
변수를 사용한 proxy_pass도 선택지지만 proxy_pass 문서의 이름 해석과 URI 처리 조건을 함께 읽어야 합니다. 사용하는 DNS는 의도한 내부 이름을 해석할 수 있는 신뢰 가능한 resolver여야 합니다. 주소를 사용자 요청에서 무제한 받아 프록시 대상으로 쓰는 방식으로 바꾸지 않습니다.
DNS 수정이 요청 경로를 바꿀 수도 있다
location /socket/ {
proxy_pass http://backend.example:8080/;
}
# A variable URI has different replacement semantics:
# proxy_pass http://$backend/;위는 문서 기반 비교 조각이며 실행 설정이 아닙니다. 리터럴의 끝 /는 location 접두어 교체에 참여하지만 변수가 있는 URI를 같은 뜻으로 읽으면 경로를 잃을 수 있습니다. 변경 전후 /socket/a와 query string이 upstream에서 실제로 어떤 URI가 되는지 검사해야 합니다. DNS만 바꿨다고 생각했는데 404가 새로 생기는 이유가 여기에 있을 수 있습니다.
시험은 DNS 응답·TTL·선택된 upstream 주소와 새 연결을 함께 기록합니다. 이미 열린 WebSocket이 DNS 변경만으로 다른 서버로 이동할 것이라고 기대하지 않습니다. 이번 글에서는 실제 DNS 회전이나 연결 재수립을 실행하지 않았으므로 반영 시간이나 무중단 성공을 주장하지 않습니다.