1. 개요
- 현상:
pmpt.sh도메인의 A 레코드를 변경했음에도 불구하고, 루트 도메인 접속 시 이전 사이트(daybreaker42.com)로 연결됨. 반면, 특정 하위 경로(pmpt.sh/prompt/...)는 정상적으로 새 사이트에 연결되는 불일치 발생. - 확인 결과: 브라우저의 개발자 도구 내 ‘Disable Cache’ 옵션 활성화 시 정상 동작 확인.
2. 기술적 원인 분석 (Root Cause Analysis)
2.1. HTTP 리다이렉트 캐싱 (Browser-Level)
가장 핵심적인 원인은 브라우저가 이전 서버에서 수신했던 HTTP 301 (Moved Permanently) 응답을 로컬에 영구 캐싱했기 때문입니다.
- 메커니즘: 브라우저는 301 응답을 받으면 해당 도메인과 목적지 URL의 매핑 정보를 Disk Cache에 저장합니다.
- 동작 방식: 이후 동일 도메인(
pmpt.sh) 접속 시, 네트워크 질의(DNS 조회 및 TCP 핸드셰이크)를 생략하고 즉시 캐싱된 타겟으로 리다이렉트합니다. - 경로별 차이: 루트 도메인은 자주 접속하여 캐시가 존재했으나, 특정 UUID가 포함된 하위 경로는 캐시된 매핑 데이터가 없어 서버에 직접 요청을 보냈고, 이 과정에서 업데이트된 DNS 정보를 참조하여 새 사이트로 연결되었습니다.
2.2. DNS TTL (Time To Live) 및 전파 지연
- 원인: 이전 DNS 레코드의 TTL 설정이 길게 남은 경우, ISP(인터넷 서비스 제공자)의 Recursive DNS 서버가 여전히 예전 IP를 반환할 수 있습니다.
- 영향: 브라우저 캐시가 비워져 있더라도 시스템 레벨의 DNS 캐시가 살아있다면 구형 IP로의 TCP 연결이 지속됩니다.
3. 아키텍처적 고려사항 및 대응 전략
3.1. 구현 레벨의 리다이렉트 최적화
프로덕션 환경에서는 영구적인 도메인 이전이 확정되기 전까지는 302 Found 또는 307 Temporary Redirect를 사용하는 것이 권장됩니다.
3.2. 인프라 설정 모범 사례
- TTL 사전 관리: 레코드 변경 24시간 전에 TTL을 300s(5분) 이하로 낮추어 전파 속도를 확보합니다.
- HSTS 주의: 만약 이전 서버에서
Strict-Transport-Security헤더를 운용했다면, 브라우저는 무조건 HTTPS 접속을 시도하며 이 과정에서 이전 서버의 인증서 정보를 대조할 수 있어 도메인 이전 시 충돌 위험이 있습니다.
4. 결론 및 향후 조치
- 현재 상태: 브라우저 캐시 무효화(
Disable Cache)를 통해 로컬 환경의 문제가 해결되었음을 확인했습니다. - 일반 사용자 대응: 일반 사용자의 경우 수동으로 캐시를 비우기 어려우므로, 서버 측에서
Cache-Control: no-store헤더를 명시하거나 쿼리 스트링(e.g.,?v=2)을 활용한 캐시 버스팅(Cache Busting)을 검토할 수 있습니다. - 모니터링:
dig또는nslookup도구를 사용하여 외부망에서의 DNS 전파 상태를 지속적으로 확인하는 것이 필요합니다.
참조: RFC 7231 (HTTP/1.1 Semantics and Content), RFC 1034 (Domain Names)