ERR_TOO_MANY_REDIRECTS

이 오류의 의미와 확인 방법

• 브라우저에 “This page isn’t working — [domain] redirected you too many times” 또는 오류 코드 ERR_TOO_MANY_REDIRECTS가 표시됩니다.
• 브라우저가 로드를 중단하기 전에 주소 표시줄이 HTTP와 HTTPS 사이 또는 www와 non-www 호스트 이름 사이를 반복해서 전환합니다.
• 사이트 전체에서 문제가 발생할 수도 있고, 특정 URL, 관리자 영역, 로그인 세션 또는 일부 기기로만 제한될 수도 있습니다.
• HTTPS 활성화, CDN 또는 reverse proxy 추가, 표준 호스트 이름 변경, 리디렉션 또는 SSL 플러그인 설치 후 문제가 시작되는 경우가 많습니다.
• 인증 또는 세션 로직이 관련된 경우 쿠키를 삭제하면 동작이 일시적으로 달라질 수 있지만, 서버 측 리디렉션 충돌이 해결되는 것은 아닙니다.

가능성이 높은 순서의 주요 원인

1. 충돌하는 HTTP/HTTPS 규칙 — 한 계층은 HTTP를 HTTPS로 리디렉션하는 반면 다른 계층은 HTTPS를 잘못 HTTP로 되돌립니다. 프록시 또는 CDN이 TLS를 종료하지만 origin이 원래 요청이 보안 연결이었다는 사실을 인식하지 못할 때 흔히 발생합니다.
2. CDN SSL/TLS 모드 불일치 — CDN이 origin에 연결할 때 HTTP를 사용할 수 있지만 origin은 HTTPS를 강제할 수 있습니다. origin은 HTTPS로 리디렉션하지만 CDN은 HTTP로 origin에 요청을 반복하여 루프가 발생합니다.
3. www와 non-www 표준 규칙 충돌 — CDN, 웹 서버, CMS 또는 플러그인이 어떤 호스트 이름을 표준으로 사용할지 서로 다르게 설정되어 있을 수 있습니다.
4. 잘못된 프록시 또는 전달 프로토콜 처리 — 애플리케이션이 설정된 프록시를 신뢰하지 않거나 X-Forwarded-Proto 또는 이에 해당하는 헤더를 올바르게 처리하지 못해 보안 요청을 반복해서 HTTP로 간주할 수 있습니다.
5. 오래된 리디렉션 캐시 — 브라우저, CDN, reverse proxy 또는 페이지 캐시에 설정을 수정하기 전의 리디렉션이 여전히 저장되어 제공될 수 있습니다.
6. 중복된 애플리케이션 또는 플러그인 규칙 — force-SSL, 로그인, 점검 모드 또는 리디렉션 플러그인이 서버 수준 규칙과 충돌할 수 있습니다.
7. 쿠키 또는 세션 설정 문제 — Secure, domain 또는 path 설정이 잘못되면 일부 사용자, 특히 로그인한 방문자에게만 인증 리디렉션이 발생할 수 있습니다.

해결 방법

1. 먼저 리디렉션 체인 캡처하기

터미널에서 읽기 전용 요청을 사용하세요. 아래 placeholder를 문제가 발생한 호스트 이름으로 바꾸세요.

curl -IL https://[your-hostname]

이 명령은 헤더를 요청하고 리디렉션을 따라갑니다. 모든 Location: 값과 HTTP 상태 코드를 기록하세요. 문제가 발생하는 정확한 URL, HTTP 버전, 그리고 관련된 경우 www 및 non-www 형식을 모두 테스트하세요. 브라우저의 Network 패널에서도 유사한 정보를 확인할 수 있습니다.

다음과 같은 패턴을 찾으세요.

• HTTPS → HTTP → HTTPS
• non-www → www → non-www
• 하나의 URL이 자기 자신으로 반복해서 리디렉션됨
• 로그인 또는 표준 URL로 리디렉션된 후 즉시 다시 되돌아감

처음부터 캐시를 삭제하거나 여러 설정을 한꺼번에 변경하지 마세요. 체인을 확인하면 어느 계층에 조치가 필요한지 파악할 수 있습니다.

2. HTTP/HTTPS 또는 CDN 루프 수정하기

CDN 또는 reverse proxy가 외부 HTTPS 연결을 처리한다면 해당 SSL/TLS 모드와 origin의 인증서 및 HTTPS 설정을 확인하세요. CDN에서 origin으로 연결하는 모드는 origin이 지원하는 방식과 일치해야 합니다. Cloudflare를 사용하는 경우 HTTPS를 올바르게 지원하고 origin 자체에서 HTTPS를 강제하는 origin에는 일반적으로 Flexible 대신 Full 또는 Full (strict)가 필요합니다.

