WordPress를 HTTPS로 이전한 후 리디렉션이 너무 많음

이 오류의 의미와 확인 방법

• HTTPS로 이전하기 전에는 HTTP에서 정상 작동했지만 이후 “리디렉션이 너무 많음”이 표시됩니다.
• 브라우저가 HTTP와 HTTPS 사이를 반복해서 전환하거나 동일한 HTTPS 주소를 계속 요청합니다.
• 사이트 전체가 작동하지 않거나 /wp-admin, 로그인 페이지 또는 특정 경로만 루프에 빠질 수 있습니다.
• HTTP 주소를 열면 예상된 HTTPS 리디렉션이 한 번 발생한 뒤 정상적인 응답 대신 리디렉션이 반복될 수 있습니다.
• 캐시된 리디렉션, 쿠키 또는 사이트 데이터 때문에 시크릿 브라우징이나 다른 기기에서는 동작이 다를 수 있습니다.

가능성이 높은 순서의 주요 원인

1. WordPress URL 설정이 여전히 HTTP를 사용합니다. WordPress Address (URL) 또는 Site Address (URL) 중 하나라도 HTTP로 남아 있고 다른 계층에서 HTTPS를 요구하면, WordPress가 서버 정책과 충돌하는 scheme으로 리디렉션할 수 있습니다.
2. 여러 계층에서 HTTPS를 강제합니다. 보안 플러그인, wp-config.php 로직, .htaccess 또는 Nginx 규칙, 호스팅 설정 및 프록시 규칙이 서로 중복되거나 요청 scheme에 대해 서로 다른 가정을 할 수 있습니다.
3. CDN 또는 reverse proxy가 TLS를 종료합니다. 방문자는 HTTPS로 연결하지만 origin 연결은 HTTP일 수 있습니다. 원래 프로토콜 정보가 누락되거나 잘못되었거나 안전하게 신뢰되지 않으면 WordPress가 요청을 계속 안전하지 않은 것으로 판단할 수 있습니다.
4. 플러그인 또는 테마가 특정 경로를 리디렉션합니다. 로그인, 관리자, canonical URL, 보안 및 멤버십 플러그인이 /wp-login.php, /wp-admin 또는 특정 페이지만 대상으로 삼을 수 있습니다.
5. 오래된 캐시된 리디렉션 또는 브라우저 쿠키가 수정 사항을 가립니다. 이것이 최초 원인일 가능성은 낮지만, 수정된 설정이 여전히 작동하지 않는 것처럼 보이게 할 수 있습니다.
6. 콘텐츠 또는 설정에 기존 HTTP 참조가 남아 있습니다. 이러한 참조는 일반적으로 mixed-content 경고나 추가 리디렉션을 일으키며 사이트 전체의 리디렉션 루프를 일으키지는 않습니다. 먼저 주요 체인을 수정한 후 조사하세요.

해결 방법

1. 리디렉션 체인 확인

초기 확인에는 시크릿 브라우징 창을 사용하세요. 셸 액세스 권한이 있다면 영향을 받는 사이트의 실제 HTTPS 주소를 셸 변수에 설정하고 다음 읽기 전용 요청을 실행하세요.

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

모든 상태 코드와 Location: 헤더를 기록하세요. HTTP와 HTTPS가 번갈아 나타나면 대개 scheme 감지 또는 리디렉션 규칙 충돌을 의미합니다. 동일한 HTTPS 주소가 반복되면 canonical 리디렉션, 플러그인, 프록시 또는 캐시된 리디렉션일 가능성이 더 높습니다. 자격 증명, 쿠키 또는 authorization 헤더는 포함하지 마세요.

2. 두 WordPress URL 설정 확인

대시보드에 액세스할 수 있다면 Settings → General을 열고 WordPress Address (URL)와 Site Address (URL)가 필요한 하위 디렉터리를 포함하여 동일한 의도된 HTTPS origin을 사용하는지 확인하세요.

리디렉션 루프 때문에 대시보드가 차단된 경우, SFTP 또는 데이터베이스 액세스 권한이 있는 인증된 관리자가 wp-config.php에 다음 값을 일시적으로 정의할 수 있습니다.

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

먼저 파일을 백업하고 한 번에 하나의 통제된 변경만 수행하세요. 이러한 상수는 정의되어 있는 동안 해당 대시보드 필드보다 우선하므로, 테스트 후 신중하게 제거하거나 관리하세요.

3. TLS가 종료되는 위치 확인

