문제 상황
여러 도메인(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. 문제 해결 체크리스트
도메인 관련 이슈가 발생하면:
- DNS 조회: 서버와 클라이언트 양쪽에서 확인
- 캐시 초기화: 문제 재현이 일관적인지 확인
- 공개 DNS 직접 조회: 캐시 없이 실제 DNS 상태 확인
- 서버 내부 테스트: nginx/apache 설정 자체의 문제인지 확인
- 네트워크 경로 확인: 라우팅, 방화벽, 로드밸런서 등
결론
"어제 DNS 바꿨는데?"라고 생각했지만, DNS 캐시는 예상보다 오래 남아있을 수 있습니다.
도메인 관련 문제를 디버깅할 때는:
- 항상 캐시를 의심하고
- 여러 지점에서 확인하며
- 인내심을 가지고 DNS 전파를 기다리세요
DNS 변경 후 바로 안 된다고 당황하지 마시고, ipconfig /flushdns부터 시도해보세요! 🎯
'개발 & IT > 백엔드' 카테고리의 다른 글
Let's Encrypt 인증서 자동 갱신 완벽 가이드 (0) | 2025.10.14 |
---|---|
apt autoremove란? 리눅스 패키지 관리의 숨은 조력자 (0) | 2025.10.10 |
MySQL vs PostgreSQL, 뭘 선택해야 할까? 완벽 비교 가이드 (0) | 2025.09.29 |
Laravel Queue Worker 완벽 가이드: 비동기 작업 처리의 핵심 (2) | 2025.09.22 |
📱 Framework7로 만든 앱을 Android APK로 패키징하는 방법 (1) | 2025.06.18 |