HTTP 헤더 조회

HTTP 헤더 조회는 일반적인 GET 요청을 보냈을 때 URL이 반환하는 모든 HTTP 응답 헤더를 가져오는 무료 도구입니다.

HTTP 응답 헤더란 무엇인가요?

HTTP 응답 헤더는 웹 서버가 HTML 페이지, 이미지, JSON 문서 같은 응답 본문보다 먼저 보내는 메타데이터입니다. 클라이언트가 응답을 해석하고 캐시하거나, 리디렉션 및 보안 처리를 하는 데 필요한 정보를 제공합니다.

HTTP/1.x 응답은 일반적으로 HTTP 상태 줄로 시작하고 그 뒤에 헤더가 이어집니다. HTTP/2와 HTTP/3에서는 이에 해당하는 상태가 :status 의사 헤더에 담깁니다. 엄밀히 말하면 HTTP/1.x 상태 줄은 헤더와 별개지만, 요청 성공 여부를 알려 주기 때문에 보통 헤더와 함께 표시됩니다. 200은 리소스가 반환되었다는 뜻이고, 301 또는 302는 리디렉션, 404는 리소스를 찾지 못했다는 뜻입니다. 500은 서버 측 오류를 나타냅니다.

헤더는 원본 서버, 리버스 프록시 또는 Cloudflare 같은 콘텐츠 전송 네트워크에서 생성될 수 있습니다. 응답이 이러한 시스템을 거치는 동안 일부 헤더가 추가되거나 삭제되므로, 결과에는 페이지를 생성한 애플리케이션 이외의 시스템 정보도 포함될 수 있습니다.

HTTP 헤더는 어떻게 조회하나요?

https://www.example.com/account처럼 스킴을 포함한 전체 URL을 입력하세요. 도구가 서버에서 일반적인 GET 요청을 보내고 해당 URL로부터 받은 HTTP 헤더를 반환합니다.

응답 헤더를 정확히 비교하려면 조사하려는 URL 형식을 그대로 입력하세요. http://example.com, https://example.com, https://www.example.com은 각각 리디렉션, 캐시 규칙, 서버 설정이 다를 수 있으므로 서로 다른 헤더를 반환할 수 있습니다.

URL 구문도 요청에 영향을 줍니다.

• 공백은 URL에 그대로 사용할 수 없는 문자이므로 일반적으로 퍼센트 인코딩해야 합니다. 경로에서는 보통 %20으로 인코딩합니다.
• ?는 쿼리 구성 요소의 시작을 나타냅니다. &와 =는 폼 형식의 쿼리 인코딩에서 흔히 사용되지만, 모든 쿼리 문자열에서 같은 역할을 하는 것은 아닙니다.
• 악센트가 있는 문자나 비라틴 문자가 포함된 도메인 이름은 IDNA로 처리되며, 일반적으로 xn--으로 시작하는 ASCII A-label로 표현됩니다. 경로 문자는 대체로 UTF-8 바이트로 인코딩한 다음 퍼센트 인코딩합니다.
• #으로 시작하는 프래그먼트는 브라우저에서 처리되며 HTTP 요청에는 전송되지 않습니다.
• 모든 환경에 공통으로 적용되는 URL 최대 길이는 없습니다. URL이 지나치게 길면 서버, 프록시 또는 애플리케이션에서 거부할 수 있습니다.

HTTP 헤더 결과는 어떻게 확인하나요?

조사 중인 문제와 관련된 헤더를 확인하세요. 헤더 이름은 대소문자를 구분하지 않지만, 헤더 값의 구문은 대소문자를 구분할 수 있습니다.

그 밖에 애플리케이션별 헤더도 있을 수 있습니다. 예를 들어 Access-Control-Allow-Origin은 브라우저의 교차 출처 요청을 통해 응답을 읽을 수 있는 출처를 제어합니다. Server 헤더에는 소프트웨어나 프록시 이름이 표시될 수 있지만, 관리자가 변경하거나 삭제할 수 있으므로 실제 기반 플랫폼을 확실히 증명하지는 않습니다.

실무에서 문제를 진단하는 방법

리디렉션 문제는 헤더를 확인하는 대표적인 이유입니다. 예를 들어 https://example.com/old-page가 301 상태와 함께 Location: https://example.com/new-page를 반환한다고 가정해 보겠습니다. 이는 서버가 클라이언트에 새 주소를 요청하라고 지시한다는 뜻입니다. 각 대상 주소를 차례로 확인하면 리디렉션 반복이나 HTTP와 HTTPS 사이의 예상치 못한 전환을 찾을 수 있습니다.

Cloudflare나 다른 CDN 뒤에 있는 페이지가 이전 콘텐츠를 표시한다면 Cache-Control, Age, ETag 및 제공업체별 캐시 헤더를 확인하세요. Age 값이 크면 상위 캐시에 머문 시간을 포함해 계산한 캐시 응답의 경과 시간이 길다는 뜻이지, 특정 중간 서버가 응답을 보관한 기간을 뜻하지는 않습니다. 또한 모든 지역 캐시에 같은 버전이 저장되어 있다는 증거도 아닙니다.

