Cloudflare Cache Response Rules: 원본 응답 뒤 캐시를 고치는 법

2026. 7. 27 (월) · 약 10분

정적 자바스크립트 파일인데도 응답에 Set-Cookie가 붙어 캐시가 비어 버리는 경우가 있다. 원본 애플리케이션을 당장 고칠 수 없다면, 요청이 들어오는 순간의 캐시 규칙만으로는 해결할 수 없다. Cloudflare가 공개한 Cache Response Rules는 원본 서버가 응답한 뒤, 그 응답을 캐시에 쓰기 직전에 Cache-Control과 일부 헤더를 조정한다. 다만 이 기능은 무엇이 캐시 키가 될지를 다시 정하는 도구가 아니며, 로그인·개인화 응답까지 넓게 건드리면 오히려 위험해진다.

오늘의 핵심뉴스

심층 분석 · Cloudflare Blog · 2026. 7. 23

Cloudflare, 원본 응답 뒤 캐시 설정을 바꾸는 Cache Response Rules 공개

Cloudflare는 원본 서버의 응답을 받은 뒤 캐시에 저장하기 전 Cache-Control 지시문을 고치고, 캐시 태그를 관리하거나 Set-Cookie·ETag·Last-Modified 헤더를 제거할 수 있는 Cache Response Rules를 소개했다. 요청 단계 Cache Rules가 캐시 키와 조회 여부를 정하는 것과 달리, 새 규칙은 응답을 본 뒤 캐시 방식과 일부 저장 여부를 조정한다.

무엇이 바뀌었나: 응답을 본 뒤에 캐시를 조정하는 단계

Cloudflare의 Cache Response Rules는 원본 서버가 응답한 뒤, 그 결과가 Cloudflare 캐시에 기록되기 전에 실행된다. 여기서 Cache-Control 지시문을 바꾸고, purge by tag에 쓰는 캐시 태그를 관리하며, Set-Cookie·ETag·Last-Modified 같은 헤더를 제거할 수 있다. 원본 코드나 로드밸런서 설정을 고치기 어려운 조직에는 유용한 위치다. 예를 들어 정적 파일에 습관적으로 세션 쿠키가 붙어 캐시 대상에서 빠지는 문제를, 정적 경로에 한정해 응답 단계에서 다룰 수 있다.

두 규칙은 실행 시점과 바꿀 수 있는 대상이 다르다

구분	Cache Rules	Cache Response Rules
실행 시점	원본에 가기 전 요청 단계	원본 응답을 받은 뒤 캐시 저장 전
주요 질문	조회할지, 어떤 키로 찾을지	응답을 보고 어떻게 저장·전달할지
대표 작업	캐시 키·우회·TTL 설정	Cache-Control 조정·헤더 제거·태그 관리
할 수 없는 일	응답 헤더를 근거로 판단	이미 정해진 캐시 키를 다시 설계

요청 단계는 아직 응답을 보지 못한다. 응답 단계는 원본이 보낸 헤더를 읽을 수 있지만, 이미 정해진 캐시 키를 되돌릴 수는 없다.

왜 기존 Cache Rules만으로는 해결되지 않았나

캐시에는 서로 다른 질문이 있다. 요청이 들어왔을 때는 URL, 확장자, 요청 헤더처럼 이미 가진 정보로 캐시를 조회할지와 어떤 키를 쓸지 정한다. 하지만 Set-Cookie나 원본의 Cache-Control, ETag, Last-Modified는 원본이 답한 뒤에야 알 수 있다. 요청 단계에서 이 값을 근거로 규칙을 만들 수 없는 이유다. Cloudflare의 설명대로 응답 단계 규칙은 ‘무엇’을 캐시 키로 삼을지 바꾸지 못하며, 이미 캐시 조회가 불가능하다고 판정된 요청을 나중에 되살리는 도구도 아니다.

대신 응답 단계는 캐시가 응답을 받아들이는 방식에 마지막 조정을 할 수 있다. Cache Rule의 Edge TTL이 원본 응답과 충돌하는 경우에도 Cache Response Rule이 설정한 Cache-Control이 우선한다. 따라서 두 규칙을 같은 목적의 중복 설정으로 쌓기보다, 요청 단계에는 키·우회·기본 정책을 두고 응답 단계에는 원본 헤더에서 발견되는 예외를 두는 편이 읽기 쉽다.

Set-Cookie를 제거하기 전, 먼저 응답의 성격을 나눠야 한다

Set-Cookie는 단순한 잡음이 아닐 수 있다. 로그인 상태, 장바구니, 지역·실험 분기처럼 방문자마다 달라지는 응답에 붙었다면 이를 제거하고 캐시하는 것은 다른 사람의 상태를 섞는 사고로 이어질 수 있다. 반대로 빌드 산출물인 CSS·JS·글꼴처럼 URL 버전이 고정되고 사용자별 내용이 전혀 없는 경로에 프레임워크 쿠키가 붙는 경우라면, 좁은 표현식으로 실험할 이유가 생긴다. 경로뿐 아니라 응답 상태와 Content-Type까지 함께 확인하는 습관이 필요하다.

728x90

 

규칙을 넓게 켜기 전에 문제 응답 하나에서 시작해 정적 경로, 캐시 상태, 되돌리기 조건을 차례로 확인한다.

실무 적용: 한 경로에서 시작하는 검증 순서

