변경 기록

변경 기록 (Changelog)

Cloudflare Cache 기능의 최신 업데이트와 변경 사항을 추적하는 페이지예요. 각 항목은 날짜와 함께 기능 개선·변경·신규 기능을 설명해요.

출처: 문서

본문

RSS 구독

2026-09-28

캐시된 콘텐츠를 제거하는 대신 무효화하기

이제 캐시된 콘텐츠를 제거(purge)하는 대신 무효화(invalidate)할 수 있어요. 무효화는 일치하는 콘텐츠를 stale로 표시해요. 다음 요청에서 Cloudflare는 오리진과 콘텐츠를 재검증해요. 오리진이 304 Not Modified로 응답하면 Cloudflare는 다시 다운로드하는 대신 캐시된 콘텐츠를 재사용해요.

자산 중 일부만 변경되었을 때 자산 그룹을 새로 고치려면 무효화를 사용해요. 예를 들어 캐시 태그를 공유하는 모든 콘텐츠를 무효화해요. Cloudflare는 변경되지 않은 자산을 다시 다운로드하는 대신 재사용해요. 이를 위해서는 오리진이 ETag 또는 Last-Modified 헤더를 반환하고 조건부 요청을 지원해야 해요.

무효화는 제거와 같은 선택자를 지원해요: URL, 캐시 태그, 호스트명, URL 접두사, 전체. 콘텐츠를 무효화하려면 새 invalidate_cache 엔드포인트에 POST 요청을 보내요:

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache" \
  --header "Authorization: Bearer $CLOUD...OKEN" \
  --header "Content-Type: application/json" \
  --data '{"tags":["product-images"]}'

대시보드에서는 Caching > Configuration 페이지의 Invalidate Cache를 사용해요.

캐시 설정이 Cloudflare가 재검증하는 동안 stale 콘텐츠를 제공하는지 여부를 결정해요. 오리진이 5xx 오류를 반환하거나 도달할 수 없으면 Cloudflare는 무효화된 콘텐츠를 stale로 제공할 수도 있어요. 캐시된 콘텐츠 제공을 중단하려면 대신 제거해요.

무효화 요청은 제거 요청과 같은 속도 제한에 포함돼요.

이번 릴리스에서는 Cache Reserve의 제거 동작도 변경됐어요. 자세한 내용은 Cache Reserve 제거 동작을 참고해요.

자세한 내용은 캐시된 콘텐츠 무효화를 참고해요.

2026-09-28

제거가 이제 Cache Reserve 콘텐츠에 대해 캐시 미스를 강제함

제거 요청은 이제 제거 유형과 무관하게 Cache Reserve 콘텐츠에 대해 캐시 미스를 강제해요. 이전에는 캐시 태그, 호스트명, 접두사, 또는 전체로 제거하면 일치하는 Cache Reserve 콘텐츠가 재검증 대상으로 표시됐어요. URL로 제거하면 이미 Cache Reserve에서 콘텐츠를 삭제했고, 이는 변경되지 않았어요.

이 변경은 API와 대시보드의 제거 요청에 적용돼요. Cache Reserve는 이제 에지 캐시와 같은 방식으로 제거를 처리해요.

비용 영향

제거 후 영향받는 콘텐츠의 다음 요청은 Cache Reserve 미스예요. 콘텐츠가 변경되지 않았더라도 오리진이 온전히 콘텐츠를 전달해야 해요. 그러면 Cloudflare가 콘텐츠를 다시 Cache Reserve에 기록하며, 이는 Class A 작업으로 청구돼요.

태그, 호스트명, 접두사, 또는 전체로 제거하면 바로 Cache Reserve에서 콘텐츠를 삭제하지 않아요. 일치하는 콘텐츠는 이후 요청이 교체하거나 보존 기간이 끝날 때까지 스토리지 비용이 계속 발생해요.

Cache Reserve 콘텐츠를 태그, 호스트명, 접두사, 또는 전체로 자주 제거한다면 오리진 이그레스와 Cache Reserve 사용량에 미치는 영향을 검토해요.

Cache Reserve 콘텐츠 계속 재검증하기

콘텐츠를 Cache Reserve에 유지하고 재검증하려면 새 invalidate_cache 엔드포인트에 같은 요청을 보내요:

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/invalidate_cache" \
  --header "Authorization: Bearer $CLOUD...OKEN" \
  --header "Content-Type: application/json" \
  --data '{"tags":["product-images"]}'

대시보드에서는 Caching > Configuration 페이지의 Invalidate Cache를 사용해요.

오리진이 304 Not Modified로 응답하면 Cloudflare는 오리진에서 다시 가져오는 대신 저장된 콘텐츠를 재사용해요. 제거와 비교해 무효화는 오리진 이그레스를 줄이지만 Cache Reserve 작업은 줄이지 않아요. 304 응답 후 저장된 콘텐츠를 업데이트하는 것은 여전히 Class A 작업이에요. URL로 무효화하면 요청을 보낼 때 저장된 콘텐츠도 업데이트되는데, 이것도 Class A 작업이에요.

이전 제거 동작과 달리, 무효화는 캐시 설정이 허용하면 재검증하는 동안 stale 콘텐츠를 제공할 수 있어요. 이는 에지 캐시의 복사본에만 적용되며 Cache Reserve에서 제공되는 콘텐츠에는 적용되지 않아요. 오리진이 5xx 오류를 반환하거나 도달할 수 없으면 Cloudflare는 무효화된 콘텐츠를 stale로 제공할 수도 있어요. 자세한 내용은 캐시된 콘텐츠 무효화를 참고해요.

2026-09-02

Rulesets API로 Origin Range Requests 구성

Rulesets API가 이제 Cache Rules에서 Origin Range Requests를 지원해요. 이 설정은 Cloudflare가 오리진에서 대용량 파일을 캐시 정렬 바이트 범위로 가져오게 해요. Cloudflare는 클라이언트 범위를 확장하고 여러 개의 단일 범위 오리진 요청을 발행할 수 있어요.

