ERR_TOO_MANY_REDIRECTS: 해결 방법 (모든 브라우저)

ERR_TOO_MANY_REDIRECTS란 무엇인가?

ERR_TOO_MANY_REDIRECTS는 웹사이트가 무한 리디렉션 루프에 빠졌을 때 발생하는 브라우저 오류입니다. 페이지가 로드되는 대신 브라우저가 URL 사이를 계속 왔다 갔다 하다가 리디렉션 한도에 도달하면 포기하고 이 오류를 표시합니다.

모든 브라우저에는 무한 루프가 리소스를 소모하는 것을 방지하기 위한 리디렉션 제한이 내장되어 있습니다. 페이지가 이 제한을 초과하면 연결이 종료되고 오류 메시지가 표시됩니다.

리디렉션 루프에서 기본이 되는 HTTP 상태 코드는 보통 301(영구 리디렉션) 또는 302(임시 리디렉션)입니다. 일반적인 루프는 다음과 같습니다: 브라우저가 URL A를 요청하면 서버가 301로 URL B로 보내고, URL B가 다시 301로 URL A로 보내면서 브라우저가 제한에 도달할 때까지 이 과정이 반복됩니다.

리디렉션 루프의 원인은 무엇인가?

리디렉션 루프는 두 개 이상의 리디렉션 규칙이 서로 충돌할 때 발생합니다. 서버가 브라우저를 특정 URL로 보내면 해당 URL이 브라우저를 다시 되돌려 보냅니다. 가장 흔한 원인은 다음과 같습니다:

• SSL/HTTPS 설정 오류 — 가장 흔한 원인입니다. 서버가 HTTP에서 HTTPS로 강제 리디렉션하지만 CDN이나 로드 밸런서가 오리진에 HTTP로 연결하여 루프가 발생합니다: CDN → HTTP → 서버가 HTTPS로 리디렉션 → CDN이 HTTPS 제거 → HTTP → 루프

• Cloudflare Flexible SSL — Cloudflare의 Flexible SSL 모드는 오리진 서버에 HTTP로 요청을 보냅니다. 오리진에도 HTTP에서 HTTPS로의 리디렉션이 있으면 Cloudflare와 서버 사이에서 무한 루프가 발생합니다

• .htaccess 규칙 충돌 — .htaccess에서 여러 리디렉션 규칙이 서로 모순되는 경우, 예를 들어 하나는 www를 강제하고 다른 하나는 동시에 non-www를 강제하는 경우

• WordPress URL 불일치 — 설정 > 일반에서 WordPress 주소(URL)와 사이트 주소(URL)가 일치하지 않거나, 하나는 HTTP이고 다른 하나는 HTTPS인 경우

• 오래된 브라우저 쿠키 — 이전 방문에서 남은 쿠키에 더 이상 존재하지 않거나 이동된 URL로 강제하는 리디렉션 지시사항이나 세션 데이터가 포함된 경우

• CDN 또는 프록시의 캐시된 리디렉션 — CDN이 현재 서버 설정과 충돌하는 이전 301 리디렉션을 캐시한 경우

• 서버 설정 충돌 — Nginx나 Apache 설정 파일에서 서버 블록과 .htaccess에서 동시에 리디렉션하는 등 경쟁하는 리디렉션 블록이 있는 경우

리디렉션 루프 진단 방법

수정을 시도하기 전에 정확한 리디렉션 체인을 확인하세요. 이를 통해 어떤 URL이 관련되어 있고 어떤 리디렉션 규칙이 루프를 유발하는지 정확히 알 수 있습니다.

방법 1: curl로 리디렉션 추적하기

리디렉션 체인을 확인하는 가장 빠른 방법은 터미널에서 curl을 사용하는 것입니다. -I 플래그는 헤더만 가져오고, -L은 리디렉션을 따라가며, --max-redirs는 따라갈 리디렉션 수를 제한합니다:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Location 헤더에서 동일한 두 URL이 번갈아 나타나면 리디렉션 루프가 확인된 것입니다. HTTP 상태 코드에 주의하세요 — 301은 영구 리디렉션(브라우저가 캐시), 302는 임시 리디렉션(캐시하지 않음)입니다.

