ERR_TOO_MANY_REDIRECTS — 리다이렉트가 너무 많음·무한 루프 원인·해결·예방
크롬에서 사이트에 들어가려는데 "이 페이지가 작동하지 않습니다 / 리디렉션이 너무 많습니다", 코드로는 ERR_TOO_MANY_REDIRECTS가 뜬다면, 브라우저가 A에서 B로, 다시 B에서 A로 끝없이 돌려보내지는 리다이렉트 루프에 빠진 것이다. 앞선 글들이 DNS·연결·인증서 단계의 문제였다면, 이번에는 연결도 보안도 다 됐는데 HTTP 단계에서 "주소를 계속 다른 곳으로 넘기기만 하는" 문제다.
브라우저는 무한 루프를 막으려고 리다이렉트 횟수에 상한을 두는데, 그 한도를 넘으면 포기하고 이 에러를 띄운다. 일반 사용자에게는 손상된 쿠키가, 사이트 운영자에게는 HTTPS·www 리다이렉트 규칙 충돌이 단골 원인이다. 이 글은 의미, 원인, 진단, 단계별 해결, 그리고 정상 리다이렉트와의 차이까지 정리한다.

이 글의 구성
🔎 ERR_TOO_MANY_REDIRECTS 의미
이 에러도 HTTP 상태 코드가 아니라 크롬(크로미엄 계열)이 표시하는 오류다. 서버가 응답으로 "다른 주소로 가라(리다이렉트)"를 반복해서 보내는데, 그 목적지가 결국 출발점으로 되돌아오는 순환이 생기면 브라우저는 같은 자리를 빙빙 돌게 된다. 브라우저는 정해진 횟수(크롬은 약 20회)를 넘으면 루프로 판단하고 멈춘다.
| 항목 | 내용 |
|---|---|
| 에러 코드 | ERR_TOO_MANY_REDIRECTS |
| 표시 환경 | 크롬 등 크로미엄 계열 브라우저 |
| 한글 의미 | 리다이렉트가 한도를 초과(무한 루프) |
| 실패 단계 | HTTP(연결·보안 성공 후 응답 단계) |
| 핵심 | 목적지가 출발점으로 되돌아오는 순환 구조 |
리다이렉트 자체는 정상 기능이다. 옮겨진 페이지를 새 주소로 보내거나(301), HTTP를 HTTPS로 올려보내는 것은 매일 일어난다. 문제는 그 화살표들이 고리를 이룰 때다. 예를 들어 A는 "HTTPS로 가라"며 B로 보내는데 B가 다시 "HTTP로 가라"며 A로 보내면, 둘은 영원히 서로를 가리킨다. 그래서 진단의 핵심은 "리다이렉트 화살표가 어디서 어디로 향하는지" 추적하는 것이다.
핵심 관찰 — 화살표가 고리를 이뤘다
고장이 아니라 설정의 순환이다. 그래서 진단은 리다이렉트 체인을 펼쳐 보는 것에서 시작한다. 한 사이트에서만 나면 그 사이트의 리다이렉트 규칙이나 내 쿠키 문제, 모든 사이트에서 나는 일은 거의 없다.
🧩 자주 나오는 발생 원인 5가지
원인 1 — 손상된 쿠키·세션 (사용자 측 1순위)
일반 사용자에게 가장 흔한 원인 중 하나다. 로그인·세션 쿠키가 꼬이면 사이트가 "로그인 안 됨 → 로그인 페이지 → 다시 확인 → 로그인 페이지"를 반복하며 루프에 빠진다. 쿠키가 원인이라면 그 사이트 쿠키 삭제로 바로 풀리지만, 서버·CDN의 리다이렉트 설정이 원인이면 쿠키를 지워도 그대로다(아래 원인들).
원인 2 — HTTPS 리다이렉트 + 잘못된 SSL 설정
대표적인 사례가 CDN의 SSL 모드 오설정이다. CDN은 방문자에게 HTTPS로 받지만 원본 서버에는 HTTP로 전달하는데, 원본이 모든 HTTP 요청을 다시 HTTPS로 리다이렉트하면 무한 루프가 된다. SSL 모드를 Full로 맞추면 해결된다.
원인 3 — www ↔ non-www·슬래시 규칙 충돌
"www 붙여라"와 "www 떼라"가 동시에 걸려 있거나, 끝 슬래시를 붙이는 규칙과 떼는 규칙이 서로 부딪히면 두 규칙이 핑퐁처럼 주고받으며 루프가 생긴다. 리다이렉트는 항상 한 방향으로만 통일해야 한다.
원인 4 — CMS·플러그인 URL 설정 불일치
워드프레스 같은 CMS에서 사이트 주소(URL) 설정과 실제 접속 주소·프로토콜이 어긋나거나, 리다이렉트 플러그인이 서버 규칙과 충돌하면 루프가 난다. 사이트 URL 설정과 HTTPS 설정을 일치시켜야 한다.
원인 5 — .htaccess·서버 rewrite 규칙 충돌
.htaccess나 Nginx의 rewrite·redirect 규칙이 여러 개 겹쳐 서로를 가리키면 루프가 생긴다. 특히 여러 곳에서 HTTPS 강제 규칙이 중복되면 충돌하기 쉽다. 규칙을 한곳에서 일관되게 관리해야 한다.
💻 재현 시나리오와 리다이렉트 추적
이 에러는 "리다이렉트 화살표가 어디로 향하는지" 추적하는 것이 핵심이다. curl로 리다이렉트 체인을 펼쳐 Location 헤더가 순환하는지 본다.
# 리다이렉트 체인 추적 (-I 헤더만, -L 따라가기)
curl -ILk https://example.com
# ✗ 루프 신호 — Location이 서로를 가리키며 반복
HTTP/1.1 301 ... Location: https://www.example.com/
HTTP/1.1 301 ... Location: https://example.com/
HTTP/1.1 301 ... Location: https://www.example.com/
브라우저에서는 개발자도구 Network 탭으로 같은 요청이 301·302로 반복되는지 확인할 수 있다.
# ✓ 브라우저 개발자도구 → Network 탭
F12 → Network → 새로고침 → 301/302 응답이 반복되는 체인 확인
# Status·Location 컬럼으로 어느 두 주소가 핑퐁하는지 파악
사용자 측에서는 해당 사이트 쿠키를 비우는 것이 가장 빠른 해결이다. 운영자는 SSL 모드와 리다이렉트 규칙을 한 방향으로 정리한다.
# 사용자: 해당 사이트 쿠키·캐시 삭제 후 재접속 (1순위)
# 운영자: CDN SSL 모드는 Flexible 금지 → Full 사용
# 운영자: HTTPS·www 리다이렉트는 한 방향으로만 통일
🛠 해결 방법과 단계별 진단
루프는 "내 쿠키 문제인가, 서버 리다이렉트 규칙 문제인가"를 가르는 것이 핵심이다.
| 상황 | 해결 방법 |
|---|---|
| 방문자 | 해당 사이트 쿠키·캐시 삭제, 시크릿 모드·다른 브라우저로 확인 |
| HTTPS·CDN | CDN SSL 모드를 Full로(Flexible 금지), 원본의 HTTPS 강제와 충돌 제거 |
| www·슬래시 | www·끝 슬래시 리다이렉트를 한 방향으로만 통일 |
| CMS | 사이트 URL·HTTPS 설정 일치, 충돌하는 리다이렉트 플러그인 점검 |
| 서버 규칙 | .htaccess·Nginx의 중복 rewrite·redirect 규칙 정리 |
단계별 진단 절차
⚖️ 정상 리다이렉트·404와의 차이
리다이렉트는 원래 정상 기능이다. 무엇이 정상이고 무엇이 루프인지 구분하면 명확해진다.
| 상황 | 동작 | 결과 |
|---|---|---|
| 정상 301/302 | 새 주소로 한두 번 이동 후 도착 | 정상 표시 |
| 리다이렉트 루프 | A↔B 무한 반복, 한도 초과 | ERR_TOO_MANY_REDIRECTS |
| 404 | 이동 없이 자원 없음 응답 | 페이지를 찾을 수 없음 |
차이는 "이동이 끝나느냐"이다. 정상 리다이렉트는 한두 번 옮긴 뒤 목적지에 도착해 멈춘다. 루프는 목적지가 다시 출발점을 가리켜 끝나지 않는다. 404는 아예 이동하지 않고 "그 자원이 없다"고 끝낸다. 그래서 루프 진단은 "어디서 끝나야 할 이동이 안 끝나고 되돌아오는가"를 찾는 일이다.
리다이렉트는 길 안내다. 그 안내가 고리를 이루면 영원히 도착하지 못한다. 화살표는 항상 한 방향이어야 한다.
— 사용자는 쿠키, 운영자는 리다이렉트 규칙
💬 자주 묻는 질문 5가지
Q1이 에러, 내 문제인가요 사이트 문제인가요?
둘 다 가능합니다. 시크릿 모드나 다른 브라우저에서 잘 열리면 내 쿠키 문제이고, 어디서도 안 되면 사이트의 리다이렉트 규칙·HTTPS 설정 문제입니다. 시크릿 모드로 먼저 확인하는 것이 가장 빠른 구분법입니다.
Q2가장 먼저 뭘 해보면 되나요?
해당 사이트의 쿠키와 캐시를 삭제하세요. 로그인·세션 쿠키가 꼬여 생기는 루프는 이것만으로 대부분 풀립니다. 브라우저 설정에서 그 사이트만 골라 쿠키를 지우거나, 시크릿 모드로 접속해 확인하면 됩니다.
Q3내 사이트에서 이 에러가 나요.
curl -IL이나 개발자도구 Network로 리다이렉트 체인을 펼쳐, 어느 두 주소가 서로를 가리키는지 찾으세요. HTTPS↔HTTP, www↔non-www가 핑퐁하는 경우가 흔합니다. CDN을 쓴다면 SSL 모드가 Flexible로 돼 있지 않은지 가장 먼저 확인하세요.
Q4Cloudflare를 쓰는데 이 에러가 떠요.
SSL 모드가 Flexible이면 흔히 발생합니다. CDN은 방문자에게 HTTPS로 받지만 원본에는 HTTP로 보내는데, 원본이 그 HTTP를 다시 HTTPS로 리다이렉트하면 무한 루프가 됩니다. SSL 모드를 Full로 바꾸면 대부분 해결됩니다.
Q5워드프레스에서 자꾸 리다이렉트 루프가 나요.
사이트 주소(URL) 설정과 실제 프로토콜이 어긋났거나, HTTPS 강제·리다이렉트 플러그인이 서버 규칙과 충돌하는 경우가 많습니다. 사이트 URL을 실제 접속 주소(https 포함)와 일치시키고, 중복된 HTTPS 강제 설정을 한 곳으로 정리하세요.
📌 결론
ERR_TOO_MANY_REDIRECTS는 "리다이렉트 화살표가 고리를 이뤄 도착하지 못한다"는 신호다. DNS·연결·인증서가 다 정상이어도, HTTP 응답이 서로를 가리키면 브라우저는 같은 자리를 맴돌다 포기한다. 그래서 시선은 "어디서 끝나야 할 이동이 안 끝나는가"로 향한다.
실무 원칙은 다음과 같다.
🍪 사용자는 쿠키부터 지운다. 세션 꼬임으로 생긴 루프는 그 사이트 쿠키 삭제로 대부분 풀린다.
🔁 운영자는 리다이렉트를 한 방향으로 통일한다. www·슬래시·HTTPS 규칙이 서로를 가리키지 않게 한다.
🔐 CDN을 쓰면 SSL 모드를 Full로 둔다. Flexible은 HTTPS 강제와 충돌해 루프를 잘 만든다.
리다이렉트 루프 트러블슈팅 체크리스트
본 글은 ERR_TOO_MANY_REDIRECTS 에러의 일반적 원인과 해결 방법을 정리한 자료다. 서버·리다이렉트·SSL 설정 변경은 영향 범위를 확인한 뒤 신중히 적용한다.
#ERR_TOO_MANY_REDIRECTS #리다이렉트오류 #무한리다이렉트 #리다이렉트루프 #쿠키삭제 #CloudflareSSL #FlexibleSSL #www리다이렉트 #301리다이렉트 #htaccess #워드프레스리다이렉트 #크롬에러 #curl #웹브라우저 #트러블슈팅
'IT' 카테고리의 다른 글
| "이 사이트에 연결할 수 없음" 종합 자가진단 — 원인 찾기·해결 (0) | 2026.06.25 |
|---|---|
| ERR_CONNECTION_RESET — 연결이 재설정됨·도중에 끊김 원인·해결·예방 (0) | 2026.06.24 |
| NET::ERR_CERT 인증서 오류 — 연결이 비공개로 설정되어 있지 않음 원인·해결·예방 (0) | 2026.06.24 |
| ERR_SSL_PROTOCOL_ERROR — 보안 연결 실패·TLS 핸드셰이크 오류 원인·해결·예방 (0) | 2026.06.24 |
| ERR_CONNECTION_TIMED_OUT — 연결 시간 초과 에러 원인·해결·예방 (0) | 2026.06.23 |
댓글