Cache Rule이 일치하는 모든 트래픽에 대해 origin_range_requests.mode를 on, off, 또는 default로 설정해요.

Cloudflare의 기본 Origin Range Requests 동작을 덮어쓰려면 모드를 off로 설정해요. 다음 규칙은 캐시 적격성을 바꾸지 않고 모든 트래픽에 대해 생성된 오리진 범위 요청을 끄는 예시예요:

{
  "expression": "true",
  "action": "set_cache_settings",
  "action_parameters": {
    "origin_range_requests": {
      "mode": "off"
    }
  }
}

Origin Range Requests는 그 외에는 적합하지 않은 콘텐츠를 캐시 가능하게 만들지 않아요. 오리진이 Range를 무시하고 완전한 200 OK를 반환하면 Cloudflare는 그 응답을 사용할 수 있지만 전체 파일을 다운로드해야 해요. 오리진은 Accept-Encoding: identity를 존중하고 일관된, 인코딩되지 않은 부분 응답을 반환해야 해요.

구성 세부 사항과 모드 동작은 Cache Rules의 Origin Range Requests를 참고해요. 클라이언트 응답과 전체 오리진 계약은 Range request behavior를 참고해요.

2026-07-02

Vary로 URL의 여러 버전 캐시

오리진은 Vary ↗︎ 응답 헤더를 반환해 같은 URL에 대해 다른 응답을 제공할 수 있어요 — Accept-Language에 따라 다른 언어, Accept에 따라 다른 포맷. Cloudflare 캐시는 이제 Cache Rules에서 그 헤더를 직접 존중해서, 같은 URL이 여러 캐시된 버전을 담을 수 있고 각 요청이 올바른 버전과 일치해요. 이전에는 올바르게 유지하기 위해 캐시를 우회해야 했던 콘텐츠를 이제 표준 HTTP 캐싱 동작 ↗︎에 따라 캐시할 수 있어요.

무엇이 바뀌었나

이제 오리진이 Vary 응답에 요청 헤더를 나열해 어떤 요청 헤더가 중요한지 결정하고, Cloudflare가 각각을 어떻게 처리할지는 당신이 제어해요. 캐시 규칙으로 Vary를 활성화했고 응답에 Vary 헤더가 포함되면, 나열된 요청 헤더가 캐시 키의 일부가 돼요.

오리진이 변형하는 각 헤더에 대해 세 가지 액션 중 하나를 선택해요:

액션	동작	가장 좋은 경우
normalize	일치하기 전에 동등한 헤더 값을 같은 캐시 키 값으로 변환해 중복 버전을 줄여요.	대부분의 Accept, Accept-Language, Accept-Encoding 사용 사례.
passthrough	캐시된 버전을 선택할 때 원시 헤더 값을 사용하고 변경 없이 오리진에 전달해요.	헤더 값의 바이트 단위 차이가 버전을 만들어야 할 때.
bypass	이 헤더 이름이 오리진의 Vary 응답에 나타날 때마다 캐시를 우회해요.	사용자별 값, 또는 안전하게 캐시하기에 가능한 값이 너무 많은 헤더.

이점

• 더 높은 캐시 적중률: normalize는 의미상 동등한 헤더를 하나의 버전으로 취급해요. 예를 들어 Accept-Language: en-US, fr;q=0.8와 Accept-Language: fr;q=0.8, en-GB는 둘 다 같은 캐시 키로 해석되므로, 오리진 대신 캐시에서 더 많은 요청을 제공해요.
• 올바른 콘텐츠 협상: 요청은 항상 자신의 헤더와 일치하는 캐시된 버전을 받으므로 언어와 포맷 변형이 정확하게 유지돼요.
• 오리진이나 Worker 변경 불필요: 오리진이 이미 Vary를 보내면 동작을 전적으로 Cache Rules에서 구성해요.
• 표준 준수: 캐시 키 계산이 RFC 9111을 따르고, Vary: *는 RFC 9110에서 요구하듯 계속 캐시를 우회해요.

제공 범위

Cache Rules의 Vary는 모든 요금제(Free, Pro, Business, Enterprise)에서 사용할 수 있어요. Workers 하위 요청에서 요청별 제어를 원하면 cf.vary 속성을 사용해요.

시작하기

Caching > Cache Rules 아래 Cloudflare 대시보드 ↗︎ 또는 Rulesets API에서 Vary를 구성해요. Vary가 캐시 키에 미치는 영향과 각 액션의 동작은 Vary와 Cache Rules Vary 설정을 참고해요.

2026-05-26

캐시 불가능한 응답에 대해 BYPASS 상태 반환

Cloudflare는 이제 응답이 캐시 불가능할 때마다 BYPASS 캐시 상태를 반환해요. 이전에는 Cloudflare가 응답을 캐시하지 않기로 한 이유에 따라 BYPASS와 MISS가 섞여서 반환됐어요.

Cloudflare가 응답 캐싱을 거부하는 이유는 여러 가지예요 — 예를 들어 응답이 요금제의 최대 캐시 가능 파일 크기를 초과하거나, 오리진이 Cache-Control: no-cache, private, 또는 max-age=0을 보내거나, 응답에 Set-Cookie 헤더가 포함되거나, 요청에 Authorization 헤더가 포함된 경우 등이에요.

이전에는 이런 조건 중 일부만 BYPASS를 반환했어요. 다른 조건들 — 예를 들어 최대 캐시 가능 파일 크기를 초과하는 응답 — 은 Origin Cache Control이 켜져 있든 꺼져 있든 매 요청에서 MISS를 반환했어요. 응답이 절대 캐시될 수 없으므로 이후의 모든 요청도 MISS를 반환했고, 이는 손상된 캐시와 구분이 안 되어 Cloudflare가 캐시를 시도하다 실패한 것인지 아니면 의도적으로 캐시하지 않기로 한 것인지 구분하기 어려웠어요.

이제 BYPASS는 이유와 무관하게 Cloudflare가 응답 캐싱을 거부했음을 일관되게 나타내요. MISS는 요청 시점에 로컬 캐시에 단순히 없었던 캐시 가능 응답을 위해 예약돼요.

