리디렉션 체인 뷰어

모든 URL에 대한 전체 리디렉션 체인을 추적하고 최종 목적지까지의 모든 홉(301/302/307/308)을 확인하세요. 표준 리디렉션(HTTP→HTTPS, www/비-www, 로케일 경로)을 검증하고, 루프 및 긴 체인을 발견하며, 선택적으로 Location을 포함한 원시 헤더를 검사할 수 있습니다. 감사 및 모니터링을 위해 결과를 JSON으로 내보내세요.

Loading…

소개 리디렉션 체인 뷰어

URL을 입력하여 리디렉션을 홉별로 따라가고 실제 종착지를 확인하세요. 이 도구는 SEO 마이그레이션, 리디렉션 규칙 디버깅(Nginx/CDN/앱), 표준 호스트/HTTPS 동작 확인, 사용자와 크롤러를 느리게 하는 리디렉션 루프 또는 불필요한 추가 홉 발견에 이상적입니다.

기능

  • 리디렉션 체인(301/302/307/308)을 추적하고 최종 목적지 URL을 표시합니다.
  • 각 홉의 Location 대상을 표시하여 라우팅 및 표준화를 이해합니다.
  • 일반적인 표준 리디렉션(HTTP→HTTPS, www↔비-www)을 검증합니다.
  • 더 깊은 디버깅을 위한 선택적 원시 헤더 보기(Location 및 캐싱 헤더 포함, 있는 경우).
  • 티켓, 감사 및 마이그레이션 실행 문서용 결과를 복사합니다.
  • 자동화 및 반복 가능한 SEO 검사를 위해 JSON 보고서를 내보냅니다.
  • 기본적으로 안전: 사설 네트워크 대상을 차단하고 고정 User-Agent를 사용합니다.

🧭 사용 방법 for redirect-chain-viewer

1

테스트할 URL 붙여넣기

시작 URL을 입력하세요(가능하면 프로토콜 포함). http://와 https://를 모두 테스트하면 표준화 문제를 발견할 수 있습니다.

2

"리디렉션 따르기" 활성화 유지

이 도구는 체인을 추적하도록 설계되었습니다. 리디렉션을 따르면 모든 홉과 최종 목적지가 표시됩니다.

3

디버깅 시 "원시 헤더 표시" 활성화

더 깊은 단서(Location 형식, 캐싱 계층, 서버 동작)가 필요한 경우, 원시 헤더를 활성화하여 더 많은 세부 정보를 확인하세요.

4

체인 해석

추가 홉, 프로토콜 전환, 호스트명 전환 또는 로케일 재작성을 찾으세요. 최상의 체인은 일반적으로 표준 URL까지 0~1홉입니다.

5

감사를 위해 JSON 내보내기

JSON 보고서를 다운로드하여 결과를 저장하고, 시간에 따른 변경 사항을 비교하거나, SEO/운영 티켓에 증거를 첨부하세요.

기술 사양

리디렉션 추적 동작

이 도구는 URL을 요청하고 리디렉션 응답을 따라가며, 최종 목적지 또는 구성된 리디렉션 제한에 도달할 때까지 각 홉을 수집합니다.

