리다이렉트 루프를 찾아 수정하는 방법

리다이렉트 루프는 요청이 이미 방문한 URL로 되돌아가는 상태입니다. 브라우저는 제한에 도달할 때까지 이동한 후 ERR_TOO_MANY_REDIRECTS를 표시합니다. 원인은 CDN, 프록시, 웹 서버와 애플리케이션 규칙 사이에 걸쳐 있을 수 있습니다.

가장 작은 반복 주기 찾기

오류가 난 정확한 주소를 URL Redirect Checker에 입력하고 반복되는 URL을 찾습니다.

https://example.com/page
→ https://www.example.com/page
→ https://example.com/page

각 단계의 상태, 프로토콜, 호스트, 경로, 쿼리와 이동 유형을 기록합니다. 두 URL이 번갈아 나타나면 서로 반대 방향을 강제하는 두 규칙이 있을 가능성이 큽니다.

흔한 원인

HTTP와 HTTPS 불일치

사용자는 HTTPS로 CDN에 연결하지만 CDN은 HTTP로 원본에 접근할 수 있습니다. 애플리케이션이 직접 연결만 보면 매번 HTTPS로 이동시킵니다. 신뢰할 수 있는 프록시에서 온 Forwarded 또는 X-Forwarded-Proto를 정확히 처리하세요.

www 정책 충돌

CDN이 www를 강제하고 애플리케이션이 non-www를 강제하면 루프가 생깁니다. 하나의 대표 호스트를 정하고 모든 레이어가 따르게 합니다.

후행 슬래시

한 프레임워크가 /docs를 /docs/로 만들고 다른 레이어가 슬래시를 제거할 수 있습니다. 정규화 책임을 한곳에 두고 내부 링크도 대표 형식을 사용합니다.

인증과 쿠키

쿠키 도메인, Secure, SameSite 또는 콜백 설정이 잘못되면 보호 페이지와 로그인 페이지가 서로 이동할 수 있습니다. 비공개 창은 상태 분리에 유용하지만 세션 로직 자체를 수정해야 합니다.

단계별 진단

1. 새 브라우저 세션과 서버 측 검사로 재현합니다.
2. 가장 작은 반복 주기를 찾습니다.
3. 응답 헤더와 로그로 각 리다이렉트의 소유 레이어를 확인합니다.
4. 스테이징에서 CDN, 서버와 앱 규칙을 하나씩 격리합니다.
5. 프로토콜, 호스트와 슬래시 정책의 단일 책임자를 정합니다.
6. 캐시를 비운 뒤 외부에서 다시 검사합니다.

영구 리다이렉트는 브라우저에 캐시될 수 있습니다. 서버를 수정한 후에도 기존 브라우저만 실패한다면 새 프로필 또는 온라인 검사로 실시간 상태를 구분하세요.

예방

• 대표 프로토콜, 호스트와 경로 정책을 문서화한다.
• 여러 레이어에서 반대 정규화를 하지 않는다.
• 신뢰할 프록시 범위를 명시한다.
• 프로덕션과 유사한 CDN 설정으로 출시 전 검사한다.
• 자기 목적지까지 다시 매치하는 광범위한 정규식을 피한다.