분석에서 기대할 수 있는 것

이 변경이 반영된 후 다음을 볼 수 있어요:

• MISS 비율 감소: 캐시 불가능한 응답이 더 이상 캐시 미스로 계산되지 않아요.
• BYPASS 비율 증가: 이제 이 같은 응답이 바이패스로 보고돼요.
• 캐시 적중률 증가: 적중률 계산에 절대 캐시될 수 없었던 캐시 불가능한 트래픽이 더 이상 포함되지 않아, 캐시 효율성을 더 정확하게 볼 수 있어요.

총 요청량과 오리진 트래픽은 변경되지 않아요 — 캐시 상태 레이블만 달라져요.

브라우저 캐시 TTL 동작 보존

변경되는 것은 캐시 상태 레이블뿐이에요. 주어진 응답의 브라우저 캐시 TTL 처리는 이전과 동일해요:

• Cloudflare가 캐싱을 거부해서 과거에 MISS를 반환했던 응답(예: 최대 캐시 가능 파일 크기를 초과하는 응답)은 이제 BYPASS를 반환하지만, MISS로 표시되던 때와 똑같이 브라우저 캐시 TTL을 계속 적용해요.
• 과거에 BYPASS를 반환하고 브라우저 캐시 TTL을 건너뛰던 응답은 브라우저 캐시 TTL을 계속 건너뛰어요.

두 경우 모두 브라우저 캐시 TTL 적용 여부는 새 BYPASS 레이블이 아니라 Cloudflare가 응답을 캐시하지 않은 근본 이유에 따라 달라져요.

2026-05-04

Pingora가 이제 Cloudflare의 캐시를 구동

Cloudflare 캐시는 이제 Pingora ↗︎ 위에 구축된 새 프록시로 실행돼요. Pingora는 이미 Cloudflare 네트워크 트래픽의 상당 부분을 처리하는 Rust 기반 프레임워크예요. 새 프록시는 더 빠르고 메모리 안전하며, 캐시 아키텍처를 발전시키도록 설계됐어요. 즉각적인 성능 개선을 제공하고 새로운 캐싱 기능을 가능하게 해요.

이것이 가져오는 것

• 더 낮은 지연: 새 프록시는 향상된 연결 재사용으로 요청당 오버헤드를 줄여요.
• 캐시 MISS 감소: 향상된 캐시 보존이 오리진 부하 완화를 개선해요.
• 더 나은 RFC 준수: 캐싱 동작이 HTTP 캐싱 표준을 더 밀접하게 따르게 돼요.
• 미래 기능의 기반: 새 아키텍처가 캐시 기능과 효율성의 향후 개선을 가능하게 해요.

새 기능

• 비동기 stale-while-revalidate: 만료 후 첫 번째 요청이 오리진을 차단하는 대신, 재검증이 백그라운드에서 일어나는 동안 모든 요청이 즉시 stale 콘텐츠를 반환해요. 자세한 내용은 비동기 stale-while-revalidate 변경 기록을 참고해요.
• 기본 무버퍼 바이패스: 캐시를 우회하는 응답은 버퍼링 없이 클라이언트로 직접 스트리밍되어 캐시 불가능한 콘텐츠의 첫 바이트까지 시간을 줄여요.

동작 변경

새 아키텍처는 RFC 준수와 정확성을 개선하기 위해 다음 동작 변경을 도입해요:

• Vary: *는 캐시 우회로 이어짐: RFC 9110 Section 12.5.5 ↗︎에 따라 * 값의 Vary 헤더는 응답이 요청 헤더 너머의 요소에 따라 변함을 나타내며 캐시에서 제공되어서는 안 돼요. Cloudflare는 이제 저장하는 대신 이러한 응답에 대해 캐시를 우회해요.
• MISS와 EXPIRED에서 Set-Cookie 제거: 캐시 가능한 자산의 경우 Set-Cookie는 이제 HIT뿐 아니라 MISS와 EXPIRED 응답에서도 제거돼요.
• 부동 소수점 TTL 값: 부동 소수점 수명 값(예: max-age=1.5)은 잘못된 것으로 거부되는 대신 가장 가까운 정수로 내림돼요.

다음 단계

새 캐시 프록시에 대한 더 깊은 설명이 곧 Cloudflare 블로그 ↗︎에 올라올 예정이에요. 기반 프레임워크에 대한 배경은 다음을 읽어요:

• Open sourcing Pingora: our Rust framework for building programmable network services ↗︎
• How we built Pingora, the proxy that connects Cloudflare to the Internet ↗︎

2026-04-27

Cache Response Rules가 이제 존 버전 관리를 지원

Cache Response Rules가 이제 Version Management와 함께 작동해요. Cache Rules 및 기타 지원되는 구성처럼 응답 단계 캐시 설정을 버전화하고 환경 간에 승격할 수 있어요.

무엇이 바뀌었나

이전에는 Cache Response Rules가 존 버전 관리에서 제외됐어요. 만든 응답 단계 규칙은 모든 환경에 전역으로 적용되어 스테이징에서 먼저 변경을 테스트할 방법이 없었어요. Cache Rules는 이미 버전 관리를 지원했지만, Cache-Control 지시어를 수정하고 캐시 태그를 관리하며 헤더를 제거하는 응답 단계는 지원하지 않았어요.

이제 Cache Response Rules가 Version Management와 완전히 통합됐어요. 버전 내에서 응답 단계 규칙을 만들거나 수정할 수 있고, 승격될 때까지 그 변경은 해당 버전에만 적용돼요.

이점

• 캐시 동작 변경의 안전한 배포: 프로덕션으로 승격하기 전에 스테이징 환경에서 응답 단계 규칙을 테스트해요. 의도하지 않은 캐싱 부작용을 조기에 발견해요.
• Cache Rules와의 동등성: Cache Response Rules가 이제 Cache Rules와 같은 버전 관리 워크플로를 따르므로, 단일 승격 파이프라인으로 모든 캐시 구성을 관리할 수 있어요.
• 독립적인 환경 제어: 환경별로 다른 응답 단계 캐시 설정을 실행해요. 예를 들어 프로덕션 트래픽에 영향을 주지 않고 스테이징에서 Set-Cookie 헤더를 제거해 캐시 가능성을 검증해요.

