pile·
네트워크·cloudflare-blogCloudflare Blog·

Cloudflare Cache Response Rules — 오리진 응답 기반 캐시 제어

Cloudflare가 오리진 응답이 도착한 뒤 캐시에 쓰이기 직전에 개입하는 Cache Response Rules를 내놨다. 기존 Cache Rules는 요청 단계에서만 동작해, 오리진이 붙인 Set-Cookie·no-cache·ETag 때문에 충분히 캐시 가능한 응답이 오리진으로 되돌아가는 문제를 풀지 못했다. 새 규칙은 응답 헤더를 보고 헤더 제거·캐시 태그 관리·Cache-Control 수정을 수행해, 오리진 수정 없이 캐시 적중률을 끌어올린다.

핵심 포인트
  • 기존 캐시 결정은 요청 단계(Cache Rules)에서 URL·헤더·지역·디바이스만 보고 내려, 오리진 응답 헤더는 손댈 수 없었다.
  • Cache Response Rules는 오리진 응답 도착 후 캐시 기록 직전에 실행돼, 응답 상태코드·헤더를 조건으로 쓸 수 있다.
  • 세 가지 동작을 제공한다: 헤더 제거(Set-Cookie/ETag/Last-Modified), 캐시 태그 add/remove/set, Cache-Control 디렉티브 수정.
  • cloudflare_only 옵션으로 Cloudflare 캐시에만 디렉티브를 적용하고 브라우저용 값은 그대로 둘 수 있다.
  • Cache Rules와 충돌하면 Cache Response Rule이 이긴다.
상세 정리
  • 문제: 세션 프레임워크가 정적 자산에 Set-Cookie를 붙이거나 오리진이 캐시 가능한 콘텐츠에 no-cache를 보내면, 캐시돼야 할 응답이 오리진으로 끌려가 적중률이 떨어진다.
  • 기존 우회의 한계: 오리진을 고치거나, 응답을 다시 받아 재작성하는 Worker를 짜거나, 낮은 적중률을 감수하는 세 방법뿐이었다.
  • 두 단계 구분: 요청 단계는 캐시 여부·캐시 키·방법을 정하고, 응답 단계는 오리진의 Cache-Control·Set-Cookie·ETag가 진실 소스인데 요청 단계에선 이 정보를 알 수 없었다.
  • 동작 1 — 헤더 제거: Set-Cookie·ETag·Last-Modified를 캐시 판정 전에 떼어내, 세션 쿠키가 붙은 정적 자산도 오리진 변경 없이 캐시 가능해진다.
  • 동작 2 — 캐시 태그: purge-by-tag용 태그를 add/remove/set 하고, split(http.response.headers[Surrogate-Keys][0], ",", 64) 같은 표현식으로 응답 헤더에서 동적으로 계산한다. CDN 이전 시 벤더별 태그 포맷 변환에 유용하다.
  • 동작 3 — Cache-Control 수정: max-age·s-maxage·stale-if-error·stale-while-revalidate 같은 기간 디렉티브와 no-store·immutable·public 같은 불리언 디렉티브를 조정한다.
  • 브라우저·CDN 수명 분리: s-maxage를 30일(cloudflare_only)로 두면서 브라우저 max-age는 1일로 따로 설정해 엣지와 브라우저 캐시 수명을 분리한다.
  • 조건 표현식: http.response.code·http.response.headers 같은 응답 필드를 조건으로 쓰고, http.request.uri.path.extension 같은 요청 필드도 함께 조합해 확장자별 규칙을 건다.
  • Smart Edge Revalidation 상호작용: ETag·Last-Modified를 제거하면 해당 응답에 Smart Edge Revalidation이 켜지고, 반대로 규칙이 새 validator를 추가하면 브라우저 조건부 요청용 재검증이 꺼진다.
  • 비캐시 응답에도 발동: 캐시 불가 응답에도 규칙이 돌아, 동적 콘텐츠를 클라이언트로 보내기 전 헤더를 정리할 수 있다.
  • 적용 경로: 대시보드(Cache > Cache Rules > Create rule), API의 http_response_cache_settings phase 엔드포인트, Terraform을 모두 지원하며 전 플랜에서 쓸 수 있다.
왜 읽나CDN 적중률과 캐시 정책을 오리진 수정 없이 손봐야 하는 프론트엔드·인프라·플랫폼 엔지니어에게 실전 설정 레퍼런스.
cloudflare-blog
Cloudflare Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 네트워크·cloudflare-blogCloudflare Blog·

    Cloudflare Internal DNS 정식 출시 — 사설·공인 DNS 통합 구조

    Cloudflare가 사설(내부)·공인 DNS 해석을 하나의 플랫폼으로 통합하는 Internal DNS를 정식 출시했다. 기존에는 공인 DNS·내부 DNS·클라우드별 DNS가 제각기 다른 보안 정책으로 흩어져 공통 컨트롤 플레인이 없었고, split-horizon 구성은 병렬 시스템을 수동 동기화하다 drift로 장애를 냈다. 새 제품은 단일 API·감사 로그·정책 계층으로 이를 합치고, 1.1.1.1 인프라 위에서 하드웨어 없이 동작하며 Enterprise는 Gateway에 무료 포함된다.

  2. 네트워크·NHN Cloud MeetupNHN Cloud·

    경계가 만든 길, Load Balancer(DSR)

    NHN Cloud가 XDP/eBPF 기반 커널 단 기술로 만든 DSR(Direct Server Return) 방식 로드 밸런서를 소개한다. 기존 프록시 방식 LB는 요청·응답을 모두 종단·중계해 응답 트래픽이 클수록 LB가 병목이 된다. 이를 요청만 LB를 경유하고 응답은 서버가 클라이언트에 직접 보내는 비대칭 구조로 해결한다. 미디어 스트리밍·대용량 다운로드·게임 서버처럼 응답이 큰 L4 워크로드가 대상이다.

  3. 네트워크·cloudflare-blogCloudflare Blog·

    .AL TLD DNSSEC 장애 분석과 EDE 33 투명성 코드 도입

    2026년 7월 3일 알바니아(.AL) TLD의 DNSSEC 키 롤오버 실수로 알바니아 정부, 은행, 미디어 등 모든 .AL 도메인이 약 5시간 동안 다운된 사건을 다룬다. Cloudflare가 Negative Trust Anchor(NTA)로 빠르게 대응했지만, 기존 NTA 응답이 정상 검증 응답과 구분되지 않는 투명성 문제가 있었다. 이를 계기로 NTA 적용 여부를 DNS 응답에 직접 표시하는 EDE 33 코드가 IANA에 공식 등록됐다.

    #network-security#dnssec#dns+2