Cloudflare

Cloudflare 는 웹사이트 앞에 서서 방문자의 요청을 먼저 받는 네트워크입니다. 도메인을 이 네트워크에 붙이면 요청이 원래 서버로 바로 가지 않고 여기를 거칩니다. 거치는 동안 응답을 저장해 두었다가 대신 돌려주기도 하고 걸러내기도 합니다.

상세

Cloudflare 는 오리진 서버(도메인이 실제로 가리키는, 콘텐츠를 갖고 있는 원래 서버) 앞에 놓이는 리버스 프록시 네트워크입니다. 공식 개발자 문서는 리버스 프록시를 웹 서버 앞에 놓여 요청을 그 웹 서버로 넘기거나 웹 서버를 대신해 요청을 처리하는 서버들의 네트워크라고 정의합니다. 그리고 리버스 프록시는 대체로 웹사이트와 웹 애플리케이션의 보안·성능·신뢰성을 높이는 데 도움이 되도록 둔다고 적습니다.

무엇이 이 네트워크를 지나가는지는 DNS(Domain Name System, 도메인 이름 체계) 레코드가 정합니다. 문서는 Cloudflare 가 도메인에 대한 DNS 질의를 받으면 응답이 그 도메인의 DNS 레코드 설정으로 결정된다고 적습니다 — 레코드의 종류, 그 레코드가 프록시 대상이 될 수 있는지, 그리고 프록시 상태 셋입니다. 프록시 상태가 켜진 레코드는 그 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약)·HTTPS(HTTP Secure) 트래픽이 클라이언트와 오리진 서버 사이에서 Cloudflare 를 거쳐 갑니다.

프록시 상태

프록시 상태는 레코드 하나하나에 붙는 스위치입니다. 대시보드에서 주황색 구름 아이콘으로 보여서 "오렌지 클라우드" 라고도 부릅니다. 켜면 Cloudflare 가 방문자와 서버 사이에 앉아 트래픽을 지나가는 길에 최적화하고 캐시하고 보호합니다. 이렇게 트래픽을 실제로 받아 처리하는 Cloudflare 서버를 엣지라고 부릅니다. 끄면 DNS-only 상태가 되어 Cloudflare 는 서버의 실제 IP(Internet Protocol, 인터넷 프로토콜) 주소를 그대로 응답하고 HTTP·HTTPS 트래픽을 자기 네트워크로 보내지 않습니다. 대시보드에서는 회색 구름 아이콘으로 표시됩니다.

프록시 상태에 따라 요청이 도는 자리가 이렇게 갈립니다.

flowchart TD
    V[방문자] -->|DNS 질의| CF["Cloudflare"]
    CF --> P{레코드가 프록시 상태인가}
    P -->|"예: Cloudflare 엣지가 요청을 대신 받아 오리진에 전달"| Origin["오리진 서버"]
    P -->|"아니오(DNS-only): 실제 IP 로 응답"| V
    V -->|HTTP·HTTPS 요청 직접 연결| Origin

프록시를 켤 수 있는 레코드는 IP 주소 해석에 쓰이는 것뿐입니다. A·AAAA·CNAME 레코드가 그것입니다. MX·TXT 같은 다른 종류는 언제나 DNS-only 입니다.

프록시를 켠 레코드에서 Cloudflare 가 할 수 있는 일로 문서가 드는 것은 셋입니다. 오리진 서버를 DDoS(Distributed Denial of Service, 분산 서비스 거부) 공격으로부터 보호하는 것, 애플리케이션으로 가는 모든 요청을 최적화하고 캐시하고 보호하는 것, 그리고 WAF(Web Application Firewall, 웹 애플리케이션 방화벽) 규칙·캐싱·리다이렉트 규칙 같은 Cloudflare 제품 설정을 들어오는 트래픽에 적용하는 것입니다.

프록시된 레코드의 TTL(Time To Live)은 기본값이 Auto 이고, 그 값은 300초입니다. 이 값은 편집할 수 없습니다.

리버스 프록시로 얻는 것