브라우저가 웹 서버에 직접 연결하는지, 아니면 CDN, load balancer 또는 reverse proxy를 거치는지 확인하세요. 프록시가 TLS를 종료하면 방문자가 HTTPS를 사용했더라도 origin은 HTTP 연결을 받을 수 있습니다.

호스팅 또는 프록시 관리자에게 원래 프로토콜이 일관되게 전달되는지, 그리고 WordPress가 해당 값을 의도한 신뢰 프록시에서만 인식하도록 구성되어 있는지 확인해 달라고 요청하세요. 임의의 클라이언트에서 보내는 X-Forwarded-Proto를 무조건 신뢰하지 마세요. 검증되지 않은 forwarded 헤더는 보안 문제를 일으킬 수 있습니다.

4. HTTPS 강제를 하나의 의도된 계층으로 줄이기

HTTP를 HTTPS로 리디렉션할 수 있는 모든 위치를 나열하세요.

• CDN 또는 load balancer 규칙
• 호스팅 제어판의 SSL 설정
• Apache .htaccess 또는 Nginx 구성
• 보안 또는 SSL 플러그인
• 사용자 지정 wp-config.php 또는 테마 코드

호스팅 아키텍처에 적합한 계층(일반적으로 edge 또는 웹 서버)에서만 강제를 유지하고, 충돌하는 애플리케이션 계층 리디렉션은 비활성화하세요. 서버 규칙을 변경하기 전에 설정을 백업하고 관리자 승인을 받으세요. 승인된 reload 또는 restart를 수행하기 전에 설정을 검증하세요. 첫 번째 진단 단계로 production 웹 서버를 재시작하지 마세요.

5. 로그인 및 관리자 경로를 별도로 테스트

프런트 엔드는 정상 작동하지만 /wp-admin 또는 로그인에서 루프가 발생한다면, 승인된 유지 관리 절차에 따라 최근 변경된 보안, 로그인, canonical URL 및 캐싱 플러그인을 검토하세요. 한 경로에서만 루프가 발생한다면 플러그인 충돌일 가능성이 더 높습니다. 테스트를 위해 플러그인을 비활성화해야 한다면 변경 사항을 기록하고 액세스 제어를 유지하며 테스트 후 다시 활성화하거나 교체하세요.

6. 캐시 삭제 후 재테스트

원래 동작을 기록하고 통제된 수정 사항을 적용한 후 브라우저 사이트 데이터를 삭제하고 WordPress 페이지 또는 object cache와 호스팅 및 CDN 캐시를 삭제하세요. HTTP 주소, HTTPS 홈페이지, 로그인 페이지 및 대표적인 내부 페이지를 다시 테스트하세요. 캐시된 301 또는 302가 실제 설정을 수정한 후에도 남아 있을 수 있습니다.

7. 남아 있는 HTTP 참조 업데이트

리디렉션 체인을 수정한 후 저장된 URL을 변경하기 전에 데이터베이스를 백업하세요. 신뢰할 수 있는 WordPress 마이그레이션 도구 또는 WP-CLI search-and-replace를 먼저 dry run으로 실행하고, serialized WordPress 데이터를 처리할 수 있는 도구를 사용하세요. 기존 사이트 origin만 HTTPS origin으로 교체하세요. 모든 http:// 값을 광범위하게 교체하면 안 됩니다. 타사 URL과 의도적으로 외부에 있는 리소스는 해당 사이트에 속하지 않을 수 있습니다.

예방 및 해결 확인 방법

• 사이트의 canonical HTTPS origin을 기록하고 마이그레이션 중 두 WordPress URL 설정을 모두 업데이트하세요.
• HTTP-to-HTTPS 리디렉션을 적용할 위치를 하나로 정해 문서화하고, force-SSL 플러그인을 활성화하기 전에 다른 계층을 검토하세요.
• CDN 또는 reverse proxy가 TLS를 종료하는지, 그리고 origin이 원래 프로토콜을 어떻게 파악하는지 문서화하세요.
• HTTPS 설정을 변경할 때마다 홈페이지, 내부 페이지, 로그인 및 대시보드를 테스트하세요.
• wp-config.php, rewrite 규칙 또는 저장된 URL을 편집하기 전에 설정과 데이터베이스를 백업하세요.
• 리디렉션이 정상 작동한 후 대상 HTTPS URL 마이그레이션을 실행하고 mixed-content 참조를 확인하세요.

자주 묻는 질문