HTTP 상태 체인 검사기

URL을 입력하면 목적지에 도달하기까지의 모든 홉을 볼 수 있습니다: 각 리디렉션 상태, 각 대상, 최종 URL, 최종 응답의 보안 헤더까지 — sysosx의 서버에서 추적하므로, 이 체인은 브라우저가 이미 캐시한 것이 아니라 인터넷의 나머지가 보는 것입니다.

자동으로 계속 감시하고 싶으신가요? myeventwatch로 무료 감시 — 만료 및 중단 알림, 카드 불필요.

리디렉션 체인이란

리디렉션 체인은 브라우저나 크롤러가 요청한 페이지로 가는 길에 실제로 방문하는 주소들의 연속입니다. URL을 입력하면 서버는 “더 이상 여기 없습니다. 이쪽을 시도하세요”라고 답합니다. 클라이언트는 이를 따르고, 다음 서버도 같은 답을 할 수 있습니다. 각 단계가 하나의 홉이며, 각 홉은 어떤 종류의 이동인지를 말해주는 상태 코드를 지닙니다. 홉이 하나인 체인은 현대 웹의 정상적인 형태입니다: 일반 http가 https로 업그레이드되거나, 맨 apex 도메인이 www로 보내지는 경우입니다. 홉이 두세 개인 체인은 보통 두 개의 서로 다른 시스템이 각각 의견을 냈다는 뜻입니다 — CDN 규칙에 CMS 규칙이 더해지거나, 오래된 마이그레이션 규칙 위에 새 마이그레이션 규칙이 쌓인 경우입니다. 이 페이지가 보여주는 체인은 sysosx의 서버에서 홉 단위로 추적되며, 각 홉은 따르기 전에 안전성을 다시 확인하고, 최대 다섯 홉까지 추적합니다.

각 홉의 상태가 주의 깊게 읽을 가치가 있는 부분입니다. 301이나 308은 이동이 영구적이라고 말합니다: 옛 주소는 사라졌고, 검색 엔진은 그 순위를 새 주소에 넘겨야 합니다. 302나 307은 일시적이라고 말합니다: 옛 주소가 돌아올 수 있으므로 순위는 그대로 남고 캐시는 고정되어서는 안 됩니다. 303은 “답은 저쪽에 있습니다”라는 뜻으로, 주로 폼 제출 후에 보입니다. 실무상의 실패는 영구적이어야 했던 302(서둘러 작성한 마이그레이션 규칙)로, 조용히 순위를 새게 하고 이동이 끝난 지 한참 뒤에도 캐시가 옛 주소를 제공하게 만듭니다. 체인은 더 따분한 방식으로도 끊어집니다: 이전 주소로 되돌아가는 홉은 끝없이 반복되고, 다른 호스트로의 홉은 경로를 잃으며, https에서 http로 내려가는 홉은 첫 홉이 막 세운 보안을 무효화합니다.

결과 읽는 법

결과는 입력한 URL에서 시작해 홉을 순서대로 나열합니다. 홉 줄에는 요청된 주소, 반환된 상태, 그리고 리디렉션인 경우 그것이 가리킨 대상이 표시됩니다. 마지막 줄은 실제로 콘텐츠로 응답한 주소로, 그 상태, 서버 헤더(전송된 경우), 추적에 걸린 총 시간과 함께 표시됩니다. 그 아래에는 최종 응답의 보안 헤더가 요약됩니다: 어떤 보호 헤더가 있고 어떤 것이 없는지. 4xx나 5xx 상태로 끝나는 체인은 리디렉션 문제가 아니라 목적지 자체가 실패한 것입니다 — 체인은 그래도 그 실패에 어떻게 도달했는지를 알려주며, 수정은 대개 거기에 있습니다. “리디렉션이 너무 많음” 결과는 다섯 번째 홉이 여전히 앞을 가리켰다는 뜻입니다. 표시된 체인이 증거이며, 수정은 그것을 더 따르는 것이 아니라 짧게 만드는 것입니다.

관련 도구: 문제가 장소마다 다른 주소가 보이는 것이라면 DNS 전파 검사, 도달 가능성, 인증서, 만료, 레코드를 함께 보는 전체 그림이라면 웹사이트 상태 검사, 홉이 인증서 오류에 도착했을 때는 SSL 검사기를 사용하세요.

더 읽어보기: 사이트가 장소마다 다르게 보이는 이유 — 리디렉션 체인, DNS 전파, 중간 캐시, 그리고 무엇이 당신을 물고 있는지 구별하는 법.

자주 묻는 질문

이 검사는 브라우저에서 실행되나요, 서버에서 실행되나요?

서버에서 실행됩니다. 브라우저가 URL을 sysosx에 보내면, sysosx의 검사기가 자체 네트워크 위치에서 각 리디렉션을 홉 단위로 따라가며 가져옵니다. 그게 핵심입니다: 서버에서 추적한 체인은 검색 엔진과 방문자의 네트워크가 보는 것을 보여주지, 브라우저 캐시가 이미 아는 것을 보여주지 않습니다. 요청은 sysosx의 검사기에서 오며, 전송되는 것은 입력한 URL뿐입니다.

시작 스킴이 왜 중요한가요?

첫 홉이 가장 중요한 경우가 많기 때문입니다. http://로 입력된 URL은 http에서 추적이 시작되므로, https로의 업그레이드가 자체 홉으로 나타납니다 — 일반 HTTP가 정말 리디렉션하는지 감사할 때 정확히 원하는 것입니다. https://로 입력된 URL은 https에서 추적됩니다. 맨 호스트 이름은 기본적으로 https를 사용합니다.

서로 다른 리디렉션 상태는 무슨 뜻인가요?

301과 308은 영구적입니다: 옛 주소는 영원히 사라졌고, 검색 엔진은 순위를 새 주소로 이전해야 합니다. 302와 307은 일시적입니다: 옛 주소가 돌아올 수 있습니다. 303은 “저쪽을 보세요”라는 뜻입니다(보통 폼 제출 후). 사이트 마이그레이션에서는 거의 항상 301이나 308이 필요합니다. 영구적이어야 했던 302는 조용히 순위를 새게 하고 캐시를 혼란스럽게 합니다.

리디렉션이 몇 개면 너무 많은 건가요?

검사기는 최대 다섯 개까지 따라갑니다. 홉이 하나나 둘인 체인은 정상입니다(http에서 https로, apex에서 www로). 셋 이상은 보통 층이 쌓였다는 뜻입니다: CDN 규칙, CMS 규칙, 오래된 마이그레이션 규칙이 순서대로 발동합니다. 각 홉은 왕복 한 번과 약간의 순위 신호를 소모하며, 다섯 개를 넘는 체인은 영원히 따라가지 않고 너무 많다고 보고됩니다 — 그렇게 긴 체인 자체가 발견입니다.

왜 속도 제한이 있나요?

각 추적은 다른 사람의 서버에 홉 단위로 실제 요청을 보내기 때문입니다. 예의를 지키기 위해, 새 추적은 방문자당 제한되고(시간당 약 스무 번, 짧은 버스트 허용 포함) 결과는 한 시간 동안 캐시됩니다. 캐시된 결과에는 그 표시가 붙습니다. API 호출에 ?fresh=1을 추가하면 같은 제한 하에 다시 검사할 수 있습니다.