HTTP 헤더 뷰어
HTTP 헤더 뷰어 사용 방법
- 1
웹사이트 URL 입력
헤더를 검사하려는 사이트의 전체 URL을 https:// 를 포함해 입력하세요.
- 2
헤더 가져오기
"Fetch Headers"를 클릭해 해당 URL이 반환하는 HTTP 응답 헤더를 가져오세요.
- 3
응답 검토
상태 코드, 응답 시간, 전체 헤더 수를 보여 주는 개요를 읽은 뒤, 헤더 이름과 값의 전체 목록을 살펴보세요.
- 4
모든 헤더 복사
"Copy All Headers"를 사용해 전체 헤더 목록을 클립보드로 보내 디버깅이나 문서화에 활용하세요.
프로처럼 HTTP 응답 헤더 읽기
HTTP 헤더란
브라우저가 웹 페이지를 요청할 때마다 실제 콘텐츠와 함께 두 묶음의 메타데이터가 오갑니다. 브라우저가 보내는 요청 헤더와 서버가 돌려보내는 응답 헤더입니다. 헤더는 Content-Type: text/html 처럼 단순한 이름과 값의 쌍으로, 눈에 보이는 페이지의 일부가 아니라 그 메시지를 설명합니다. 헤더는 캐싱, 보안, 콘텐츠 협상, 쿠키, 리디렉션 등 많은 것을 제어합니다. 페이지 본문은 보이는 것이고, 헤더는 브라우저에게 그것을 어떻게 다룰지 알려 주는 지시입니다.
이 도구는 서버가 어떤 URL에 대해 돌려보내는 응답 헤더를 상태 코드 및 응답에 걸린 시간과 함께 보여 줍니다. 헤더를 읽는 것은 사이트가 어떻게 구성되어 있는지 이해하는 가장 빠른 방법 중 하나입니다. 페이지에서는 보이지 않는 많은 동작이 헤더에 명시적으로 적혀 있기 때문이죠.
상태 코드: 가장 먼저 읽을 것
어떤 헤더보다 앞서, 상태 코드가 무슨 일이 일어났는지 알려 줍니다. 200번대는 성공을 뜻하며 200 OK가 일반적인 경우입니다. 300번대는 리디렉션을 뜻합니다. 301은 영구 이동이고 302나 307은 임시이며, 각각 새 URL을 가리키는 Location 헤더를 동반합니다. 400번대는 404 Not Found나 403 Forbidden처럼 클라이언트 측 문제를, 500번대는 500 Internal Server Error나 503 Service Unavailable처럼 서버 자체의 실패를 뜻합니다.
상태 코드는 나머지 모든 것의 틀을 잡습니다. 브라우저에서는 멀쩡해 보여도 크롤러에게 404나 소프트 오류를 반환하는 페이지는 색인되지 않으며, 간헐적으로 500을 반환하는 리소스는 조사할 가치가 있는 서버 문제를 알립니다. 렌더링된 페이지를 믿는 대신 원시 상태를 확인하면 브라우저가 슬쩍 덮어 버리는 문제를 잡아냅니다.
콘텐츠와 캐싱 헤더
Content-Type은 응답의 미디어 유형과 문자 집합을 선언합니다. 예를 들어 text/html; charset=utf-8 이나 application/json 입니다. 잘못된 Content-Type은 브라우저가 응답을 잘못 다루게 하는데, 가령 HTML 페이지를 표시하는 대신 내려받기로 제안하는 식이죠. Content-Encoding은 gzip이나 br(Brotli) 같은 압축을 드러내, 텍스트 자산이 효율적으로 전송되고 있음을 확인해 줍니다. Content-Length는 바이트 단위 크기를 줍니다.
캐싱은 주로 Cache-Control이 좌우하며, max-age, public, private, no-store 같은 지시문으로 응답을 얼마나 오래, 어디에 캐시할 수 있는지 명시합니다. ETag와 Last-Modified는 조건부 요청을 지원해, 브라우저가 캐시된 사본이 여전히 유효한지 물어보고 바뀐 것이 없으면 가벼운 304 Not Modified를 받게 해 줍니다. 잘못 구성된 캐싱 헤더는 오래된 콘텐츠와 불필요하게 느린 재방문 둘 다의 주된 원인이므로, 면밀히 살필 가치가 있습니다.
확인할 가치가 있는 보안 헤더
한 무리의 응답 헤더가 흔한 공격에 맞서 사이트를 단단히 하며, 그 존재 여부가 빠른 건강 점검이 됩니다. Strict-Transport-Security(HSTS)는 브라우저가 이후 방문에 HTTPS를 쓰도록 강제해 다운그레이드 공격의 틈을 닫습니다. Content-Security-Policy(CSP)는 어떤 스크립트, 스타일, 그 밖의 리소스가 로드될 수 있는지 제한하는데, 이는 교차 사이트 스크립팅에 대한 가장 강력한 방어입니다. X-Frame-Options(또는 CSP의 frame-ancestors 지시문)는 페이지가 악성 iframe에 끼워 넣어지는 것을 막아 클릭재킹을 무력화합니다. X-Content-Type-Options: nosniff는 브라우저가 콘텐츠 유형을 추측하는 것을 막습니다.
사이트를 점검할 때 이런 헤더의 부재 자체가 정보가 됩니다. 민감한 콘텐츠를 제공하면서 HSTS도, CSP도, X-Frame-Options도 없는 사이트는 명백한 보안 강화 공백을 지닙니다. 헤더를 보면 보안 태세가 한눈에 드러나는데, 이는 자신의 사이트뿐 아니라 제삼자를 평가하는 데도 유용합니다.
쿠키, CORS, 그리고 서버 지문
Set-Cookie 헤더는 서버가 어떤 쿠키를 어떤 플래그와 함께 심는지 보여 줍니다. 쿠키의 Secure, HttpOnly, SameSite 속성은 그 쿠키가 HTTPS로만 전송되는지, JavaScript로부터 숨겨지는지, 교차 사이트 요청으로부터 보호되는지를 정하므로, 이를 읽으면 세션 쿠키가 안전하게 구성되었는지 드러납니다. CORS의 일부인 Access-Control-Allow-Origin 헤더는 어떤 리소스가 다른 도메인의 스크립트에서 요청될 수 있는지, 그리고 어디서부터 가능한지 알려 주는데, 이는 프런트엔드 요청이 왜 차단되는지 디버깅할 때 필수적입니다.
다른 헤더들은 기술 스택의 지문을 남깁니다. Server는 웹 서버 소프트웨어의 이름을, X-Powered-By는 애플리케이션 프레임워크를 드러낼 수 있고, Via나 CF-Cache-Status는 오리진 앞에 자리한 Cloudflare 같은 CDN을 노출할 수 있습니다. 많은 운영자가 정보 누출을 줄이려고 이런 헤더를 제거하므로, 무엇이 있는지와 무엇이 눈에 띄게 없는지가 모두 이야기를 들려줍니다.
헤더 검사가 SEO와 디버깅에 중요한 이유
몇몇 헤더는 검색에 직접 영향을 줍니다. X-Robots-Tag 헤더는 noindex와 nofollow처럼 robots 메타 태그와 같은 지시문을 담지만 HTTP 수준에서 적용되며, 그래서 PDF 같은 비HTML 파일의 색인을 제어하는 유일한 방법입니다. 운영 환경에 잘못 남겨진 X-Robots-Tag: noindex 하나가 소리 없이 페이지를 색인에서 빼 버릴 수 있는데, 페이지 자체에서는 보이지 않으므로 원시 헤더를 보는 것이 그것을 찾는 유일한 방법인 경우가 많습니다. Link 헤더도 서버 측에서 정규 관계를 선언할 수 있습니다.
일상적인 디버깅에서 헤더는 명백한 진실입니다. HTTPS가 강제되는지, 압축과 캐싱이 실제로 켜져 있는지, 리디렉션이 의도한 301인지 아니면 302인지, 서버가 기대한 상태 코드를 반환하는지를 헤더가 확인해 줍니다. 브라우저는 스크립트가 교차 출처 헤더를 읽는 것을 차단하므로, 이 도구는 그러한 제약 없이 어떤 공개 페이지의 응답 헤더든 검사할 수 있도록 URL을 서버 프록시를 통해 가져옵니다.
자주 묻는 질문
이 도구는 어떤 HTTP 헤더를 보여 주나요?
HTTP 헤더가 SEO와 디버깅에 왜 유용한가요?
왜 URL에 https:// 를 포함해야 하나요?
왜 가져오기가 오류를 반환할 수 있나요?
이 도구는 무료이고 URL이 비공개로 처리되나요?
관련 도구
이런 편리한 도구도 함께 사용해 보세요