public다른 캐싱 조건도 만족하면 공유 저장을 허용합니다.
1줄, 16열
HTTP & Request Debugging
Cache-Control 파서저장과 재사용 조건을 구분하세요
응답 헤더를 분석하거나 폼으로 새 헤더를 만드세요. 현재 나이는 예제를 위한 가정값입니다.
Cache-Control 파서
헤더와 폼 값은 이 브라우저에서만 처리하며 원본 서버에 요청하지 않습니다.
브라우저 / 개인 캐시
이 나이 예제에서는 신선함
max-age: 수명 3600초
남은 신선도: 3600초
공유 캐시 / CDN
이 나이 예제에서는 신선함
s-maxage: 수명 86400초
남은 신선도: 86400초
이 지시문에서는 오래된 응답을 재사용하기 전에 검증해야 합니다.
이미 저장된 응답과 아래 나이를 가정합니다. 신선함은 저장이나 재사용 보장이 아니며 다른 헤더와 플랫폼 규칙도 영향을 줍니다.
current_age를 0부터 2147483648까지 가정하세요. Age 헤더만으로 모든 전송·체류 시간을 알 수 없습니다. 정적인 예제입니다.
분석된 지시문
max-age=3600개인 캐시와 s-maxage가 없는 공유 캐시의 신선도 수명입니다.
1줄, 24열
s-maxage=86400공유 캐시의 max-age를 재정의하며 브라우저에는 적용되지 않습니다.
1줄, 38열
전체 3개 중 3개 표시
정책 메모
모델링한 지시문에서 문제를 찾지 못했습니다. 배포 검증은 아닙니다.
지시문 3개 · 정책 메모 0개
캐시를 켰는데도 원본 서버 요청이 계속되면 저장 여부와 재검증 조건을 나눠 봐야 합니다. Cache-Control 파서에서는 브라우저와 공유 캐시를 별도로 보여 주므로, 서로 다른 수명이 설정된 응답을 비교하기 좋습니다.
이 Cache-Control 분석기는 기존 캐시 응답 헤더를 살펴보는 입력과 새 캐시 정책을 만드는 폼을 따로 유지합니다. 폼이 모르는 확장이나 중복 지시문도 원문 분석에서 사라지지 않습니다.
Cache-Control 파서로 확인하는 차이
진단할 단서를 남겨 두기
Cache-Control 파서는 private="X-Foo, X-Bar" 안의 쉼표를 구분자로 오해하지 않습니다. 반복된 max-age도 삭제하지 않고 위치와 함께 표시합니다. 생성 모드로 바꿔 새 값을 조합해도 분석 입력은 그대로 남습니다.
브라우저와 공유 캐시의 시간 비교
기본값은 max-age=3600과 s-maxage=86400입니다. 가정한 현재 나이를 4000초로 바꾸면 브라우저 예제는 오래된 상태이고 공유 캐시는 신선도 TTL이 82400초 남습니다. 실제 요청이 캐시에 적중한다는 뜻은 아닙니다.
수명을 바꾸기 전에 살펴볼 세 가지
01
관련 필드만 가져오기
값 한 줄 또는 Cache-Control:로 시작하는 여러 줄을 입력할 수 있습니다. Age나 ETag가 섞인 전체 응답은 거부합니다. 일부만 읽고 전체를 검사한 것처럼 보이는 일을 피합니다.
02
빈칸과 0 구별하기
폼에서 빈 시간 칸은 지시문을 생략하고 0은 명시적인 0초를 만듭니다. 예제와 지우기는 적용 전 교체 미리보기를 표시합니다. 실행 취소는 두 모드의 입력과 이전 결과를 한 번 복원합니다.
03
나이를 바꿔 경계 확인하기
현재 나이는 직접 가정하는 정수 초이며 실시간 타이머가 아닙니다. 자동 분석은 편집 후 350ms를 기다립니다. 끄면 버튼이나 Ctrl/Cmd + Enter로 실행하며, 편집 직후 이전 결과의 내보내기는 비활성화됩니다.
지시문에서 재사용 조건까지
인수와 반복을 보존하는 분석
이름은 대소문자를 구분하지 않고 출력에서 소문자로 정리합니다. 인수 표기, 따옴표, 순서와 중복은 남기며 빈 쉼표 항목은 건너뜁니다. 각 항목의 줄과 열로 여러 설정이 합쳐진 위치를 추적할 수 있습니다.
응답 지시문을 폼으로 조합
아홉 스위치와 네 시간 입력으로 응답 헤더를 구성합니다. max-age, s-maxage, stale-while-revalidate, stale-if-error는 0부터 2147483648까지의 정수 초를 사용합니다. 충돌하는 선택도 자동 삭제하지 않습니다.
신선도와 재사용을 따로 해석
일반적인 no-cache는 재사용 전에 성공적인 검증을 요구하고 no-store는 저장을 금지합니다. 양수 수명이 있어도 모든 저장 조건이 충족된 것은 아닙니다. 공유 캐시는 s-maxage가 있으면 이를 우선합니다.
확정할 수 없는 이유 표시
알 수 없는 확장, 필드 제한 형식, must-understand에는 추가 문맥이 필요합니다. 알려진 지시문의 중복이나 잘못된 인수에는 확정적인 초 값을 내지 않습니다. 화면은 50개씩 표시하지만 복사와 텍스트 저장은 전체 현재 헤더를 담습니다.
헤더 하나로 알 수 있는 범위
- 응답 필드만 분석
- 주소를 요청하거나 ETag, Vary, Expires를 함께 평가하지 않습니다. 요청 전용 지시문은 보존하고 범위를 설명합니다. 서버 설정 코드, 파일 업로드, 대량 헤더 처리도 제공하지 않습니다.
- 실제 만료 시각 계산은 제외
- 수명에서 가정한 현재 나이를 빼는 예제에는 Date 보정, 전송 지연, 저장 후 체류 시간이 없습니다. 명시적 수명이 없더라도 다른 Expires나 휴리스틱 캐싱이 적용될 수 있으므로 저장 불가로 단정하지 않습니다.
- CDN 전체 설정 검증은 제외
- 플랫폼 재정의, 인증, 응답 상태와 캐시 키가 결과를 바꿀 수 있습니다. 진단이 없다는 것은 배포 승인이나 캐시 적중 보장이 아닙니다. 기존 캐시를 삭제하는 기능도 없습니다.
- 입력 한도와 보수적인 판단
- 최대 16384 UTF-16 단위와 128개 지시문을 받습니다. 문법 오류는 위치를 표시하고 내보내기를 중지합니다. 범위를 넘는 분석 값은 원문을 보존하고 수치 추론을 하지 않습니다. 생성 값과 가정한 나이의 상한은 2147483648입니다.
- 오래된 응답의 허용은 조건부
- stale-while-revalidate와 stale-if-error는 신선한 기간에 더해지지 않습니다. 오래된 응답을 돌려주려면 구현과 요청, 오류 조건 등이 맞아야 합니다. 재검증 제약과 함께 있으면 검토 메모를 표시합니다.
Cache-Control 파서 질문과 답변
max-age와 s-maxage는 어떤 차이가 있나요?
max-age는 개인 캐시와 별도의 s-maxage가 없는 공유 캐시에 적용됩니다. s-maxage는 공유 캐시 수명을 정하고 오래된 응답에는 검증을 요구합니다. 브라우저 수명까지 늘리는 설정은 아닙니다.
캐시를 설정해도 브라우저가 계속 원본 서버를 요청하는 이유는 무엇인가요?
no-cache가 있으면 저장된 응답도 재사용 전 검증해야 합니다. 이미 신선도를 잃었거나 요청 측의 재검증 요구가 있을 수도 있습니다. 헤더 하나만으로 실제 요청 원인을 확정할 수 없으므로 네트워크 기록과 함께 확인하세요.
CDN이나 정적 리소스의 캐시 문제도 확인할 수 있나요?
응답 헤더의 지시문과 브라우저·공유 캐시의 수명 차이는 살펴볼 수 있습니다. 그러나 실제 CDN 규칙, 캐시 키 또는 적중 상태는 가져오지 않습니다. 정적 리소스도 배포된 응답과 플랫폼 설정을 별도로 확인해야 합니다.
no-cache와 no-store는 어떻게 다른가요?
일반적인 no-cache는 저장을 허용하지만 재사용 전 검증을 요구합니다. no-store는 응답 저장을 금지합니다. 두 값 모두 이미 존재하는 모든 캐시 사본을 지우는 명령은 아닙니다.
모든 캐싱 문제를 이 분석기로 찾을 수 있나요?
아니요. 이 도구는 응답 Cache-Control 텍스트만 다룹니다. 인증, 상태 코드, ETag, Vary, 서비스 워커 및 플랫폼 설정은 더 넓은 조사 대상입니다. 진단 결과가 깨끗해도 모든 캐시 문제가 해결됐다고 판단할 수 없습니다.
문제가 있나요?