클라우드플레어 장애 확인·대비법 2026, 사후 보고서 5건 정리

여러 사이트가 한꺼번에 안 열리면 먼저 클라우드플레어 상태 페이지(cloudflarestatus.com)를 보세요. 이 페이지는 클라우드플레어 밖에서 따로 돌아가요. 내 사이트만의 문제인지는 오류 화면과 명령 두 줄로 가릴 수 있어요. 같이 멈추지 않으려면 원본 서버로 바로 가는 길을 미리 만들어 둬야 해요.

글·측정 서순명(솔리드그루 이사, 웹 에이전시·SI PM 10년, 퓨쳐인프라 서버·CDN·DNS 운영) · 운영사 솔리드그루(퓨쳐인프라, 사업자등록번호 875-44-00335, 서울 구로구) · 측정 2026-11-03 14:02~15:32(한국 시간), 서울 사무실 유선, 5분마다 19번 · 마지막 확인 2026-11-03(장애 사실은 클라우드플레어 공식 사후 보고서 기준) · 원자료는 글 끝 부록 · 문의 support@futureinfra.ai

지금 클라우드플레어가 터진 건가요? 1분 점검 순서

화면에 뜬 증상으로 먼저 갈라요. 클라우드플레어가 보여 주는 오류 화면 아래에는 Ray ID(요청 번호) 줄이 있어요. 문의할 때 이 번호로 그 요청을 찾아요.

1. 클라우드플레어를 안 쓰는 사이트 하나를 열어 내 인터넷부터 확인해요.
2. cloudflarestatus.com에서 진행 중인 사고(Active incidents)를 봐요.
3. 오류 화면 아래 Ray ID를 적어 둬요. 사이트 운영자나 호스팅 업체에 보낼 때 필요해요.
4. 내 사이트라면 아래 명령 두 줄로 원본 서버를 직접 확인해요.

공식 상태 페이지는 어떻게 읽나요?

주소는 www.cloudflarestatus.com이에요. 위쪽 탭은 Overview(요약)·Services & Sites(서비스별)·Locations(지점 지도)·History(지난 사고) 네 개예요. 11월 3일 14시 1분 화면이에요.

사고 꼬리표는 Investigating(조사 중) → Identified(원인 찾음) → Monitoring(고친 뒤 지켜봄) → Resolved(해결) 순서로 바뀌어요. 이날 컨테이너 문제는 13시 12분 조사 시작, 14시 7분 원인 찾음, 14시 12분 지켜봄, 14시 23분 해결로 닫혔어요.

맨 위 한 줄 요약도 같아요. 이날 Status API 는 "indicator":"major","description":"Partial System Outage"(일부 시스템 장애)를 돌려줬어요. 그때 진행 중 사고 두 건은 영향도가 모두 ‘minor’였어요. 우회·점검 중인 지점 상태가 요약에 같이 반영된 것으로 보여요. 그러니 요약 문구보다 내 지역(ICN)과 내가 쓰는 서비스 줄을 보세요.

$ curl -s https://www.cloudflarestatus.com/api/v2/status.json
{"page":{"id":"yh6f0r4529hb","name":"Cloudflare Status",…},
 "status":{"indicator":"major","description":"Partial System Outage"}}   ← 2026-11-03 14:02

상태 페이지는 클라우드플레어 밖에 있어요. 응답 머리말에 server: Google Frontend가 찍히고 클라우드플레어 표시(cf-ray)가 없어요. 2025-11-18 사후 보고서도 “상태 페이지는 클라우드플레어 인프라와 완전히 분리돼 있다”고 적었어요. 다만 그날은 우연히 상태 페이지도 같이 멈췄어요(11/18 사후 보고서). 알림은 ‘Subscribe to updates’ 버튼이나 페이지 아래 RSS 피드로 받을 수 있어요.

내 사이트만의 문제인지 명령어로 가리는 법은?

윈도우는 PowerShell, 맥·리눅스는 터미널에서 해요. 11월 3일 실제로 친 결과예요(내 IP 는 가렸어요).

1. 이 사이트가 클라우드플레어를 쓰나요?

