리다이렉트 확인 (리디렉션 체인 추적)
URL 만 서버로 전송됩니다. 입력한 URL 은 진단을 위해 microlab scan-api 로 전송됩니다. 대상 페이지가 돌려준 내용의 분석은 브라우저 안에서 하며, URL 외에는 아무것도 서버로 가지 않습니다. 익명 방문 통계만 집계합니다.
사용법
- 확인할 주소를 입력합니다. http→https 전환까지 보려면 http:// 를 붙여서 넣습니다 — 도메인만 쓰면 https:// 로 시작하는 주소로 검사합니다.
- "검사"를 누르면 사람 확인(대부분 저절로 끝납니다)을 거쳐 microlab scan-api 가 그 주소부터 리다이렉트를 최대 5번까지 따라갑니다.
- "체인"에서 주소마다 받은 상태 코드와, 다음 주소로 넘어가며 무엇이 바뀌었는지(http→https, www 붙임, 끝의 / 정리, 다른 도메인 등)를 확인합니다.
- "짚어 볼 것"에서 루프, 끝까지 따라가지 못한 체인, 최종 오류(4xx·5xx), https 에서 http 로 내려가는 이동, 임시 리다이렉트(302·307), 홉 수를 확인합니다. 임시 리다이렉트 항목은 판정이 아니라 의도를 묻는 질문입니다.
- www 있는 주소와 없는 주소, http 와 https 주소를 각각 넣어 네 입구가 모두 같은 최종 주소로 모이는지 보면 주소 정리 설정을 한 번에 점검할 수 있습니다.
자주 묻는 질문
301 과 302 는 무엇이 다른가요? 그냥 이동만 되면 같은 것 아닌가요?
방문자 눈에는 똑같이 이동하지만 뜻이 다릅니다. 301·308 은 "주소가 영구히 옮겨졌다", 302·307 은 "지금만 다른 곳에 있다"는 뜻입니다(RFC 9110 §15.4). Google 은 영구 리다이렉트(301·308)는 이동한 주소를 대표 주소로 삼으라는 신호로 쓰지만, 임시 리다이렉트(302·303·307)는 그런 신호로 쓰지 않는다고 안내합니다(Google 검색 센터 "리디렉션 및 Google 검색"). 307·308 은 POST 같은 요청 방식을 바꾸지 않고 그대로 옮기라는 점이 301·302 와 다릅니다. 반대로 301 은 브라우저가 따로 지시가 없어도 캐시할 수 있어서(RFC 9110 §15.4.2), 잘못 건 301 은 고친 뒤에도 이미 방문한 사람의 브라우저에 한동안 남을 수 있습니다. 그래서 이 도구는 302·307 을 틀렸다고 단정하지 않고 "영구 이동인가요?"라고 묻습니다.
브라우저에서 열어 본 것과 결과가 다르게 나와요. 왜 그런가요?
이 검사는 브라우저와 다른 조건으로 요청하기 때문입니다. 쿠키를 보내지 않고, 이동 사이에 받은 쿠키도 다시 보내지 않으며, 요청은 Cloudflare 데이터센터에서 microlab-scan 이라는 이름으로 나갑니다. 그래서 접속 국가·언어·로그인 여부에 따라 다른 곳으로 보내는 사이트는 결과가 달라지고, 봇을 막는 사이트는 403·429 로 답할 수 있습니다. 또 브라우저는 HSTS 로 기억해 둔 사이트의 http 주소를 요청을 보내기 전에 스스로 https 로 바꾸는데(개발자 도구에 "307 Internal Redirect"로 보입니다), 이 도구는 서버가 실제로 보낸 응답만 보여 줍니다. 같은 주소를 10분 안에 다시 검사하면 검사 서버에 저장된 결과가 나올 수 있습니다.
meta refresh 나 자바스크립트로 이동하는 페이지도 확인되나요?
아니요. 이 도구가 따라가는 것은 서버가 3xx 상태 코드와 Location 헤더로 보낸 HTTP 리다이렉트(301·302·303·307·308)뿐입니다. HTML 의 <meta http-equiv="refresh">, 자바스크립트의 location 변경, Refresh 응답 헤더는 따라가지 않습니다(Refresh 헤더가 있으면 그 사실은 알려 줍니다). 그런 페이지는 체인이 200 에서 끝난 것으로 나오므로, 다음 주소는 직접 넣어 따로 검사해야 합니다. 참고로 Google 은 즉시(0초) meta refresh 를 영구 리다이렉트로 해석하지만, 자바스크립트 리다이렉트는 렌더링이 실패하면 보지 못할 수 있다고 안내합니다.
몇 번까지 따라가나요? "끝까지 따라가지 못함"은 무슨 뜻인가요?
최대 5번까지 따라갑니다. 5번째 이동 뒤에도 또 리다이렉트가 오면 더 요청하지 않고 멈추며, 그 응답이 가리키는 다음 주소(Location)를 보여 줍니다. 이 경우 최종 목적지와 그 응답은 확인하지 못한 것이므로, 표시된 다음 주소를 넣어 이어서 검사할 수 있습니다. 참고로 브라우저는 20번까지(WHATWG Fetch §4.5), Google 크롤러는 기본 10번까지 따라가지만, 이동마다 요청 왕복이 한 번씩 더 붙으므로 실제로는 한두 번 안에 끝나는 것이 좋습니다. 또 이어진 주소가 사설·내부 대역이거나 80·443 이 아닌 포트처럼 검사 서버가 요청하지 않는 곳이면 거기서 멈추는데, 이때는 그때까지 지나온 체인을 보여 주지 못하고 멈춘 이유만 알려 줍니다 — 검사 서버가 중간까지의 결과를 돌려주지 않기 때문입니다.
리다이렉트 루프는 왜 생기나요?
두 규칙이 서로를 되돌리는 경우가 대부분입니다. 예를 들어 CDN 은 원서버에 http 로 접속하는데 원서버는 http 요청을 https 로 보내면(Cloudflare 의 Flexible SSL 에서 흔한 구성), 서로 끝없이 주고받게 됩니다. www 를 붙이는 규칙과 떼는 규칙이 두 곳에 따로 있을 때, 끝의 / 를 붙이는 규칙과 떼는 규칙이 부딪힐 때도 같은 일이 생깁니다. 브라우저에서는 "리디렉션한 횟수가 너무 많습니다" 오류로 보입니다. 다만 첫 방문에 쿠키를 심고 같은 주소로 되돌려 보내는 사이트는 쿠키를 보내지 않는 이 검사에서만 루프로 보일 수 있습니다.
"다른 도메인으로 넘어갑니다"는 문제인가요? 판정은 정확한가요?
문제라는 뜻이 아닙니다. 단축 주소(bit.ly 등), 로그인(SSO), 광고·추적 링크는 원래 다른 도메인으로 보냅니다. 최종 도메인이 의도한 곳인지 확인해 보라는 안내입니다. 도메인 비교는 co.kr·go.kr·co.uk·github.io 처럼 흔한 다단계 접미사를 내장 목록으로 처리하는 근사 판정이라, 목록에 없는 접미사에서는 서로 다른 사이트를 같은 도메인으로 볼 수 있습니다.
입력한 주소는 어디로 가나요?
주소는 진단을 위해 microlab scan-api 로 전송되고, scan-api 가 그 주소와 이어지는 리다이렉트 주소에 요청을 한 번씩 보냅니다. 사설·내부 대역을 가리키는 주소와 80·443 이외의 포트는 거부하며, 이동할 때마다 같은 검사를 다시 합니다. 결과의 해석은 이 브라우저 안에서 합니다.