도구스개발

Cache-Control 해석기

Cache-Control 헤더를 넣으면 브라우저와 CDN이 각각 언제까지 그대로 내주고 언제 재검증하는지 풀어서 설명합니다. 어긋나는 조합도 짚어 줍니다.

응답 헤더의 값을 그대로 붙여 넣으세요.

정리된 헤더

Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=600

브라우저 (개인 캐시)private cache

저장하는가저장합니다
그대로 내주는 기간없음 — 매번 확인합니다
그 뒤 낡은 것을 주는 기간10분 (뒤에서 새로 받아 둡니다)
그 뒤에는원본에 물어봅니다. 바뀌지 않았으면 304 로 짧게 끝납니다.
새로고침하면어차피 매번 원본에 물어봅니다.

CDN·프록시 (공유 캐시)shared cache

저장하는가저장합니다
그대로 내주는 기간1분
그 뒤 낡은 것을 주는 기간10분 (뒤에서 새로 받아 둡니다)
그 뒤에는재검증에 성공해야만 다시 쓸 수 있습니다.
새로고침하면사용자의 새로고침은 공유 캐시에 직접 전달되지 않습니다.

쓰인 디렉티브

max-ageRFC 9111 §5.2.2.1이 초가 지나면 낡은 것으로 봅니다.
s-maxageRFC 9111 §5.2.2.10공유 캐시에서만 max-age 를 덮어씁니다. proxy-revalidate 의 뜻도 함께 갖습니다.
publicRFC 9111 §5.2.2.9원래 캐시하면 안 될 응답도 저장해도 된다고 못박습니다.
stale-while-revalidateRFC 5861 §3낡은 뒤 이 초 동안은 낡은 것을 바로 내주고 뒤에서 새로 받아 둡니다.
no-cache 는 캐시하지 말라는 뜻이 아닙니다. 저장은 하되 쓸 때마다 원본에 물어보라는 뜻이고, 저장 자체를 막는 것은 no-store 입니다. no-cache 는 바뀌지 않았으면 304 로 짧게 끝나 대역폭을 아끼지만, no-store 는 매번 전부 다시 받습니다.
브라우저와 CDN 은 같은 헤더를 다르게 읽습니다. private 는 공유 캐시만 막고, s-maxage 는 공유 캐시에만 적용됩니다. 그래서 max-age=0, s-maxage=600 이면 브라우저는 매번 물어보지만 CDN 은 10분간 대신 내보냅니다 — 원본 부하를 줄이면서도 사용자에게는 늘 최신을 주는 흔한 조합입니다.
해석은 RFC 9111 §5.2.2(응답 디렉티브), RFC 5861(stale-while-revalidate · stale-if-error), RFC 8246(immutable)을 따릅니다. 다만 브라우저와 CDN 마다 구현이 조금씩 다르고, 특히 CDN 은 Surrogate-Control 같은 자체 헤더를 우선하기도 하므로 실제 동작은 응답 헤더로 확인하세요.

사용 방법

  1. 1Cache-Control 헤더 값을 붙여 넣거나 아래 예시를 고릅니다.
  2. 2브라우저와 CDN이 각각 어떻게 다루는지 확인합니다.
  3. 3어긋나거나 군더더기인 조합이 있으면 “눈여겨볼 점”에서 확인합니다.

자주 묻는 질문

no-cache는 저장은 하되 쓸 때마다 원본에 물어보라는 뜻이고, no-store는 저장 자체를 금지합니다. 이름 때문에 no-cache를 “캐시하지 마라”로 오해하기 쉽지만, no-cache는 바뀌지 않았으면 304로 짧게 끝나 대역폭을 아낍니다. no-store는 매번 전부 다시 받습니다.

s-maxage는 공유 캐시(CDN·프록시)에만 적용되며 그곳에서는 max-age를 덮어씁니다. max-age=0, s-maxage=600이면 브라우저는 매번 확인하지만 CDN은 10분간 그대로 내보냅니다. 원본 부하를 줄이면서 사용자에게는 늘 최신을 주는 흔한 조합입니다.

신선 기간이 끝난 뒤 지정한 초 동안은 낡은 응답을 즉시 내주면서 뒤에서 몰래 새로 받아 둡니다. 사용자는 기다리지 않고 다음 사람이 새 것을 받습니다. RFC 5861에 정의되어 있으며, 체감 속도를 크게 바꾸는 디렉티브입니다.

파일명에 해시가 붙어 내용이 바뀌면 주소도 바뀌는 정적 자산에 씁니다. 신선한 동안에는 사용자가 새로고침을 눌러도 재검증하지 않아 요청 자체가 줄어듭니다. max-age와 함께 써야 뜻이 있으며, 보통 public, max-age=31536000, immutable로 씁니다.

필요 없습니다. RFC 9111 §5.2.2.10이 s-maxage에 proxy-revalidate의 뜻이 이미 포함된다고 정해 두었습니다. s-maxage가 있으면 공유 캐시는 기간이 지난 응답을 재검증 없이 다시 쓸 수 없습니다.

캐시가 스스로 짐작합니다(휴리스틱 캐싱). 보통 Last-Modified로부터 지난 시간의 10% 정도를 신선 기간으로 잡는데, 캐시마다 달라 예측할 수 없습니다. 의도한 동작이 있다면 명시하는 편이 안전합니다.

알아두면 좋은 점

  • RFC 9111 §5.2.2, RFC 5861, RFC 8246을 따라 해석합니다.
  • 브라우저와 CDN마다 구현이 조금씩 다릅니다. CDN은 Surrogate-Control 같은 자체 헤더를 우선하기도 합니다.
  • no-store가 있어도 브라우저 뒤로 가기 캐시(bfcache)나 메모리에 잠시 남을 수 있습니다. 보안 목적이라면 이것만 믿지 마세요.

함께 보면 좋은 도구

HTTP 헤더HTTP 헤더가 하는 일과 요청·응답 어느 쪽에 쓰이는지 찾아봅니다.HTTP 상태 코드HTTP 상태 코드의 뜻과 언제 쓰는지 찾아봅니다.메타태그 생성제목·설명·이미지 URL을 입력하면 SEO·오픈그래프·트위터 카드 메타태그를 한 번에 생성합니다.다운로드 시간 계산파일 크기와 인터넷 속도를 입력하면 다운로드에 걸리는 예상 시간을 계산합니다.로그 용량초당 요청 수와 한 줄 크기로 하루 로그량을 구하고, 보존 기간·압축률·복제본을 반영해 필요한 저장 용량을 계산합니다.

마지막 검증: 2026년 8월 30일 · 결과는 참고용 추정치입니다.