문서가 드는 것은 부하 분산, 공격으로부터의 보호, 캐싱, SSL(Secure Sockets Layer) 암호화입니다. 리버스 프록시를 앞에 두면 웹사이트나 서비스가 오리진 서버의 IP 주소를 드러낼 일이 없고, 그래서 공격자가 오리진을 겨냥해 공격하기가 훨씬 어려워진다고 적습니다. 캐싱은 리버스 프록시가 콘텐츠를 저장해 두었다가 돌려주는 것입니다. SSL 은 들어오는 요청을 모두 복호화하고 나가는 응답을 모두 암호화하도록 설정할 수 있어서, 그만큼 오리진 서버의 자원이 남는다는 설명입니다.

포기한 것

기본 캐시에서 빠지는 것

Cloudflare 는 파일 확장자만 보고 캐시 대상을 정합니다. MIME(Multipurpose Internet Mail Extensions) 타입은 보지 않습니다. 그래서 확장자 목록에 없는 HTML(HyperText Markup Language, 하이퍼텍스트 마크업 언어)과 JSON(JavaScript Object Notation)은 기본 상태에서 캐시되지 않습니다. 기본으로 캐시되는 것은 zip · png · css · js · pdf · woff2 처럼 확장자가 목록에 든 자원과 robots.txt 입니다.

확장자가 맞아도 캐시하지 않는 조건이 셋 더 있습니다. Cache-Control 헤더가 private · no-store · no-cache · max-age=0 중 하나일 때, Set-Cookie 헤더가 있을 때, 그리고 요청 메서드가 GET 이 아닐 때입니다. 캐시에 담기지 않은 응답은 캐시에서 다시 나가지도 않습니다.

넷 중 하나라도 걸리면 그 자리에서 캐시 대상에서 빠집니다.

flowchart TD
    A[요청받은 자원] --> B{확장자가 캐시 목록에 있나}
    B -->|아니오| N[캐시 안 함]
    B -->|예| C{"Cache-Control 이 private·no-store·<br/>no-cache·max-age=0 인가"}
    C -->|예| N
    C -->|아니오| D{Set-Cookie 헤더가 있나}
    D -->|예| N
    D -->|아니오| E{메서드가 GET 인가}
    E -->|아니오| N
    E -->|예| Y[캐시 대상]

대신 캐시되는 것에는 상태 코드별 기본 TTL 이 붙습니다.

그 밖의 상태 코드는 기본으로 캐시되지 않습니다.

프록시되는 포트

기본으로 프록시되는 것은 문서가 목록으로 못 박은 HTTP·HTTPS 포트입니다.

세 번째 행은 앞 두 행과 나란한 갈래가 아니라, HTTP·HTTPS 포트 가운데 캐싱만 꺼진 것을 추려낸 부분집합입니다. 그래서 8443 처럼 HTTPS 행과 세 번째 행에 같이 나오는 포트가 있습니다. 캐싱까지 켜져 있는 것은 세 번째 행에 없는 80·8080·443 세 포트뿐입니다.

목록 밖 포트로 오는 트래픽 — 예를 들어 22번 포트에서 연결을 기다리는 SSH(Secure Shell) 서버 — 는 두 갈래뿐입니다. 그 서브도메인을 회색 구름으로 바꿔 Cloudflare 네트워크를 우회해 오리진에 바로 붙게 하거나, 그 호스트 이름에 Spectrum(TCP·UDP 기반 애플리케이션을 보호하고 가속하는 서비스) 애플리케이션을 설정하는 것입니다. Spectrum 은 모든 포트를 지원하지만, 모든 TCP(Transmission Control Protocol)· UDP(User Datagram Protocol) 포트를 여는 Spectrum 은 Enterprise 요금제에서만 쓸 수 있습니다.

포트가 목록 안에 있는지에 따라 트래픽이 도는 자리가 이렇게 갈립니다.

flowchart TD
    A[요청이 오는 포트] --> B{목록 안 포트인가}
    B -->|예| C[프록시됨]
    C --> D{캐싱도 켜진 포트인가}
    D -->|예| E[프록시 + 캐싱]
    D -->|아니오| F["프록시만, 캐싱 꺼짐"]
    B -->|아니오| G[둘 중 하나를 고른다]
    G --> H[서브도메인을 회색 구름으로 바꿔 오리진에 직접 연결]
    G --> I[Spectrum 애플리케이션 설정]