첫째, 브라우저 개발자 도구나 curl로 문제 URL의 Cache-Control, Set-Cookie, ETag, Last-Modified와 캐시 상태 헤더를 기록한다. 둘째, 로그인 없이도 같은 본문이 나오는 버전된 정적 경로 하나를 고른다. 셋째, 대시보드의 Cache > Cache Rules에서 Cache Response Rule을 만들고 그 경로에만 맞는 표현식을 둔다. Cloudflare 문서는 대시보드, API, Terraform으로 만들 수 있다고 안내하지만, 처음에는 초안으로 저장해 범위를 재확인하는 편이 낫다.

넷째, 응답을 여러 번 요청해 의도한 헤더가 바뀌었는지와 캐시 상태가 기대대로 달라졌는지 함께 본다. 지시문을 Cloudflare에만 적용하는 선택을 사용하면 방문자에게 전달되는 Cache-Control은 원본 값을 유지하면서 edge의 저장 정책만 다르게 둘 수도 있다. 다섯째, 로그인 요청·개인화 URL·오류 응답이 같은 표현식에 걸리지 않는지 확인한 뒤에만 범위를 넓힌다. 예상과 다르면 규칙을 비활성화하거나 초안으로 돌리고, 원본 헤더와 매칭 조건을 다시 비교한다.

• 정적 파일 하나의 원본 응답 헤더와 캐시 상태를 저장한다.
• 사용자별 본문이 없는 경로와 응답 상태만 조건으로 삼는다.
• 규칙 적용 전후에 브라우저로 전달되는 헤더와 edge 동작을 따로 확인한다.
• 개인화·로그인·결제 경로는 같은 표현식에 포함하지 않는다.
• 규칙을 넓힌 뒤에도 캐시 태그 purge와 배포 무효화 절차를 점검한다.

ETag와 Last-Modified를 지울 때 생기는 교환 조건

검증 헤더를 제거하는 일도 단순한 성능 스위치가 아니다. Cloudflare 문서는 Last-Modified를 제거하면 Smart Edge Revalidation이 꺼진다고 설명한다. ETag와 Last-Modified가 원본에서 과도하게 바뀌어 재검증이 반복되는 상황에는 도움이 될 수 있지만, 조건부 요청과 배포 후 최신성 확인에 어떤 신호를 쓸지 다시 확인해야 한다. 캐시 적중률만 보고 성공으로 판단하면 오래된 자산을 보는 문제를 놓칠 수 있다.

한계: 원본 설계와 캐시 키의 문제를 대신 풀지는 않는다

Cache Response Rules는 원본 응답을 본 뒤에만 일한다. 요청이 처음부터 캐시 조회 대상이 아니었거나, 캐시 키가 사용자 구분에 맞지 않거나, 원본이 민감한 본문을 잘못 공개하는 문제는 이 기능 하나로 해결되지 않는다. 또한 여러 규칙이 같은 설정을 지정하면 마지막으로 일치한 규칙이 적용될 수 있으므로, 기존 Cache Rules와 응답 규칙의 순서·표현식을 문서화해야 한다. 원본 팀과 CDN 팀이 나뉘어 있다면 규칙이 임시 우회인지 장기 정책인지도 합의해 두는 편이 좋다.

바로 확인할 체크리스트

배포 전에 확인할 질문

질문	확인 신호	문제가 있으면
정적 응답인가	로그인 여부와 무관하게 본문이 같다	규칙 범위를 더 좁힌다
헤더가 원인인가	Set-Cookie 또는 Cache-Control이 기록됐다	원본 수정 가능성도 함께 검토한다
edge만 바꿀 것인가	방문자 헤더와 edge 정책을 각각 확인했다	Cloudflare only 옵션을 재검토한다
되돌릴 수 있는가	초안·비활성화 절차와 담당자가 있다	전체 경로 적용을 미룬다

이번 기능은 ‘캐시를 강제로 켠다’는 버튼보다, 응답을 본 뒤에만 판단할 수 있는 문제를 따로 다루는 도구에 가깝다. 가장 작은 정적 경로에서 원본 헤더와 캐시 상태를 나란히 확인하면, 성능 개선이 필요한 예외와 원본에서 고쳐야 할 설계를 구분할 수 있다.

참고한 자료

• Introducing Cache Response Rules공식
• Cache Response Rules documentation공식 문서
• Create a Cache Response Rule in the dashboard공식 문서
• Cache Response Rules settings공식 문서
• Community discussion of Cache Response Rules독립 자료

함께 읽기

이어서 보면 좋은 글

• 웹페이지가 바뀌었을 때만 알려주는 변경 감지기 만들기: Python 직접 실험배포 뒤 응답 헤더와 설정 변화가 실제로 달라졌는지 감지하는 운영 관점에서 이어 읽을 수 있다.
• WordPress 7.0.2 보안 업데이트: Cloudflare WAF가 있어도 패치해야 하는 이유CDN 경계의 규칙이 원본 애플리케이션의 책임을 모두 대신하지 않는다는 점을 함께 살펴볼 수 있다.

Cache Response Rules의 핵심은 원본을 대신하는 마법이 아니라, 응답 헤더 때문에 생긴 캐시 문제를 원본 코드 변경 없이 좁게 다룰 수 있는 위치를 제공한다는 점이다. 먼저 요청 단계 규칙과 응답 단계 규칙의 책임을 나누고, 정적 경로에서 헤더와 캐시 상태를 확인한 뒤 범위를 넓혀야 한다. 특히 쿠키나 검증 헤더를 없애는 선택은 성능 개선과 재검증 방식의 변화를 함께 가져온다.

직접 확인해보려면캐시가 기대와 다르게 동작하는 정적 경로 하나를 골라 응답 헤더, 캐시 상태, 로그인 여부를 먼저 기록해 보자.