이 글의 목적은 브라우저에 ERR_TOO_MANY_REDIRECTS 오류가 표시될 때 원인을 체계적으로 진단하고 서버·애플리케이션·네트워크·클라이언트 측에서 단계별로 해결하는 방법을 제공하는 것이다.
1. 증상 정의와 원리
ERR_TOO_MANY_REDIRECTS 오류는 사용자가 요청한 URL이 서로 다른 주소로 반복 리다이렉트되어 브라우저가 최대 허용 횟수에 도달했을 때 발생하는 현상이다. 일반적으로 HTTP→HTTPS, www→non-www, 슬래시 유무, 언어 경로, 트레일링 슬래시, 모바일 도메인 등 규칙이 서로 상충할 때 루프가 형성된다. 프록시나 CDN이 원본과 다른 스킴을 가정할 때도 동일 현상이 발생한다. 쿠키나 세션의 잘못된 값이 조건부 리다이렉트를 반복시키는 경우도 있다.
2. 즉시 복구: 클라이언트 측 1차 조치
- 해당 사이트의 쿠키만 삭제한다. 크로스 도메인 로그인 또는 지역 설정 쿠키가 잘못 저장된 경우 즉시 복구되는 사례가 많다.
- 시크릿 모드 또는 다른 브라우저로 재시도한다. 확장 프로그램·캐시 영향 배제에 유효하다.
- 시스템 시간과 타임존을 확인한다. 시간이 어긋나면 보안 쿠키 만료 판단이 잘못될 수 있다.
- VPN·프록시를 끈 상태에서 시도한다. 기업 프록시의 재작성 규칙이 루프를 유발하기도 한다.
3. 서버·애플리케이션 측 원인 분류
| 분류 | 세부 원인 | 전형적 징후 | 우선 조치 |
|---|---|---|---|
| 스킴 충돌 | HTTP→HTTPS 강제와 프록시의 X-Forwarded-Proto 불일치 | http와 https가 번갈아 요청됨 | 프록시 헤더 정합성 확보 및 단일 소스에서만 강제 |
| 호스트 충돌 | www ↔ non-www 양방향 규칙 | www가 붙었다 빠지며 루프 | 정규 호스트를 1개로 고정 |
| 경로 규칙 | 트레일링 슬래시 또는 locale prefix 처리 오류 | /ko → /ko/ → /ko 루프 | 정규화 규칙을 단방향으로 통일 |
| CDN/프록시 | Flexible SSL, 오리진 http 강제 | 원본과 엣지 스킴 불일치 | Full 또는 Origin 인증서 모드로 전환 |
| 애플리케이션 설정 | 사이트 URL, 베이스 URL, 도메인 상이 | 관리자 페이지 접속 가능하나 프런트 루프 | DB·환경변수의 기준 URL 일치 |
| 세션/쿠키 | 도메인, Secure, SameSite, 경로 설정 오류 | 로그인·언어 변경 시에만 발생 | 쿠키 속성 재설정 및 조건부 리다이렉트 로직 점검 |
| 리버스 프록시 체인 | Nginx↔Apache 이중 리다이렉트 | 서버별 access log에 교차 흔적 | 프런트에서만 리다이렉트 수행 |
4. 표준 점검 절차(15분 컷)
- curl -I로 리다이렉트 체인을 확인한다. 예:
curl -I http://example.com -L -o /dev/null -w "%{url_effective} %{http_code}\n"형태로 단계별 최종 URL과 코드 확인이 가능하다. - 서버 access/error 로그에서 동일 요청의 301/302/307/308 패턴을 추출한다. X-Forwarded-Proto, Host, Referer, Set-Cookie를 함께 본다.
- 애플리케이션의 기준 URL을 점검한다. CMS·프레임워크의 환경설정과 데이터베이스에 저장된 값이 서버 리다이렉트와 중복되지 않도록 한다.
- 프록시·CDN 모드를 확인한다. 원본과 엣지의 TLS 모드 일관성을 확보한다.
- 임시로 모든 강제 리다이렉트를 비활성화하고 200 응답을 내도록 한 뒤, 개별 규칙을 하나씩 복귀시키며 원인을 특정한다.
5. Nginx 설정 예시와 주의점
중복을 피하기 위해 리다이렉트는 한 계층에서만 처리하는 것이 원칙이다.
# 5-1. www를 정규 호스트로 통일하는 단방향 규칙
server {
listen 80;
server_name example.com;
return 301 http://www.example.com$request_uri;
}
# 5-2. HTTP → HTTPS 단일 지점 강제
server {
listen 80;
server_name [www.example.com](http://www.example.com);
return 301 [https://www.example.com$request_uri](https://www.example.com$request_uri);
}
# 5-3. 최종 애플리케이션 서버
server {
listen 443 ssl http2;
server_name [www.example.com](http://www.example.com);
# 프록시 또는 업스트림에 스킴 정보를 정확히 전달
set $origin_scheme $scheme;
proxy_set_header X-Forwarded-Proto $origin_scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host;
# 트레일링 슬래시 정책: 한 방향만
location /ko {
try_files $uri $uri/ /index.php?$query_string;
}
} HTTP→HTTPS 강제는 위 예시처럼 80 포트에서만 수행하고 443에서 다시 http로 내보내는 규칙이 존재하면 즉시 루프가 발생한다. map이나 if 블록에서 $scheme을 강제로 덮어쓰는 경우에도 주의가 필요하다.
6. Apache(.htaccess) 설정 예시
# 6-1. HTTPS 강제
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# 6-2. non-www → www 통일
RewriteCond %{HTTP_HOST} !^[www](http://www).
RewriteRule ^(.*)$ [https://www.%{HTTP_HOST}/$1](https://www.%{HTTP_HOST}/$1) [R=301,L] .htaccess와 가상호스트 설정, CMS 내부 리다이렉트 플러그인이 동시에 동작하면 루프 위험이 커진다. 한 곳만 사용하고 나머지는 비활성화한다.
7. 리버스 프록시·CDN 사용 시 체크리스트
| 항목 | 설명 | 통과 기준 |
|---|---|---|
| TLS 모드 | 엣지와 오리진 간 암호화 일관성 | Full 또는 Full(Strict) 사용 |
| X-Forwarded-Proto | 원본이 클라이언트 스킴을 정확히 인지 | https 요청 시 https가 전달 |
| HSTS | 브라우저의 http→https 자동 승격 | 배포 전 http 접근 경로 제거 |
| 도메인 정규화 | www·non-www 중 한 방향만 허용 | 서로 상충 규칙 미존재 |
| 오리진 리다이렉트 | 오리진에서 추가 리다이렉트 수행 여부 | 엣지와 중복 금지 |
8. 애플리케이션별 자주 발생하는 사례
8-1. WordPress
- DB의 siteurl과 home 값이 실제 접속 도메인과 다르면 루프가 발생한다. wp-config.php에서
define('WP_HOME','https://www.example.com');,define('WP_SITEURL','https://www.example.com');로 고정하여 중복 리다이렉트를 제거한다. - 캐시·보안 플러그인의 리다이렉트 기능을 비활성화하고 서버 한 곳에서만 강제한다.
8-2. Laravel·Django 등
- APP_URL, ALLOWED_HOSTS, FORCE_HTTPS 미스매치로 루프가 발생한다. 프록시 신뢰 설정과
X-Forwarded-Proto를 함께 구성한다.
8-3. Magento·Shop 플랫폼
- Base URL과 Secure Base URL이 서로 달라 엣지에서 https, 원본에서 http를 강제하며 루프가 생긴다. 관리자에서 두 값을 동일하게 맞춘다.
9. 쿠키·세션 유발 루프 해결
조건부 리다이렉트 로직이 쿠키 값에 의존하면 잘못된 만료·도메인 설정으로 무한 루프가 생길 수 있다.
- 쿠키 Domain은 상위 도메인으로 단일화한다. 서브도메인 전환 시 새 쿠키가 계속 발급되어 조건이 반복될 수 있다.
- Secure 플래그는 HTTPS에서만 설정한다. HTTP에서 Secure 쿠키가 전송되지 않아 인증 루프가 다시 발생할 수 있다.
- SameSite는 크로스 도메인 인증에 맞도록 Lax/None을 선정한다. None 사용 시 Secure가 필수이다.
- 쿠키 크기가 4KB를 넘으면 일부 프록시에서 잘리는 사례가 있다. 값 최소화가 필요하다.
10. 리다이렉트 정책 설계 원칙
- 단일 진실 소스 원칙을 적용한다. 정규화는 로드밸런서·CDN·웹서버·앱 중 한 곳에서만 수행한다.
- 단방향 규칙만 선언한다. 역방향 규칙을 금지한다.
- 스킴·호스트·경로 정규화 순서를 고정하고 중간 단계에 조건부 분기를 두지 않는다.
- 가시성 확보를 위해 모든 3xx 응답에 요청·응답 로그를 남기고 상관 ID를 부여한다.
11. 단계별 실전 복구 시나리오
- 가역적 조치: 서버 규칙 백업 후 HTTP→HTTPS, www 정규화, 앱 내부 리다이렉트 기능 중 2가지를 비활성화한다.
- 체인 관찰:
curl -IL로 현재 체인을 재확인한다. 최종 200 또는 3xx의 Location 헤더가 일관적인지 본다. - 프록시 정합성: 로드밸런서/프록시가
X-Forwarded-Proto=https를 정확히 전달하는지 확인한다. - 애플리케이션 고정: 기준 URL을 환경변수 또는 설정 파일로 명시하여 서버 규칙과 충돌을 제거한다.
- 정책 재적용: 서버 한 곳에서만 정규화 규칙을 복귀시키고 모니터링한다.
12. 진단 명령 모음
# 체인과 최종 상태 코드
curl -IL https://example.com
# 프록시가 전달한 헤더 확인(엔드포인트 마련 필요)
curl -I [https://example.com/debug/headers](https://example.com/debug/headers)
# HSTS 확인
curl -s -D- [https://example.com](https://example.com) | grep -i strict-transport-security
# 서버 로그(예시)
grep '" 301 ' /var/log/nginx/access.log | tail -n 20 13. QA 체크리스트(배포 전)
| 항목 | 체크 방법 | 기준 |
|---|---|---|
| 정규 도메인 | 요구사항 문서와 일치 확인 | 하나의 호스트로 고정 |
| 스킴 정책 | HTTP 접근 시 동작 확인 | 항상 HTTPS로 301 한 번 |
| 경로 규칙 | /, /ko, /ko/ 요청 테스트 | 단방향 정규화 |
| 프록시 헤더 | X-Forwarded-* 유효성 | 실제 스킴·호스트 반영 |
| 쿠키 정책 | 보안·도메인·SameSite 점검 | 요구사항에 부합 |
| HSTS | 응답 헤더 확인 | 적절한 max-age 설정 |
14. 흔한 함정과 예방
- CDN에서 http 오리진을 가정하고 원본은 https를 강제하는 이중 정책을 피한다.
- 마이그레이션 후 DNS 전파 동안 혼합 환경이 생기면 임시로 리다이렉트를 완화하고 정식 전파 후 재적용한다.
- 모바일·다국어 서브도메인 전환은 서버 리다이렉트 대신 애플리케이션 라우팅으로 처리한다.
- 테스트 자동화에 리다이렉트 횟수 제한 검증을 포함한다.
15. 빠른 복구 템플릿
# 15-1. 프런트 Nginx에서만 정규화
server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
# 15-2. 백엔드 Nginx/Apache에서는 추가 리다이렉트 금지
# 200 응답 고정 후 앱에서 기준 URL만 세팅
FAQ
브라우저에서만 발생하고 다른 사용자는 정상일 때 무엇을 확인해야 하나?
해당 사이트의 쿠키를 삭제하고 시크릿 모드로 재시도한다. 특정 사용자 쿠키에 의존하는 조건부 리다이렉트가 반복되는 경우가 많다.
Cloud 기반 보안·WAF 뒤에 있을 때 루프가 생긴다. 원인은 무엇인가?
엣지에서 HTTPS로 종료하나 오리진으로는 HTTP로 프록시하며, 오리진이 다시 HTTPS를 강제해 루프가 생긴다. TLS 모드를 Full로 바꾸고 오리진 인증서를 배치한다.
정규 도메인을 www로 할지 non-www로 할지 기준은 무엇인가?
기술적 차이는 없다. 검색엔진과 북마크 일관성을 위해 하나만 선택하고 301로 단방향 통일하면 된다.
HSTS가 활성화되어 테스트가 어렵다. 어떻게 하나?
테스트 도메인을 분리하고 HSTS를 비활성화한다. 운영 도메인에서는 HSTS를 유지하되 규칙 충돌이 없도록 검증한다.
서버와 앱 중 어디서 리다이렉트를 처리하는 것이 좋은가?
규칙이 단순하면 웹서버에서 처리하고, 사용자 상태나 언어와 연동되는 동적 전환은 앱 라우팅에서 처리한다. 중복 적용은 금지한다.