웹사이트 공개 9편: 접속 오류를 구분하는 순서
웹사이트 공개 실습 9/14 · 가상 프로젝트 작은 작업실 기준입니다.
example.com은 설명용 예약 도메인입니다. 실제 연결에는 본인 소유 도메인을 사용하세요.
이번 편의 목표
“안 열린다”를 하나의 문제로 보지 않고 DNS·Tunnel·앱·브라우저 문제로 나눕니다. 설정을 바꾸기 전에 정확한 주소·오류 문구·다른 네트워크의 결과를 기록합니다. 로그인 코드나 URL의 인증 매개변수는 공유하지 않습니다.
먼저 네 가지를 비교하기
- 브라우저에서
http://localhost:4100을 엽니다. 여기서도 안 열리면 도메인보다 앱 실행부터 확인합니다. - 대표
https://example.com을 엽니다.www가 붙었는지도 기록합니다. - 휴대폰 Wi-Fi를 끄고 모바일 데이터에서 같은 주소를 엽니다. 다른 네트워크에서도 실패하는지 비교합니다.
- 브라우저 오류 문구를 기록합니다. ‘주소를 찾을 수 없음’과 ‘502’는 확인할 대상이 다릅니다.
| 결과 | 먼저 볼 곳 | | --- | --- | | 주소를 찾을 수 없음 | 네임서버·DNS 레코드·반영 상태 | | Tunnel 연결 오류 | 커넥터 실행·토큰·외부 연결 상태 | | 502 | 앱 실행·Service URL·컨테이너 네트워크 | | 404 | 앱에 해당 경로가 있는지 | | 로그인 후 되돌아옴 | 10편의 콜백·쿠키·환경 설정 |
DNS만 기기별로 다를 때
Mac은 dig example.com @1.1.1.1, Windows는 nslookup example.com 1.1.1.1로 공용 조회 결과와 로컬 브라우저 결과를 비교합니다. 다른 기기에서 정상이라면 먼저 저장한 값을 재확인하고 캐시·반영 시간을 고려합니다. 주소를 다시 저장하고 네임서버를 계속 바꾸면 원인 파악이 더 어려워집니다.
브라우저 새로고침과 DNS 캐시는 다릅니다. Chrome 강력 새로고침은 Mac에서 Cmd+Shift+R, Windows에서 Ctrl+Shift+R입니다. 이것만으로 운영체제나 DNS 서버 캐시까지 모두 지워지는 것은 아닙니다.
앱과 Tunnel 확인하기
프로젝트 터미널에서 다음 명령을 실행합니다.
docker compose -f compose.yaml -f compose.tunnel.yaml ps
docker compose -f compose.yaml -f compose.tunnel.yaml logs --tail=50 web
docker compose -f compose.yaml -f compose.tunnel.yaml logs --tail=50 tunnel
필요한 오류 주변만 읽고, 공유 전 토큰·이메일·내부 식별자를 가립니다. 앱이 실행 중인데 502라면 Service URL이 http://web:3000인지 확인합니다. 같은 Compose 네트워크 안의 주소라는 전제를 놓치지 않습니다.
흔한 시행착오
휴대폰에서는 되는데 PC에서만 안 됩니다. 이 사실만으로 서버 장애라고 단정하지 않습니다. 실제로 확인한 네트워크와 DNS 응답을 비교합니다.
캐시를 지워도 502가 남아요. 앱 쪽 문제일 수 있습니다. 서버 로그와 서비스 주소부터 확인하세요.
기다리면 다 해결되나요? 올바른 DNS의 반영 지연에는 기다림이 필요할 수 있지만, 잘못된 Service URL이나 꺼진 앱은 기다리는 것으로 고쳐지지 않습니다.
완료 기준과 확인 범위
실패하는 단계와 다음 확인 대상을 말할 수 있으면 완료입니다. 오류를 일부러 운영 도메인에 발생시키는 실습은 하지 않습니다.
공식 자료 확인: 2026-11-15. Cloudflare Tunnel 문제 해결(영문), Compose 네트워크(영문).