Railway URL 타임아웃: 정상적인 서버가 여전히 접근 불가능한 이유

Source: Dev.to

번역을 진행하려면 번역하고자 하는 전체 텍스트를 제공해 주시겠어요?
코드 블록, URL 및 마크다운 형식은 그대로 유지하면서 내용만 한국어로 번역해 드리겠습니다.

Railway에 배포한 백엔드가 시간 초과되었습니다…

문제는 내 코드, 포트 설정, 배포가 아니라 내 모바일 핫스팟의 DNS 리졸버가 오래된 IP 주소를 캐시하고 있었던 것이었습니다. 이 글에서는 무슨 일이 있었는지, 왜 Cloudflare DNS(1.1.1.1) 로 전환했을 때 즉시 해결됐는지, 그리고 DNS 해석이 어떻게 현대 클라우드 배포를 조용히 망가뜨릴 수 있는지 설명합니다.

상황

나는 방금 백엔드를 Railway에 배포했습니다

https://0x*******-production.up.railway.app

로컬에서는 모든 것이 완벽히 동작했습니다:

curl localhost:8080   → ✅ OK

• 서버 로그에 정상적으로 실행 중인 것이 표시됨
• 데이터베이스 연결 성공
• 헬스‑체크 라우트 응답

하지만 공개 URL에 접근하려고 하면 ERR_CONNECTION_TIMED_OUT 가 발생했습니다.

즉각적인 생각: 프로덕션에서 서버가 크래시가 났을 것이다.

헛된 추적

프로덕션 타임아웃에 직면한 개발자라면 누구나 하는 표준 체크리스트를 돌렸습니다:

• ✅ 포트 설정(0.0.0.0) 확인
• ✅ SSL 인증서 확인
• ✅ CORS 설정 검토
• ✅ 여러 번 재배포
• ✅ 방화벽 규칙 확인

아무것도 바뀌지 않았습니다. 타임아웃은 계속되었습니다.

그때 내가 이전에 썼던 무작위 기사에서 다음과 같은 제안을 발견했습니다:

“Cloudflare DNS(1.1.1.1) 로 전환해 보세요.”

반신반의했지만 변경해 보았습니다. 즉시 사이트가 열렸습니다. 이 단 한 번의 DNS 변경이 실제 문제를 드러냈습니다: 내 애플리케이션은 내내 정상적으로 동작하고 있었던 것입니다.

DNS 이해하기: 인터넷 전화번호부

https://railway.app 같은 URL에 접속할 때, 컴퓨터는 그 서버가 어디에 있는지 스스로 알지 못합니다. 실제로 일어나는 일은 다음과 같습니다:

1. 브라우저가 DNS 리졸버에 “이 도메인의 IP 주소가 뭐야?” 라고 질문
2. DNS가 IP를 반환, 예: 0x*******-production.up.railway.app → 104.26.xx.xx
3. 브라우저가 해당 IP에 연결
4. 서버가 응답

핵심 인사이트: DNS가 잘못된 IP를 반환하면 브라우저는 잘못된 머신에 연결합니다. 백엔드는 완벽히 정상일 수 있지만 동시에 완전히 접근 불가능 할 수 있습니다.

현대 플랫폼이 다른 이유

전통적인 호스팅은 고정 IP 주소를 사용합니다: 서버를 배포하고 IP를 얻고, 끝.

현대 플랫폼(Railway, Vercel, Cloudflare Pages 등)은 Anycast CDN 라우팅을 사용합니다. 이는:

• 동일한 도메인이 다음에 따라 다른 엣지 서버로 해석됨
  • 지리적 위치
  • 로드 밸런싱
  • 서버 가용성
• 도메인 뒤의 IP 주소가 자주 변경됨
• DNS 레코드가 매우 짧은 TTL(시간‑존재값)을 가짐, 보통 60 초

이 아키텍처는 전 세계적인 확장성과 복원력을 제공하지만, DNS 리졸버가 TTL 값을 존중하고 지속적으로 최신 레코드를 가져와야 합니다. 좋은 리졸버는 이를 수행하고, 나쁜 리졸버는 그렇지 못합니다.

숨겨진 문제: 내 모바일 핫스팟의 DNS

내 네트워크에서 실제로 일어난 일:

Laptop → Phone Hotspot → Mobile Carrier DNS → Internet

• 노트북이 핫스팟의 DNS 서버(172.20.10.1)에 질의했으며, 이는 캐리어의 리졸버로 요청을 전달했습니다.
• 캐리어의 DNS 리졸버가 오래된 Railway 엣지 서버 IP 주소를 캐시하고 있었습니다.

따라서 브라우저에서 보낸 모든 요청은 더 이상 내 애플리케이션을 호스팅하지 않는 서버로 향했으며, 그 결과 연결 타임아웃(“연결 거부”가 아니라)이 발생했습니다.

• 서버가 실제로 크래시가 나면 일반적으로 connection refused 를 반환합니다.
• 잘못된 IP 주소에 연결하면 timeout 이 발생하며, 이는 겉보기에 다른 증상입니다.

왜 Cloudflare DNS(1.1.1.1)가 해결했는가

Cloudflare의 퍼블릭 DNS로 전환하면 경로가 다음과 같이 바뀝니다:

Laptop → Cloudflare DNS (1.1.1.1) → 올바른 Railway Edge → Backend

Cloudflare 리졸버는:

• 짧은 TTL 값을 존중(약 60 초마다 레코드 새로 고침)
• 현재 올바른 엣지 서버 위치를 반환
• 전 세계에 분산된 인프라를 사용해 신뢰성 제공

내 백엔드는 내내 정상적으로 동작했지만, 나는 단지 그것에 도달하지 못했을 뿐이었습니다.

가장 혼란스러운 부분

로컬 테스트는 완벽히 동작했습니다:

curl localhost:8080   # ✅ 200 OK

왜 그럴까요? l (이하 내용은 다음 파트에 이어집니다)

Source: …

localhost는 DNS를 완전히 우회하고 바로 루프백 인터페이스(127.0.0.1)로 연결됩니다.

이 때문에 최악의 디버깅 경험이 발생했습니다:

프로덕션이 죽어 보이는 반면, 모든 것이 건강해 보였습니다.

DNS Resolver 문제를 인식하는 방법

다음과 같은 현상이 보이면 DNS 문제일 가능성이 높습니다:

• 배포된 URL이 꾸준히 타임아웃됨
• localhost는 완벽히 동작
• 서버 로그에 오류가 없음
• 모바일 데이터에서는 동작하지만 Wi‑Fi에서는 안 됨(또는 그 반대)
• 동료는 정상인데 본인만 안 됨
• 코드 변경 없이 몇 시간 뒤에 갑자기 정상 작동
• DNS 제공자를 바꾸면 즉시 해결 ← 결정적 증거

마지막 항목이 가장 확실한 테스트입니다.

영구적인 해결책

ISP/라우터/핫스팟 DNS에 의존하지 말고 신뢰할 수 있는 퍼블릭 Resolver를 사용하세요:

DNS 설정을 변경한 후:

1. DNS 캐시를 플러시합니다 (ipconfig /flushdns – Windows, sudo dscacheutil -flushcache – macOS, systemd-resolve --flush-caches – Linux)
2. 네트워크에 다시 연결합니다
3. 배포를 테스트합니다

이제 배포된 서비스가 즉시, 그리고 일관되게 열릴 것입니다.

개발자에게 중요한 이유

다음과 같이 자주 작업한다면:

• Serverless 백엔드(Railway, Vercel, Render)
• 프리뷰 배포 URL
• 커스텀 도메인 설정
• 엣지 배포 애플리케이션

…새로운 DNS 레코드를 계속 생성하고 빠르게 전파되어야 합니다. 신뢰할 수 없는 DNS Resolver는:

• 잘못된 IP를 캐시
• 낮은 TTL 값을 무시
• 팀 전체에 일관성 없는 동작을 초래
• 프로덕션 시스템이 불안정하다고 착각하게 함

그 결과 위험한 오해가 생깁니다: 실제 문제는 상위 네트워크에 있는데 애플리케이션이 깨졌다고 생각하게 되는 것이죠.

TL;DR

• 올바르게 배포된 서비스에서도 타임아웃은 오래된 DNS 캐시 때문에 발생할 수 있습니다.
• 최신 플랫폼은 낮은 TTL, 애니캐스트 DNS에 의존하므로 이를 존중하는 Resolver가 필요합니다.
• 빠르고 신뢰할 수 있는 퍼블릭 DNS(예: Cloudflare 1.1.1.1)로 전환하면 문제를 즉시 해결할 수 있습니다.

행복한 디버깅 되세요!

더 넓은 교훈

현대 웹 개발은 변했습니다.

디버깅은 이제 코드만을 위한 것이 아닙니다.

당신의 애플리케이션 스택은 이제 여러 계층으로 구성됩니다:

Code → Container → Platform → CDN → DNS → Resolver → Network

이러한 계층 중 어느 하나에서 실패가 발생하면 애플리케이션 실패처럼 보일 수 있습니다.

핵심 디버깅 규칙:
로컬호스트에서는 정상 작동하지만 프로덕션에서는 타임아웃이 발생한다면, 백엔드를 수정하기 전에 DNS를 의심하세요.

때때로 서버가 다운된 것이 아니라, 단지 잘못된 사람에게 길을 물어보고 있는 것입니다.

최종 생각

이 “버그” 때문에 디버깅에 몇 시간을 허비했습니다—포트, SSL 인증서, 방화벽 규칙, 배포 설정을 다시 확인하는 데 시간을 쏟았죠. 실제 문제는 애플리케이션 로그에 전혀 보이지 않았습니다.

수정은 30 seconds: DNS 서버 주소 두 개를 바꾸는 것뿐이었어요.

현대 클라우드 플랫폼에 배포하면서 로그는 완벽해 보이는데 원인 모를 타임아웃이 발생한다면, 먼저 DNS 리졸버를 확인하세요. 전체 배포 전략을 의심하게 되는 상황을 피할 수 있습니다.

그리고 개발에 모바일 핫스팟을 사용하고 있다면?

지금 바로 1.1.1.1 로 전환하세요. 미래의 당신이 감사할 겁니다.

---

신비로운 타임아웃이 DNS 문제였던 경험이 있나요? 댓글로 여러분의 전쟁 이야기를 들려주세요.