리디렉션 오류

이 오류 카테고리 소개

# 리디렉션 오류

리디렉션 오류는 요청이 한 URL에서 다른 URL로 전송되지만 최종 페이지에 도달하지 못하거나, 필요 이상으로 많은 리디렉션을 거칠 때 발생합니다. 일반적인 증상으로는 ERR_TOO_MANY_REDIRECTS, 주소 표시줄의 반복적인 변경, HTTP와 HTTPS URL의 교대, 여러 번의 리디렉션 후 페이지 로드 실패 등이 있습니다.

리디렉션은 일반적으로 HTTPS 적용, 선호 호스트 이름 선택, 이전 URL 이전, 새 경로로 요청 라우팅과 같은 정당한 목적으로 사용됩니다. 오류는 보통 여러 계층의 리디렉션 결정이 서로 충돌하거나 캐시된 상태로 인해 브라우저가 오래된 결과를 반복할 때 나타납니다.

리디렉션 오류의 주요 유형

리디렉션 루프

리디렉션 루프는 리디렉션 순서가 결국 이미 요청한 URL로 되돌아갈 때 발생합니다. 예를 들어 한 규칙이 HTTP를 HTTPS로 리디렉션하는 반면, 다른 규칙은 HTTPS 요청을 안전하지 않은 것으로 처리해 다시 HTTP로 보낼 수 있습니다. 브라우저는 사이클을 따라가다가 중지하고 너무 많은 리디렉션이 발생했다고 보고합니다.

호스트 이름, 후행 슬래시가 있는 경로와 없는 경로, 경로, 애플리케이션 URL과 프록시 URL 사이에서도 루프가 반복될 수 있습니다. WordPress에서는 HTTPS로 이전한 후 WordPress Address, Site Address, force-SSL 설정, 프록시 처리 및 서버 리디렉션이 동일한 공개 URL을 가리키지 않을 때 루프가 시작될 수 있습니다. 이 사례에 대한 자세한 내용은 [WordPress를 HTTPS로 이전한 후 너무 많은 리디렉션](/wordpress-too-many-redirects-https)을 참조하세요.

긴 리디렉션 체인

리디렉션 체인은 요청이 최종 목적지에 도달하기 전에 여러 리디렉션을 연속으로 거치는 경우를 말합니다. 이전 URL이 먼저 변경된 경로로 리디렉션된 다음 선호 호스트 이름으로, 마지막으로 HTTPS로 리디렉션될 수 있습니다. 여러 번의 이전 작업이나 겹치는 규칙 때문에 체인이 남을 수 있습니다.

체인은 결국 최종 응답에 도달하므로 루프와는 다릅니다. 그러나 탐색을 느리게 만들고 최종 목적지를 결정한 규칙이 무엇인지 파악하기 어렵게 할 수 있습니다. 유용한 진단 질문은 각 중간 리디렉션이 아직도 필요한지 여부입니다.

충돌하는 리디렉션 규칙

리디렉션 동작은 reverse proxy 또는 CDN, 호스팅 플랫폼, 웹 서버, 콘텐츠 관리 시스템, 애플리케이션 코드 또는 플러그인이 제어할 수 있습니다. 이러한 계층은 다음 사항에 대해 서로 다른 결정을 내릴 수 있습니다.

• 원래 요청이 HTTP 또는 HTTPS를 사용했는지 여부
• 어떤 호스트 이름이 canonical인지 여부
• 경로에 후행 슬래시를 포함해야 하는지 여부
• 이전 경로를 rewrite해야 하는지 redirect해야 하는지 여부
• 어떤 URL을 최종 애플리케이션 주소로 간주해야 하는지 여부

프록시는 방문자로부터 HTTPS를 수신한 후 다른 연결 스킴으로 origin에 전달할 수 있습니다. 애플리케이션이 전달된 스킴을 올바르게 해석하도록 설정되지 않았다면 방문자가 이미 HTTPS를 사용 중이어도 또 다른 HTTPS 리디렉션을 발생시킬 수 있습니다.

캐시된 리디렉션 또는 쿠키 관련 동작

비공개 브라우징 테스트를 통해 브라우저별 상태와 공유 구성 문제를 구분할 수 있습니다. 쿠키, 캐시된 응답 또는 애플리케이션 세션 상태가 이전 도메인, 로그인 흐름 또는 프로토콜 결정을 유지할 수 있습니다. 그렇다고 서버 구성이 올바르다는 의미는 아니며, 저장된 클라이언트 상태에 따라 결과가 달라질 수 있다는 뜻일 뿐입니다.

여러 브라우저와 다른 기기에서 동일한 URL이 루프를 일으킨다면 로컬 데이터를 반복해서 삭제하기보다 리디렉션 응답과 공유 구성을 우선적으로 확인하세요.

리디렉션 오류를 진단하는 방법

