CDN 장애 이슈로 웹·앱이 안 열릴 때 확인 순서와 대처법

웹과 앱이 한꺼번에 안 열리는 이유는 가까운 CDN 노드가 원본을 가져오지 못하거나 캐시 미스가 오리진에 몰려 정적 파일과 API가 동시에 실패하기 때문입니다. 주소는 맞는데도 빈 화면이면 로컬 오류보다 CDN 장애 이슈를 먼저 의심하면 됩니다.

이용자는 공개 상태 페이지와 DNS를 보고 이동통신이나 다른 회선으로 우회해 본인 네트워크 문제와 가릅니다. 운영자는 오리진 연결, 호스트 헤더, Cache-Control을 같은 순서로 점검해야 캐시 서버 오류인지 원본 장애인지 구분할 수 있습니다. 헤더의 캐시 히트 여부와 HTTP 상태 코드를 함께 적어두면 이후 재발 점검이 빨라집니다. 같은 증상이 여러 사이트에서 반복되면 단말 설정 초기화보다 CDN 경로를 먼저 의심하면 됩니다.

CDN 장애란 무엇이고 접속 장애로 보이는 이유

콘텐츠 전송 네트워크는 이용자와 가까운 캐시 서버에 파일을 복제해 원본 서버 부하를 줄입니다. 원본 서버가 다운되거나 CDN과 오리진 사이 트래픽이 병목에 걸리면 캐시에 없는 콘텐츠를 가져와 제공할 수 없습니다. 브라우도메인 자체는 해석해도 본문과 자산을 받지 못해 접속이 안 된 것처럼 멈춥니다.

캐시 적중률이 낮으면 페이지 대부분이 캐시가 아니라 원본에서 나갑니다. 원본만 흔들려도 전 구간이 느려지거나 빈 화면이 됩니다. 그래서 CDN 장애는 주소창 오타와 달리 레이아웃 붕괴, 로그인 실패, 이미지 전부 깨짐 같은 서비스 단위 증상으로 보입니다. 특정 도시 노드만 실패하면 같은 사이트도 지역마다 다르게 열립니다.

정적 파일·API가 한꺼번에 막히는 경우

한 화면은 HTML만이 아니라 CSS, 스크립트, 폰트, 이미지와 API를 같은 CDN 호스트에서 받는 구성이 많습니다. 그 호스트가 멈추면 정적 파일과 데이터 요청이 동시에 막혀 웹과 앱이 첫 로딩에서 멈춥니다. HTML만 예전 캐시에 남아 있으면 껍데기는 뜨고 버튼만 죽어 단말기 문제로 오인하기 쉽습니다.

앱은 웹뷰나 공통 API 도메인을 쓰는 경우가 많아 사이트와 같은 시각에 멈춥니다. 일부 국가 노드만 실패하면 특정 통신사에서만 안 열리는 것처럼 보이므로 한 대의 결과만으로 장애를 단정하지 마십시오. 정적 자산은 뜨고 JSON만 실패하면 목록이 비는 형태로 보이니 네트워크 탭에서 호스트를 확인하십시오.

장애 여부를 직접 확인하는 방법

먼저 해당 CDN 업체의 공개 상태 페이지에서 제품명과 지역 사건을 확인합니다. Cloudflare는 cloudflarestatus.com에서 CDN과 Cache 이력을 볼 수 있고 한 제품·한 지역 사건은 전 세계 장애가 아닙니다. 영향 서비스와 위치를 같이 읽어야 실제 이용 구간과 맞는지를 알 수 있습니다.

AWS는 로그인 없이 health.aws.amazon.com/health/status에서 이벤트명, 리전, 심각도, 타임라인을 공개합니다. Open and recent issues와 최근 이력을 보면 지금 장애인지 이미 회복 구간인지를 나눌 수 있습니다. 상태 페이지가 정상이면 다음으로 DNS와 경로를 봅니다. 계정 전용 Health 이벤트와 공개 서비스 상태를 혼동하지 마십시오.

상태 페이지와 DNS·경로 확인

nslookup으로 CNAME이 지정 CDN을 가리키는지 확인하고 ping으로 접속 노드 IP와 지연, 패킷 손실을 봅니다. CDN 도메인 상태가 비활성이면 사이트가 열리지 않을 수 있으니 활성 여부부터 봅니다. 응답 헤더의 캐시 조회 값으로 히트와 미스를 나누면 엣지 문제인지 원본 경로 문제인지 갈립니다. 상태 페이지가 초록이어도 CNAME만 빠지면 접속은 그대로 실패합니다.

