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

ERR_TOO_MANY_REDIRECTS란 무엇인가?

ERR_TOO_MANY_REDIRECTS는 페이지가 한 번도 로드되지 않은 채 브라우저가 20번 넘게 다른 주소로 보내졌다는 뜻, 즉 리디렉션 루프입니다. Chrome에서는 '페이지가 작동하지 않습니다. example.com에서 리디렉션한 횟수가 너무 많습니다.'라고 표시되고, Firefox에서는 '페이지가 제대로 리디렉션되지 않음', Safari에서는 'Safari가 페이지를 열 수 없음'과 함께 '너무 많은 재이동으로 인하여 ‘example.com’을(를) 열 수 없습니다.'라고 표시됩니다.

방문자라면 해당 사이트의 쿠키를 삭제하고 새로고침하세요. 다른 사람에게는 사이트가 잘 열린다면 대개 오래된 쿠키가 원인입니다. 내 사이트에서 생긴 문제라면 원인은 거의 항상 HTTPS(또는 www)를 두 곳에서 동시에 강제하는 것이며, 가장 흔한 경우는 Cloudflare의 Flexible SSL 모드와 서버의 HTTPS 리디렉션이 겹친 것입니다.

한도가 어느 브라우저에서나 같은 이유는 브라우저들이 구현하는 Fetch Standard에 '요청의 리디렉션 횟수가 20이면 네트워크 오류를 반환한다'고 정해져 있기 때문입니다. 루프 자체는 보통 서로를 가리키는 두 개의 301 또는 302 응답입니다. URL A가 URL B로 보내고 URL B가 다시 A로 돌려보내면, 브라우저는 20번째에서 세기를 멈춥니다.

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

리디렉션 루프는 두 개 이상의 리디렉션 규칙이 서로 충돌할 때 발생합니다. 서버가 브라우저를 특정 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에서 동시에 리디렉션하는 등 경쟁하는 리디렉션 블록이 있는 경우
• 앱 로그인 루프 — 로그아웃 상태의 방문자를 자기 자신으로 리디렉션하는 로그인 페이지, 또는 브라우저가 저장을 거부하는 세션 쿠키(OAuth, Supabase Auth, NextAuth). 해결법 8 참고

리디렉션 루프 진단 방법

수정을 시도하기 전에 정확한 리디렉션 체인을 확인하세요. 이를 통해 어떤 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이 번갈아 나타나면 리디렉션 루프가 확인된 것입니다. 상태 코드도 확인하세요. 301은 브라우저가 캐시하는 영구 리디렉션이고, 302는 임시 리디렉션이라 응답에서 따로 지정하지 않는 한 캐시되지 않습니다.

각 Location 헤더의 스킴(scheme)도 살펴보세요. 같은 URL의 http:// 버전과 https:// 버전 사이를 오가는 루프가 가장 흔한 패턴이며, 곧바로 SSL 설정 문제를 가리킵니다.

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

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

• 1단계 — F12 또는 Ctrl+Shift+I (Mac: Cmd+Option+I)로 Chrome 개발자 도구를 엽니다
• 2단계 — 네트워크 탭으로 이동하여 로그 보존을 체크합니다 (리디렉션 간 항목이 유지됩니다)
• 3단계 — 오류가 발생하는 페이지를 로드합니다
• 4단계 — 요청 순서를 확인합니다. 각 리디렉션은 301 또는 302 상태와 함께 별도의 항목으로 표시됩니다. Location 열에 각 리디렉션이 가리키는 곳이 표시됩니다

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

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

터미널을 쓸 수 없다면 URL을 DNS Robot의 리다이렉트 확인에 붙여 넣으세요. 저희 서버에서 모든 경유지를 따라가며 각 상태 코드와 Location 헤더를 보여 주고, 체인이 처음으로 되돌아가 루프가 되면 알려 줍니다. 내 브라우저 쿠키 없이 확인하므로 루프가 사이트 문제인지 내 브라우저 문제인지 바로 알 수 있습니다.

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

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

Chrome에서 쿠키 삭제

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

• 1단계 — 주소창 옆의 자물쇠 아이콘(또는 튜닝 아이콘)을 클릭합니다
• 2단계 — 사이트 설정을 클릭합니다
• 3단계 — 데이터 삭제를 클릭하여 해당 사이트의 쿠키와 캐시 데이터만 제거합니다
• 4단계 — 페이지를 새로고침합니다

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

모든 사이트의 데이터를 한꺼번에 지우려면 Ctrl+Shift+Delete(Mac: Cmd+Shift+Delete)를 눌러 인터넷 사용 기록 삭제를 열고, 쿠키 및 기타 사이트 데이터와 캐시된 이미지 및 파일을 선택한 다음 기간을 전체 기간으로 정하고 데이터 삭제를 클릭합니다.

Firefox와 Safari에서 쿠키 삭제

Firefox: Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete)를 눌러 쿠키 및 사이트 데이터와 임시 캐시된 파일 및 페이지를 선택하고, 기간을 전체로 설정한 후 지우기를 클릭합니다.

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