설정동작기본값
리디렉션 따르기전체 체인을 수집하기 위해 리디렉션을 따릅니다활성화됨
최대 리디렉션 횟수지정된 홉 수 이후 추적을 중지합니다15
원시 헤더 표시디버깅을 위해 출력에 원시 응답 헤더를 포함합니다비활성화됨
타임아웃요청 타임아웃 제한15000 ms
사용자 에이전트요청 사용자 에이전트를 식별합니다Encode64Bot/1.0 (+https://encode64.com)
사설 네트워크안전을 위해 사설 네트워크 범위 접근을 차단합니다비활성화됨 (사설 네트워크 허용 안 됨)

일반적인 "좋은" 리디렉션 패턴

대부분의 사이트는 지연 시간과 크롤러 오버헤드를 최소화하기 위해 신속하게 하나의 표준 URL로 수렴해야 합니다.

목표예시 체인권장 사항
HTTP→HTTPShttp://example.com → https://example.com✅ 예 (영구적)
표준 호스트https://example.com → https://www.example.com (또는 반대)✅ 예 (영구적)
끝 슬래시 정규화/page → /page/✅ 경우에 따라 (일관성 유지)
로케일 정규화/ → /en/✅ 전략상 필요한 경우
다중 홉http → https → www → /en/ → /page/⚠️ 가능하면 줄이기
SEO 마이그레이션의 경우, 영구 리디렉션은 일반적으로 301 또는 308입니다. 리디렉션 체인을 가능한 한 짧게 유지하고, 내부 링크와 사이트맵을 최종 표준 URL로 직접 가리키도록 업데이트하세요.

루프 감지 및 실패 모드

리디렉션 루프는 일반적으로 계층 간 충돌하는 규칙(CDN + Nginx + 앱) 또는 일치하지 않는 표준화 설정에서 발생합니다.

증상일반적인 원인해결 방법
리디렉션 한도 도달두 URL 간 루프(www↔비-www, http↔https, 슬래시 규칙)CDN, 리버스 프록시, 앱 라우터의 규칙 검토; 단일 진실 공급원 보장
예상치 못한 302/307인증, A/B 테스트, 미들웨어에 의해 설정된 임시 리디렉션영구 이동 시 301/308로 전환; 미들웨어 동작 분리
지역별 체인 차이에지 라우팅이 POP/지리적 위치/장치에 따라 다름여러 진입 URL 테스트; 에지에서 리디렉션 표준화

명령줄

이 도구가 시각화하는 것과 유사하게 터미널에서 curl을 사용하여 리디렉션 체인을 빠르게 검사하세요.

macOS / Linux

리디렉션 체인 헤더 표시

curl -IL http://example.com

-I는 헤더만 출력하고, -L은 리디렉션을 따릅니다. 각 HTTP 상태와 Location 이동을 볼 수 있습니다.

리디렉션 후 최종 유효 URL 출력

curl -Ls -o /dev/null -w "%{url_effective}
" http://example.com

리디렉션을 따른 후 최종 URL을 출력합니다.

Windows (PowerShell)

응답 및 리디렉션 검사

Invoke-WebRequest -Uri http://example.com -MaximumRedirection 10 -Method Get | Select-Object StatusCode, BaseResponse

PowerShell은 제한까지 리디렉션을 따라가고 결과 상태를 표시할 수 있습니다.

루프를 디버깅하는 경우, 리디렉션 한도를 일시적으로 낮추어(예: 3–5) 빠르게 실패하고 충돌하는 규칙 쌍을 식별하세요.

사용 사례

SEO 표준화 검사

모든 진입 URL이 하나의 표준 URL로 빠르고 일관되게 해결되는지 확인하세요.

  • HTTP가 HTTPS로 리디렉션되는지 확인
  • www/비-www 표준 선택이 적용되는지 확인
  • 크롤링 효율성을 향상시키기 위해 다중 홉 체인 줄이기

사이트 마이그레이션 및 도메인 변경

이전 URL이 새로운 동등한 URL로 올바르게 리디렉션되고 체인이 200 응답으로 끝나는지 검증하세요.

  • 이전 슬러그가 새로운 슬러그로 리디렉션되는지 확인
  • 이동된 콘텐츠에 대해 영구 리디렉션(301/308) 확인
  • 리디렉션-대-404 상황 포착

CDN / 리버스 프록시 디버깅

URL이 요청될 때 엣지 규칙, 프록시, 애플리케이션이 어떻게 상호작용하는지 이해합니다.

  • 각 홉을 생성하는 레이어 식별
  • 중복 정규화 규칙으로 인한 루프 감지

지역화 라우팅 QA

긴 리디렉션 체인이나 루프를 실수로 생성하지 않고 로케일 또는 지역 라우팅(예: / → /en/)을 검증합니다.

  • 로케일 재작성 동작 확인
  • /fr → /fr/ → /fr (루프) 패턴 방지

❓ Frequently Asked Questions

❓리디렉션 체인이 SEO에 나쁜 이유는 무엇인가요?

리디렉션 체인은 크롤러에 지연 시간을 추가하고 실패 지점을 증가시킵니다. 검색 엔진은 리디렉션을 따라갈 수 있지만, 긴 체인은 크롤링 예산을 낭비하고 특히 대규모 사이트에서 신뢰성을 감소시킬 수 있습니다.

❓301과 308 중 무엇을 사용해야 하나요?

둘 다 영구 리디렉션입니다. 308은 HTTP 메서드를 더 엄격하게 보존하는 반면, 301은 널리 사용되고 이해됩니다. SEO 측면에서는 영구 이동에 일관되게 사용된다면 둘 다 괜찮을 수 있습니다.

❓301을 기대했는데 302/307이 보이는 이유는 무엇인가요?

임시 리디렉션은 미들웨어, 인증 흐름, A/B 테스트 또는 잘못 구성된 엣지 규칙에서 자주 발생합니다. 이동이 영구적이라면 301/308로 전환하고 내부 링크를 최종 URL로 업데이트하세요.

❓리디렉션 루프의 원인을 어떻게 찾나요?

루프는 일반적으로 충돌하는 규칙(예: CDN이 www를 강제하고, 앱이 non-www를 강제함; 프록시가 HTTPS를 강제하고, 앱이 HTTP를 강제함)에서 발생합니다. 한 번에 한 레이어씩 감사하고 가능하면 정규화 로직을 단일 위치에 유지하세요.

❓후행 슬래시를 리디렉션해야 하나요?

어느 전략도 작동할 수 있지만 일관성을 유지하세요. 하나의 정규 형식을 선택하고 내부 링크와 사이트맵이 이를 직접 사용하도록 하여 리디렉션을 줄이세요.

❓여기에 URL을 붙여넣는 것이 안전한가요?

이 도구는 제공된 URL에 대해 서버 측 요청을 수행하며 사설 네트워크 대상을 차단합니다. URL에 비밀 정보(쿼리 문자열의 토큰)를 포함하지 마세요.

Pro Tips

Best Practice

정규 URL에 도달하기 위해 0~1회의 리디렉션을 목표로 하세요. 내부 링크와 사이트맵을 최종 목적지로 직접 가리키도록 업데이트하세요.

Best Practice

충돌하는 리디렉션과 루프를 피하기 위해 정규화 규칙을 하나의 레이어(CDN 또는 프록시 또는 앱)에 유지하세요.

Best Practice

영구 이동의 경우 301/308을 사용하고 리디렉션이 진정으로 임시적인 경우가 아니면 302/307을 피하세요.

CI Tip

정규 동작을 테스트할 때 프로토콜과 호스트 변형(http/https + www/non-www)을 모두 확인하고 결과를 비교하세요.

CI Tip

마이그레이션 중에 JSON 결과를 내보내서 회귀를 추적하고 이해관계자에게 리디렉션 정확성을 증명하세요.

Additional Resources

HTTP 리디렉션 (MDN)
Documentation
HTTP 응답 상태 코드 (MDN)
Documentation
Google Search Central: URL 리디렉션 및 상태 코드
Documentation

Other Tools

리디렉션 체인 뷰어 — 301/302 리디렉션을 추적하여 최종 URL 확인 | Encode64