시작하기

Caching > Cache Rules 아래 Cloudflare 대시보드 ↗︎ 또는 Rulesets API에서 Cache Response Rules를 구성해요. 자세한 내용은 Cache Response Rules 문서와 Version Management 문서를 참고해요.

2026-04-17

Smart Tiered Cache가 퍼블릭 클라우드 오리진을 최적화

이제 Smart Tiered Cache로 퍼블릭 클라우드 제공업체에 호스팅된 오리진에서 더 높은 캐시 HIT 비율을 달성하고 오리진 부하를 줄일 수 있어요. 오리진에 클라우드 지역 힌트를 설정하면 Cloudflare가 해당 클라우드 지역에 최적의 상위 티어 데이터 센터를 선택하고, 모든 캐시 MISS를 오리진에 가까운 단일 위치로 보내요.

이전에는 Smart Tiered Cache가 클라우드 제공업체가 흔히 사용하는 anycast 또는 지역 유니캐스트 네트워크 뒤의 오리진에 대해 최적의 상위 티어를 안정적으로 선택할 수 없었어요. AWS, GCP, Azure, Oracle Cloud의 오리진은 다중 상위 티어 토폴로지로 폴백되어 캐시 HIT 비율이 낮아지고 오리진에 도달하는 요청이 늘어났어요.

작동 방식

오리진 IP 또는 호스트명에 클라우드 지역 힌트(예: aws/us-east-1 또는 gcp/europe-west1)를 설정해요. Smart Tiered Cache는 이 힌트와 실시간 지연 데이터를 사용해 클라우드 지역에 가까운 기본 상위 티어를 선택하고, 복원력을 위해 다른 위치에 폴백도 선택해요.

• 지원 제공업체: AWS, GCP, Azure, Oracle Cloud.
• 모든 요금제: 추가 비용 없이 Free, Pro, Business, Enterprise 요금제에서 사용할 수 있어요.
• 대시보드 및 API: Caching > Tiered Cache > Origin Configuration에서 구성하거나, API와 Terraform을 사용해요.

시작하기

시작하려면 Smart Tiered Cache를 활성화하고 Tiered Cache 설정에서 오리진에 클라우드 지역 힌트를 설정해요.

2026-03-24

Cache Response Rules

이제 오리진을 변경하지 않고 Cloudflare가 오리진 응답을 처리하는 방식을 제어할 수 있어요. Cache Response Rules를 사용하면 Cache-Control 지시어를 수정하고, 캐시 태그를 관리하며, Cloudflare 캐시에 도달하기 전에 오리진 응답에서 Set-Cookie 같은 헤더를 제거할 수 있어요. 트래픽이 캐시되든 동적으로 통과하든, 이 규칙은 이전에는 닿을 수 없었던 오리진 응답 동작을 제어하게 해 줘요.

무엇이 바뀌었나

Cache Rules는 이전에 요청 속성에서만 동작했어요. Cache Response Rules는 오리진 응답을 평가하고 캐싱 전에 그에 대한 작업을 하게 하는 새 응답 단계를 도입해요. 이제 다음을 할 수 있어요:

• Cache-Control 지시어 수정: no-store, no-cache, max-age, s-maxage, stale-while-revalidate, immutable 등 개별 지시어를 설정하거나 제거해요. 예를 들어 오리진이 보내는 no-cache 지시어를 제거해 Cloudflare가 자산을 캐시하게 하거나, s-maxage를 설정해 Cloudflare가 저장하는 시간을 제어해요.
• 다른 브라우저 Cache-Control 설정: Cloudflare가 내부적으로 사용하는 것과 다른 Cache-Control 헤더를 브라우저와 다른 클라이언트에 하위로 보내, 에지와 브라우저 캐싱 전략을 독립적으로 제어할 수 있게 해 줘요.
• 캐시 태그 관리: 응답에 캐시 태그를 추가, 설정, 또는 제거해요. 여기에는 다른 CDN의 헤더 형식의 태그를 Cloudflare의 Cache-Tag 헤더로 변환하는 것도 포함돼요. 이는 다른 태그 헤더나 구분자를 사용하는 CDN에서 마이그레이션할 때 특히 유용해요.
• 캐싱을 막는 헤더 제거: 캐싱 전에 오리진 응답에서 Set-Cookie, ETag, 또는 Last-Modified 헤더를 제거해, 그렇지 않으면 캐시 불가능으로 처리될 응답을 저장하고 캐시에서 제공할 수 있게 해요.

이점

• 오리진 변경 불필요: 오리진 구성이 잠겨 있거나 다른 팀이 관리하더라도 캐싱 동작을 전적으로 Cloudflare에서 수정해요.
• 더 간단한 CDN 마이그레이션: 오리진을 다시 쓰지 않고 다른 CDN 제공업체의 캐싱 동작을 맞춰요. 캐시 태그 형식을 변환하고 Cloudflare 기본값과 맞지 않는 지시어를 덮어써요.
• 네이티브 지원, 더 적은 해결 방법: 이전에 해결 방법이 필요했던 기능이 이제 Tiered Cache와 완전히 호환되는 Cache Rules에 내장돼요.
• 세밀한 제어: 표현식을 사용해 요청 및 응답 속성을 일치시킨 다음 규칙별로 정확한 캐시 설정을 적용해요. 규칙은 기존 Cache Rules와 스택 가능하고 조합 가능해요.

시작하기

Caching > Cache Rules 아래 Cloudflare 대시보드 ↗︎ 또는 Rulesets API ↗︎에서 Cache Response Rules를 구성해요. 자세한 내용은 Cache Rules 문서 ↗︎를 참고해요.

2026-02-26

비동기 stale-while-revalidate