쿠키를 삭제해서 해결됐다면 서버의 리디렉션 규칙이 최근에 바뀌었는데 브라우저에 이전 상태가 남아 있었던 것입니다. 새 세션으로 접속하는 방문자에게는 이 오류가 전혀 나타나지 않을 수도 있습니다.

Gmail·Google 드라이브·accounts.google.com에서 '리디렉션한 횟수가 너무 많습니다'가 뜰 때

Chrome에 '페이지가 작동하지 않습니다. accounts.google.com에서 리디렉션한 횟수가 너무 많습니다. 쿠키 삭제해 보기.'처럼 accounts.google.com, mail.google.com, drive.google.com이 표시된다면, 루프는 Google 로그인 페이지와 브라우저 쿠키 사이에서 생긴 것이지 웹사이트가 고장 난 것이 아닙니다. Google 로그인은 브라우저가 Google 쿠키를 보관할 수 있을 때만 작동하므로, 쿠키를 차단하거나 바꾸는 것이 있으면 같은 페이지를 계속 맴돌게 됩니다.

• Google 쿠키만 삭제 — chrome://settings/content/all(모든 사이트 데이터 및 권한 보기)을 열고 google.com을 검색해 데이터를 삭제한 다음 다시 로그인합니다. Google 고객센터의 안내처럼 삭제한 뒤에는 해당 브라우저에서 Google 계정에 다시 로그인해야 합니다
• Google에 쿠키 허용 — 쿠키 사용이 허용되지 않은 사이트 목록에 google.com이 있으면 빼고, 서드 파티 쿠키를 차단하고 있다면 [*.]google.com을 쿠키 사용이 허용된 사이트에 추가합니다(Chrome: 설정 → 개인 정보 보호 및 보안 → 서드 파티 쿠키)
• 모든 계정에서 로그아웃한 뒤 하나로만 로그인 — 여러 계정에 동시에 로그인되어 있거나, 회사 자체 로그인 페이지로 로그인을 넘기는 회사 계정을 쓰면 두 곳 사이를 오갈 수 있습니다
• 쿠키·개인정보 보호 확장 프로그램 끄기 — 로그인 도중 쿠키를 지우거나 바꾸는 확장 프로그램이 흔한 원인입니다. Chrome은 따로 허용하지 않는 한 시크릿 모드에서 확장 프로그램을 실행하지 않으므로 먼저 시크릿 창에서 시도해 보세요

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

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

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

같은 구성에서 인증서에 문제가 있으면 다른 오류가 표시됩니다. ERR_SSL_PROTOCOL_ERROR와 '연결이 비공개로 설정되어 있지 않습니다'를 참고하세요.

• SSL 인증서 확인 — DNS Robot의 SSL 인증서 확인를 사용하여 인증서가 유효하고, 만료되지 않았으며, 올바른 도메인을 포함하는지 확인합니다
• 프로토콜 일치 — CDN이 SSL을 종료하는 경우, 오리진에서 HTTP에서 HTTPS로의 리디렉션을 제거하거나 CDN이 오리진에 HTTPS로 연결하도록 설정합니다
• HTTPS 강제 설정 확인 — 서버 수준 리디렉션(Nginx/Apache)과 CDN 수준 HTTPS 강제가 모두 있는 경우, 하나를 제거합니다
• X-Forwarded-Proto 헤더 확인 — 프록시 뒤에 있는 경우, 오리진은 원시 연결 프로토콜 대신 이 헤더를 확인하여 원래 요청이 HTTPS였는지 판단해야 합니다

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

Cloudflare가 가장 흔한 원인인 이유는 암호화 모드에 따라 Cloudflare가 서버에 HTTP로 접속할지 HTTPS로 접속할지가 정해지기 때문입니다. Cloudflare 문제 해결 페이지(2026년 9월 업데이트)는 루프를 일으키는 설정 다섯 가지를 들고 있으며, 각각 오리진 서버의 특정 동작과 맞물려 루프가 생깁니다:

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

Cloudflare 단계별 해결 방법

• 1단계 — Cloudflare 대시보드에 로그인합니다
• 2단계 — 도메인을 선택합니다
• 3단계 — SSL/TLS > Overview로 이동합니다
• 4단계 — 오리진에 유효한 인증서가 있으면 암호화 모드를 Full (strict)로 변경합니다(무료 Cloudflare Origin CA 인증서도 유효한 인증서에 해당합니다). Full은 자체 서명 인증서일 때만 선택합니다
• 5단계 — SSL/TLS > Edge Certificates로 이동하여 Always Use HTTPS가 활성화되어 있는지 확인합니다. 오리진에서 이미 HTTPS로 리디렉션하는 경우 이중 리디렉션을 방지하기 위해 비활성화합니다
• 6단계 — Page Rules 및 Redirect Rules에서 충돌하는 URL 리디렉션이 있는지 확인합니다
• 7단계 — Cloudflare 캐시를 퍼지합니다: Caching > Configuration > Purge Everything

해결법 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;
    }
}