PS> nslookup -type=ns medium.com
medium.com   nameserver = kip.ns.cloudflare.com     ← DNS 를 클라우드플레어에 맡김
medium.com   nameserver = alina.ns.cloudflare.com

PS> curl.exe -sI https://www.npmjs.com/
Server: cloudflare
CF-RAY: a548d42c4c0dc6c3-ICN                         ← 서울(ICN) 지점이 처리

머리말에 server: cloudflare와 cf-ray가 있으면 클라우드플레어를 지나온 응답이에요. cf-ray 끝 세 글자가 처리한 지점이에요(Cf-Ray 공식 설명). 주소(A 레코드)가 104.16.0.0/13·172.64.0.0/13·162.158.0.0/15 같은 대역이면 주황 구름이에요(클라우드플레어 IP 목록).

2. 클라우드플레어 지점은 살아 있나요?

PS> curl.exe -s https://www.npmjs.com/cdn-cgi/trace
h=www.npmjs.com
colo=ICN          ← 응답한 지점
loc=KR
tls=TLSv1.3
http=http/1.1

/cdn-cgi/trace는 클라우드플레어 지점이 직접 답하는 주소예요. 원본 서버까지 가지 않아요(공식 문서). 여기서 colo 가 나오면 적어도 그 지점은 살아 있어요. 이것도 안 되면 클라우드플레어 지점이나 그 앞 인터넷 구간 문제일 가능성이 커요.

3. 원본 서버는 살아 있나요? (내 사이트일 때)

PS> curl.exe -svo NUL https://내도메인 --connect-to ::원본서버IP
# 맥·리눅스는 NUL 대신 /dev/null

클라우드플레어를 건너뛰고 원본에 바로 붙는 명령이에요. 여기서 잘 되면 원본은 정상이고, 문제는 클라우드플레어 쪽이에요. 여기서도 안 되면 내 서버·방화벽 문제예요. 자세한 오류별 해석은 클라우드플레어 사용법·520~526 오류 글에 있어요.

4. dig 가 없어도 DNS 를 볼 수 있나요?

$ curl -s "https://dns.google/resolve?name=medium.com&type=NS"
{"Status":0,…,"Answer":[{"name":"medium.com.","type":2,"TTL":21600,"data":"kip.ns.cloudflare.com."},…]}

$ curl -s -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=medium.com&type=A"
{"Status":0,…,"Answer":[{"name":"medium.com","type":1,"TTL":300,"data":"162.159.153.4"},…]}

구글과 클라우드플레어의 공개 DNS 에 웹으로 물어보는 방법이에요. 두 곳 답이 다르면 DNS 가 바뀌는 중이거나 한쪽이 문제예요. 맥·리눅스라면 dig +short medium.com A @8.8.8.8과 @1.1.1.1로 같은 비교를 해요. 위 TTL 300 은 주황 구름 레코드에 고정된 값이에요(5분, TTL 문서).

상태 페이지에 장애 공지가 뜨면 내 사이트도 멈추나요?

꼭 그렇지는 않아요. 직접 재 봤어요. 11월 3일 13시 44분, 상태 페이지에 ‘APJC 지역 네트워크 성능 문제’ 공지가 올라왔어요(13시 53분 원인 찾음). APJC 는 아시아·태평양이에요. 서울도 들어가는 지역이라 14:02부터 5분마다 클라우드플레어 사이트 5곳(cloudflare.com·medium.com·npmjs.com·gitlab.com·chatgpt.com)을 재 봤어요.

결과는 이래요. 공지가 떠 있던 11번(14:02~14:52)은 5곳이 모두 응답했고(165/165), 가운데 값은 32ms였어요. 응답한 지점은 늘 서울(ICN)이었고, 상태 페이지의 서울 지점도 19/19번 ‘정상’이었어요. 공지는 14:49에 ‘지켜봄’, 14:56에 ‘해결’로 닫혔어요.

