WordPress 로그인 페이지가 리디렉션 루프를 계속 반복하는 경우
직접 답변
WordPress 로그인 리디렉션 루프는 일반적으로 일치하지 않는 `siteurl` 및 `home` 값, 오래된 로그인 쿠키, 또는 WordPress와 reverse proxy 간 HTTPS 상태 불일치로 발생합니다. 비공개 창에서 `wp-login.php`를 테스트하고, options table의 URL 값을 확인하고, 사이트 쿠키를 삭제한 다음, proxy 및 SSL 동작을 점검하세요. 로그인에서만 발생하는 루프와 사이트 전체의 리디렉션 문제는 별도로 다뤄야 합니다.
핵심 요점
siteurl과home이 현재 도메인을 사용하고 동일한 의도된 프로토콜로 설정되어 있는지 확인하세요.- 비공개 창이나 다른 브라우저에서 테스트하여 저장된 쿠키 문제와 서버 측 설정 문제를 구분하세요.
- proxy 또는 load balancer가 SSL을 종료하는 경우, WordPress가 올바른 HTTPS 상태를 전달받는지 확인하세요.
- 루프가 시작되기 직전에 변경한 도메인, 마이그레이션, 캐싱, 보안 및 쿠키 설정을 검토하세요.
- URL 또는 리디렉션 설정을 변경하기 전에 데이터베이스와 설정을 백업하고, 한 번에 하나의 설정만 변경하세요.
Site Administrator
이 오류의 의미와 확인 방법
wp-login.php를 열면 로그인 페이지로 계속 돌아갑니다.- 브라우저에 리디렉션이 너무 많다는 메시지가 표시되거나 로그인 폼 로딩이 끝나지 않습니다.
- 로그인이 성공한 것처럼 보이지만 세션이 즉시 로그인 화면으로 돌아갑니다.
- 한 브라우저에서만 루프가 발생하거나 다른 브라우저에서는 발생하지 않으며, 비공개 브라우징 창에서는 사라집니다.
- 도메인 변경, HTTP에서 HTTPS로의 마이그레이션, 호스팅 이전, proxy 변경 또는 쿠키 관련 설정 변경 후 문제가 시작되었습니다.
가능성이 높은 순서의 주요 원인
- 일치하지 않는
siteurl및home값: WordPress 데이터베이스 값에 서로 다른 도메인, 프로토콜 또는 오래된 마이그레이션 주소가 사용되었을 수 있습니다. 그러면 로그인 리디렉션이 서로 충돌하는 URL 사이를 이동할 수 있습니다. - 오래되었거나 범위가 잘못 설정된 쿠키: 이전 도메인, 프로토콜 또는 경로의 쿠키에 사용할 수 없는 인증 상태가 포함되어 브라우저가 로그인 페이지로 계속 돌아갈 수 있습니다.
- SSL 종료 또는 reverse proxy 불일치: proxy는 HTTPS 요청을 받지만 origin은 해당 요청을 HTTP로 해석할 수 있습니다. 그러면 WordPress가 잘못된 프로토콜을 기준으로 리디렉션을 생성할 수 있습니다.
- 완료되지 않은 마이그레이션 또는 도메인 변경: 설정이나 데이터베이스 값에 이전 사이트 주소가 여전히 남아 있을 수 있습니다.
- 충돌하는 리디렉션, 캐싱, 보안 또는 쿠키 설정: URL, 쿠키 및 HTTPS 문제보다는 가능성이 낮지만, 정상적인 WordPress 로그인 동작을 재정의하거나 충돌을 일으킬 수 있습니다.
해결 방법
1. 문제가 브라우저별로 발생하는지 확인하세요
비공개 브라우징 창이나 다른 브라우저에서 wp-login.php를 여세요. 루프가 사라지면 원래 브라우저에서 문제가 발생하는 도메인의 쿠키와 사이트 데이터를 삭제한 다음 새 세션을 시작하세요.
이 테스트는 저장된 브라우저 상태와 서버 측 문제를 구분하는 데 도움이 되지만, 서버 설정이 올바르다는 것을 증명하지는 않습니다.
2. siteurl과 home을 확인하세요
데이터베이스 관리 도구 또는 신뢰할 수 있는 다른 유지 관리 방법을 사용하여 WordPress options table의 siteurl 및 home 항목을 확인하세요. 테이블에는 기본 wp_ 접두사가 아닌 사용자 지정 접두사가 사용될 수 있습니다.
수정하기 전에 데이터베이스를 백업하고 올바른 사이트에서 작업하고 있는지 확인하세요. 두 값은 다음 조건을 충족해야 합니다.
- 현재 도메인을 사용해야 합니다.
- 동일한 의도된 프로토콜을 사용해야 합니다. 일반적으로 사이트가 HTTPS로 구성되어 있다면 HTTPS를 사용합니다.
- 이전 도메인, 마이그레이션 주소 또는 의도하지 않은 다른 호스트 이름을 사용하지 않아야 합니다.
- 사용자가 실제로 사이트에 접속할 때 사용하는 주소와 일치해야 합니다.
값이 잘못되었다면 승인된 유지 관리 절차에 따라 일관되게 수정한 후 로그인 페이지를 다시 테스트하세요. 동시에 관련 없는 다른 설정을 변경하지 마세요.
3. 오래된 로그인 쿠키를 삭제하세요
문제가 발생하는 도메인의 쿠키와 사이트 데이터를 삭제하고 기존 로그인 탭을 닫은 다음 새 세션을 여세요. 가능하면 비공개 창에서도 다시 테스트하세요.
이는 도메인을 변경했거나 HTTPS를 활성화했거나 사이트를 이전한 후 특히 유용합니다. 쿠키를 삭제했을 때만 일시적으로 루프가 해결된다면 쿠키 삭제를 영구적인 해결책으로 간주하지 말고 URL 및 HTTPS 확인을 계속 진행하세요.
4. HTTPS 및 reverse proxy 동작을 확인하세요
reverse proxy, load balancer 또는 호스팅 계층이 요청이 WordPress에 도달하기 전에 SSL을 처리하는 경우, 올바른 HTTPS 상태를 전달하는지와 origin이 해당 구성에 맞게 설정되어 있는지 확인하세요.
브라우저, proxy, 웹 서버 및 WordPress는 해당 요청이 HTTPS인지에 대해 서로 일치해야 합니다. 흔한 장애 패턴은 HTTPS 요청이 origin에 HTTP로 전달된 후 HTTPS로 리디렉션되는 것입니다. 다음 요청도 같은 방식으로 해석되면서 순환이 반복됩니다.
호스팅 환경과 승인된 유지 관리 절차에 따라 변경 사항을 적용한 후 wp-login.php를 다시 테스트하세요. proxy 또는 서버 설정은 사이트 전체에 영향을 줄 수 있으므로 승인 없이 변경하지 마세요.
5. 최근 변경 사항을 검토하세요
마이그레이션, 도메인 변경, SSL 변경, proxy 변경 또는 호스팅 이전 후 루프가 시작되었다면 현재 설정을 이전 설정과 비교하세요. 이전 도메인 참조, 일치하지 않는 프로토콜, 이전 환경을 여전히 가리키는 쿠키 설정을 확인하세요.
6. 리디렉션 및 보안 충돌을 분리하세요
URL 값, 쿠키 및 HTTPS 구성이 올바르다면 리디렉션, 캐싱, 보안 및 쿠키 관련 설정을 검토하세요. 승인된 유지 관리 절차를 사용하고 백업을 보존하며 한 번에 하나의 설정만 변경하세요.
목표는 보호 기능을 영구적으로 비활성화하는 것이 아니라 로그인 동작을 변경하는 설정을 찾는 것입니다.
7. 다시 테스트하고 처음 예상과 다른 리디렉션을 기록하세요
변경할 때마다 새 브라우저 세션으로 시작하여 로그인 페이지에 직접 접속해 테스트하세요. 폼이 로드되는지, 인증 정보를 제출했을 때 로그인 페이지로 돌아가는지, 도메인 또는 프로토콜 간에 주소가 변경되는지 기록하세요.
처음 발생한 예상과 다른 리디렉션은 수정이 필요한 설정을 찾는 데 도움이 되는 경우가 많습니다.
예방 및 해결 확인 방법
- WordPress URL 설정을 변경하기 전에 의도한 도메인과 프로토콜을 기록하세요.
- 마이그레이션, URL 변경 또는 proxy 변경 전에 데이터베이스와 설정을 백업하세요.
- SSL 또는 proxy를 활성화한 후 깨끗한 브라우저 세션에서 프런트 엔드와
wp-login.php를 모두 테스트하세요. - 마이그레이션 후 이전 도메인 참조를 삭제하거나 업데이트하세요.
- proxy가 origin에 HTTPS를 전달하는 방식을 문서화하세요.
- 리디렉션, 보안, 캐싱 또는 쿠키 관련 설정은 한 번에 하나씩 변경하고 로그인 흐름을 다시 테스트하세요.
외부 도움을 받아야 할 때
데이터베이스에 액세스할 수 없거나, SSL이 proxy에서 종료되는지 알 수 없거나, 쿠키와 URL 값을 확인한 후에도 루프가 계속되면 호스팅 제공업체 또는 WordPress 관리자에게 문의하세요.
마이그레이션 후 어떤 데이터베이스 또는 설정 값이 기준이 되는지 확실하지 않다면 신속하게 에스컬레이션하세요. 대략적인 시작 시간, 최근 변경 사항, 비공개 브라우징에서 결과가 달라지는지 여부, 도메인 및 프로토콜 동작, 처음 발생한 예상과 다른 리디렉션을 전달하세요. 비밀번호나 인증 쿠키는 공유하지 마세요.
추가 문서
권위 있는 구현 세부 정보는 사이트 URL 변경, 로그인 쿠키, HTTPS 또는 reverse-proxy 구성을 다루는 WordPress 문서를 참고하세요. 또한 HTTPS 상태가 WordPress로 전달되는 방식을 확인하려면 해당 사이트의 호스팅 제공업체, proxy, load balancer 또는 웹 서버 문서도 참고하세요.