애니캐스트(하나의 IP 주소를 여러 서버가 함께 응답하는 방식) 네트워크라는 성질 때문에 80·443 밖의 포트도 열려 있기는 합니다. Cloudflare 가 다른 고객의 트래픽을 그 포트로 처리할 수 있게 하려는 것이라고 문서는 적습니다. 열려 있다는 것이 내 도메인의 그 포트가 프록시된다는 뜻은 아닙니다.

Workers 의 자원 상한

Workers 는 이 네트워크 위에서 코드를 돌리는 자리입니다. Workers 는 이 자리(플랫폼) 이름이고, 그 위에서 도는 코드 한 벌은 단수형 Worker 라 부릅니다 — 이 문서에서는 이를 「워커」로 씁니다. 그런데 워커가 돌릴 수 있는 코드의 크기와 쓸 수 있는 자원이 항목마다 시간·개수·MB(Megabyte, 메가바이트) 단위의 값으로 못 박혀 있습니다. 아래 표의 Free·Paid 는 Workers 만의 요금제 구분이라, 뒤에 나오는 운영 절의 Free·Pro·Business· Enterprise 축과는 다릅니다. 표의 서브리퀘스트는 Worker 가 fetch() 호출이나 다른 Cloudflare 서비스로 보내는 요청을 셉니다.

메모리 128 MB 는 아이솔레이트(Worker 코드가 실행되는 격리 단위) 하나당 값입니다. 호출 하나당이 아닙니다. 자바스크립트 힙과 웹어셈블리 할당이 여기에 다 들어갑니다. 상한을 넘기면 Cloudflare 는 클라이언트에 오류 1102 와 worker exceeded resource limits 메시지를 돌려줍니다. CPU 시간을 넘겨도, 메모리를 넘겨도 같은 1102 입니다.

대신 CPU 시간은 코드를 실제로 실행한 시간만 셉니다. fetch() 호출이나 KV(Key-Value, 키-값) 읽기, 데이터베이스 질의처럼 네트워크를 기다리는 시간은 CPU 시간에 안 들어갑니다. 문서는 대부분의 워커가 CPU 시간을 아주 조금만 쓰고, 평균적인 워커가 요청당 약 2.2 ms 를 쓴다고 적습니다.

예시

CF-Cache-Status 응답 헤더

캐시에 맞았는지 아닌지는 CF-Cache-Status 라는 응답 헤더 하나로 드러납니다. 이름 앞의 CF(Cache-Status·Connecting-IP 처럼 여러 헤더 이름에 공통으로 붙는, Cloudflare 를 줄인 접두어)는 뒤에서 볼 CF-Connecting-IP 에도 그대로 붙습니다.

CF-Cache-Status: DYNAMIC

이 헤더가 가질 수 있는 값은 아홉 가지입니다. HIT · MISS · NONE/UNKNOWN · EXPIRED · STALE · BYPASS · REVALIDATED · UPDATING · DYNAMIC 입니다. 이 가운데 DYNAMIC 과 BYPASS 만 여기서 뜻을 풉니다.

DYNAMIC 과 BYPASS 는 판단 시점이 다릅니다. DYNAMIC 은 요청 시점에 Cloudflare 가 그 자원을 캐시 대상이 아니라고 판정했을 때만 나옵니다. BYPASS 는 캐시하지 않기로 한 결정이 응답 시점에 내려졌다는 뜻입니다. 처음에는 캐시 대상이었지만 오리진 응답이나 그 응답 헤더가 캐시하지 말라고 지시한 경우입니다. 예를 들어 캐시 규칙이 "cache": true 로 요청 시점의 캐싱을 켜 두었는데 오리진이 Cache-Control: no-store 를 돌려주면 그 응답은 BYPASS 가 됩니다.

sequenceDiagram
    participant 방문자
    participant 엣지
    participant 오리진
    방문자->>엣지: 요청
    alt 요청 시점에 캐시 대상이 아님
        Note over 엣지: 캐시 규칙 평가(요청 시점)
        엣지-->>방문자: CF-Cache-Status DYNAMIC
    else 요청 시점엔 캐시 대상, 응답이 뒤집음
        Note over 엣지: 캐시 규칙 평가(요청 시점)<br/>"cache": true
        엣지->>오리진: 전달
        오리진-->>엣지: Cache-Control no-store
        Note over 엣지: 캐싱 거부(응답 시점)
        엣지-->>방문자: CF-Cache-Status BYPASS
    end