그런데 해결 뒤인 15:02~15:22에는 오히려 느려졌어요. 클라우드플레어 5곳 가운데 값이 247ms 로 7.6배가 됐어요. 이때 클라우드플레어를 안 쓰는 네이버·쿠팡도 같이 2.3~6.2배 느려졌고, 연결(TCP) 시간 자체가 16ms → 91ms 로 늘었어요. 같은 사무실 안 공유기까지 보낸 ping 도 평균 45ms(최소 0ms, 최대 74ms)가 걸렸어요. 클라우드플레어가 아니라 우리 사무실 회선이 붐빈 거예요. 15:27에는 클라우드플레어 쪽 가운데 값이 43ms 로 돌아왔어요.

쉽게 말하면, 상태 페이지의 공지는 ‘어딘가에서 문제가 있다’는 알림이에요. 내 사이트가 쓰는 지점·서비스가 그 안에 드는지를 따로 봐야 해요. 이 측정은 사무실 한 곳, 통신사 한 곳에서 지점 응답만 잰 거라 다른 망·다른 서비스까지 괜찮았다는 뜻은 아니에요.

최근 큰 장애는 언제, 왜 났나요?

클라우드플레어가 공식 사후 보고서를 낸 2025~2026년 큰 장애 5건이에요. 시각은 한국 시간으로 바꿨어요. 2025-11-18 장애를 ‘11월 19일’로 적은 글이 있는 건, 회복이 한국 시간으로 다음 날 새벽에 끝났기 때문이에요.

다섯 건 모두 보고서에 공격이 아니었다고 적혀 있어요. 원인은 내부 설정·코드 변경이거나 기대던 외부 서비스였어요. 특히 11/18·12/05 는 한 번 바꾼 설정이 몇 분, 몇 초 만에 전 세계로 퍼진 게 컸어요. 2026-01-22 에는 마이애미 라우터 설정 실수로 25분간 IPv6 경로가 새는 일도 있었어요(보고서).

클라우드플레어는 2026-05-01 ‘Code Orange: Fail Small’ 작업을 마쳤다고 밝혔어요. 설정 변경도 조금씩 내보내며 상태를 보고, 이상하면 자동으로 되돌리는 방식이에요. 장애 중에는 30분이나 60분처럼 정해진 간격으로 공지를 올리겠다고 했어요(공식 글). 11월 3일 기준, 그 뒤로 ‘사후 보고서(Post Mortem)’ 꼬리표가 붙은 새 글은 없었어요(목록).

장애 때 방문자는 무엇을 할 수 있나요?

• 기다리기 — 전 세계 장애면 내 쪽에서 고칠 게 없어요. 상태 페이지 공지를 기다려요.
• 새로고침 연타는 그만 — 11/18 보고서는 복구 뒤 한꺼번에 몰린 트래픽을 푸는 데 몇 시간이 더 걸렸다고 적었어요.
• DNS 를 바꾸는 건 DNS 장애 때만 — 1.1.1.1 이 멈춘 2025-07-14 같은 경우엔 컴퓨터의 DNS 를 통신사 DNS 로 바꾸면 돼요. 사이트 쪽 장애엔 소용없어요.
• hosts 파일 고치기·‘우회’ 프로그램은 쓰지 않기 — 잘못된 주소로 연결되거나 보안 위험이 생겨요.

운영자는 장애 중에 무엇을 할 수 있나요?

클라우드플레어의 관문(프록시)이 멈춘 장애라면, 레코드를 회색 구름(DNS only)으로 바꿔 손님을 원본 서버로 바로 보낼 수 있어요. 공식 문서도 원인 확인용으로 프록시를 끄거나 클라우드플레어를 일시 정지(Pause)하는 방법을 안내해요(Pause Cloudflare). 다만 준비 없이 바꾸면 더 크게 깨져요.

API 토큰이 있으면 로그인 없이 명령 한 줄로 바꿀 수 있어요. 레코드 고치기 API 는 PATCH /zones/{zone_id}/dns_records/{dns_record_id}예요(API 문서).

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records/RECORD_ID" -H "Authorization: Bearer 미리_만든_토큰" -H "Content-Type: application/json" --data '{"proxied":false}'
# 한 줄로 쳐요. 되돌릴 때는 false 를 true 로

바꾸기 전에 상태 페이지에서 무엇이 멈췄는지 먼저 봐요. 2025-06-12 처럼 DNS·캐시·프록시가 멀쩡했던 장애라면 바꿀 이유가 없어요.

