주소 입력과 전송 구분
도메인만 쓰면 HTTPS를 덧붙입니다. 예시 버튼은 주소만 입력하고, 헤더 확인을 누르기 전에는 대상 사이트에 요청하지 않습니다.
HTTP 및 요청 디버깅
공개 URL의 첫 응답 살펴보기
공개 URL을 입력한 뒤 확인하세요.
URL은 이 사이트의 Worker로 전송되고, Worker가 공개 사이트에 익명 요청을 보냅니다. 쿠키와 인증 정보는 전달하지 않습니다.
공개 URL을 입력한 뒤 확인하세요.
HTTP 헤더 확인은 배포 후 캐시가 갱신되지 않거나 예상과 다른 리디렉션이 생겼을 때 첫 응답을 살펴보는 방법입니다. 상태와 실제 필드 값을 한 번의 관찰로 남깁니다.
HTTP 응답 헤더 조회 결과를 브라우저의 최종 페이지와 혼동하지 마세요. 먼저 HEAD를 보내고 거절된 경우에만 GET으로 다시 시도하며 다음 주소로 자동 이동하지 않습니다.
첫 단계의 응답을 그대로 보기
301 또는 302와 Location을 그대로 보여 줍니다. HTTP 헤더 확인은 최종 페이지로 이동하지 않으므로 입력 주소에서 일어난 설정 변화를 놓치지 않습니다.
보안 헤더와 캐시 헤더를 나누고 나머지 응답 필드도 보존합니다. 보이지 않는 항목은 이번 익명 요청의 관찰 결과이며 취약점 판정이 아닙니다.
도메인만 쓰면 HTTPS를 덧붙입니다. 예시 버튼은 주소만 입력하고, 헤더 확인을 누르기 전에는 대상 사이트에 요청하지 않습니다.
HEAD를 먼저 사용합니다. 405 또는 501 응답에는 본문을 버리는 GET 요청을 한 번 보내며, 3xx의 Location은 표시만 합니다.
확인 시각은 대상의 Date 헤더가 아니라 이번 요청이 끝난 시점입니다. URL을 고치면 이전 결과의 복사와 다운로드가 비활성화됩니다.
404와 500도 실제 응답이므로 헤더를 보여 줍니다. HEAD 대신 GET을 사용한 경우도 보고서에 표시합니다.
CSP, HSTS, Referrer-Policy 등을 확인할 수 있습니다. 보안 헤더가 있다는 사실만으로 안전하다고 채점하지 않습니다.
Cache-Control, ETag, Vary 등 캐시 헤더를 보면 변경 사항이 언제 반영될지 추적하는 데 도움이 됩니다.
Cache-Control, ETag, Vary를 보면 캐시의 동작을 추적할 단서를 얻습니다. 이 도구는 실제로 받은 값만 보여 주며 CDN의 전체 규칙을 추론하지 않습니다.
이 보고서에서 실제 값을 보고 사이트의 의도한 정책과 대조하세요. 헤더 이름이 존재한다는 것만으로 올바르게 설정되었다고 볼 수 없습니다.
네. 첫 응답의 상태 코드와 실제 요청 방식, 확인 시각이 함께 표시됩니다. 4xx와 5xx도 응답으로 취급합니다.
아니요. 이 도구는 HTTP 응답 헤더만 읽습니다. 인증서 체인은 별도의 인증서 검사 도구에서 확인해야 합니다.
브라우저는 쿠키나 로그인 상태를 사용할 수 있지만 여기서는 Worker가 익명으로 요청합니다. 지역과 캐시 경로도 달라질 수 있습니다.
궁금한 점이 남았나요?