방법 2: 브라우저 개발자 도구 네트워크 탭

Chrome 개발자 도구에서 리디렉션을 시각적으로 추적할 수도 있습니다:

• 1단계 — F12 또는 Ctrl+Shift+I (Mac: Cmd+Option+I)로 Chrome 개발자 도구를 엽니다

• 2단계 — 네트워크 탭으로 이동하여 로그 보존을 체크합니다 (리디렉션 간 항목이 유지됩니다)

• 3단계 — 오류가 발생하는 페이지를 로드합니다

• 4단계 — 요청 순서를 확인합니다. 각 리디렉션은 301 또는 302 상태와 함께 별도의 항목으로 표시됩니다. Location 열에 각 리디렉션이 가리키는 곳이 표시됩니다

네트워크 탭은 전체 리디렉션 체인을 시간순으로 보여줍니다. 일반적으로 두세 개의 URL이 반복되는 패턴을 볼 수 있습니다. DNS Robot의 HTTP 헤더 체커를 사용하여 브라우저 캐시의 영향 없이 외부에서 응답 헤더를 검사할 수 있습니다.

방법 3: 온라인 리디렉션 체커

터미널 접근이 어려운 경우, DNS Robot의 리디렉션 체커를 사용하여 전체 리디렉션 체인을 추적할 수 있습니다. URL을 입력하면 모든 경유지, 상태 코드, 최종 목적지를 보여주거나 루프가 존재하는지 확인해 줍니다. 브라우저 쿠키의 영향 없이 중립적인 위치에서 확인하므로 유용합니다.

해결법 1: 브라우저 쿠키 및 캐시 삭제

가장 간단한 해결법부터 시작하세요. 브라우저에 남아 있는 오래된 쿠키나 캐시된 리디렉션은 서버 설정이 정상인 경우에도 루프를 유발할 수 있습니다. 이 현상은 사이트가 HTTP에서 HTTPS로 마이그레이션한 후 특히 흔하게 발생합니다 — 이전 쿠키가 여전히 HTTP URL을 참조할 수 있습니다.

Chrome에서 쿠키 삭제

모든 쿠키가 아닌 특정 사이트의 쿠키만 삭제하세요 — 다른 사이트의 로그인 상태가 유지됩니다:

• 1단계 — 주소창 옆의 자물쇠 아이콘(또는 튜닝 아이콘)을 클릭합니다

• 2단계 — 사이트 설정을 클릭합니다

• 3단계 — 데이터 삭제를 클릭하여 해당 사이트의 쿠키와 캐시 데이터만 제거합니다

• 4단계 — 페이지를 새로고침합니다

# Chrome keyboard shortcut to open Clear Browsing Data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

또는 chrome://settings/clearBrowserData로 이동하여 쿠키 및 기타 사이트 데이터와 캐시된 이미지 및 파일을 선택하고, 기간을 전체로 설정한 후 데이터 삭제를 클릭합니다.

Firefox와 Safari에서 쿠키 삭제

Firefox: Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete)를 눌러 쿠키와 캐시를 선택하고, 기간을 전체로 설정한 후 지금 삭제를 클릭합니다.

Safari: Safari > 설정 > 개인 정보 보호 > 웹 사이트 데이터 관리로 이동하여 영향받은 도메인을 검색하고 선택한 후 제거를 클릭합니다. 그런 다음 Cmd+Option+E로 캐시를 비웁니다.

해결법 2: SSL/HTTPS 설정 확인

SSL 설정 오류는 리디렉션 루프의 가장 큰 원인입니다. 가장 흔한 시나리오는 CDN/프록시와 오리진 서버 간에 HTTP를 사용할지 HTTPS를 사용할지에 대한 충돌입니다.

일반적인 문제 상황은 다음과 같습니다: CDN이 SSL 종료를 처리하기 때문에 오리진에 HTTP로 연결하는데, 오리진에 HTTP에서 HTTPS로의 리디렉션이 있는 경우입니다. 오리진이 CDN을 HTTPS로 다시 보내면 CDN이 이를 제거하고 다시 HTTP로 전송합니다 — 무한 루프입니다.

