본문 바로가기

개발 & IT/백엔드

nginx SSL 설정 중 만난 DNS 캐시 트러블슈팅

문제 상황

여러 도메인(example.com, example.kr, example.net)을 운영하는 nginx 서버에 SSL을 적용하던 중, 한 가지 이상한 현상을 발견했습니다.

# 각 도메인 테스트 결과
curl -I http://example.com
# HTTP/1.1 200 OK
# Server: nginx/1.24.0 (Ubuntu)

curl -I http://example.kr
# HTTP/1.1 200 OK
# Server: nginx/1.24.0 (Ubuntu)

curl -I http://example.net
# HTTP/1.1 200 OK
# Server: Apache  ← 🚨 왜 Apache?

example.net만 유독 Apache 서버를 반환하고 있었습니다. 브라우저에서는 about:blank#blocked 에러가 발생했고요.

첫 번째 가설: 네트워크 라우팅 문제?

DNS를 확인해보니 모든 도메인이 같은 IP를 가리키고 있었습니다.

nslookup example.com
# Address: 203.0.113.10

nslookup example.kr
# Address: 203.0.113.10

nslookup example.net
# Address: 203.0.113.10  ← 같은 IP인데?

같은 IP를 가리키는데 다른 서버가 응답한다? 네트워크 장비(스위치/방화벽)에서 특정 도메인만 다르게 라우팅하는 것으로 의심했습니다.

서버 내부에서 테스트

# 서버 로컬에서 테스트
curl -I http://localhost -H "Host: example.net"
# HTTP/1.1 200 OK
# Server: nginx/1.24.0 (Ubuntu)  ← nginx로 정상 응답!

서버 자체에서는 nginx가 정상적으로 응답하는데, 외부에서만 Apache를 반환했습니다.

두 번째 가설: Apache가 같이 실행 중?

sudo systemctl status apache2
# Unit apache2.service could not be found.

Apache는 설치조차 되어 있지 않았습니다.

진짜 원인: DNS 캐시

네트워크 관리자에게 확인 요청 후, 클라이언트 PC에서 실제 IP를 확인해봤습니다.

# PowerShell에서 실제 IP 확인
[System.Net.Dns]::GetHostAddresses("example.com")
# IPAddressToString: 203.0.113.10  ✅

[System.Net.Dns]::GetHostAddresses("example.net")
# IPAddressToString: 203.0.113.50  ❌ 완전히 다른 IP!

문제는 DNS 캐시였습니다!

  • 전날 DNS A 레코드를 새 서버 IP(203.0.113.10)로 변경했지만
  • 로컬 DNS 캐시에는 여전히 옛날 서버 IP(203.0.113.50)가 남아있었고
  • 그 옛날 서버에는 Apache가 실행 중이었던 것

해결 방법

1. DNS 캐시 초기화

# Windows (관리자 권한)
ipconfig /flushdns

# Linux/Mac
sudo systemd-resolve --flush-caches
# 또는
sudo dscacheutil -flushcache

2. 공개 DNS로 직접 확인

캐시 없이 실제 DNS 상태를 확인하려면 공개 DNS 서버를 직접 조회합니다.

# Google DNS
nslookup example.net 8.8.8.8

# Cloudflare DNS
nslookup example.net 1.1.1.1

3. DNS 전파 상태 확인

https://www.whatsmydns.net/에서 전 세계 DNS 서버들의 응답을 확인할 수 있습니다.

교훈

1. DNS는 생각보다 끈질기다

DNS 레코드를 변경해도:

  • 로컬 시스템 캐시
  • 공유기/라우터 캐시
  • ISP DNS 캐시
  • 각종 중간 DNS 서버 캐시

모든 계층에서 캐시가 만료될 때까지 기다려야 합니다. TTL(Time To Live)이 짧아도 여러 단계의 캐시가 있어 완전한 전파에는 시간이 걸립니다.

2. 서버 내부 vs 외부 테스트는 다르다

# 내부 테스트
curl http://localhost -H "Host: example.com"

# 외부 테스트  
curl http://example.com

서버에서는 정상이지만 외부에서 문제가 있다면, DNS, 네트워크 라우팅, 방화벽 등 인프라 레이어를 의심해야 합니다.

3. 문제 해결 체크리스트

도메인 관련 이슈가 발생하면:

  1. DNS 조회: 서버와 클라이언트 양쪽에서 확인
  2. 캐시 초기화: 문제 재현이 일관적인지 확인
  3. 공개 DNS 직접 조회: 캐시 없이 실제 DNS 상태 확인
  4. 서버 내부 테스트: nginx/apache 설정 자체의 문제인지 확인
  5. 네트워크 경로 확인: 라우팅, 방화벽, 로드밸런서 등

결론

"어제 DNS 바꿨는데?"라고 생각했지만, DNS 캐시는 예상보다 오래 남아있을 수 있습니다.

도메인 관련 문제를 디버깅할 때는:

  • 항상 캐시를 의심하고
  • 여러 지점에서 확인하며
  • 인내심을 가지고 DNS 전파를 기다리세요

DNS 변경 후 바로 안 된다고 당황하지 마시고, ipconfig /flushdns부터 시도해보세요! 🎯

반응형