API가 서버 측 스크립트에서는 작동하지만 브라우저에서는 실패한다면 Content-Type과 Access-Control-Allow-Origin을 비롯한 CORS 응답 헤더를 살펴보세요. JSON 엔드포인트가 text/html을 반환한다면 실제로는 오류 페이지나 로그인 화면을 제공하는 것일 수 있습니다. 서버가 200 상태를 반환했더라도 교차 출처 권한이 없으면 브라우저에서 접근을 차단할 수 있습니다.

사이트에 접속할 수 없는 것처럼 보일 때도 헤더가 도움이 됩니다. 503 응답은 일시적인 서버 또는 상위 시스템 장애일 가능성을 나타내며, 404는 요청한 경로를 찾지 못했다는 뜻입니다. 하지만 헤더만으로 모든 장애를 진단할 수는 없습니다. HTTP 응답이 생성되기 전에 DNS 확인, TCP 연결 또는 TLS 협상에 실패하면 확인할 응답 헤더가 없을 수 있습니다. 핑으로 연결 상태를 별도로 점검하고, HTTP/2 검사기로 프로토콜 지원 여부를 확인할 수 있습니다.

헤더 결과가 정확한데도 잘못된 것처럼 보이는 이유는 무엇인가요?

캐시, DNS 레코드, 요청 환경에 따라 두 요청이 서로 다른 응답으로 연결될 수 있으므로, 정확한 결과라도 브라우저에서 본 내용과 다를 수 있습니다. 이 조회는 서버에서 실행되기 때문에 다른 CDN 노드에 연결되거나, 최근 변경된 DNS 레코드를 사용자의 로컬 네트워크보다 먼저 또는 나중에 확인할 수 있습니다.

브라우저는 자체 쿠키, 허용하는 콘텐츠 유형, 언어, 캐시 검증자도 전송합니다. 따라서 로그인한 WordPress 페이지는 익명의 서버 요청과 다른 캐시 규칙을 반환할 수 있습니다. 지역별 라우팅과 봇 관리 시스템도 요청이 시작된 네트워크나 요청 헤더에 따라 응답을 다르게 제공할 수 있습니다.

DNS를 변경한 뒤에도 캐시된 리졸버는 TTL이 만료될 때까지 이전 레코드를 계속 사용할 수 있습니다. 트래픽이 새 서버에 도달한 후에도 기존 CDN 객체나 브라우저 캐시가 예전 콘텐츠를 반환할 수 있습니다. 확인된 호스트를 별도로 점검하고, 필요한 경우 캐시를 비운 다음, 모든 호스트 이름이 같은 설정을 사용한다고 가정하지 말고 정확한 URL을 비교하세요.

자주 묻는 질문

요청 헤더도 조회할 수 있나요?

아니요. 이 도구는 일반적인 GET 요청을 보냈을 때 URL이 반환하는 응답 헤더를 가져옵니다. 요청 헤더는 서버로 전송되는 메타데이터이며, 전체 내용을 확인하려면 별도의 브라우저 개발자 도구, 서버 로그 또는 명령줄 클라이언트가 필요합니다.

입력한 URL은 비공개로 처리되나요?

조회는 서버에서 수행됩니다. 입력한 내용은 HTTPS를 통해 해당 서버로 전송되며 저장되지 않습니다. 요청 시 대상 서버도 URL에 포함된 값을 받으므로 비밀번호, 액세스 토큰 또는 민감한 쿼리 매개변수가 들어 있는 URL은 입력하지 마세요.

HTTP 헤더로 인증서 경고의 원인을 알 수 있나요?

일반적으로 HTTP 헤더만으로는 알 수 없습니다. TLS 연결은 HTTP 응답을 보내기 전에 설정되므로 인증서 만료, 호스트 이름 불일치 또는 신뢰할 수 없는 발급자 문제로 인해 헤더가 전혀 반환되지 않을 수 있습니다. 페이지가 로드되기 전에 브라우저 경고가 나타난다면 인증서와 인증서 체인을 별도로 확인하세요.

Set-Cookie 헤더가 여러 개 반환되는 이유는 무엇인가요?

하나의 응답에서 여러 쿠키를 설정할 수 있으며, 각 쿠키는 자체 Set-Cookie 필드를 사용합니다. 쿠키 만료 날짜 자체에 쉼표가 포함될 수 있으므로 쉼표로 구분된 하나의 목록처럼 합치지 마세요. 각 쿠키의 도메인, 경로, 보안 속성을 따로 확인해야 합니다.

curl 결과와 비교할 수 있나요?

네. curl -D - https://example.com/ -o /dev/null 같은 명령은 응답 본문을 버리고 응답 헤더만 출력합니다. Curl 버전, 요청 헤더, 리디렉션 설정, 네트워크 위치에 따라 결과가 달라질 수 있으므로, 차이를 서버 문제로 판단하기 전에 이러한 조건을 동일하게 맞추세요.