Cloudflare의 stale-while-revalidate 지원이 이제 완전히 비동기예요. 이전에는 캐시에 있는 stale(만료된) 자산에 대한 첫 번째 요청이 오리진 응답을 기다려야 했고, 그 후 그 방문자는 REVALIDATED 또는 EXPIRED 상태를 받았어요. 이제 자산이 만료된 후 첫 번째 요청이 백그라운드에서 재검증을 트리거하고 즉시 UPDATING 상태의 stale 콘텐츠를 받아요. 이후의 모든 요청도 오리진이 응답할 때까지 UPDATING 상태의 stale 콘텐츠를 받고, 이후 요청은 HIT 상태의 신선한 콘텐츠를 받아요.

stale-while-revalidate는 오리진 서버가 설정하는 Cache-Control 지시어로, 오리진에서 새 복사본을 가져오는 동안 Cloudflare가 만료된 캐시 자산을 제공할 수 있게 해 줘요.

비동기 재검증은 다음을 가져와요:

• 더 낮은 지연: 자산이 이미 캐시에 있을 때는 어떤 방문자도 오리진을 기다리지 않아요. 재검증 중에 모든 요청이 캐시에서 제공돼요.
• 일관된 경험: 재검증 중에 모든 방문자가 같은 캐시된 응답을 받아요.
• 오류 노출 감소: 첫 번째 요청이 더 이상 오리진 타임아웃이나 오류에 취약하지 않아요. 재검증이 백그라운드에서 일어나는 동안 모든 방문자가 캐시된 응답을 받아요.

제공 범위

이 변경은 모든 Free, Pro, Business 존에서 적용돼요. Enterprise 존의 약 75%가 마이그레이션되었고, 나머지 존은 이번 분기 내에 배포돼요.

시작하기

이 기능을 사용하려면 오리진이 Cache-Control 헤더에 stale-while-revalidate 지시어를 포함하는지 확인해요. 자세한 내용은 Cache-Control 문서를 참고해요.

2025-11-25

캐시 제거 이벤트에 대한 감사 로그

이제 캐시 제거 이벤트에 대한 상세 감사 로그를 검토할 수 있어요. 어떤 제거 요청이 보내졌는지, 무엇을 담았는지, 누가 보냈는지 볼 수 있어요. 모든 제거 방법에 대해 대시보드 또는 API로 제거 요청을 감사해요:

• 전체 제거
• 접두사 목록
• 태그 목록
• 호스트 목록
• 파일 목록

예시

상세 감사 페이로드는 Cloudflare 대시보드(Manage Account > Audit Logs 아래)와 API에서 볼 수 있어요. 다음은 Audit Logs v2 페이로드 구조의 예시예요:

{
  "action": {
    "result": "success",
    "type": "create"
  },
  "actor": {
    "id": "1234567890abcdef",
    "email": "user@example.com",
    "type": "user"
  },
  "resource": {
    "product": "purge_cache",
    "request": {
      "files": [
        "https://example.com/images/logo.png",
        "https://example.com/css/styles.css"
      ]
    }
  },
  "zone": {
    "id": "023e105f4ecef8ad9ca31a8372d0c353",
    "name": "example.com"
  }
}

시작하기

시작하려면 Audit Logs 문서를 참고해요.

2025-11-07

Cloudflare Trace로 캐시 키 검사

이제 Cloudflare Trace에서 어떤 요청에 대해 생성된 정확한 캐시 키를 직접 볼 수 있어요. 이 가시성은 캐시 히트와 미스를 문제 해결하는 데 도움을 주고, Cache Rules 또는 Page Rules로 구성한 Custom Cache Key가 의도대로 작동하는지 확인하게 해 줘요.

이전에는 캐싱 동작을 진단하려면 구성 설정에서 키를 추론해야 했어요. 이제 헤더, 쿼리 문자열, 기기 유형에 대한 커스텀 로직이 올바르게 적용되었는지 확인할 수 있어요.

Trace는 대시보드 또는 API로 접근할 수 있어요. 임시 디버깅을 위해 수동으로, 또는 서비스 품질 모니터링의 일부로 자동으로 사용할 수 있어요.

예시 시나리오

특정 쿠키(예: user_region)를 기준으로 콘텐츠를 분할하는 Cache Rule이 있다면, 해당 쿠키가 있는 상태로 Trace를 실행해 user_region 값이 결과 캐시 키에 나타나는지 확인해요.

Trace 응답은 cache 객체에 캐시 키를 포함해요:

{
  "step_name": "request",
  "type": "cache",
  "matched": true,
  "public_name": "Cache Parameters",
  "cache": {
    "key": {
      "zone_id": "023e105f4ecef8ad9ca31a8372d0c353",
      "scheme": "https",
      "host": "example.com",
      "uri": "/images/hero.jpg"
    },
    "key_string": "023e105f4ecef8ad9ca31a8372d0c353::::https://example.com/images/hero.jpg:::::"
  }
}

시작하기

자세한 내용은 Trace 문서와 Custom Cache Keys 안내를 참고해요.

2025-08-29

Smart Tiered Cache의 Generic으로의 폴백

오리진 위치를 확인할 수 없을 때 Smart Tiered Cache가 이제 Generic Tiered Cache로 폴백해 콘텐츠의 캐시 정밀도를 개선해요.

이전에는 Smart Tiered Cache가 최적의 상위 티어를 선택할 수 없을 때(예: 오리진이 Anycast IP로 가려진 경우) 지연이 부정적으로 영향을 받을 수 있었어요. 이 폴백은 이제 Generic Tiered Cache를 대신 사용해 더 나은 성능과 캐시 효율성을 제공해요.

작동 방식

Smart Tiered Cache가 Generic Tiered Cache로 폴백하면:

1. 여러 상위 티어: 단일 최적 위치 대신 Cloudflare의 모든 글로벌 데이터 센터를 상위 티어 네트워크로 사용해요.
2. 분산 캐시 요청: 하위 티어 데이터 센터가 캐시된 콘텐츠를 위해 사용 가능한 상위 티어 중 아무 것이나 쿼리할 수 있어요.
3. 개선된 글로벌 커버리지: 지리적으로 분산된 방문자에게 더 나은 캐시 적중률을 제공해요.
4. 자동 폴백: Anycast로 가려진 오리진처럼 오리진 위치를 확인할 수 없을 때 원활하게 전환돼요.