같이 안 죽으려면 미리 무엇을 해 두나요?

무료·Pro 요금제에서 할 수 있는 것부터 큰 사이트용까지 순서대로 적었어요. 요금제 조건은 11월 3일 공식 문서 기준이에요.

DNS 를 두 곳에 둘 때는 주의할 게 있어요. 주황 구름 주소는 클라우드플레어가 자기 IP 를 대신 알려 주는데, 다른 업체는 원본 IP 를 알려 줘요. 손님마다 다른 길로 가게 되니 설계를 먼저 해야 해요(존 전송·Multi-provider DNS·CNAME 설정 문서). 가동 보장(SLA) 문서는 Business 요금제부터 있어요. 100% 가동을 약속하고 못 지키면 크레딧을 줘요(Business SLA).

쉽게 말하면, 작은 사이트는 ‘회색 구름으로 넘길 준비’ 하나만 해 둬도 11/18 같은 날 몇 시간을 몇 분으로 줄일 수 있어요. 큰 사이트는 길 자체를 두 개 만들어 둬요. 가용성이 무엇인지는 가용성 글, 숫자로 약속하는 법은 SLA 글에 정리했어요.

예비 경로 만들기 — 퓨쳐인프라 CDN·DNS

퓨쳐인프라는 이 글을 쓴 회사의 서비스예요. 아래 요금은 2026-11-03 공식 페이지 값이에요(부가세 포함).

위 표의 ‘두 번째 CDN’과 ‘DNS 를 두 업체에’를 하려면 다른 회사가 하나 더 있어야 해요. 평소에 만들어 두고, 장애 때 DNS 레코드를 그쪽으로 돌리는 방식이에요.

어느 쪽이든 누르는 순간 넘어가지는 않아요. 레코드를 바꾼 뒤 손님 쪽 DNS 기억(TTL)이 끝나야 새 길로 가요. 그래서 장애가 없는 날 한 번 돌려 보고, 걸린 시간을 적어 두세요.

이럴 땐 이렇게

자주 묻는 질문

클라우드플레어 장애는 얼마나 자주 나나요?

공식 사후 보고서가 붙은 큰 장애는 2025~2026년에 5건이었어요. 작은 공지는 훨씬 잦아요. 상태 페이지 기록을 보면 10월 18일부터 11월 3일까지 사고 공지가 50건이었고, 그중 영향도 major 5건·critical 1건이었어요.

상태 페이지가 안 열리면 어떻게 확인해요?

클라우드플레어를 쓰는 사이트 몇 곳에 위의 /cdn-cgi/trace 를 열어 봐요. 여러 곳이 동시에 안 되면 클라우드플레어 쪽일 가능성이 커요. 다운디텍터 같은 외부 집계 사이트도 참고가 돼요.

오류 화면에 ‘500 Internal Server Error’와 cloudflare 가 같이 떠요.

11/18 장애 때 클라우드플레어 관문이 멈추면서 5xx 오류가 났어요. 520~526 은 대개 원본 서버 쪽이에요. 화면의 숫자로 갈라 보고, 원본 쪽 해석은 520~526 오류 글을 보세요.

무료 요금제도 장애 보상이 있나요?

공식 가동 보장(SLA) 문서는 Business 요금제부터 있어요. 100% 가동을 약속하고, 못 지키면 크레딧으로 돌려줘요. 무료·Pro 는 보상보다 대비를 해 두는 편이 현실적이에요.

다른 CDN 으로 옮기면 장애가 없나요?

어느 업체든 장애는 나요. 업체를 바꾸기보다 한 곳이 멈춰도 다른 길로 갈 수 있게 해 두는 게 핵심이에요. CDN 이란? 글도 같이 보세요.

1.1.1.1 DNS 를 쓰는데 같이 멈추나요?

1.1.1.1 은 사이트 관문과 따로 돌아가는 공개 DNS 예요. 2025-07-14 에는 1.1.1.1 이 62분 멈췄어요(Gateway DNS 일부도 영향). 그럴 땐 통신사 DNS 로 바꾸면 돼요.

부록 — 실측 방법과 원자료