Cloudflare를 사용하는 워드프레스, 쇼핑몰, 커뮤니티 운영자라면 캐시 설정 문제로 인해 웹사이트 변경 사항이 즉시 반영되지 않거나 성능 저하를 겪는 경우가 발생합니다. Cloudflare 캐시 설정 시 원본 서버 헤더와 Cloudflare 규칙 간의 상호작용, 그리고 캐시 무효화 및 갱신 지연 문제에 대한 명확한 이해가 필요합니다.
Cloudflare 캐시가 작동하지 않는 근본 원인
Cloudflare는 특정 조건에서 응답을 캐시하지 않으며, 이 경우 `BYPASS` 상태를 반환합니다. 이전에는 `BYPASS`와 `MISS`가 혼용되었으나, 이제 캐시 불가 응답은 이유와 무관하게 `BYPASS`로 통일됩니다. `MISS`는 캐시 가능한 콘텐츠가 엣지 캐시에 없을 때만 발생합니다.
캐시 불가 응답의 주요 조건
Cloudflare는 다음과 같은 경우에 콘텐츠를 캐시하지 않습니다. 원본 서버에서 `Cache-Control: no-cache`, `private`, `max-age=0` 헤더를 전송하거나, `Set-Cookie` 헤더가 응답에 포함될 때 캐시를 하지 않습니다. 또한 요청에 `Authorization` 헤더가 존재하거나, 파일 크기가 해당 요금제의 최대 캐시 가능 크기를 초과하는 경우에도 캐시가 제외됩니다.
`stale-while-revalidate`의 동작 방식
`stale-while-revalidate` 지시문이 활성화된 경우, 만료된 자산에 대한 첫 요청은 백그라운드에서 재검증을 트리거합니다. 이때 클라이언트에게는 즉시 오래된 콘텐츠가 `UPDATING` 상태로 반환됩니다. 이후 동일 자산에 대한 요청도 원본 서버의 새 응답이 도착할 때까지 `UPDATING` 상태를 유지하며, 새 응답 수신 후에는 `HIT`로 전환됩니다.
Cloudflare 캐시 설정, 원본 헤더 무시하고 강제 캐시하는 방법
Cloudflare Cache Rules를 사용하면 원본 서버의 `Cache-Control` 헤더를 덮어쓰고 특정 페이지를 강제로 캐시할 수 있습니다. 이는 특히 공개 HTML 페이지의 로딩 속도를 개선하는 데 효과적입니다.
Cache Rules를 활용한 성능 개선
Cloudflare Cache Rules를 설정하여 공개 페이지를 캐시하고, 관리자 페이지, 로그인 사용자, 미리보기, 비밀글, 댓글 작성자 관련 페이지, 그리고 `POST` 요청은 캐시에서 제외하는 방식으로 규칙을 분리할 수 있습니다. 이 방법을 통해 HTML 응답 시간이 348ms에서 154ms로 단축된 사례가 있으며, 이는 무료 플랜에서도 적용 가능합니다. Cloudflare 캐시 설정 시 이 기능을 적극 활용해야 합니다.
캐시 규칙의 우선순위 설정
캐시 규칙을 설정할 때는 순서가 매우 중요합니다. 먼저 `/wp-admin`, `/checkout` 등 캐시하면 안 되는 요청을 `BYPASS`로 설정하여 걸러낸 뒤, 그 아래에 공개 페이지 강제 캐시 규칙을 적용해야 합니다. 이 순서가 바뀌면 중요한 동적 콘텐츠가 잘못 캐시될 수 있습니다.
Cloudflare 캐시 응답 규칙으로 동적 페이지 최적화
Cloudflare는 Cache Response Rules를 제공하여 원본 응답이 엣지 캐시에 저장되기 전에 헤더를 조정할 수 있습니다. 이를 통해 원본 서버 코드를 수정하지 않고도 쿠키나 `Cache-Control` 지시문을 유연하게 수정할 수 있습니다.
Cache Response Rules의 기능 및 요금제별 한도
Cache Response Rules는 Free, Pro, Business, Enterprise 모든 요금제에서 사용할 수 있습니다. 각 요금제별 생성 한도는 Free 10개, Pro 25개, Business 50개, Enterprise 300개입니다. 이 규칙을 통해 특정 쿠키를 제거하여 캐시 효율을 높이거나, `Cache-Control` 헤더를 재정의하여 캐시 수명을 조절하는 것이 가능합니다.
`/wp-admin`, `/checkout`, 로그인 쿠키 예외 처리
WordPress 관리자 페이지(`/wp-admin`), 결제 페이지(`/checkout`), 그리고 로그인 사용자에게 발급되는 쿠키는 반드시 캐시에서 제외해야 합니다. 이러한 페이지나 쿠키가 캐시되면 사용자별 세션 정보가 노출되거나, 관리 기능이 오작동할 수 있습니다. Cache Response Rules를 사용하여 `Set-Cookie` 헤더를 제거하거나 특정 경로를 `BYPASS` 처리함으로써 문제를 방지합니다.
Cloudflare 캐시 무효화 및 갱신 지연 해결 전략
`TTL` (Time To Live)을 길게 설정해도 최신 내용이 즉시 반영되지 않는 문제는 캐시 무효화 전략의 부재에서 비롯됩니다. 효과적인 캐시 퍼지(Purge)와 함께 `stale-while-revalidate` 지시문을 활용하여 갱신 지연을 최소화해야 합니다.
캐시 퍼지(Purge)의 중요성
콘텐츠가 업데이트되었을 때 Cloudflare 엣지 캐시에 저장된 오래된 콘텐츠를 강제로 삭제하려면 캐시 퍼지가 필수적입니다. Cloudflare 대시보드에서 전체 캐시를 퍼지하거나, 특정 URL 또는 접두사를 지정하여 부분적으로 퍼지할 수 있습니다. 특히 중요한 업데이트 후에는 즉시 캐시 퍼지를 실행하여 최신 내용이 사용자에게 전달되도록 해야 합니다.
원본 헤더와 Edge TTL의 조화
Cloudflare는 원본 서버의 `Cache-Control` 헤더를 우선적으로 따르지만, Edge TTL 설정을 통해 Cloudflare 엣지에서 콘텐츠를 캐시할 최대 시간을 지정할 수 있습니다. 원본 서버의 `max-age` 값이 짧더라도 Edge TTL을 길게 설정하여 Cloudflare 엣지에서 더 오래 캐시하도록 할 수 있습니다. 그러나 `stale-while-revalidate`와 같은 고급 전략을 함께 사용하여 오래된 콘텐츠가 제공되는 동안 백그라운드에서 새로운 콘텐츠를 가져오도록 해야 합니다.
Cloudflare 캐시 관련 주요 장애 이력 및 현재 상태
Cloudflare는 안정적인 서비스를 제공하지만, 캐시 관련 장애가 발생할 수 있습니다. 서비스 운영자는 Cloudflare 상태 페이지를 정기적으로 확인하여 잠재적인 문제에 대비해야 합니다.
최근 캐시 관련 장애 이력
Cloudflare 상태 페이지에 따르면, 2026년 5월 13일에는 “Cache Purging and Cache Rule Update Issues” (Major)와 같은 주요 장애가 발생했습니다. 또한 2026년 6월 14일에는 “Intermittent Slow Cache Responses” (Minor)와 같은 간헐적인 응답 지연 문제가 확인되었습니다. 이러한 이력은 Cloudflare 캐시 설정 시 장애 발생 가능성을 고려해야 함을 시사합니다.
현재 Cloudflare 서비스 상태
2026년 8월 6일 기준으로 Cloudflare 상태 페이지에는 Durable Objects 및 downstream services 관련 오류 증가가 표시되고 있습니다. 이는 캐시 전용 장애로 명시된 것은 아니지만, 전반적인 Cloudflare 서비스 성능에 영향을 미칠 수 있으므로 지속적인 모니터링이 필요합니다.
자주 묻는 질문
Cloudflare가 원본 서버의 `Cache-Control` 헤더를 덮어씁니까?
네, Cloudflare의 Cache Rules를 사용하면 원본 서버의 `Cache-Control` 헤더를 덮어쓰고 캐시 정책을 강제로 적용할 수 있습니다.
Page Rules 대신 Cache Rules로 어떻게 마이그레이션하나요?
Cloudflare 대시보드에서 Page Rules와 유사한 기능을 Cache Rules 섹션에서 설정할 수 있으며, 기존 Page Rules의 캐시 관련 설정을 Cache Rules로 이전하여 관리할 수 있습니다.
TTL을 길게 잡아도 최신 내용이 안 바뀌는 이유는 무엇인가요?
`TTL`을 길게 설정했더라도 캐시 퍼지(Purge)를 실행하지 않으면 엣지 캐시에 오래된 콘텐츠가 남아있을 수 있으므로, 업데이트 후에는 반드시 퍼지를 진행해야 합니다.