이점

• 폴백 중에도 높은 성능 유지: Smart Tiered Cache는 최적의 상위 티어 선택이 불가능할 때도 강력한 캐시 효율성을 유지해요.
• 지연 영향 최소화: 오리진 위치를 확인할 수 없을 때 Generic Tiered Cache 토폴로지를 자동으로 사용해 성능을 높게 유지해요.
• 원활한 경험: 폴백 발생 시 구성 변경이나 개입이 필요 없어요.
• 개선된 복원력: Anycast로 가려진 오리진을 포함해 다양한 오리진 인프라에서 Smart Tiered Cache가 효과적으로 유지돼요.

시작하기

이 개선은 Smart Tiered Cache를 사용하는 모든 존에 자동으로 적용돼요. 당신이 할 일은 없어요.

2025-04-04

Workers Fetch API가 Cache Rules를 덮어쓸 수 있음

이제 fetch() 명령의 cf 객체를 사용해 프로그래밍 방식으로 Cache Rules를 덮어쓸 수 있어요. 이 기능은 요청별로 캐싱 동작을 세밀하게 제어하게 해 주며, Workers가 요청 속성, 사용자 컨텍스트, 또는 비즈니스 로직에 따라 캐시 설정을 동적으로 맞춤 설정할 수 있게 해 줘요.

작동 방식

fetch()에서 cf 객체를 사용해 특정 Cache Rules 설정을 덮어쓸 수 있어요:

1. 커스텀 캐시 옵션 설정: 기본 Cache Rules를 덮어쓰기 위해 fetch()의 두 번째 인자로 cf 객체에 캐시 속성을 전달해요.
2. 동적 캐시 제어: 요청 헤더, 쿠키, 또는 다른 런타임 조건에 따라 다른 캐싱 전략을 적용해요.
3. 요청별 커스터마이즈: 다른 요청의 기본 동작을 유지하면서 개별 요청에 대해 Cache Rules를 우회하거나 수정해요.
4. 프로그래밍 방식 캐시 관리: 애플리케이션 요구에 맞춰 적응하는 복잡한 캐싱 로직을 구현해요.

구성할 수 있는 것

Workers는 cf 객체를 통해 다음 Cache Rules 설정을 덮어쓸 수 있어요:

• cacheEverything: 모든 콘텐츠를 정적으로 취급하고 기본 캐시 콘텐츠를 넘어 모든 파일 유형을 캐시해요.
• cacheTtl: 오리진 헤더와 무관하게 에지에서 캐시된 콘텐츠에 대해 초 단위의 커스텀 수명 값을 설정해요.
• cacheTtlByStatus: 응답 상태 코드에 따라 다른 TTL을 설정해요(예: { "200-299": 86400, 404: 1, "500-599": 0 }).
• cacheKey: 캐싱 목적에서 어떤 요청을 같은 것으로 취급할지 제어하도록 캐시 키를 커스터마이즈해요(Enterprise only).
• cacheTags: 대상 캐시 제거 작업을 위해 추가 캐시 태그를 덧붙여요.

이점

• 향상된 유연성: 존 수준 Cache Rules를 수정하지 않고 캐시 동작을 커스터마이즈해요.
• 동적 최적화: 요청 컨텍스트에 따라 실시간으로 캐싱 전략을 조정해요.
• 간소화된 구성: 엣지 케이스를 프로그래밍 방식으로 처리해 필요한 Cache Rules 수를 줄여요.
• 개선된 성능: 특정 사용 사례에 대해 캐시 동작을 세밀하게 조정해 적중률을 최대화해요.

시작하기

시작하려면 Workers Fetch API 문서와 cf 객체 속성 문서를 참고해요.

2025-04-03

모든 캐시 제거 방법이 모든 요금제에서 제공됨

이제 요금제와 무관하게 모든 Cloudflare 캐시 제거 방법에 접근할 수 있어요. 단일 자산을 업데이트해야 하든 사이트 콘텐츠의 상당 부분을 즉시 무효화해야 하든, 이전에 Enterprise 고객에게 예약되어 있던 강력한 도구를 이제 사용할 수 있어요.

Cloudflare의 모든 사용자가 이제 다음을 할 수 있어요:

1. 전체 제거(Purge Everything): 웹사이트와 연결된 모든 캐시된 콘텐츠를 지워요.
2. 접두사별 제거(Purge by Prefix): 공통 접두사를 공유하는 URL을 대상으로 해요.
3. 호스트명별 제거(Purge by Hostname): 특정 호스트명으로 콘텐츠를 무효화해요.
4. URL별 제거(단일 파일 제거): 개별 URL을 정확히 대상으로 해요.
5. 태그별 제거(Purge by Tag): Cache-Tag 응답 헤더를 사용해 그룹 자산을 무효화해 복잡한 캐시 관리 시나리오에 유연성을 제공해요.

각 제거 방법의 작동 방식, 사용 시점, 요금제에 적용되는 한계를 알고 싶다면 제거 캐시 문서와 API 참조 ↗︎에서 모든 내용을 확인해요.

2025-02-12

오리진으로의 HTTP/2 멀티플렉싱 구성 가능

이제 Enterprise 요금제에서 오리진 연결에 대한 HTTP/2 멀티플렉싱 설정을 구성할 수 있어요. 이 기능은 Cloudflare가 HTTP/2 연결을 통해 오리진 서버로의 동시 요청을 관리하는 방식을 최적화해 캐시 효율성을 개선하고 연결 오버헤드를 줄이게 해 줘요.

작동 방식

HTTP/2 멀티플렉싱은 단일 TCP 연결로 여러 요청을 보내게 해요. 이 구성 옵션으로 다음을 할 수 있어요:

