HTTP 헤더 확인

HTTP 헤더 확인은 입력한 URL에 서버가 실제로 어떤 응답 상태 코드와 응답 헤더를 돌려주는지 실시간으로 보여 주는 도구입니다. 브라우저 개발자도구를 열 필요 없이, 보안 헤더(HSTS·CSP· X-Frame-Options), 캐시 정책(Cache-Control·ETag), 서버 종류(Server)와 콘텐츠 타입을 한눈에 점검할 수 있습니다.

요청은 안전한 서버 측 프록시를 통해 전송되므로 CORS 제약 없이 모든 헤더를 그대로 받아옵니다. 리다이렉트가 있으면 각 단계를 추적해 최종 도착 URL과 상태 코드를 함께 표시합니다. URL만 입력하면 됩니다.

주요 응답 헤더 빠른 정리

• Content-Type: 본문의 MIME 타입과 문자 인코딩(charset)
• Cache-Control / ETag / Last-Modified: 캐싱·재검증 정책
• Strict-Transport-Security: HTTPS 강제(HSTS) 적용 여부
• Content-Security-Policy: 스크립트·리소스 출처 제한 정책
• X-Frame-Options: 클릭재킹 방지를 위한 프레임 삽입 제한
• Server: 서버 소프트웨어(노출 시 정보 누출 주의)

상태 코드와 리다이렉트 읽기

2xx는 정상, 3xx는 리다이렉트, 4xx는 클라이언트 오류, 5xx는 서버 오류입니다. 이 도구는 301·302 같은 리다이렉트를 따라가며 각 단계를 기록하므로, http→https 강제나 www 정규화가 의도대로 동작하는지 확인할 수 있습니다. 최종 URL이 입력과 다르면 리다이렉트가 발생한 것입니다.

이렇게 활용하세요

배포 직후 보안 헤더가 빠지지 않았는지, CDN·캐시 정책이 적용됐는지, 잘못된 리다이렉트 루프가 없는지 빠르게 점검하기에 좋습니다. 본문은 가져오지 않고 헤더만 확인하므로 가볍고 빠릅니다. 보안 헤더만 등급으로 평가하려면 보안 헤더 점검을, 리다이렉트 체인만 단계별로 추적하려면 HTTP 상태·리다이렉트 추적을 함께 사용하세요.

헤더 값 빠른 해석표

실무에서 가장 자주 마주치는 값과 그 의미입니다. 권장값과 비교하면 설정 누락을 바로 찾을 수 있습니다.

리다이렉트 체인 읽기 예시

http://example.com을 입력했을 때 실제로 나타나는 전형적인 흐름입니다:

• 1단계 http://example.com → 301 Moved Permanently, Location: https://example.com/ (HTTP→HTTPS 강제)
• 2단계 https://example.com/ → 301, Location: https://www.example.com/ (www 정규화)
• 3단계 https://www.example.com/ → 200 OK (최종 도착)

여기서 1단계 응답에 들어 있는 Strict-Transport-Security 헤더는 사실상 무의미합니다. 브라우저는 HTTP(평문) 응답의 HSTS를 무시하므로, HSTS는 2·3단계의 HTTPS 응답에 반드시 있어야 합니다. 또 1→2가 301(영구) 인데 실수로 도메인을 바꾸면 브라우저·검색엔진이 캐시해 되돌리기 어려우니, 확신이 없을 땐 302(임시)로 시작하는 편이 안전합니다.

흔한 실수 / 함정

• no-cache를 “캐시 안 함”으로 오해하기 — 실제로는 캐시하되 사용 전 매번 재검증입니다. 진짜 캐시를 막으려면 no-store를 써야 합니다.
• HTTP 응답에 HSTS를 넣고 안심하기 — 평문 응답의 HSTS는 브라우저가 무조건 무시합니다. HTTPS 응답에 있어야 효과가 있습니다.
• 최종 URL의 헤더만 보고 판단하기 — 보안 헤더가 빠진 곳은 보통 중간 리다이렉트 단계입니다. 각 hop을 모두 확인하세요.