X-Cache-Lookup 같은 헤더에서 Hit From MemCache 또는 Disktank면 캐시 히트입니다. 원본 Cache-Control이나 Expires가 저장을 막으면 매번 오리진을 두드리므로 장애 때 파급이 커집니다. ping 손실이 크고 CNAME이 비어 있으면 애플리케이션 버그보다 전송 경로를 의심하십시오. 같은 시각의 traceroute 결과도 함께 남기십시오.

이용자가 바로 시도할 수 있는 우회·점검 절차

같은 Wi-Fi를 유지한 채 새로고침만 반복하지 말고 이동통신으로 바꿔 요청 경로를 네트워크 우회합니다. DNS를 공용 서버로 바꾸고 브라우저 저장 데이터와 앱 프로세스를 완전히 종료한 뒤 다시 엽니다. 다른 기기에서만 정상이면 단말 설정 문제이고 여러 서비스가 동시에 실패하면 CDN 쪽 가능성이 큽니다.

VPN은 경로만 바꿀 뿐 오리진이 다운된 상태는 우회하지 못합니다. 우회 뒤에도 같은 HTTP 오류가 나면 이용자 회선이 아니라 서비스 공통 장애로 보고 공지와 상태 페이지를 기다리면 됩니다. 회사망 방화벽이 CDN 대역을 막을 수도 있으니 개인 핫스팟과 한 번 더 비교하십시오. 우회에 성공해도 결제·로그인만 실패하면 API 전용 호스트를 따로 의심하면 됩니다.

서비스·사이트 운영자가 점검할 캐시·오리진 포인트

캐시 누락이면 엣지가 원본에서 다시 가져오므로 적중률이 낮으면 트래픽 대부분이 오리진으로 갑니다. 잘못 둔 캐시 규칙, 쿼리스트링, 원본 Cache-Control이 적중률을 떨어뜨립니다. HTTP 502가 나면 CloudFront 기준으로 SSL 협상 실패, 만료·유효하지 않은 인증서, 호스트 헤더 불일치, 지정 포트 무응답, 오리진의 조기 연결 종료, 오리진 DNS 확인 실패를 순서대로 봅니다.

엣지에 없는 콘텐츠는 설정한 원본 주소로 Origin-pull되며 실제 요청 사이트는 호스트 헤더로 결정됩니다. 원본 주소나 호스트 헤더가 어긋나면 404 같은 접속 이상으로 나타납니다. 스테이징 호스트를 운영 헤더에 그대로 두면 빈 응답이 나니 환경별 값을 분리하십시오. 아래 표는 증상별로 먼저 볼 지점을 나눈 것입니다.

증상	우선 점검
HTTP 502	오리진 TLS, 인증서, 호스트 헤더, 포트, DNS
전체 정적 파일 실패	CDN 도메인 활성, 상태 페이지, CNAME
404·빈 응답	원본 주소, 호스트 헤더, Origin-pull 경로
일부만 깨지거나 느림	캐시 히트율, Cache-Control, Expires

CDN 장애 대응 정리와 재발 시 체크리스트

장애 직후 상태 페이지, DNS, 헤더의 캐시 히트, HTTP 코드를 기록하고 이용자 우회와 오리진 점검을 나눕니다. 원본 Cache-Control과 Expires가 캐시를 막으면 히트율이 다시 떨어지므로 규칙을 고칩니다. 인증서 만료일과 호스트 헤더 불일치는 재발 빈도가 높으니 배포 전 확인 항목에 넣으십시오.

재발 때는 도메인 활성, CNAME, 인증서, 호스트 헤더, 원본 주소, 캐시 적중률을 같은 순서로 보면 웹사이트 접속 불가 원인을 빠르게 좁힐 수 있습니다. 단일 지역 사건과 전 구간 장애를 섞어 공지하지 말고 영향 리전을 상태 페이지 기준으로 적습니다. 이용자 안내에는 우회 시도와 공식 상태 URL만 짧게 남기면 혼선을 줄일 수 있습니다. 점검 시각과 담당 구간을 남겨 두면 다음 장애 때 같은 항목을 빠뜨리지 않습니다.