1. 동시 스트림 제어: 연결당 최대 동시 스트림 수를 조정해요.
2. 연결 재사용 최적화: 오리진 인프라에 대한 연결 풀링 동작을 세밀하게 조정해요.
3. 연결 오버헤드 감소: Cloudflare와 오리진 사이에 필요한 TCP 연결 수를 최소화해요.
4. 캐시 성능 개선: 더 나은 연결 관리가 캐시 가져오기 효율성을 향상시킬 수 있어요.

이점

• 맞춤 가능한 성능: 멀티플렉싱 설정을 오리진의 성능에 맞게 조정해요.
• 지연 감소: 더 적은 연결 핸드셰이크가 응답 시간을 개선해요.
• 오리진 부하 감소: 더 효율적인 연결 사용이 서버 리소스 소비를 줄여요.
• 향상된 확장성: 더 나은 연결 관리가 더 높은 트래픽 볼륨을 지원해요.

시작하기

Enterprise 고객은 Cloudflare 대시보드 ↗︎ 또는 API에서 HTTP/2 멀티플렉싱 설정을 구성할 수 있어요.

중요 고려 사항 — 이 설정은 오리진 인프라에 맞게 신중히 조정해야 해요. 동시 스트림 한계를 너무 높게 설정하면 공유 TCP 연결을 포화시키고 서버 처리 용량을 압도해 개별 요청의 지연이 증가하는 등 성능에 부정적 영향을 줄 수 있어요.

2025-02-04

CSAM 퇴치를 그 어느 때보다 쉽게

이제 아동 안전 도구인 CSAM Scanning Tool 을 더 쉽게 도입할 수 있어요. 외부 보고 자격 증명 대신 알림용으로 검증된 이메일 주소만 필요해요. 이 변경으로 도구가 더 넓은 고객층에 접근 가능해졌어요.

작동 방식

활성화되면 도구는 웹사이트에 대해 이미지가 Cloudflare 캐시에 들어올 때 자동으로 해시합니다 ↗︎. 그런 다음 이 해시를 알려진 학대 이미지 데이터베이스와 대조해요.

• 잠재적 일치가 감지됐나요?
  • 콘텐츠 URL이 차단되고,
  • Cloudflare가 제공된 이메일 주소로 발견된 일치 항목을 알려줘요.

업데이트된 서비스별 약관

또한 이러한 변경을 반영하기 위해 서비스별 약관 ↗︎ 을 업데이트했어요.

2025-01-08

Smart Tiered Cache가 Load Balancing 풀을 최적화

Load Balancing을 Smart Tiered Cache와 함께 사용할 때 이제 더 높은 캐시 적중률을 달성하고 오리진 부하를 줄일 수 있어요. Cloudflare는 Load Balancing 풀의 모든 오리진에 대해 단일 최적 티어 데이터 센터를 자동으로 선택해요.

작동 방식

Load Balancing을 Smart Tiered Cache와 함께 사용하면 Cloudflare는 풀의 오리진 전반의 성능 지표를 분석하고 풀 전체에 대해 최적의 Upper Tier 데이터 센터를 자동으로 선택해요. 이는 다음을 의미해요:

• 일관된 캐시 위치: 풀의 모든 오리진이 같은 Upper Tier 캐시를 공유해요.
• 더 높은 HIT 비율: 같은 콘텐츠에 대한 요청이 캐시에 더 자주 적중해요.
• 오리진 요청 감소: 오리진 서버에 도달하는 요청이 더 적어요.
• 성능 개선: 캐시 HIT에 대한 응답 시간이 빨라져요.

예시 워크플로

Load Balancing Pool: api-pool
├── Origin 1: api-1.example.com
├── Origin 2: api-2.example.com
└── Origin 3: api-3.example.com
    ↓
Selected Upper Tier: [Optimal data center based on pool performance]

시작하기

시작하려면 존에서 Smart Tiered Cache를 활성화하고 Load Balancing 풀을 구성해요.

2024-11-20

Smart Tiered Cache가 R2 캐싱을 자동으로 최적화

Smart Tiered Cache를 R2와 함께 사용할 때 지연을 줄이고 R2 이그레스 비용을 자동으로 낮출 수 있어요. Cloudflare는 R2 버킷 위치에 가까운 티어 데이터 센터를 지능적으로 선택해 추가 구성 없이 효율적인 캐싱 토폴로지를 만들어요.

작동 방식

R2를 오리진으로 사용하는 존에서 Smart Tiered Cache를 활성화하면 Cloudflare는 자동으로:

1. R2 버킷 위치 식별: R2 버킷이 저장된 지리적 지역을 결정해요.
2. 최적의 Upper Tier 선택: 버킷에 가까운 데이터 센터를 공통 Upper Tier 캐시로 선택해요.
3. 요청 효율적 라우팅: 에지 위치의 모든 캐시 미스가 R2에 도달하기 전에 이 Upper Tier를 통해 라우팅돼요.

이점

• 자동 최적화: 수동 구성이 필요 없어요.
• 더 낮은 이그레스 비용: R2에 대한 요청이 적어 이그레스 요금이 줄어요.
• 개선된 적중 비율: 공통 Upper Tier가 캐시 효율성을 높여요.
• 지연 감소: R2에 대한 Upper Tier 근접성이 가져오기 시간을 최소화해요.

시작하기

시작하려면 R2를 오리진으로 사용하는 존에서 Smart Tiered Cache를 활성화해요.

2024-11-07

캐시 구성을 안전하게 스테이징 및 테스트

이제 캐시 구성을 프로덕션에 배포하기 전에 스테이징하고 테스트할 수 있어요. 버전화된 환경에서 캐시 규칙, 제거 작업, 구성 변경을 라이브 트래픽에 영향을 주지 않고 안전하게 검증할 수 있어요.

작동 방식

버전화된 환경으로 다음을 할 수 있어요:

1. 캐시 구성의 스테이징 버전을 만든다.
2. 프로덕션이 아닌 환경에서 캐시 규칙을 테스트한다.
3. 프로덕션과 독립적으로 스테이징된 콘텐츠를 제거한다.
4. 프로덕션으로 승격하기 전에 변경을 검증한다.