모드를 변경하기 전에 CDN을 수정할 권한이 있는지, 그리고 엄격한 인증서 검증을 사용하는 경우 origin에 해당 호스트 이름에 유효한 인증서가 있는지 확인하세요. CDN TLS 설정을 변경하면 실시간 트래픽에 영향을 줄 수 있으므로 승인된 변경 절차 또는 유지보수 시간 요건을 따르세요.

3. 프록시의 HTTPS 감지 수정하기

프록시 뒤에서 실행되는 애플리케이션이 HTTPS를 강제한다면 애플리케이션 또는 프레임워크가 의도한 프록시를 신뢰하고 전달된 프로토콜을 인식하도록 설정하세요. 플랫폼에 따라 설정 이름은 trust proxy, trusted proxies 또는 force-SSL 설정일 수 있습니다.

알려지고 제어되는 프록시 경로에서 전달된 프로토콜 헤더만 신뢰하세요. 인터넷에 직접 노출된 origin에서 클라이언트가 제공한 헤더를 무조건 신뢰하지 마세요. 올바른 설정은 해당 플랫폼의 문서에서 확인한 후 리디렉션 체인을 다시 테스트하세요.

4. www와 non-www 불일치 해결하기

하나의 표준 호스트 이름을 선택하고 문서화하세요. CDN, 웹 서버 설정, 해당되는 경우 .htaccess 규칙, CMS URL 설정 및 리디렉션 플러그인을 확인하세요.

하나의 권위 있는 호스트 이름 리디렉션만 유지하세요. 예를 들어 non-www에서 www로 또는 www에서 non-www로 리디렉션하도록 설정하고 중복되거나 반대되는 규칙을 제거하세요. 변경 후 모든 HTTP 및 HTTPS 변형을 확인하세요. HTTPS가 올바르게 설정되어 있어도 웹 서버의 대상과 다른 표준 URL 설정이 있으면 루프가 다시 발생할 수 있습니다.

5. 애플리케이션, 로그인 및 쿠키 동작 검토하기

익명 사용자는 페이지를 로드할 수 있지만 로그인한 사용자는 로드할 수 없다면, 권한이 있는 테스트 계정 또는 비공개 창을 사용해 세션 쿠키가 있을 때와 없을 때의 리디렉션 체인을 비교하세요. force-SSL, 로그인, 멤버십 및 리디렉션 플러그인과 애플리케이션에 설정된 사이트 URL을 확인하세요.

세션 쿠키가 선택한 HTTPS 호스트 이름에 맞는 Secure 속성, domain 및 path를 사용하는지 확인하세요. 변경 관리 절차에 따라 의심되는 플러그인을 한 번에 하나씩 비활성화하거나 변경하세요. 롤백 계획 없이 프로덕션 사이트에서 인증 또는 보안 제어를 제거하지 마세요.

6. 오래된 리디렉션을 비우고 다시 테스트하기

설정을 수정한 후 권한이 있다면 관련 CDN, reverse proxy 및 페이지 캐시 항목을 비우세요. 브라우저 리디렉션도 남아 있을 수 있으므로 curl, 비공개 창, 필요한 경우 별도의 네트워크 또는 기기로 다시 테스트하세요.

성공적인 테스트에서는 반복되는 Location 시퀀스 없이 의도한 페이지에 도달해야 합니다. 홈페이지뿐 아니라 표준 호스트 이름, HTTP에서 HTTPS로의 동작, 로그인 흐름 및 대표적인 내부 URL도 확인하세요.

예방 및 해결 확인 방법

• CDN, reverse proxy, CMS 플러그인 또는 서버 규칙을 추가하기 전에 표준 호스트 이름과 의도한 HTTP에서 HTTPS로의 동작을 문서화하세요.
• 가능한 경우 각 리디렉션 결정을 하나의 계층에서 권위 있게 관리하고, 다른 계층에서 반대 규칙을 발행하지 않도록 하세요.
• 사이트를 프록시 뒤에 배치할 때 trusted-proxy 및 전달 프로토콜 처리를 신중하게 설정하세요. 클라이언트가 제공한 전달 헤더를 무분별하게 수용하지 마세요.
• HTTPS, 호스트 이름, CDN, CMS 또는 플러그인을 변경한 후 사용자가 실제로 접근하는 정확한 URL로 전체 리디렉션 체인을 테스트하세요.
• 해당 경로가 지원되는 경우 배포 점검에 익명 사용자, 로그인 사용자, www, non-www, HTTP 및 HTTPS 테스트를 포함하세요.
• 리디렉션을 변경한 후 관련 캐시를 비우거나 버전을 변경하고, 비공개 창 또는 깨끗한 클라이언트에서 확인하세요.

자주 묻는 질문