EC2 재부팅 시 IP 변경 문제와 DuckDNS 전파 지연 해결 전략

 EC2 재부팅 시 IP 변경 문제와 DuckDNS 전파 지연 해결 전략

 

EC2 퍼블릭 IP 변경으로 인한 문제 상황

✅ 전체 코드 및 로그 상황

EC2 인스턴스를 재시작할 경우 퍼블릭 IP가 변경되어, DuckDNS가 가리키는 주소와 실제 서버 주소가 불일치하는 문제가 발생합니다. 이로 인해 Nginx는 요청을 받지만, Django에서는 ALLOWED_HOSTS 불일치로 인해 400 Bad Request가 반환되었습니다.

$ curl http://checkip.amazonaws.com
3.34.129.166

$ nslookup teamnotfound.duckdns.org
Address: 15.164.49.138

🛠 구현 흐름 ①: 문제 발생 경로
→ EC2 재시작 → IP 변경 → DuckDNS가 옛날 IP 가리킴 → 도메인으로 접속 시 400 에러 발생

🔍 검증: Django 로그, nginx 로그 모두 400 발생 확인 / curl, dig 명령어로 IP 불일치 검증 완료

⚠️ 주의: DuckDNS는 전파 지연이 존재하며, DNS TTL이 적용됨 (최대 수십 분 소요)

소제목: DuckDNS 자동 갱신 스크립트 확인 및 수동 갱신

✅ 전체 코드 및 스크립트

기존에 crontab으로 DuckDNS 자동 갱신 스크립트가 등록되어 있었고, 아래와 같이 수동으로 갱신 명령어도 실행했습니다.

$ curl "https://www.duckdns.org/update?domains=teamnotfound&token=&ip="
OK

🛠 구현 흐름 ②: crontab 자동 갱신 구조 확인
→ crontab -l 결과로 갱신 주기 확인
→ duck.sh 스크립트 존재 확인 및 chmod +x 처리

🔍 검증: 수동 갱신 시 OK 반환됨 → DuckDNS 자체는 반영 성공

⚠️ 실수 방지 팁: DuckDNS는 갱신 요청을 수용하더라도 실제 DNS 서버 반영은 최대 30분 이상 걸릴 수 있음

소제목: DNS 전파 상태 확인 (dig, nslookup, trace)

✅ 전체 명령어 흐름

$ dig @8.8.8.8 teamnotfound.duckdns.org +short
15.164.49.138

$ dig teamnotfound.duckdns.org @ns1.duckdns.org +short
;; connection refused

🛠 구현 흐름 ③: DNS 전파 지연 확인
→ DuckDNS 대시보드는 3.34.129.166으로 갱신 완료됨
→ 그러나 글로벌 DNS 서버에서는 여전히 예전 IP 반환

🔍 검증: dig +trace 명령으로 NS 서버가 아직 예전 IP 반환 확인

⚠️ 주의: ns1.duckdns.org 등의 일부 네임서버에서 connection refused, timeout 발생

소제목: 임시 우회 방법 - /etc/hosts 파일 사용

✅ 전체 설정 예시 (로컬 또는 EC2에서)

sudo nano /etc/hosts

# 아래 내용 추가
3.34.129.166 teamnotfound.duckdns.org

🛠 구현 흐름 ④: 로컬 DNS 우회
→ DNS 캐시나 전파 대기 없이 바로 새로운 IP로 접속 가능

🔍 검증: 브라우저에서 https://teamnotfound.duckdns.org 접속 성공

⚠️ 주의: hosts 파일은 수동 관리이므로, 테스트 환경에서만 일시적으로 사용

소제목: Elastic IP를 사용하지 않는 선택

✅ 선택 이유
→ 탄력적 IP는 유료 자원이며, 연결하지 않은 상태에서는 과금 발생
→ 학습 및 테스트 프로젝트에는 DuckDNS 자동 갱신 방식으로 충분

🛠 해결 전략: crontab 자동 갱신 + 수동 갱신 스크립트 + hosts 우회 병행

🔍 장점: 추가 비용 없이도 운영 가능, 도메인 기반 설정 유지 가능

⚠️ 주의: EC2를 재시작할 경우, 즉시 IP 확인 후 갱신해야 오류 발생 방지 가능

소제목: 최종 정리 및 실무 팁

✅ 반드시 기억할 핵심 체크리스트:

• EC2 재시작 후 IP 변경되면 curl http://checkip.amazonaws.com 확인
• DuckDNS 갱신 수동으로 curl 요청해서 강제 적용 가능
• dig, nslookup 결과가 달라질 수 있음 → TTL 전파 대기 필요
• 전파 기다리기 어려울 땐 /etc/hosts 우회 사용 가능
• 자동화: duck.sh + crontab -l로 유지하면 운영 문제 없음

💡 실전 팁: DNS TTL 전파 시간 동안 문제 원인을 서버 설정에서 찾는 경우가 많으므로, 반드시 dig/trace로 전파 상태 확인할 것