이 기능은 Cloudflare의 더 넓은 버전 관리 시스템과 통합되어, 다른 존 설정과 함께 캐시 구성을 관리하게 해 줘요.

이점

• 무위험 테스트: 프로덕션에 영향을 주지 않고 구성 변경을 검증해요.
• 독립적 제거: 라이브 콘텐츠에 영향을 주지 않고 스테이징 캐시를 지워요.
• 배포 확신: 문제가 최종 사용자에게 도달하기 전에 발견해요.
• 팀 협업: 여러 팀 구성원이 다른 버전에서 작업할 수 있어요.

시작하기

시작하려면 버전 관리 문서를 참고해요.

중요한 한계 — Cache Reserve는 프로덕션 환경에서만 지원돼요. 스테이징 환경은 표준 캐시 기능을 사용할 수 있지만, Cache Reserve 지속성은 프로덕션 배포로 제한돼요.

2024-11-07

커스텀 캐시 키 값으로 캐시 분할

Enterprise 고객은 이제 커스텀 캐시 키로 이전에 제한된 헤더의 최대 10개 값을 사용해 기기, 언어, 또는 리퍼러에 따라 달라지는 콘텐츠의 캐시 적중률을 캐시 분할(sharding) 로 최적화할 수 있어요.

작동 방식

커스텀 캐시 키를 구성할 때 이제 다음 헤더의 값을 포함해 별도의 캐시 항목을 만들 수 있어요:

• accept* 헤더(예: accept, accept-encoding, accept-language): 콘텐츠 협상에 따라 다른 캐시된 버전을 제공해요.
• referer 헤더: 리퍼러 페이지나 사이트에 따라 콘텐츠를 다르게 캐시해요.
• user-agent 헤더: 다른 브라우저, 기기, 또는 봇에 대해 별도의 캐시를 유지해요.

캐시 분할을 사용할 때

• 콘텐츠가 기기 유형(모바일 vs 데스크톱)에 따라 크게 달라질 때.
• 다른 언어나 인코딩 선호가 별도의 응답을 요구할 때.
• 리퍼러별 콘텐츠 최적화가 필요할 때.

예시 구성

{
  "cache_key": {
    "custom_key": {
      "header": {
        "include": ["accept-language", "user-agent"],
        "check_presence": ["referer"]
      }
    }
  }
}

이 구성은 accept-language와 user-agent 헤더에 기반해 별도의 캐시 항목을 만들고, referer 헤더의 존재 여부도 고려해요.

시작하기

시작하려면 커스텀 캐시 키 문서를 참고해요.

참고 — 캐시 분할은 특정 사용 사례의 적중률을 개선할 수 있지만, 과도하게 분할하면 전체 캐시 효율성이 떨어지고 성능에 부정적 영향을 줄 수 있어요. 분할이 당신의 특정 트래픽 패턴에 도움이 되는지 신중히 평가하세요.

2024-09-05

원클릭 Cache Rules 템플릿 제공

이제 원클릭 템플릿으로 최적화된 캐시 규칙을 즉시 만들 수 있어요. 수동 규칙 구성의 복잡성을 없애 줘요.

작동 방식

1. Cloudflare 대시보드에서 Rules > Templates로 이동해요.
2. 사용 사례에 맞는 템플릿을 선택해요.
3. 합리적인 기본값으로 템플릿을 적용하기 위해 클릭해요.
4. 특정 요구 사항에 맞게 필요에 따라 커스터마이즈해요.

사용 가능한 캐시 템플릿

• Cache everything: 모든 요청에 대해 캐시 레벨을 조정해요.
• Bypass cache for everything: 모든 요청에 대해 캐시를 우회해요.
• Cache default file extensions: 기본 확장자만 캐시에 적합하게 만들어 Page Rules 캐싱 동작을 재현해요.
• Bypass cache on cookie: 특정 쿠키가 포함된 요청에 대해 캐시를 우회해요.
• Set edge cache time: 200~599 사이의 상태 코드가 있는 응답을 Cloudflare 에지에 캐시해요.
• Set browser cache time: 브라우저가 리소스를 캐시하는 시간을 조정해요.

시작하기

시작하려면 대시보드에서 Rules > Templates ↗︎로 가요. 자세한 내용은 Cache Rules 문서를 참고해요.

2024-07-19

더 높은 적중률을 위한 지역화된 Generic Tiered Cache

이제 Generic Global Tiered Cache로 더 높은 캐시 적중률을 달성할 수 있어요. 지역 콘텐츠 해싱이 콘텐츠를 동일한 상위 티어 데이터 센터로 일관되게 라우팅해 중복 캐싱을 없애고 오리진 부하를 줄여요.

작동 방식

지역 콘텐츠 해싱은 데이터 센터를 지역별로 그룹화하고 일관 해싱을 사용해 콘텐츠를 지정된 상위 티어 캐시로 라우팅해요:

• 같은 콘텐츠는 항상 지역 내의 같은 상위 티어 데이터 센터로 라우팅돼요.
• 여러 상위 티어 캐시에 걸친 중복 복사본을 없애요.
• 같은 콘텐츠의 캐시 HIT 가능성을 높여요.

예시

지역의 여러 에지 위치에서 요청된 인기 이미지:

• 이전: 3-4개의 다른 상위 티어 데이터 센터에 캐시됨
• 이후: 1개의 지정된 상위 티어 데이터 센터에 캐시됨
• 결과: 캐시 MISS가 3-4배 줄어 오리진 부하가 감소하고 성능이 개선됨

시작하기

시작하려면 존에서 Generic Global Tiered Cache를 활성화해요.

더 알아보기 (Learn more)

이 페이지는 Cloudflare Cache 기능의 변경 기록이에요. 무효화 지원, 비동기 stale-while-revalidate, Vary, Cache Response Rules, Tiered Cache 최적화, 캐시 키 분할 등 최근 업데이트를 날짜순으로 정리해요. 최신 변경은 RSS 피드로도 구독할 수 있어요.