[Cloudflare] Cache의 오해와 진실
캐시 미적중과 콘텐츠 갱신 지연을 만드는 7가지 사례
“Cloudflare 캐시를 설정했는데도 왜 오리진 요청이 계속 발생할까요?”
운영 환경에서 자주 받는 질문입니다. 그러나 “캐시가 동작하지 않습니다”라는 현상은 하나의 원인으로 설명되지 않습니다. 브라우저가 이전 콘텐츠를 보관하고 있는 경우도 있고, Cloudflare가 요청을 캐시 대상으로 판단하지 않은 경우도 있으며, 캐시 키가 지나치게 세분화된 경우도 있습니다. 오리진이 응답 헤더를 통해 캐시 저장을 막거나, 재검증 과정에서 이전 객체를 계속 사용하게 만드는 경우도 있습니다.
따라서 캐시 문제는 다음 세 계층으로 나누어 보아야 합니다.
- 브라우저 캐시: 사용자의 브라우저가 이미 콘텐츠를 보관하고 있는지 여부입니다.
- Cloudflare Edge 캐시: Cloudflare가 해당 요청을 캐시 대상으로 판단하고, Edge에 객체를 저장·재사용하는지 여부입니다.
- 오리진 서버: 캐시 가능 여부와 재검증 결과를 결정하는 응답 헤더 및 조건부 요청 처리 방식입니다.
이 글에서는 Cloudflare Cache Rules과 일반적인 Origin Cache Control 동작을 기준으로, 캐시 미적중과 콘텐츠 갱신 문제를 일으키는 일곱 가지 사례를 정리합니다.
캐시 상태를 확인하는 기본 방법
브라우저 화면만으로는 Cloudflare Edge 캐시 상태를 정확히 판단하기 어렵습니다. 동일한 URL을 반복 호출하면서 응답 헤더를 확인하시는 것이 좋습니다.
cf-cache-status | 의미 |
|---|---|
HIT | Cloudflare Edge 캐시에 저장된 객체가 제공된 상태입니다. |
MISS | 캐시 대상이지만, 요청 시점에 해당 Edge에 객체가 없었던 상태입니다. |
DYNAMIC | 요청이 처음부터 캐시 대상이 아니었던 상태입니다. |
BYPASS | 요청은 캐시 대상이었지만, 오리진 응답 조건으로 저장하지 않은 상태입니다. |
REVALIDATED | 오리진 재검증을 거쳐 기존 캐시 객체를 다시 사용한 상태일 수 있습니다. |
EXPIRED | 캐시 객체가 만료되어 오리진에서 다시 응답을 받아 제공한 상태입니다. |
UPDATING | 만료된 객체를 제공하면서 백그라운드에서 재검증을 수행하는 상태입니다. |
1. 쿼리스트링에 따라 캐시 키가 달라지는 사례
이슈 현상
이미지, CSS, JavaScript처럼 실제 파일은 같은데도 요청마다 MISS가 발생하고, 오리진 트래픽이 줄지 않는 현상이 발생할 수 있습니다.
예를 들어 다음 두 URL은 동일한 이미지를 반환할 수 있습니다.
/images/banner.webp?utm_source=newsletter
/images/banner.webp?utm_source=search그러나 Cloudflare는 두 요청을 서로 다른 캐시 객체로 판단할 수 있습니다.
원인
Cloudflare의 기본 Cache Key에는 전체 URI가 포함되며, URI의 쿼리스트링도 기본적으로 포함됩니다. 따라서 쿼리스트링 값이 달라지면 다른 Cache Key가 생성됩니다.
사용자 식별자, 광고 파라미터, 랜덤 토큰, 타임스탬프 등이 쿼리스트링에 포함되어 있다면 요청마다 새로운 캐시 키가 만들어지고 캐시 적중률은 낮아질 수 있습니다.
분석 결과
이 문제는 Cloudflare가 캐시하지 않은 것이 아니라, 동일한 리소스를 너무 많은 캐시 키로 분리한 상황에 가깝습니다.
Cache Rule 조건을 URI Path starts with /assets/로 변경하더라도, 캐시 키에서 쿼리스트링이 자동으로 제거되지는 않습니다. 규칙 조건은 “이 요청을 캐시 대상으로 볼 것인가”를 결정하고, Cache Key는 “이 요청을 기존 캐시 객체와 같은 것으로 볼 것인가”를 결정합니다.
두 설정은 서로 다른 역할을 수행합니다.
조치
utm_source,utm_campaign처럼 응답 본문에 영향을 주지 않는 추적 파라미터는 Cache Key에서 제외하는 방식을 검토합니다.userId,token,lang,currency, 서명 URL 파라미터처럼 응답 내용 또는 접근 권한에 영향을 주는 값은 Cache Key에서 제거하면 안 됩니다.- 공용 정적 리소스에 한해서
Ignore query string또는 쿼리 파라미터 제외 정책을 검토합니다. - 배포 후 기존 쿼리스트링 변형 객체가 남아 있는지 purge 정책도 함께 점검합니다.
사용자별 콘텐츠에서 쿼리스트링을 무시하면 다른 사용자의 콘텐츠가 전달되는 캐시 오염 문제가 발생할 수 있습니다. 캐시 적중률보다 콘텐츠 격리가 우선되어야 합니다.
2. Last-Modified 역행으로 새 콘텐츠가 갱신되지 않는 사례
이슈 현상
Cloudflare Edge TTL이 만료되어 오리진 재검증이 발생했음에도, 배포된 새 콘텐츠가 Cloudflare 캐시에 반영되지 않고 이전 콘텐츠가 계속 제공되는 현상이 발생할 수 있습니다.
이 현상은 기존 Cloudflare 캐시 객체의 Last-Modified 값보다, 오리진의 새 콘텐츠가 더 과거의 Last-Modified 값을 반환할 때 발생할 수 있습니다.
예를 들어 기존 Cloudflare 캐시 객체가 다음 값을 가지고 있다고 가정하겠습니다.
Last-Modified: Wed, 12 Feb 2025 10:00:00 GMT이후 새 콘텐츠를 배포했지만, 파일 복사, 롤백, 아티팩트 재사용 또는 수정 시각 보존 문제로 오리진이 더 과거의 값을 반환할 수 있습니다.
Last-Modified: Mon, 10 Feb 2025 10:00:00 GMT원인
Edge TTL이 만료되면 Cloudflare는 기존 캐시 객체의 수정 시각을 기준으로 오리진에 조건부 요청을 보낼 수 있습니다.
If-Modified-Since: Wed, 12 Feb 2025 10:00:00 GMT이때 오리진이 실제 콘텐츠 본문이 변경되었는지 확인하지 않고 Last-Modified 값만 비교하면, 새 콘텐츠의 수정 시각이 요청 헤더보다 과거이므로 “변경되지 않았습니다”라고 잘못 판단하여 304 Not Modified를 반환할 수 있습니다.
Cloudflare는 오리진의 304 응답을 신뢰하고 기존 캐시 객체를 계속 사용합니다. 결과적으로 새 콘텐츠는 오리진에 존재하지만 Cloudflare 캐시에 저장되지 않으며, 사용자는 이전 콘텐츠를 계속 보게 됩니다.
분석 결과
이 문제의 본질은 Cloudflare가 과거 시각의 Last-Modified를 이유로 새 콘텐츠를 거부하는 것이 아닙니다. Cloudflare의 조건부 재검증 요청에 대해 오리진이 잘못된 304 응답을 반환하는 것이 직접적인 원인입니다.
오리진이 새 콘텐츠를 200 OK로 정상 반환한다면, 새 응답의 Last-Modified 값이 기존 캐시 객체보다 과거이더라도 Cloudflare는 새 응답 본문을 받아 캐시를 갱신할 수 있습니다.
따라서 이 사례는 다음 항목을 함께 검증해야 합니다.
- Cloudflare가 Edge TTL 만료 후 실제로 조건부 요청을 보냈는지 확인합니다.
- 오리진이
If-Modified-Since요청에 어떤 상태 코드와 헤더를 반환했는지 확인합니다. - 배포된 파일의 실제 콘텐츠 해시와
Last-Modified값이 일관된지 확인합니다. - 파일 복사, 롤백, 아티팩트 배포 과정에서 과거 수정 시각이 유지되지 않는지 확인합니다.
Cloudflare는 만료된 객체를 If-Modified-Since 또는 If-None-Match로 재검증할 수 있으며, 오리진의 304 응답을 받으면 기존 객체를 재사용합니다.
조치
- 새 콘텐츠가 배포될 때
Last-Modified값도 실제 변경 시점에 맞게 갱신되도록 구성합니다. - 파일 복사, 롤백, 아티팩트 배포 과정에서 이전 파일의 수정 시각이 보존되지 않는지 확인합니다.
- 콘텐츠 버전 또는 본문 해시를 기반으로 한
ETag를 함께 제공하는 방식을 검토합니다. - 콘텐츠 본문이 변경되었다면 오리진은 조건부 요청에
304 Not Modified가 아닌200 OK와 새 본문을 반환해야 합니다. - 배포 직후 즉시 반영이 필요하다면 Cloudflare purge를 함께 수행합니다.
purge는 이미 Edge에 저장된 이전 객체를 제거하는 데 유용하지만, 오리진이 잘못된 조건부 응답을 반환하는 근본 원인을 해결하지는 못합니다.
3. 브라우저 캐시 때문에 변경된 콘텐츠가 갱신되지 않는 사례
이슈 현상
오리진과 Cloudflare Edge에서는 새 콘텐츠가 제공되는데도 일부 사용자에게만 이전 JavaScript, CSS, 이미지 또는 HTML이 계속 보일 수 있습니다.
시크릿 창에서는 정상이고 강력 새로고침 후 정상으로 보인다면 브라우저 캐시를 우선 의심해 보셔야 합니다.
원인
브라우저는 아직 유효하다고 판단한 리소스에 대해 Cloudflare로 요청을 보내지 않을 수 있습니다. 즉, Cloudflare Edge에서 purge를 수행하더라도 이미 사용자 브라우저에 저장된 파일까지 원격으로 삭제할 수는 없습니다.
브라우저 뒤로 가기 캐시인 BFCache까지 개입하면 네트워크 요청 없이 이전 화면 상태가 복원될 수도 있습니다.
분석 결과
Edge Cache TTL과 Browser Cache TTL은 서로 다른 설정입니다. Edge Cache TTL은 Cloudflare 내부에서 객체를 얼마나 오래 신선한 상태로 볼지 결정하며, 일반적으로 브라우저 응답 헤더에 직접 표시되지 않습니다.
Browser Cache TTL은 방문자 브라우저가 리소스를 얼마나 오래 보관할지를 결정합니다. 따라서 Cloudflare Edge에서는 최신 파일이 준비되어 있어도 브라우저가 이전 파일을 유효하다고 판단하면 사용자는 오래된 콘텐츠를 보게 될 수 있습니다.
조치
HTML과 정적 리소스를 다르게 운영하시는 것이 좋습니다. HTML처럼 최신 여부 확인이 필요한 응답에는 다음과 같은 재검증 중심 정책을 검토할 수 있습니다.
Cache-Control: no-cache반면 파일명이 콘텐츠 변경에 따라 함께 바뀌는 정적 리소스에는 긴 캐시 기간을 사용할 수 있습니다.
Cache-Control: public, max-age=31536000, immutable예를 들어 app.8d91f2c.js의 내용이 변경되면 app.a37cd1e.js처럼 새 파일명으로 배포하시는 것이 좋습니다. 같은 URL의 파일 내용만 변경하는 방식은 브라우저 캐시와 충돌하기 쉽습니다.
4. Browser Cache 설정과 오리진 Cache-Control 우선순위 문제
이슈 현상
오리진에서 Cache-Control: max-age=300을 반환했는데 사용자는 하루 이상 오래된 파일을 보거나, Cloudflare Edge TTL을 길게 설정했는데 브라우저가 너무 자주 재검증하는 일이 발생할 수 있습니다.
원인
Edge Cache TTL과 Browser Cache TTL을 하나의 설정처럼 이해했기 때문입니다. Cloudflare Edge는 여러 사용자가 공유하는 캐시이고, 브라우저는 개별 사용자 환경에 저장되는 캐시입니다. 두 계층은 서로 다른 TTL을 가질 수 있습니다.
Cache-Control: public, max-age=300, s-maxage=3600이 경우 max-age=300은 브라우저 관점의 5분 정책으로 사용될 수 있으며, s-maxage=3600은 Cloudflare와 같은 공유 캐시 관점의 1시간 정책으로 사용될 수 있습니다.
분석 결과
Cloudflare는 기본적으로 오리진의 Cache-Control과 Expires 설정을 존중합니다. Browser Cache TTL을 설정한 경우에도 오리진의 max-age가 더 길다면 Cloudflare 설정만으로 브라우저 캐시 시간을 더 짧게 강제하지 못할 수 있습니다.
반대로 오리진 헤더가 없거나 Browser Cache TTL보다 짧다면 Cloudflare의 Browser Cache TTL 설정이 브라우저에 전달되는 정책에 영향을 줄 수 있습니다.
또한 Edge Cache TTL을 오리진 헤더 무시 방식으로 설정하더라도, 그것이 Browser Cache TTL까지 같은 값으로 변경한다는 뜻은 아닙니다. Edge 캐시 정책과 브라우저 캐시 정책은 분리하여 검증하셔야 합니다.
조치
- HTML은 짧게 캐시하거나 재검증 중심으로 운영합니다.
- 콘텐츠 해시가 포함된 정적 파일은 브라우저와 Edge에서 길게 캐시합니다.
- 브라우저와 Edge의 TTL을 다르게 운영해야 한다면
max-age와s-maxage의 목적을 구분합니다. - Cloudflare 설정 변경 후에는 실제 사용자 응답의
Cache-Control헤더와cf-cache-status를 각각 확인합니다.
5. 기본 Cloudflare 캐시 정책과 Cache Rule 기본 TTL을 혼동한 사례
이슈 현상
Cache Rule이 없을 때 HTML은 계속 DYNAMIC으로 보이는데, HTML에 Cache Rule을 적용한 뒤에는 오리진이 캐시 헤더를 반환하지 않아도 일정 시간 캐시되는 현상이 발생할 수 있습니다.
원인
캐시 대상 여부와 캐시 보존 시간인 TTL을 같은 개념으로 생각했기 때문입니다.
Cloudflare의 기본 캐시 정책은 확장자 기반입니다. CSS, JavaScript, 이미지 등은 기본적으로 캐시 대상이 될 수 있지만, HTML과 JSON은 기본적으로 캐시하지 않습니다. HTML이 DYNAMIC으로 보이는 이유는 TTL이 짧아서가 아니라, 처음부터 기본 캐시 대상이 아니기 때문입니다.
<기본 Cloudflare Cache 정책>
| 상태 코드 | 기본 Edge TTL |
|---|---|
| 200, 206, 301 | 120분 |
| 302, 303 | 20분 |
| 404, 410 | 3분 |
| 그 외 상태 코드 | 기본적으로 캐시하지 않음 |
분석 결과
Cache Rule에서 HTML을 Eligible for cache 또는 Cache Everything 대상으로 지정하면 HTML도 캐시 가능 객체가 됩니다. 이후 오리진이 Cache-Control 또는 Expires 헤더를 반환하지 않는다면, 응답 상태 코드에 따라 Cloudflare 기본 TTL이 적용될 수 있습니다.
예를 들어 다음 두 상황은 서로 모순되지 않습니다.
- Cache Rule이 없는
index.html요청은 기본 정책상 캐시 대상이 아니므로DYNAMIC으로 처리됩니다. index.html을 캐시 가능하게 만든 Cache Rule이 있고, 오리진 캐시 헤더가 없으며, 응답이 200인 경우에는 기본 TTL 120분이 적용될 수 있습니다.
Cache Rule의 Edge Cache TTL에서 “오리진 Cache-Control이 있으면 따르고, 없으면 Cloudflare 기본 캐싱 동작을 사용”하는 옵션의 “Cloudflare 기본 캐싱 동작”은 Cache Rule이 전혀 없을 때의 기본 동작과 일치하지 않습니다.
그 이유는 Cache Rule이 HTML 요청을 이미 캐시 가능 상태로 만들었기 때문입니다. 즉, 해당 옵션은 Cache Rule을 제거하고 Cloudflare의 기본 확장자 기반 캐시 대상을 다시 적용하는 기능이 아닙니다. 캐시 가능 상태가 된 응답에 대해 오리진 헤더가 없을 때, 상태 코드별 기본 TTL을 적용하는 방식으로 이해하셔야 합니다.
| 구분 | Cache Rule 없음 | Cache Rule로 HTML을 캐시 가능하게 설정 |
|---|---|---|
index.html의 캐시 대상 여부 | 기본적으로 캐시 대상이 아니며 DYNAMIC으로 처리될 수 있습니다. | 캐시 가능 객체로 처리됩니다. |
| 오리진 캐시 헤더 없음 | 캐시 대상이 아니므로 기본 TTL이 적용되지 않습니다. | 200 응답이라면 기본 TTL 120분이 적용될 수 있습니다. |
| 기본 TTL의 의미 | 캐시 대상 판정 이전에는 의미가 없습니다. | 이미 캐시 가능해진 객체의 보존 시간을 결정합니다. |
따라서 “Cloudflare 기본 캐싱 동작”이라는 문구를 “Cache Rule이 없던 상태로 되돌아간다”고 해석하면 안 됩니다. 이는 캐시 가능 객체에 적용되는 TTL의 기본값에 관한 의미입니다.
조치
- HTML을 캐시하기 전에 해당 페이지가 모든 사용자에게 동일한 공용 콘텐츠인지 확인합니다.
- 로그인 상태, 장바구니, 마이페이지, 회원 등급, 지역, 언어에 따라 달라지는 HTML은 무조건 Cache Everything으로 처리하지 않습니다.
- 공용 HTML이라면 캐시 대상 조건, Edge TTL, Browser TTL, 제외 경로, 쿠키 조건을 명시적으로 구성합니다.
- 기본 TTL에 기대기보다 서비스 요구사항에 맞는 명시적인 Edge TTL 정책을 설계합니다.
- 요금제별 최소 Edge TTL 제한도 함께 확인합니다.
6. 오리진 응답 헤더로 인해 BYPASS가 발생하는 사례
이슈 현상
Cache Rule에서 캐시를 활성화했는데도 cf-cache-status: BYPASS가 반복적으로 나타날 수 있습니다.
원인
Cloudflare의 캐시 판단은 요청 시점에 끝나지 않습니다. 요청이 캐시 대상으로 판정되더라도 오리진 응답의 헤더, 쿠키, 상태 코드, 인증 정보, 파일 크기에 따라 최종 저장 여부가 달라집니다.
| 헤더 또는 조건 | 주의할 점 |
|---|---|
Set-Cookie | 기본 정책과 Origin Cache Control 상태에 따라 공유 캐시 저장을 막을 수 있습니다. |
Vary: * | Cloudflare에서 항상 캐시를 우회합니다. |
Cache-Control: private | 공유 캐시인 Cloudflare에 저장하면 안 되는 응답입니다. |
Cache-Control: no-store | 어떤 캐시에도 저장하지 말라는 지시입니다. |
Cache-Control: no-cache | 저장 자체를 무조건 금지하지는 않지만, 사용 전 재검증을 요구합니다. |
Cache-Control: public, no-store | public이 있어도 no-store가 우선합니다. |
Authorization 요청 헤더 | Origin Cache Control 설정에 따라 추가 캐시 조건이 필요할 수 있습니다. |
분석 결과
DYNAMIC과 BYPASS를 구분해서 보셔야 합니다.
DYNAMIC은 HTML처럼 처음부터 캐시 자격이 없거나 Bypass Rule이 적용된 경우입니다. 반면 BYPASS는 요청이 캐시 대상이었지만 오리진 응답이 최종 캐시 저장을 거부한 경우입니다.
또한 Cloudflare는 Cloudflare-CDN-Cache-Control, CDN-Cache-Control, Cache-Control 순으로 캐시 지시어를 해석할 수 있습니다. 애플리케이션에서 Cache-Control: public을 반환하더라도 상위 프록시나 미들웨어가 CDN-Cache-Control: no-store를 추가하면 예상과 다르게 BYPASS가 발생할 수 있습니다.
조치
- Cloudflare Edge를 통과한 실제 응답 헤더와 오리진 직접 응답 헤더를 비교합니다.
- 애플리케이션, 웹 서버, API Gateway, 보안 미들웨어 중 어디에서 캐시 제어 헤더가 추가되는지 추적합니다.
- 공용 정적 리소스에 실수로 세션 쿠키가 설정되는 경우에는 쿠키 발급 경로를 분리하는 방식을 검토합니다.
- 캐시 적중률을 높이기 위해
Set-Cookie를 무조건 제거해서는 안 됩니다. Vary: *가 반환된다면 캐시 우회를 강제로 해제하기보다, 왜 응답이 모든 요청 조건에 따라 달라지는지 오리진 설계를 먼저 점검합니다.
7. Cache Rule 조건 설정 차이로 발생하는 사례
이슈 현상
/assets/ 경로에 캐시를 적용했는데 일부 쿼리스트링 요청까지 함께 캐시되거나, 특정 URL만 매칭하려 했는데 광고 파라미터가 붙는 순간 규칙이 적용되지 않는 문제가 발생할 수 있습니다.
원인
URI Full, URI, URI Path, URI Query String의 범위를 혼동했기 때문입니다.
특히 URI Path는 쿼리스트링을 포함하지 않으므로 다음 두 요청은 동일한 Path 조건에 매칭됩니다.
/assets/app.js
/assets/app.js?preview=1반대로 URI Full은 쿼리스트링까지 포함하므로 utm_source 같은 부수 파라미터 하나만 달라져도 완전 일치 조건이 달라질 수 있습니다.
분석 결과
Cache Rule의 조건과 Cache Key는 별개의 설정입니다.
예를 들어 아래 조건은 /assets/ 경로에 캐시를 적용하되 preview=1 쿼리스트링이 포함된 요청은 제외하는 방식으로 사용할 수 있습니다.
(http.request.uri.path starts_with "/assets/")
and not (http.request.uri.query matches "(^|&)preview=1(&|$)")다만 위 조건만으로 ?utm_source=a와 ?utm_source=b가 같은 캐시 객체가 되지는 않습니다. 기본 Cache Key에는 쿼리스트링이 포함되기 때문입니다.
<필드 조건에 따른 의미>
| 필드 | 의미 |
|---|---|
http.request.full_uri | 호스트, 경로, 쿼리스트링을 포함한 전체 URI입니다. |
http.request.uri | 경로와 쿼리스트링을 포함합니다. |
http.request.uri.path | 경로만 포함하며, 쿼리스트링은 포함하지 않습니다. |
http.request.uri.query | ?를 제외한 쿼리스트링만 포함합니다. |
즉, URI Full은 쿼리스트링을 포함하고 URI Path는 쿼리스트링을 포함하지 않습니다.
조치
- 경로만 기준으로 규칙을 적용하려면
http.request.uri.path를 사용합니다. - 쿼리스트링 존재 여부 또는 특정 파라미터를 확인하려면
http.request.uri.query를 사용합니다. - 호스트, 경로, 쿼리스트링까지 포함한 전체 URL을 판단하려면
http.request.full_uri를 사용합니다. - 경로와 쿼리스트링을 함께 판단하되 호스트는 제외하려면
http.request.uri를 사용합니다. - 서명 URL, 인증 토큰, 사용자 식별자, 미리보기 파라미터가 붙는 URL에는 쿼리스트링 무시 정책을 적용하지 않습니다.
조건이 요청을 캐시 대상으로 만들었다고 해서, 서로 다른 쿼리스트링 요청이 자동으로 같은 Cache Key를 공유하는 것은 아닙니다. 조건과 Cache Key를 함께 설계하셔야 합니다.
마무리
Cloudflare 캐시 문제의 대부분은 Cloudflare가 예상과 다르게 동작해서 발생하기보다, 다음 요소들이 서로 다른 역할을 한다는 점을 놓쳐서 발생합니다.
- 캐시 대상 여부
- Cache Key
- 오리진 응답 헤더
- Edge TTL
- Browser TTL
- 재검증 헤더와 조건부 요청 처리
- purge 및 배포 전략
운영 중에는 다음 순서로 확인하시면 원인을 빠르게 좁히실 수 있습니다.
- 해당 응답이 모든 사용자에게 동일한 공용 콘텐츠인지 확인합니다.
- Cloudflare가 요청 시점에 캐시 대상으로 판단했는지 확인합니다.
- 오리진 응답 헤더가 캐시 저장을 막고 있는지 확인합니다.
- 동일한 요청이 실제로 동일한 Cache Key를 사용하는지 확인합니다.
- Edge TTL과 Browser TTL을 분리하여 확인합니다.
- 재검증 요청에 오리진이 올바른 200 또는 304 응답을 반환하는지 확인합니다.
- 변경 반영을 TTL 만료에 맡길지, purge와 버전 URL로 제어할지 결정합니다.
좋은 캐시 정책은 단순히 오래 보관하는 정책이 아닙니다. 공용 콘텐츠는 안전하게 재사용하고, 개인화 콘텐츠는 명확히 우회하며, 변경이 필요한 정적 리소스는 파일 버전과 purge 전략으로 통제하는 정책이 좋은 캐시 정책입니다.
참고 문서
- Cloudflare Default cache behavior
- Cloudflare Cache Keys
- Cloudflare Revalidation
- Cloudflare Edge and Browser Cache TTL
- Cloudflare Browser Cache TTL
- Cloudflare Cache Rules settings
- Cloudflare cache responses
- Cloudflare Origin Cache Control
공식 문서의 기술적 사실관계를 바탕으로 재서술했습니다. Content was rephrased for compliance with licensing restrictions.