1. 시작 URL과 정확한 증상을 기록합니다. 스킴, 호스트 이름, 경로, 후행 슬래시, 브라우저 메시지 및 주소가 반복해서 변경되는지 여부를 기록하세요.
2. 새 브라우저 세션에서 테스트합니다. 비공개 창을 사용하거나 해당 사이트의 쿠키와 캐시된 데이터를 삭제합니다. 가능하면 다른 브라우저 또는 기기에서 결과를 비교하세요.
3. 리디렉션 이력을 추적합니다. 브라우저 개발자 도구 또는 HTTP 헤더 검사 도구를 사용하면 각 응답과 해당 Location 대상을 확인할 수 있습니다. 각 단계에서 반환된 상태를 확인하고, 반복되는 URL, 스킴 교대, 변경되는 호스트 이름 또는 불필요한 중간 주소가 있는지 살펴보세요.
4. 패턴을 분류합니다. 동일한 주소가 반복되면 루프입니다. 페이지에서 끝나는 순서라면 체인입니다. HTTP와 HTTPS 사이의 전환은 프로토콜 처리를, 호스트 이름이나 경로 사이의 전환은 canonicalization 또는 이전 규칙을 가리킵니다.
5. 공개 URL 설정을 확인합니다. 애플리케이션에 설정된 사이트 URL이 방문자에게 제공하려는 스킴 및 호스트 이름과 일치하는지 확인하세요. WordPress에서는 한 값만 변경하지 말고 WordPress Address와 Site Address를 비교하세요.
6. 외부 계층부터 내부 계층 순서로 리디렉션 계층을 검토합니다. CDN 또는 reverse proxy, 호스팅 설정, 웹 서버 규칙, 애플리케이션 구성, redirect 또는 SSL 플러그인을 확인하세요. 예상하지 못한 Location 응답을 생성한 계층부터 살펴보세요.
7. 최근 변경 사항을 신중하게 격리합니다. HTTPS 활성화, 도메인 변경, 사이트 이전, 고유주소 편집 또는 플러그인 설치 후 문제가 시작되었다면 해당 변경 사항과 리디렉션 순서를 비교하세요. 권한이 있고 이전 구성을 복원할 방법이 있을 때만 규칙을 비활성화하거나 변경하세요.
8. 원래 URL과 최종 URL을 다시 테스트합니다. 제어된 변경을 한 후에는 새 세션을 사용하세요. 원래 URL이 의도한 목적지에 도달하고 최종 URL에 더 이상 불필요한 리디렉션이 발생하지 않는지 확인하세요.

먼저 확인할 항목

HTTPS를 활성화한 후 오류가 시작된 경우

프로토콜 처리부터 확인하세요. HTTPS가 어디에서 종료되는지, 애플리케이션이 예상한 secure-request 정보를 수신하는지, 둘 이상의 계층에서 HTTPS를 적용하고 있는지 확인합니다. 이미 보안 연결인 요청을 HTTP로 되돌리거나 애플리케이션이 두 번째 HTTPS 리디렉션을 발생시키게 하는 규칙을 찾으세요.

도메인 또는 이전을 변경한 후 오류가 시작된 경우

이전 및 새 호스트 이름, 스킴, 경로와 후행 슬래시 동작을 비교하세요. 이전 리디렉션과 애플리케이션 URL 설정을 함께 검토합니다. 호스트 이름이 일부만 업데이트되었거나 여전히 이전 도메인을 대상으로 하는 리디렉션이 있으면 루프 또는 긴 체인이 발생할 수 있습니다.

특정 브라우저 또는 사용자에게만 영향을 미치는 경우

영향받은 사이트의 쿠키와 캐시된 데이터를 삭제한 상태에서 테스트하세요. 문제가 사라진다면 공유 서버 규칙을 변경하기 전에 저장된 세션 또는 리디렉션 상태를 조사합니다. 여러 브라우저와 기기에서 지속된다면 응답 헤더와 공통 프록시, 서버 또는 애플리케이션 구성을 중점적으로 확인하세요.

리디렉션 체인이 페이지에 도달하지만 비정상적으로 긴 경우

모든 중간 URL을 나열하고 어떤 규칙이 각 URL을 추가했는지 확인하세요. 적절한 경우 오래된 이전 규칙을 통합하되, 의도된 리디렉션은 유지하고 이전 URL이 올바른 최종 목적지에 계속 도달하는지 확인합니다.

참조할 공급업체 문서

구현별 세부 사항은 해당 요청에 관여하는 웹 서버, reverse proxy 또는 CDN, 호스팅 플랫폼, 콘텐츠 관리 시스템, redirect 또는 SSL 플러그인의 문서를 참조하세요. 해당 문서에서 HTTPS 종료, 전달된 프로토콜 헤더, canonical 호스트 리디렉션, 리디렉션 우선순위 및 캐시 무효화를 검색하세요. 올바른 설정은 원래 요청을 어느 계층이 수신하고 각 리디렉션을 어느 계층이 생성하는지에 따라 달라집니다.