편집한 뒤에는 nginx -t로 문법 오류를 확인하고, systemctl reload nginx로 다운타임 없이 변경 사항을 적용하세요.

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를 클릭합니다(DNS 캐시 삭제 방법에서 다른 방법도 확인하세요)
• 시크릿 모드에서 테스트 — 시크릿 창(Ctrl+Shift+N)을 열고 URL을 시도합니다. 시크릿에서 작동하지만 일반 창에서는 안 된다면, 캐시된 리디렉션이나 확장 프로그램이 원인입니다

Firefox 및 Safari 해결법

Firefox: 주소창에 about:config를 입력하고 network.http.redirection-limit를 검색하여 20(기본값)인지 확인합니다. 직접 또는 기업 정책으로 이보다 낮은 값이 설정되어 있으면 리디렉션이 더 일찍 실패합니다. 사이트 데이터 삭제도 시도하세요: 설정 > 개인 정보 및 보안 > 데이터 관리 > 도메인 검색 > 선택 항목 삭제.

Safari: Safari에서는 'Safari가 페이지를 열 수 없음'과 함께 '너무 많은 재이동으로 인하여 … 열 수 없습니다.'라고 표시되고, Web Inspector 콘솔에는 'Load cannot follow more than 20 redirections'라고 나옵니다. Safari > 설정 > 개인정보 보호 > 웹사이트 데이터 관리에서 도메인을 찾아 데이터를 제거하세요. 그래도 루프가 생기면 개인정보 보호 윈도우에서 테스트하세요. 거기서도 루프가 생긴다면 사이트 설정이 잘못된 것입니다.

해결법 8: 웹 앱의 로그인 리디렉션 루프

웹 앱에서는 루프의 원인이 내 코드인 경우가 많습니다. 로그인이 필요한 페이지가 /login으로 리디렉션하는데, 무언가가 /login(또는 로그인 콜백)을 곧바로 다시 돌려보내는 것입니다. 브라우저 콘솔에는 실패한 요청이 net::ERR_TOO_MANY_REDIRECTS로 표시되며, Chrome 오류 화면에 'auth.supabase.io에서 리디렉션한 횟수가 너무 많습니다.'처럼 인증 서비스 주소가 나올 때도 이 경우에 해당합니다.

• 로그인 페이지까지 보호됨 — 모든 경로에서 실행되는 인증 미들웨어가 /login과 콜백 경로까지 /login으로 리디렉션합니다. 이 경로들은 검사 대상에서 제외하세요
• 세션 쿠키가 저장되지 않음 — SameSite=None으로 설정한 쿠키는 Secure도 함께 설정해야 하며, 그렇지 않으면 브라우저가 버립니다. 잘못된 도메인으로 설정한 쿠키는 다시 전송되지 않습니다. 어느 쪽이든 모든 요청이 계속 로그아웃 상태로 보입니다
• 콜백 URL 불일치 — 인증 제공자(Google, GitHub, Supabase Auth)가 앱에서 처리하지 않는 콜백으로 사용자를 보내고, 그 경로가 다시 로그인으로 리디렉션합니다
• 프록시 뒤의 HTTP와 HTTPS — 앱이 X-Forwarded-Proto를 무시해서 리디렉션 URL을 http://로 만듭니다. 해결법 2의 루프가 한 계층 위에서 생기는 것입니다

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

로그아웃한 상태에서 리디렉션 체커나 curl -IL로 수정 결과를 확인하세요. 정상적인 체인은 또 다른 리디렉션이 아니라 로그인 페이지의 200으로 끝납니다.

리디렉션 루프 예방 방법

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

• 한 곳에서만 리디렉션 — 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이 며칠 동안 유지될 수 있습니다

정상적인 체인은 많아야 1~2단계입니다(예: HTTP → HTTPS → 200 OK). 3단계 이상이라면 대개 더 이상 필요 없는 리디렉션이 남아 있는 것입니다.

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

리디렉션 루프가 생기면 페이지가 검색에서 빠집니다. Google 크롤링 문서에 따르면 Google 크롤러는 '최대 10개의 리디렉션 홉을 따라갑니다'. 루프는 콘텐츠에 도달하지 못하므로 Search Console에 리디렉션 오류로 보고되고, 루프가 고쳐질 때까지 해당 URL은 색인에서 빠집니다.

결국 페이지에 도달하는 체인이라도 길면 손해입니다. 홉마다 페이지가 로드되기 전에 브라우저와 Googlebot이 요청을 한 번 더 보내야 하므로, 링크와 리디렉션은 최종 URL을 직접 가리키도록 하세요.

• 색인 손실 — 리디렉션 루프에 갇힌 페이지는 색인되지 않으며 검색 결과에서 완전히 사라집니다
• 크롤 예산 낭비 — Googlebot이 제한된 크롤 예산을 실제 콘텐츠 크롤링 대신 리디렉션 따라가기에 사용합니다
• 페이지 속도 저하 — 홉마다 콘텐츠가 로드되기 전에 요청과 왕복이 한 번씩 늘어나며, 다른 호스트로 넘어가는 홉은 새 연결도 필요합니다