본문으로 건너뛰기

HTTP 헤더 확인

HTTP Header Inspector

URL을 요청해 전체 응답 헤더·리다이렉트 경로·소요 시간·사용된 압축 방식을 보여 줍니다.

URL에 요청을 한 번 보내고 돌아온 응답 헤더를 전부 보여 줍니다. 용도별로 묶고, Cache-Control은 지시어 단위로 쪼개 뜻을 붙였습니다. 브라우저가 화면을 그리기 전에 보는 것이 이것이고, 캐시와 압축 문제는 대개 여기에 있습니다.

☁️ 서버를 사용httpheadersinspectdebug

이 도구는 우리 서버가 대신 요청합니다. 입력한 URL만 서버로 전송되고, 브라우저의 쿠키나 로그인 정보는 함께 가지 않습니다. 서버는 공인 주소에만 접속하며 사설망·내부 주소로의 요청은 거부합니다.

리다이렉트는 최대 5번 따라가고, 마지막 응답의 헤더를 보여 줍니다.

사용 방법

  1. 실제로 볼 주소를 넣습니다

    리다이렉트는 5번까지 따라가고, 보여 주는 헤더는 마지막 응답의 것입니다. 리다이렉트 자체가 궁금하다면 위쪽에 각 홉의 상태와 함께 경로가 그려집니다.

  2. 표보다 지적 사항을 먼저 봅니다

    지적 사항은 저마다 특정 헤더에서 나옵니다. Cache-Control이 없다거나, max-age에 밀려 무시되는 Expires가 있다거나, charset 없는 HTML이라거나. 지적 사항이 결론이고 표는 근거입니다.

  3. 압축 항목을 확인합니다

    요청은 gzip, deflate, br 및 zstd를 받겠다고 알리고, 돌아온 값이 서버가 고른 것입니다. Content-Encoding이 없는 텍스트 응답은 대개 필요한 용량보다 70% 이상 큽니다.

자주 묻는 질문

내 로그인이나 쿠키가 함께 가나요?

가지 않습니다. 요청은 우리 서버가 보내므로 브라우저의 쿠키도 세션도 실리지 않습니다. 그래서 로그인해야 보이는 페이지는 여러분이 보는 화면이 아니라 로그인 페이지가 돌아옵니다.

사내망 주소도 확인할 수 있나요?

안 되고, 일부러 그렇게 했습니다. 서버는 요청 전에 호스트를 먼저 해석해 사설·루프백·링크로컬 주소를 거부합니다. 공개 도메인이 그런 주소로 풀리는 경우도 마찬가지입니다. 이 규칙이 없으면 이 페이지는 남의 내부망을 우리 서버로 훑는 도구가 됩니다.

개발자 도구와 헤더가 다릅니다

그럴 수 있습니다. CDN은 지역, Accept-Encoding, Vary, 해당 엣지의 캐시 유무에 따라 답을 달리합니다. 여기는 한 곳에서 보낸 요청 하나이고, 브라우저의 요청은 다른 요청입니다.

Content-Length가 왜 없나요?

거의 언제나 청크 전송 때문입니다. 서버가 크기를 알기 전에 보내기 시작한 것입니다. 동적 페이지에서는 정상이며, 그런 응답을 내려받을 때 진행률이 안 보이는 이유이기도 합니다.

이 도구로 이어지는 것

다음 단계

이 도구의 결과를 그대로 받을 수 있는 도구들입니다.