• SSL 인증서 확인 — DNS Robot의 SSL 체커를 사용하여 인증서가 유효하고, 만료되지 않았으며, 올바른 도메인을 포함하는지 확인합니다

• 프로토콜 일치 — CDN이 SSL을 종료하는 경우, 오리진에서 HTTP에서 HTTPS로의 리디렉션을 제거하거나 CDN이 오리진에 HTTPS로 연결하도록 설정합니다

• HTTPS 강제 설정 확인 — 서버 수준 리디렉션(Nginx/Apache)과 CDN 수준 HTTPS 강제가 모두 있는 경우, 하나를 제거합니다

• X-Forwarded-Proto 헤더 확인 — 프록시 뒤에 있는 경우, 오리진은 원시 연결 프로토콜 대신 이 헤더를 확인하여 원래 요청이 HTTPS였는지 판단해야 합니다

해결법 3: Cloudflare 리디렉션 루프 수정

Cloudflare는 SSL 모드 작동 방식 때문에 ERR_TOO_MANY_REDIRECTS의 가장 흔한 원인입니다. 해결 방법은 사용 중인 SSL/TLS 암호화 모드에 따라 다릅니다.

Cloudflare 리디렉션 루프의 90%에 대한 해결법: SSL/TLS 암호화 모드를 Flexible에서 Full 또는 Full (Strict)로 변경합니다. 이렇게 하면 Cloudflare가 오리진에 HTTPS로 연결하여 HTTP에서 HTTPS로의 루프가 제거됩니다.

Cloudflare 단계별 해결 방법

• 1단계 — Cloudflare 대시보드에 로그인합니다

• 2단계 — 도메인을 선택합니다

• 3단계 — SSL/TLS > 개요로 이동합니다

• 4단계 — 오리진에 유효한 SSL 인증서가 있으면 암호화 모드를 Full (Strict)로, 자체 서명 인증서인 경우 Full로 변경합니다

• 5단계 — SSL/TLS > Edge 인증서로 이동하여 항상 HTTPS 사용이 활성화되어 있는지 확인합니다. 오리진에서 이미 HTTPS로 리디렉션하는 경우 이중 리디렉션을 방지하기 위해 비활성화합니다

• 6단계 — 페이지 규칙 및 리디렉션 규칙에서 충돌하는 URL 리디렉션이 있는지 확인합니다

• 7단계 — Cloudflare 캐시를 퍼지합니다: 캐싱 > 설정 > 모두 퍼지

해결법 4: .htaccess 리디렉션 규칙 수정 (Apache)

Apache 서버에서 .htaccess는 리디렉션 규칙의 가장 일반적인 위치이며, 리디렉션 루프가 시작되는 가장 흔한 장소이기도 합니다. 충돌하는 규칙, 중복 리디렉션, 누락된 조건 검사 등이 모두 루프를 만들 수 있습니다.

• 중복 HTTPS 리디렉션 확인 — 호스팅 패널(cPanel, Plesk)이 HTTPS를 강제하는 경우 .htaccess에서 수동 리디렉션을 제거합니다

• RewriteCond 조건 확인 — 리디렉션하는 모든 RewriteRule에는 이미 일치하는 URL에서 실행되지 않도록 하는 RewriteCond가 있어야 합니다. 이것이 없으면 리디렉션된 요청을 포함한 모든 요청에서 규칙이 실행됩니다

• [L] 플래그 주의 — [L] 플래그는 '마지막 규칙'을 의미하지만 현재 패스에서만 그렇습니다. 하위 디렉토리에 다른 .htaccess가 있으면 다시 실행됩니다. Apache 2.4 이상에서는 대신 [END]를 사용하세요

• 프록시 헤더 확인 — CDN 뒤에서는 원래 프로토콜을 감지하기 위해 %{HTTPS} 대신 %{HTTP:X-Forwarded-Proto}를 사용합니다

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

어떤 규칙이 루프를 유발하는지 확실하지 않으면, .htaccess를 일시적으로 .htaccess.bak로 이름을 변경하고 사이트가 로드되는지 테스트하세요. 로드된다면 문제는 .htaccess 파일에 있습니다. 규칙을 하나씩 다시 활성화하여 문제가 되는 규칙을 찾으세요.

