단계별 점검 순서: DNS, 연결, HTTP
웹 접속은 대략 도메인을 IP로 바꾸고(DNS), 서버와 연결을 맺고(TCP, HTTPS면 TLS), 요청을 보내 응답을 받는(HTTP) 순서로 진행됩니다. 어느 단계에서 멈췄는지에 따라 의심할 곳이 달라집니다.
| 단계 | 실패 신호(일반적 예) | 확인 방법 | 의심할 곳 |
|---|---|---|---|
| 1. DNS | 도메인을 찾을 수 없다는 오류 (NXDOMAIN 등) | nslookup 도메인, 다른 DNS로 비교 | 내 DNS 설정과 캐시, 도메인 설정, DNS 사업자 |
| 2. 연결 | 연결 거부, 시간 초과 | 핑, tracert, 다른 네트워크 시도 | 회선, 방화벽, 서버 다운, 경로 문제 |
| 3. TLS | 인증서 경고, 보안 연결 실패 | 기기 날짜와 시간, 브라우저 경고 내용 | 인증서 만료, 시간 오차 |
| 4. HTTP | 5xx 오류 페이지 | 오류 번호 확인, 잠시 후 재시도 | 서버, 로드밸런서, 프록시 |
HTTP 상태 코드는 RFC 9110(2022년 6월)이 정의합니다. 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout은 각각 15.6.3, 15.6.4, 15.6.5절에 있으며, 모두 서버 쪽 오류 계열(5xx)입니다. 즉 5xx가 보인다는 것은 요청이 서버나 중간 장비까지는 도달했다는 뜻이므로 내 인터넷 회선 문제와는 구별해 생각할 수 있습니다. 핑은 일부 서버가 응답을 막아 둘 수 있어, 핑이 안 된다고 해서 사이트가 죽었다고 단정하면 안 됩니다. 명령어는 조회용이라 위험은 없지만, 해결책으로 소개되는 낯선 스크립트나 설정 변경은 출처를 확인하고 따라야 합니다.
실제 장애 사례에서 배우기
사례 1. 2019년 7월 2일 클라우드플레어: 서버는 살아 있는데 502
클라우드플레어의 공식 사후 분석에 따르면 2019년 7월 2일 13:42부터 14:09(UTC)까지 약 27분 동안 이 회사가 서비스하는 사이트들이 HTTP 502 오류 페이지를 보였습니다. 원인은 방화벽(WAF) 규칙 업데이트에 들어 있던 정규식이 처리 중 엄청나게 되돌아가며 계산해 전 세계 서버의 CPU를 거의 100%까지 소진시킨 것입니다. 이 규칙은 '시뮬레이트' 모드였지만 정규식은 그래도 실행되었고, 변경이 단계적 배포 없이 전 세계에 빠르게 적용된 점도 원인으로 꼽혔습니다. 회사는 WAF를 전 세계에서 껐고, 14:52에 원인 확인과 재활성화를 마쳤습니다. 이용자에게는 '사이트 서버'가 아니라 중간의 CDN 계층 문제였던 사례입니다. 배울 점은 502가 보일 때 원 서버가 멀쩡해도 앞단 서비스 때문에 접속이 막힐 수 있고, 이 경우 사용자 쪽에서 할 수 있는 일은 많지 않다는 것입니다.
사례 2. 2021년 6월 8일 패스틀리: 설정 변경 하나가 드러낸 숨은 버그
패스틀리 공식 요약에 따르면 2021년 6월 8일 09:47(UTC)에 전 세계 장애가 시작되어 1분 안에 감지되었고, 네트워크의 85%가 오류를 반환했습니다. 원인은 한 고객의 정상적인 설정 변경이 5월 12일부터 배포된 소프트웨어 안의 발견되지 않은 버그를 건드린 것이었습니다. 네트워크의 95%는 49분 안에 정상으로 돌아왔고, 12:35에 장애가 완화되었으며 영구 수정 배포는 17:25에 시작되었다고 합니다. 여러 서비스가 같은 CDN에 의존할 때 한 업체의 문제가 서로 다른 사이트의 동시 장애로 보일 수 있다는 점을 보여 줍니다.
사례 3. 가상 예시: 나만 안 되는 경우와 모두 안 되는 경우
가상 예시입니다. 어떤 쇼핑몰이 집 와이파이에서만 열리지 않고 모바일 데이터에서는 열린다면, 서버 장애가 아니라 공유기, DNS 설정, 통신사 회선 쪽을 먼저 의심합니다. 반대로 두 네트워크 모두에서 5xx 오류가 보이고 SNS에서도 같은 호소가 보이면 서비스 쪽 장애일 가능성이 높아 복구 안내를 기다리는 것이 합리적입니다.
흔한 오해와 정정
- 오해: 핑이 되면 사이트도 정상이다. 실제: 핑은 IP 수준의 응답일 뿐 웹 서비스(HTTP)의 정상 여부와는 별개입니다.
- 오해: 다운디텍터에 신고가 없으면 장애가 아니다. 실제: 신고 기반이라 이용자가 적거나 국지적인 장애는 반영되지 않을 수 있습니다.
- 오해: 오류가 나면 내 컴퓨터를 초기화해야 한다. 실제: 단계별로 나누어 보면 대부분 기다리거나 DNS와 캐시 정도만 점검하면 됩니다.
- 오해: 큰 회사는 장애가 나지 않는다. 실제: 위 두 사례처럼 대형 CDN도 설정과 배포 문제로 장애를 겪으며, 이를 공개 보고서로 설명합니다.
한계와 더 알아볼 점
이 글의 순서는 일반적인 점검 흐름이며 모든 원인을 포괄하지 않습니다. 회사 방화벽, 국가나 통신사 차단, 사이트 자체 접근 제한은 같은 증상으로 보일 수 있습니다. 사후 분석 보고서는 회사가 작성한 것이라 사건의 모든 내부 사정이 공개되지는 않을 수 있다는 점도 감안해야 합니다.
직접 진단하는 방법을 더 깊이 알고 싶다면
핑과 트레이스라우트를 실제로 어떻게 실행하고 결과를 읽는지 궁금하다면핑(Ping)으로 인터넷 연결 상태 진단하는 방법과트레이스라우트(tracert)로 네트워크 경로 진단하는 방법도 확인해보세요.
브라우저에 에러 코드가 뜬다면
DNS_PROBE_FINISHED_NXDOMAIN이나 ERR_CONNECTION_REFUSED 같은 구체적인 에러 코드가 보인다면브라우저 네트워크 에러 코드 완전정복에서 의미를 바로 찾아볼 수 있습니다.
자주 묻는 질문
다운디텍터에 아무 신고가 없는데도 저는 안 열려요.
다운디텍터류 서비스는 사용자 신고에 의존하기 때문에 이용자가 적은 사이트나 특정 지역·통신사에서만 발생한 문제는 반영되지 않을 수 있습니다. 이런 경우 다른 기기·다른 네트워크로 접속을 비교해보고, 핑·트레이스라우트로 직접 진단해보는 것이 더 정확합니다.
특정 사이트만 안 되고 나머지는 다 잘 되는데, 이것도 장애인가요?
다른 사이트는 잘 되는데 특정 사이트만 안 된다면 전체 인터넷 장애가 아니라 그 사이트 서버 문제, DNS 문제, 또는 그 사이트로 가는 경로만의 문제일 가능성이 높습니다. 이때는 해당 사이트의 공식 상태 페이지나 SNS 검색이 가장 빠른 확인 방법입니다.
502, 503, 504는 어떻게 다른가요?
RFC 9110은 세 코드를 모두 서버 오류(5xx)로 분류합니다. 대체로 502는 중간 서버가 상위 서버에서 잘못된 응답을 받은 경우, 503은 서버가 일시적으로 요청을 처리하지 못하는 경우, 504는 상위 서버의 응답이 제때 오지 않은 경우를 가리킵니다.
DNS 문제인지 어떻게 구분하나요?
도메인 대신 IP 주소로는 연결되는데 도메인으로는 안 된다면 DNS가 의심됩니다. nslookup으로 주소가 조회되는지, 다른 DNS 서버로 조회하면 결과가 다른지 비교해 볼 수 있습니다.
장애가 확인되면 제가 할 수 있는 일은 무엇인가요?
서비스 쪽 장애라면 공식 공지를 확인하며 기다리는 것이 기본입니다. 반복 새로고침은 서버 부담을 키울 수 있으므로 간격을 두고 확인하는 편이 좋습니다.
회사나 학교 네트워크에서만 안 되면요?
방화벽이나 프록시 정책으로 접근이 제한되었을 수 있습니다. 모바일 데이터에서는 열리는지 확인한 뒤 네트워크 관리자에게 문의하세요.