CF-Connecting-IP 요청 헤더

프록시를 거치면 오리진이 보는 접속 주소는 Cloudflare 의 것입니다. 방문자의 실제 주소는 CF-Connecting-IP 라는 별도 요청 헤더로 오리진에 넘어갑니다. 문서는 이 헤더가 Cloudflare 에 접속한 클라이언트의 IP 주소를 오리진 웹 서버에 준다고 적습니다. 이 헤더는 Cloudflare 엣지에서 오리진 웹 서버로 가는 트래픽에만 붙습니다.

CF-Connecting-IP

이 값이 채워지는 경로는 상황에 따라 갈립니다. 엣지가 오리진에 직접 트래픽을 넘길 때는 엣지가 그 연결을 직접 보고 이 헤더에 방문자 IP 를 채웁니다. 반면 존(도메인을 Cloudflare 계정에 등록한 단위) 안에서 Worker 가 오리진으로 서브리퀘스트를 보낼 때는, 이 값이 같은 요청에 이미 붙어 있던 X-Real-IP(방문자 IP 를 담아 오는 헤더) 값을 그대로 따라갑니다. 두 경로 모두 결과는 방문자 IP 지만, 값을 채우는 경로가 다릅니다 — 엣지가 직접 채우느냐, 앞서 있던 X-Real-IP 값을 그대로 옮기느냐입니다.

sequenceDiagram
    participant 방문자
    participant 엣지
    participant Worker
    participant 오리진
    방문자->>엣지: 요청
    alt 엣지 → 오리진 직접 트래픽
        엣지->>오리진: 전달(CF-Connecting-IP = 방문자 IP, 엣지가 직접 채움)
    else 같은 존 안의 Worker 서브리퀘스트
        엣지->>Worker: 전달(X-Real-IP = 방문자 IP)
        Worker->>오리진: 서브리퀘스트(CF-Connecting-IP 가 X-Real-IP 값을 그대로 따름)
    end

단일 파일 퍼지

캐시에 든 자원 하나를 지우는 것을 단일 파일 퍼지라고 부릅니다. 문서는 이 퍼지가 모든 데이터 센터마다 도는 엣지 캐시 전체에서 — 이 네트워크의 CDN(Content Delivery Network, 콘텐츠 전송 네트워크)에 저장된 자원 전부에서 — 그 자원을 즉시 지운다고 적습니다. 지워진 자원에 대한 새 요청은 오리진 웹 서버에서 최신 버전을 받아 오고, 그 요청을 받은 데이터 센터의 엣지 캐시에 다시 담깁니다. 퍼지의 결과는 헤더로 확인할 수 있습니다 — 지워진 자원을 다시 요청하면 캐시에 없어 오리진에서 받아온 것이므로 CF-Cache-Status 가 MISS(캐시에서 못 찾음)가 됩니다.

한 가지 예외가 문서에 적혀 있습니다. 캐시 규칙으로 헤더·쿠키·그 밖의 요청 속성을 넣은 커스텀 캐시 키를 쓰고 있으면, 대시보드를 통한 단일 파일 퍼지로는 그 캐시된 자원이 무효화되지 않습니다. 이럴 때는 API(Application Programming Interface, 응용 프로그램 인터페이스)로 퍼지하되 커스텀 캐시 키에 들어간 헤더와 쿠키를 모두 함께 넘겨야 합니다.

sequenceDiagram
    participant 방문자
    participant 엣지
    participant 오리진
    Note over 엣지: 단일 파일 퍼지 실행 — 데이터 센터마다 도는<br/>엣지 캐시 전체에서 그 자원 즉시 삭제
    방문자->>엣지: 같은 자원 요청
    엣지->>오리진: 최신 버전 요청
    오리진-->>엣지: 최신 버전 응답
    엣지-->>방문자: CF-Cache-Status MISS
    Note over 엣지: 응답을 요청을 받은 데이터 센터의 엣지 캐시에 다시 담음

운영

