서버 IP를 바꿨는데 일부 사용자만 계속 옛날 서버로 접속한 이유

문제 발생

서버를 새 인프라로 이전하면서 DNS의 A 레코드를 새 IP로 바꿨는데, 일부 사용자들이 몇 시간 동안 계속 예전(이미 내려버린) 서버로 접속을 시도하며 오류를 겪었습니다.

원인 분석

DNS 레코드에는 **TTL(Time To Live)**이 있습니다 — 이 값은 "이 응답을 얼마 동안 캐싱해도 되는지"를 리졸버(운영체제, ISP의 DNS 서버, 브라우저 등)에게 알려줍니다. TTL이 3600(1시간)으로 설정되어 있었다면, 이미 그 값을 캐싱한 리졸버는 DNS 레코드를 실제로 바꾼 뒤에도 최대 1시간 동안은 예전 IP를 계속 돌려줄 수 있습니다.

문제는 이 캐싱이 여러 계층에서 각각 독립적으로 일어난다는 점입니다 — 사용자의 브라우저, 운영체제의 DNS 캐시, 사내/ISP의 DNS 서버까지 각자 다른 시점에 값을 캐싱했을 수 있어서, 레코드를 바꾼 직후에도 사용자마다 새 IP를 받는 시점이 제각각입니다.

해결 방안

1. 인프라 이전처럼 계획된 IP 변경이 있다면, 변경 며칠 전에 미리 TTL을 낮춰둡니다(예: 3600초 → 60초). 이렇게 하면 실제 IP를 바꾸는 시점에는 이미 짧은 TTL이 전파되어 있어, 변경이 훨씬 빠르게(수 분 내로) 전체에 반영됩니다.

example.com.  60  IN  A  203.0.113.10   # TTL을 미리 짧게

2. 실제 IP를 바꾼 뒤에는, 필요하다면 TTL을 다시 원래 값(더 긴 값)으로 되돌립니다 — TTL을 항상 짧게 유지하면 매 요청마다 DNS 조회가 늘어나 약간의 지연과 DNS 서버 부하가 늘어날 수 있습니다.
3. 예전 서버를 IP 변경 직후 바로 내리지 않습니다 — 일부 리졸버는 여전히 예전 IP로 요청을 보낼 수 있으므로, 캐싱이 완전히 해소될 시간(예정했던 TTL 이상)을 두고 나서 예전 서버를 종료합니다. 급하게 내려야 한다면 최소한 리다이렉트나 안내 페이지라도 남겨두는 것이 안전합니다.
4. dig나 온라인 DNS 전파 확인 도구로 여러 지역의 리졸버가 실제로 새 값을 반환하는지 확인할 수 있습니다 — 다만 이걸로 확인했다고 해서 모든 사용자의 로컬 캐시까지 확인되는 것은 아니라는 점을 감안합니다.
5. 이런 이슈를 근본적으로 줄이고 싶다면, IP를 직접 하드코딩해서 알리기보다 CDN이나 로드밸런서 앞단을 두고 그 뒤의 실제 서버를 바꾸는 방식으로, 클라이언트가 보는 DNS 값 자체는 거의 안 바뀌도록 설계하는 것도 방법입니다.

공식 문서

• Cloudflare Learning: What is DNS TTL?