Magento 리디렉션 루프는 아마 VPN 때문이 아닙니다

액세스 로그에 302가 보이고, 스토어프런트가 VPN으로 열리지 않으면 결론은 저절로 써집니다. 그 결론은 대개 흥미로운 방식으로 틀립니다. 리디렉션 응답은 브라우저에 가라고 지시한 목적지를 기록할 뿐, 터널이나 인증서 또는 애플리케이션이 문제를 일으켰는지는 말하지 않습니다. 로그 한 줄은 조사의 시작이지 결과가 아닙니다.

302는 어디로인지를 말하고 왜인지는 말하지 않습니다

액세스 로그 항목은 요청, 상태, 크기를 기록하고 중요한 Location 헤더는 보통 빠뜨립니다. 단일 리디렉션은 정규 호스트 이름, 끝 슬래시 정규화, HTTPS 전환처럼 완전히 정상일 수 있습니다. 필요한 것은 순서인데, 한 번의 도약과 루프는 원인이 다른 별개의 장애이기 때문입니다. 스킴 사이를 반복해서 도약하면 URL과 스킴 처리를 가리킵니다. 반면 브라우저가 해석할 수 없는 이름으로 도약하면 전혀 다른 곳을 가리킵니다.

어느 것도 VPN에 대한 증거가 아닙니다. 터널은 경로이고, 리디렉션은 애플리케이션이 쓴 지시입니다.

로그 한 줄이 아니라 체인을 기록하세요

브라우저의 네트워크 보기를 사용해 도약마다 요청 URL, 상태, Location 헤더, 시간의 네 항목을 적습니다. 흥미로운 사례는 결코 완료되지 않는 도약이므로, 마지막은 최종 응답이나 연결 오류로 끝냅니다. 작동하는 경로에서 한 번, 실패하는 경로에서 한 번, 같은 계정과 같은 탐색으로 하세요. 두 체인을 비교하는 것이 로그의 어떤 한 줄보다 값집니다.

그 기록은 비공개로 두세요. URL은 세션 식별자를 담고, 저장된 브라우저 아카이브는 예상보다 많은 것을 담습니다. 티켓에 붙이기 전에 쿼리 문자열을 제거하세요.

애플리케이션이 자기 URL에 대해 갖는 생각

Magento는 구성에서 절대 URL을 생성하며 웹사이트나 스토어 뷰별로 범위를 정합니다. bin/magento config:show web/secure/base_url는 애플리케이션이 믿는 값을 출력하는데, 그것은 브라우저가 쓴 이름이 아니라 빌드나 마이그레이션에서 남은 호스트 이름인 경우가 많습니다. 거기에 내부 호스트가 적혀 있으면 브라우저는 갈 수 없는 곳으로 보내지고, 터널을 바꿔도 고쳐지지 않습니다.

보안 및 비보안 기본 URL을 눈앞의 공개 이름과 비교하세요. 둘 중 하나라도 어긋나면 지금 보고 있는 바로 그 리디렉션이 생깁니다.

신뢰하는 프록시 헤더는 계약입니다

TLS가 로드 밸런서에서 끝나면 애플리케이션은 평문 HTTP를 보고, 그렇지 않다고 알려야 합니다. 오프로더 헤더 설정은 전달된 프로토콜처럼 프록시가 설정하는 헤더 이름을 지정하며, 애플리케이션은 스킴 결정에서 그것을 신뢰합니다.

그 신뢰는 하나의 프록시와 맺은 계약이지 일반적인 허가가 아닙니다. 임의의 클라이언트에서 헤더를 받아들이면 누구나 스킴을 주장할 수 있으므로, 지정된 프록시가 설정하는 곳에만 두어야 합니다. 헤더 이름과 프록시 동작이 어긋나면 애플리케이션은 브라우저가 한 번도 쓰지 않은 스킴으로 리디렉션을 만들고 루프가 닫힙니다. 프록시 구성과 애플리케이션 설정을 함께 확인한 뒤 변경이 적용되도록 구성 캐시를 비우세요.

루프가 경로가 아니라 세션일 때

항상 로그인으로 돌아가는 체인은 대개 쿠키 문제입니다. 세션 쿠키가 브라우저가 실제로 쓴 호스트 이름에 발급되었는지, 브라우저가 안전하다고 보는 연결에서 보안으로 표시되었는지 확인하세요. 잘못된 도메인에 묶인 쿠키는 라우팅 실패와 똑같이 보이는 로그인 루프를 만듭니다.

입증된 불일치를 기본 URL, 쿠키 도메인, 프록시 계약 중 어디에 있든 그 주인에게서 고친 뒤, 302 하나가 사라지는 것을 지켜보는 대신 전체 탐색을 다시 시험하세요. 루프를 끊으려고 HTTPS 요구 사항을 끄는 것은 리디렉션을 더 나쁜 문제와 맞바꾸는 일입니다. 변경이 끝나면 터널을 따로 확인하되, 알려진 비공개 리소스를 요청해 도착하는지 확인하면 다음 리디렉션에 비교할 깨끗한 기준이 생깁니다.