해결법 5: WordPress 리디렉션 루프 수정

WordPress 리디렉션 루프는 보통 세 가지 원인에서 비롯됩니다: 설정에서 URL 불일치, 플러그인 충돌, 또는 잘못된 wp-config.php 값. 리디렉션 루프 때문에 WordPress 대시보드에 접근할 수 없는 경우, 데이터베이스나 설정 파일을 직접 수정해야 합니다.

WordPress URL 설정 확인

WordPress에는 일치해야 하는 두 가지 URL 설정이 있습니다: 설정 > 일반에서 WordPress 주소(URL)와 사이트 주소(URL). 하나는 http://이고 다른 하나는 https://를 사용하거나, 하나에는 www.가 있고 다른 하나에는 없으면 리디렉션 루프가 발생합니다.

대시보드에 접근할 수 없는 경우, wp-config.php에 URL을 하드코딩합니다:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

플러그인 비활성화로 충돌 찾기

리디렉션 및 캐싱 플러그인이 자주 원인이 됩니다. Redirection, Yoast SEO, Really Simple SSL, WP Super Cache, W3 Total Cache와 같은 플러그인은 서버나 CDN 설정과 충돌하는 리디렉션 규칙을 추가할 수 있습니다.

대시보드에 접근할 수 없는 경우, FTP 또는 SSH를 통해 모든 플러그인을 비활성화합니다:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

플러그인을 비활성화하면 오류가 해결되는 경우, 하나씩 다시 활성화하여 충돌하는 플러그인을 식별합니다. 가장 흔한 원인은 서버나 CDN이 이미 처리하고 있는 상황에서 HTTP에서 HTTPS로의 리디렉션을 추가하는 SSL 플러그인입니다.

해결법 6: 서버 수준 리디렉션 수정 (Nginx 및 Apache)

서버 설정 파일에는 애플리케이션 수준 리디렉션(WordPress, .htaccess)이나 CDN 설정과 충돌하는 리디렉션 규칙이 포함될 수 있습니다.

Nginx: 리디렉션 충돌 확인

Nginx 리디렉션 루프는 일반적으로 HTTP 서버 블록이 HTTPS로 리디렉션하지만 HTTPS 블록의 무언가가 다시 HTTP로 리디렉션할 때 발생합니다. 사이트 설정을 확인하세요:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Apache: VirtualHost 리디렉션 확인

Apache에서는 VirtualHost 설정과 .htaccess를 모두 확인하세요. VirtualHost 설정의 리디렉션과 .htaccess의 리디렉션이 합쳐지면 루프를 유발하는 이중 리디렉션이 만들어질 수 있습니다:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

중복 리디렉션을 제거하고 리디렉션은 한 곳에서만 유지하세요. 모범 사례는 HTTPS 리디렉션을 VirtualHost 설정에서 처리하는 것입니다(.htaccess가 아닌). VirtualHost 규칙은 요청당 한 번 처리되는 반면, .htaccess는 모든 요청마다 처리됩니다.

해결법 7: 브라우저별 문제 해결

한 브라우저에서만 오류가 나타나는 경우, 서버 문제가 아닌 캐시된 리디렉션이나 확장 프로그램 충돌일 가능성이 높습니다.

Chrome: HSTS 및 소켓 풀 삭제

Chrome은 HTTPS를 강제하는 HSTS(HTTP Strict Transport Security) 정책을 캐시합니다. 사이트가 이전에 HSTS 헤더를 보냈지만 더 이상 HTTPS를 올바르게 사용하지 않는 경우, 쿠키를 삭제한 후에도 Chrome이 계속 HTTPS로 리디렉션합니다.

• HSTS 캐시 삭제 — chrome://net-internals/#hsts로 이동하여 Delete domain security policies 아래에 도메인을 입력하고 Delete를 클릭합니다

• 소켓 풀 플러시 — chrome://net-internals/#sockets로 이동하여 Flush socket pools를 클릭하여 캐시된 연결을 지웁니다

• DNS 캐시 삭제 — chrome://net-internals/#dns로 이동하여 Clear host cache를 클릭합니다

