ERR_TOO_MANY_REDIRECTS 해결: 쿠키 문제와 HTTPS 리다이렉트 루프 구분
AI Editter
브라우저가 ERR_TOO_MANY_REDIRECTS를 표시하면 사이트가 다른 주소로 보내는 동작을 반복하고 있다는 뜻입니다. 쿠키 삭제로 해결되는 경우도 있지만, 서버가 HTTP와 HTTPS 사이를 계속 왕복하게 만들었다면 방문자 모두가 같은 오류를 겪습니다.
방문자는 문제가 자신의 브라우저에 한정됐는지 확인하고, 운영자는 실제 이동 경로를 확인해야 합니다. 운영 설정을 바꿀 권한이 없다면 아래 방문자 점검까지만 진행하고 결과를 사이트 운영자에게 전달하세요.
한 사람만 안 되는지 모든 사람이 안 되는지
| 비교 | 결과 | 다음 확인 |
|---|---|---|
| 같은 기기의 시크릿 창 | 여기서는 정상 | 해당 사이트 쿠키·로그인 상태 |
| 다른 기기·다른 네트워크 | 모두 실패 | 서버·CDN 이동 규칙 |
| 비로그인 페이지와 로그인 페이지 | 로그인 후에만 반복 | 세션·콜백 URL·프록시 설정 |
| www 주소와 기본 도메인 | 한쪽에서만 반복 | 정규 도메인 통일 규칙 |
방문자는 주소의 오타를 확인하고 해당 사이트의 쿠키만 지운 뒤 다시 로그인해 볼 수 있습니다. 전체 브라우저 데이터를 먼저 지울 필요는 없습니다. 시크릿 창도 실패한다면 같은 쿠키 삭제를 반복하기보다 발생 주소와 시각을 전달합니다.
운영자는 Location 응답을 따라간다
아래 예시의 도메인은 실제로 관리하는 도메인으로 바꿉니다. 로그인 쿠키나 토큰이 포함되지 않은 공개 페이지부터 검사합니다.
curl -sS -D - -o /dev/null https://example.com/
curl -sS -L --max-redirs 8 -D - -o /dev/null https://example.com/첫 명령은 첫 응답의 상태와 헤더를 보여 줍니다. 두 번째는 최대 8번까지 이동하며 Location을 확인합니다. Windows PowerShell에서는 필요하면 curl.exe로 실행하고 /dev/null 대신 NUL을 사용합니다.
로그를 공유할 때는 쿠키, 세션 식별자와 인증 관련 값은 제외합니다. 301, 302, 307, 308 중 어느 코드인지보다 같은 주소가 경로 안에 다시 나타나는지가 먼저 볼 단서입니다.
HTTPS 요청이 다시 같은 HTTPS로 돌아오는 구조
대표적인 사례는 CDN이 원본 서버에 HTTP로 연결하는데, 원본이 HTTPS로 다시 보내는 구성입니다. 브라우저는 이미 HTTPS 주소를 요청했지만 원본은 계속 HTTP 요청으로 인식합니다.
Cloudflare의 Flexible 모드가 이런 조건에 해당할 수 있습니다. 공식 Flexible 설명은 원본의 강제 HTTPS 이동과 충돌할 수 있다고 안내합니다. 원본에 유효한 인증서와 HTTPS 연결을 준비하고 요구사항에 맞는 암호화 모드를 선택해야 합니다. 오류를 없애려고 HTTPS를 포기하는 방향으로 바꾸지 않습니다.
www·슬래시·로그인 규칙이 서로 반대인지 확인
| 관찰한 이동 | 의심할 충돌 | 수정 기준 |
|---|---|---|
| www → 기본 도메인 → www | CDN과 웹 서버의 도메인 규칙 | 대표 주소를 한 곳에서 결정 |
/shop → /shop/ → /shop | 앱과 프록시의 슬래시 처리 | 앱 라우팅에 맞춰 통일 |
| 로그인 → 대시보드 → 로그인 | 쿠키 범위·세션·인증 콜백 | 실제 쿠키와 인증 로그 확인 |
| HTTPS → HTTP → HTTPS | 프록시 연결·앱 URL | 원본 연결과 외부 URL 인식 일치 |
WordPress라면 사이트 주소·WordPress 주소, 리다이렉트 플러그인, 웹 서버 규칙, CDN 규칙을 함께 확인합니다. 프록시 뒤의 앱이 HTTPS 여부를 인식하도록 설정할 때는 신뢰하는 프록시에서 전달된 헤더만 사용해야 합니다. 외부 클라이언트가 임의로 보낸 헤더까지 신뢰하면 다른 문제가 생깁니다.
한 규칙씩 고치고 같은 주소로 다시 시험
설정 변경 전 규칙과 시간을 기록하고 한 곳씩 수정합니다. Nginx 설정을 바꿨다면 구문 검사 후 적용하고, CDN 규칙은 어떤 규칙이 해당 주소와 일치하는지 확인합니다. 운영 캐시가 남아 있으면 수정된 경로에 한해 캐시와 브라우저 상태를 다시 점검합니다.
정상 기준은 무조건 이동 0회가 아닙니다. HTTP에서 HTTPS로 한 번 이동한 뒤 200에 도달하는 것은 의도한 동작일 수 있습니다. 기본 도메인·www, 로그인·비로그인, 주요 하위 경로를 모두 확인하고, 루프만 사라진 대신 다른 페이지가 404가 되지 않았는지 점검하세요.
함께 확인할 절차: Nginx 502·504 오류 해결: upstream 로그로 원인 찾는 순서