크기 상한

프록시된 요청에는 크기 상한이 걸립니다. 단위는 MB 와 GB(Gigabyte, 기가바이트)입니다. 문서는 이 상한이 요금제마다 다르고, 트래픽이 프록시되는 동안에는 우회할 수 없다고 적습니다.

요청 본문이 상한을 넘으면 413 Request Entity Too Large 가 돌아옵니다. 최대 업로드 크기는 존의 네트워크 페이지에서 더 줄일 수 있습니다. Enterprise 의 캐시 가능 파일 크기 5 GB 는 기본값이고, 계정 팀에 상한 상향을 요청할 수 있다고 적혀 있습니다.

요금제와 무관하게 걸리는 상한도 있습니다.

퍼지 호출의 빈도

캐시 퍼지는 계정 단위로 빈도가 제한됩니다. Cloudflare 는 토큰 버킷 방식으로 어느 시점에나 시스템을 흐르는 퍼지 요청 수를 제한한다고 적습니다. 아래 표의 초당·분당 값은 토큰이 다시 차는 속도입니다. 버킷마다 이 속도와 별개로 한 번에 밀어 넣을 수 있는 최대 용량(버킷 크기)도 있는데, 공식 문서가 그 값을 적어 둔 것은 Free·Pro 뿐입니다 — 둘 다 토큰 25개로, 표에는 나오지 않는 값입니다.

퍼지 요청 행은 캐시 퍼지 API 호출 자체의 빈도를 제한하고, 단일 파일 퍼지 URL 행은 단일 파일 퍼지로 지울 수 있는 URL 개수의 빈도를 따로 제한합니다. 서로 다른 것을 세는 값이라 두 행을 곱하거나 더해 하나의 처리량으로 합칠 수 없습니다.

오리진이 안 잡힐 때

Cloudflare 는 자기와 오리진 서버 사이에 기본 프록시 읽기 타임아웃을 겁니다. 정해진 시간 안에 오리진이 HTTP 응답을 보내지 않으면 524 를 돌려줍니다. 문서가 적은 기본값은 읽기 타임아웃 125초입니다. 쓰기 쪽에도 타임아웃이 있습니다. 이 타임아웃은 Cloudflare 가 오리진에 연결해 데이터를 쓰기 시작한 시점부터 셉니다. 30초 안에 쓰기가 끝나지 않아도 524 가 납니다. 이 네트워크 위의 다른 제품인 Cloudflare Images 의 경우 이 쓰기 타임아웃은 6.5초입니다. Enterprise 고객은 524 타임아웃을 6,000초까지 올릴 수 있습니다.

524 는 오리진 쪽 5xx 계열 가운데 하나입니다. 문서가 목록으로 정리한 것은 이렇습니다.

522 와 523 은 연결 쪽 이름이 붙어 있고, 524 는 연결에 성공한 뒤 응답이 제때 안 온 경우입니다. 525 와 526 은 SSL 쪽 이름이고, 530 은 문서가 목록에만 올렸을 뿐 이름을 따로 붙이지 않았습니다.

flowchart TD
    A[오리진 요청] --> B{무엇이 실패했나}
    B -->|연결 자체| C["522 · 523"]
    B -->|SSL 핸드셰이크| D["525 · 526"]
    B -->|"연결 성공 뒤 응답 지연<br/>(읽기 125초 또는 쓰기 30초·Images 는 6.5초)"| E["524"]
    B -->|"문서가 이름 없이 목록에만 올림"| F["530"]

관련 항목

이 네트워크가 파는 제품

Workers · R2 · KV · D1 · Pages · Cloudflare Tunnel · Spectrum · WARP 클라이언트 · WAF · DDoS 방어 · Argo Smart Routing · Cloudflare Images

요청이 지나가는 경로의 구성 요소

리버스 프록시 · CDN · 오리진 서버 · 엣지 · 애니캐스트 · 네임서버 · 캐시 규칙 · 캐시 키 · 데이터 센터

여기서 보는 헤더와 코드

CF-Cache-Status · CF-Connecting-IP · X-Real-IP · Cache-Control · Set-Cookie · HTTP 413 · HTTP 522 · HTTP 524 · 토큰 버킷 · 아이솔레이트