• 시크릿 모드에서 테스트 — 시크릿 창(Ctrl+Shift+N)을 열고 URL을 시도합니다. 시크릿에서 작동하지만 일반 창에서는 안 된다면, 캐시된 리디렉션이나 확장 프로그램이 원인입니다

Firefox 및 Safari 해결법

Firefox: 주소창에 about:config를 입력하고 network.http.redirection-limit를 검색하여 20(기본값)으로 설정되어 있는지 확인합니다. 확장 프로그램이 이 값을 매우 낮은 숫자로 변경했으면 리디렉션이 조기에 실패할 수 있습니다. 사이트 데이터 삭제도 시도하세요: 설정 > 개인 정보 및 보안 > 데이터 관리 > 도메인 검색 > 선택 항목 제거.

Safari: Safari는 "too many redirects occurred" 메시지를 표시하며 Chrome보다 덜 상세한 오류를 보여줍니다. Safari > 설정 > 개인 정보 보호 > 웹 사이트 데이터 관리에서 도메인을 찾아 데이터를 제거하세요. 문제가 지속되면 Safari > 기록 지우기(전체 기록 선택)를 시도하세요.

리디렉션 루프 예방 방법

즉각적인 오류를 해결한 후에는 리디렉션 루프가 다시 발생하지 않도록 다음 사항을 준수하세요:

• 한 곳에서만 리디렉션 — HTTPS 리디렉션을 위한 위치를 하나 선택하세요: CDN, 웹 서버, 또는 애플리케이션. 여러 계층에서 동시에 리디렉션하지 마세요

• 테스트 중에는 302 사용 — 디버깅하는 동안 301(영구) 대신 302(임시) 리디렉션을 사용하세요. 브라우저가 301을 강력하게 캐시하여 변경 사항을 테스트하기 어려워집니다. 리디렉션이 올바르게 작동하는 것을 확인한 후 301로 전환하세요

• 항상 curl로 테스트 — 리디렉션 규칙을 추가한 후 curl -ILs https://yoursite.com | grep -i 'HTTP/\|location:'을 실행하여 리디렉션 체인이 최종 200 응답으로 해결되는지 확인하세요

• 도구로 모니터링 — DNS Robot의 HTTP 헤더 체커를 정기적으로 사용하여 사이트가 예기치 않은 리디렉션 없이 깨끗한 200 응답을 반환하는지 확인하세요

• 리디렉션 문서화 — 서버 설정, .htaccess, CDN 규칙, 애플리케이션 설정의 모든 리디렉션 규칙을 기록으로 남기세요. 여러 팀원이 사이트를 관리할 때 문서화되지 않은 리디렉션이 루프의 가장 큰 원인입니다

• 변경 후 CDN 캐시 퍼지 — 리디렉션 규칙을 수정한 후 CDN 캐시를 즉시 퍼지하세요. 오래된 캐시된 301이 며칠 동안 유지될 수 있습니다

리디렉션 루프가 SEO에 미치는 영향

리디렉션 루프는 검색 순위에 직접적인 피해를 줍니다. Google의 크롤러(Googlebot)는 URL당 최대 10개의 리디렉션을 따라갑니다. Googlebot이 리디렉션 루프를 만나면 해당 페이지를 크롤 오류로 표시하고 색인을 중단합니다.

Google의 리디렉션 문서에 따르면, 리디렉션 체인은 가능한 짧아야 합니다. 추가 리디렉션 단계마다 약 100-500ms의 지연이 추가되고 크롤 예산(Google이 하루에 사이트에서 크롤하는 페이지 수)이 낭비됩니다.

• 색인 손실 — 리디렉션 루프에 갇힌 페이지는 색인되지 않으며 검색 결과에서 완전히 사라집니다

• 크롤 예산 낭비 — Googlebot이 제한된 크롤 예산을 실제 콘텐츠 크롤링 대신 리디렉션 따라가기에 사용합니다

• 페이지 속도 저하 — 각 301 리디렉션은 전체 왕복(100-500ms)을 추가합니다. 세 번의 리디렉션은 로드 시간에 1초 이상을 추가할 수 있습니다

• 링크 자산 희석 — 리디렉션하는 URL을 가리키는 백링크는 단계당 약 1-5%의 PageRank 값을 잃습니다

자주 묻는 질문