# Cloudflare 글로벌 네트워크 장애 발생

> Clean Markdown view of GeekNews topic #24459. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24459](https://news.hada.io/topic?id=24459)
- GeekNews Markdown: [https://news.hada.io/topic/24459.md](https://news.hada.io/topic/24459.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-11-19T10:00:25+09:00
- Updated: 2025-11-19T10:00:25+09:00
- Original source: [cloudflarestatus.com](https://www.cloudflarestatus.com/incidents/8gmgl950y3h7)
- Points: 1
- Comments: 1

## Topic Body

- **Cloudflare 글로벌 네트워크**에서 내부 서비스 성능 저하가 발생해 여러 서비스가 간헐적으로 영향을 받음  
- **Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers** 등 주요 서비스가 일시적으로 장애를 겪음  
- 엔지니어링 팀이 문제를 식별하고 수정 작업을 진행했으며, **WARP와 Access 서비스**가 먼저 복구됨  
- 이후 전 세계적으로 오류율과 지연이 점차 정상 수준으로 회복되고, **대시보드 서비스**도 복원됨  
- 현재 모든 서비스가 정상적으로 운영 중이며, **사건은 완전히 해결된 상태**

---
### 사건 개요
- Cloudflare는 내부 서비스 **성능 저하(Internal Service Degradation)** 를 겪으며 일부 서비스가 간헐적으로 중단됨  
  - 영향을 받은 서비스에는 **Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers** 등이 포함됨  
  - 회사는 즉시 복구 작업에 착수하고, 문제 해결 진행 상황을 지속적으로 업데이트함  

### 문제 식별 및 초기 대응
- Cloudflare는 문제를 **조사 중(Investigating)** 단계에서 내부 서비스 저하를 확인함  
  - 일부 고객이 간헐적인 오류와 지연을 경험함  
  - 엔지니어링 팀이 원인 분석과 복구 작업을 병행함  
- 이후 **문제 원인을 식별(Identified)** 하고 수정 작업을 시작함  
  - 수정 도중 **런던 지역의 WARP 접속이 일시적으로 비활성화**되어, 해당 지역 사용자는 인터넷 연결 실패를 경험함  

### 서비스 복구 진행
- 수정 작업 후 **Access와 WARP 서비스**가 먼저 복구되어 오류율이 사고 이전 수준으로 돌아감  
  - 런던 지역의 WARP 접속이 재활성화됨  
- 이후 **Application Services 고객 대상 서비스 복원 작업**이 이어짐  
  - 대시보드 서비스 복구를 위한 변경 사항이 배포됨  
  - 여전히 일부 고객이 로그인 또는 대시보드 사용 문제를 겪었으나, 추가 수정으로 해결됨  

### 네트워크 전반의 안정화
- 전 세계적으로 **오류율과 지연(latency)** 이 점차 감소하며 정상 수준으로 회복됨  
  - **Bot Management의 점수 계산(bot scores)** 이 일시적으로 영향을 받았으나, 복구 과정에서 정상화됨  
  - 엔지니어링 팀은 남은 오류를 제거하고 전체 네트워크 복구를 가속화함  
- 이후 모든 서비스가 정상적으로 작동하며, **오류율과 지연이 완전히 정상화됨**  

### 사건 종료 및 후속 조치
- Cloudflare는 **모든 서비스가 정상 운영 중**임을 확인하고 사건을 종료함  
  - 현재 **추가적인 구성 변경은 없으며**, 플랫폼을 면밀히 모니터링 중  
  - 사고 원인에 대한 **사후 조사(post-incident investigation)** 가 진행 중이며, 결과는 추후 공개 예정  
- 이번 장애는 **글로벌 네트워크 전반에 영향을 미친 사건**으로 기록됨

## Comments



### Comment 46517

- Author: neo
- Created: 2025-11-19T10:00:26+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45963780) 
- Cloudflare API 토큰이 있는 사람이라면 **CF 프록시를 비활성화**할 수 있는 명령어를 공유함  
  `curl` 명령으로 zone ID와 DNS 레코드를 가져오고, `PATCH` 요청으로 `"proxied": false`로 설정하면 됨  
  다만 SSL 인증서 손실, **보안/성능 저하**, 그리고 백엔드 IP 노출 위험이 있으니 주의해야 함
  - 오래된 **Global API Key**만 있는 경우에는 `X-Auth-Email`과 `X-Auth-Key` 헤더를 사용하면 됨  
    그리고 Cloudflare 트래픽만 허용하도록 설정해둔 사람은 그 규칙을 잠시 꺼야 함
  - 다음번에는 이 방법을 써야겠다고 생각했는데, API 토큰을 미리 만들어두지 않아 기다릴 수밖에 없었음  
    다행히 지금은 다시 온라인 상태로 복구됨
  - Terraform provider로 처리했지만, 대시보드 접근이 안 되는 사람에게는 이 방법이 유용함
  - 좋은 팁임. 참고로 `curl`에서 GET 요청은 기본값이라 `-X GET`은 필요 없음  
    `-d` 옵션을 쓰면 자동으로 POST가 되고, PATCH에는 `-X PATCH`가 맞음
  - Cloudflare WARP를 켜면 일부 사이트가 다시 작동함. 1.1.1.1도 비슷한 효과가 있을 듯함  
    다만 터널링 후에도 일부 사이트는 여전히 부분적으로 다운 상태임

- Cloudflare CTO가 밝히길, **봇 차단 시스템의 잠재 버그**가 설정 변경 후 폭주하면서 네트워크 전반에 장애를 일으켰다고 함  
  공격이 아니라 내부 문제였다고 [출처](https://x.com/dok2001/status/1990791419653484646)에서 설명함
  - 대형 기업들이 아직도 **구성 변경을 단계적으로 배포하지 않는 것**이 놀라움  
    코드나 설정 모두 데이터인데, 전 세계에 한 번에 배포하다가 대형 장애가 나는 패턴이 반복됨
  - 이런 핵심 정보가 댓글 상단에 올라갔으면 좋겠음. 사이버 공격 추측 댓글 사이에서 찾기 힘들었음
  - 설정 변경 하나로 CF 주가가 4% 하락했음. 이런 장애가 업계 전체에 미치는 **경제적 영향**이 궁금함

- 동료가 갑자기 뛰어와서 자신이 Cloudflare 설정을 바꾼 직후 사이트가 다운돼서 **자기가 망친 줄 알고 놀랐다**고 함  
  이 글을 보고 안도했다고 함
  - “그보다 더 심각함, 네가 Cloudflare 전체를 다운시킨 거야”라고 농담함
  - 그래도 정말 아닐까? 예전에 [Fastly 대규모 장애](https://www.fastly.com/blog/summary-of-june-8-outage)도 있었으니까 의심은 남음
  - 누군가 실수한 게 아니라는 걸 알고 느끼는 **이상한 안도감**에 딱 맞는 단어가 있을까 궁금함
  - 혹시 그 동료가 Cloudflare 직원일지도 모름
  - 나도 클라이언트들한테 사이트가 안 된다는 메시지를 수십 개 받았는데, 어제 설정을 바꿔서 식은땀 흘렸음  
    “Cloudflare down” 메시지를 보고 진심으로 안도했음

- 네덜란드에서 확인해보니 **거의 모든 서비스가 다운** 상태였음  
  Cloudflare 대시보드도 접속 불가였고, Betterstack 대시보드도 마찬가지였음  
  아이러니하게도 상태 페이지는 살아 있어서 고객에게 공지를 못 하는 상황이었음
  - 나도 같은 경험을 했음. HN만 멀쩡한 이유는 Cloudflare를 안 쓰기 때문임  
    “필요 없으면 Cloudflare 뒤에 두지 말라”는 [블로그 글](https://huijzer.xyz/posts/123/)을 썼음
  - AWS나 Cloudflare에 과도하게 의존하는 게 위험하다는 걸 매년 깨닫지만, **대체가 쉽지 않음**  
    그래도 이런 대규모 장애가 나면 고객들이 의외로 이해심을 보여줌
  - Cloudflare 대시보드가 완전히 죽은 건 아니고, **집요하게 시도하면 프록시를 끌 수 있음**  
    몇 분 걸렸지만 [hcker.news](https://hcker.news)를 CF에서 분리함
  - 이런 상황을 보니 **로컬 VPS에 상태 페이지를 올려주는 서비스**를 만들면 비즈니스 기회가 있을 듯함
  - 내 사이드 프로젝트 [Total Real Returns](https://totalrealreturns.com/)에서는  
    하단에 외부 상태 페이지와 연결된 **실시간 가동률 위젯**을 넣어둠  
    [상태 SVG](https://status.heyoncall.com/svg/uptime/zCFGfCmjJN6XBX0pACYY/uptime_bars_and_percent_400x200)와  
    [외부 상태 페이지](https://status.heyoncall.com/o/zCFGfCmjJN6XBX0pACYY)를 참고하면 됨

- Cloudflare나 AWS가 멈췄을 때 내 **self-hosted 서비스가 멀쩡히 작동하는 걸 보는 쾌감**이 있음  
  그들의 99.999% 가용성보다 지금은 내가 더 안정적임
  - 내 허접한 개인 사이트도 AWS, Azure, Cloudflare 장애 때 전부 살아 있었음  
    이제 **업타임 트래커**를 달아볼까 함
  - 내 self-hosted 사이트는 Cloudflare 프록시 때문에 오히려 다운됨. 허탈함
  - 전통 기업들이 Oracle, SAP 같은 시스템은 멀쩡한데, **신규 클라우드 기반 서비스만 멈춘 상황**을 겪고 있음  
    신생 SaaS 기업들이 배워야 할 교훈임
  - DNS를 어떻게 처리하냐는 질문이 많음. 나도 라즈베리파이에서 호스팅 중인데 DNS를 Cloudflare로 옮긴 직후라  
    내 작은 사이트가 다운된 게 웃기면서도 묘하게 만족스러움

- 최근 들어 **대규모 인프라 장애가 급증**한 것 같음. AWS, Cloudflare 모두 SLA보다 훨씬 못 미침
  - 대형 기업들이 **대규모 해고 후 AI로 대체**하겠다고 한 시점과 맞물려 있음
  - 이런 장애를 통해 SLA의 **‘9의 개수’가 의미 없다는 것**을 깨달음  
    실제 가동률이 아니라 기업이 임의로 정의한 수치일 뿐임
  - 어떤 사람은 “**vibe code theory**”라고 부름. 감으로 짠 코드가 늘수록 버그와 장애도 늘어난다는 농담 섞인 이론임
  - 연말 배포 금지 기간과 Q4 목표 압박이 겹쳐서 **서둘러 배포하는 문화**가 원인이라는 분석도 있음
  - 혹은 **국가 단위의 사이버 공격**일 수도 있다는 음모론적 시각도 있음

- Cloudflare나 AWS가 멈추면 웹의 절반이 멈추는 **중앙화 문제**가 심각함
  - 사용자들도 크게 신경 쓰지 않음. “인터넷이 멈췄다”는 인식 덕분에 개별 서비스는 **책임 회피**가 가능함  
    이런 구조가 바뀌지 않는 이유임
  - DDoS 방어에는 **규모의 경제**가 작용함. 고객이 많을수록 대역폭이 커지고 방어력이 강해짐  
    작은 CDN은 경쟁이 어렵고, 결국 **자연 독점 구조**가 형성됨  
    Cloudflare가 무료 요금제를 제공한 건 이런 네트워크 효과를 노린 전략이었음
  - 단일 장애 지점보다 더 걱정되는 건, 이런 중앙화가 **웹 표준과 자율 호스팅의 미래를 왜곡**할 수 있다는 점임  
    또한 정부 검열의 집중 타깃이 될 가능성도 큼
  - Let's Encrypt도 잠재적 위험이 있음.  
    웹의 2/3가 의존하고, 인증서 수명이 점점 짧아지며, 만약 **해킹이나 장애가 발생하면 웹 전체가 마비될 수 있음**  
    지금은 선한 조직이지만, 과거의 Google도 그랬다는 점을 잊지 말아야 함
  - AWS 열풍 이후 개발자들이 **전용 서버 대신 클라우드에만 의존**하게 된 게 문제임  
    소프트웨어 레벨의 백업은 많지만, 인프라 레벨의 **다중 호스팅 상식**이 사라졌음

- 아이러니하게도 **DownDetector도 Cloudflare Turnstile**을 써서 같이 다운됨
  - AWS 장애 보고도 폭증했지만, 아마 **오탐**일 가능성이 큼
  - 나도 그 현상을 봤음

- Cloudflare의 “Your browser: Working / Host: Working / Cloudflare: Error”라는 **시각적 사과 메시지**가 인상적이었음
  - 이런 화면은 처음 봄. 다만 내 경우 “Host”가 Cloudflare Pages라서 의미가 애매했음
  - “Cloudflare”를 클릭하면 여전히 고객 서버 문제라고 안내하는 건 좀 웃김
  - 솔직한 메시지라 좋았지만, 사용자들은 “와이파이 고쳐달라”는 반응뿐이었음
  - 그래도 상황을 명확히 알고 대응할 수 있었음. 필요하면 **프록시를 비활성화**해 서비스 영향 최소화 가능함
  - 나도 한 시간 동안 로그를 뒤지다가 내 서버 문제가 아니라는 걸 깨달았음

- Cloudflare Challenge(“I’m not a robot”)를 쓰는 사이트들도 **HTTP 500 오류**를 내며 멈춤  
  “challenges.cloudflare.com을 차단 해제하라”는 메시지가 뜸
  - 요즘 **에러 처리 수준이 너무 낮음**. 기업들이 책임을 회피하려고 사용자 탓으로 돌리거나  
    무한 로딩 화면만 보여줌. 실제로는 백엔드가 명확한 에러를 반환하는데 프론트가 숨김  
    최근엔 비밀번호가 너무 길다는 에러를 “이메일이 이미 사용 중”으로 바꿔 보여주는 사례도 봄
  - 이 장애로 **chat.bing.com의 AI 검색(GPT5)** 도 멈춤  
    아이러니하게도 AI에게 인간임을 증명해야 하는 상황이 됨
  - 일부 사이트(pinkbike 등)는 “you have been blocked” 메시지를 표시함
  - 로봇뿐 아니라 실제 사람도 차단당하는 셈임 /s
  - 프론트엔드가 사용자가 DNS나 확장 프로그램으로 도메인을 차단했다고 오인하는 듯함  
    Cloudflare Captcha가 다운될 리 없다는 **/s식 부정**이 웃김