리버스 프록시가 다시 시작된 후 Immich 로그인 실패

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Immich Login Fails After the Reverse Proxy Restarts - Zima Store Online

리버스 프록시를 재시작한 후에만 Immich 로그인이 실패한다면, 먼저 Immich 애플리케이션과 계정이 직접 접속에서는 여전히 작동하는지 확인하여 프록시 경로가 중단되었는지 입증하세요.

재시작으로 오래된 업스트림 주소, 공유 네트워크 멤버십 누락, 헤더 변경, 쿠키 동작 문제 또는 종속 항목에 연결되기 전에 다시 시작된 프록시 프로세스가 드러날 수 있습니다. 로컬 Immich 엔드포인트와 일반 공개 호스트 이름을 통해 동일한 계정으로 테스트한 다음, 두 경로가 처음으로 달라지는 계층을 따라가세요.

직접 접속으로 인증 문제와 프록시 실패를 구분하세요

신뢰할 수 있는 로컬 경로를 통해 리버스 프록시를 우회하여 알려진 계정으로 Immich 서버에 접속해 보세요. 직접 로그인이 성공하는데 공개 호스트 이름에서는 로딩이 계속되거나 리디렉션되거나 업스트림 오류가 반환된다면, 사용자 레코드와 핵심 인증 경로는 정상일 가능성이 높습니다. 조사는 프록시, TLS, 라우팅 및 브라우저 상태에 집중하세요.

직접 접속은 작동했지만 프록시를 통한 로그인은 실패한 사례는 이러한 격리 방법을 보여 줍니다. 해당 보고서는 특정 버전에 관한 것이므로, 동일한 근본 원인이라고 단정하기보다 두 경로를 비교하는 근거로 활용하세요.

직접 로그인과 프록시 로그인 모두 실패한다면 프록시 설정 변경을 중단하세요. 대신 Immich 서비스 상태, 데이터베이스 연결, 계정 상태 및 서버 로그를 확인하세요. 실패 시점과 가까운 프록시 재시작은 우연일 수 있습니다. 우회 테스트를 통해 그러한 시간적 일치를 근거 없는 진단으로 확대하지 않도록 할 수 있습니다.

프록시가 현재 Immich 업스트림에 연결할 수 있는지 확인하세요

프록시가 재시작된 후 자체 네트워크 네임스페이스에서 Immich 업스트림을 확인하고 연결할 수 있는지 검증하세요. Docker에서는 컨테이너가 재생성될 때 변경되는 컨테이너 IP를 수동으로 복사해 사용하는 것보다, 공유 사용자 정의 네트워크에 연결된 서비스 이름을 업스트림으로 사용하는 편이 일반적으로 더 안정적입니다.

프록시와 Immich 간 연결을 다룬 리버스 프록시 장애 논의는 계정 복구를 시도하기 전에 업스트림 연결 가능성과 WebSocket을 지원하는 프록시 설정을 확인해야 하는 이유를 보여 줍니다. 해당 설정의 세부 내용은 일화적 근거로만 취급하고, 모든 프록시에 적용할 템플릿으로 사용하지 마세요.

프록시만 두 번 재시작하면서 매번 업스트림이 동일한 서비스로 확인되는지 관찰하세요. 주소를 수정하지 않고 즉시 성공적으로 연결되면 통과입니다. 컨테이너 재생성 후 이름 확인, 네트워크 멤버십 또는 대상 포트가 변경된다면 스택을 반복해서 재시작하지 말고 Compose 네트워크 정의를 수정하세요.

전달 헤더, TLS 및 쿠키 동작을 점검하세요

프록시가 Immich 페이지를 반환하더라도 인증은 전체 HTTP 경로에 의존하므로 로그인이 실패할 수 있습니다. 재시작 전후의 프록시 설정을 비교하세요. 여기에는 호스트와 스킴 전달, HTTPS 종료, 리디렉션, 쿠키 재작성 여부, 그리고 두 번째 프록시나 터널이 응답을 추가로 수정하는지 여부가 포함됩니다.

한 Immich 커뮤니티 논의에서는 중복 쿠키로 인한 로그인 사례가 기록되어 있으며, 프록시의 쿠키 처리로 로그인 멈춤 현상이 발생했습니다. 이는 제한적인 사례이지만, 올바른 자격 증명이라도 프록시를 통한 세션 성공을 보장하지는 않으므로 브라우저 응답과 쿠키를 확인해야 한다는 점을 상기시켜 줍니다.

브라우저 세션이 멈춘 것처럼 보인다고 해서 모든 계정을 삭제하거나 데이터베이스를 재설정하지 마세요. 먼저 원래 쿠키와 응답을 기록한 뒤 시크릿 창이나 다른 브라우저를 사용하세요. 깨끗한 클라이언트에서 작동한다면 영향을 받은 사이트 상태만 삭제하고 잘못된 쿠키나 리디렉션을 만든 프록시 규칙을 수정하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

실패한 요청의 타임스탬프에서 프록시 액세스 및 오류 로그를 확인하세요

로그인 시도를 한 번 재현하고 정확한 시간, 공개 호스트 이름, 클라이언트 및 반환된 상태를 기록하세요. 그런 다음 해당 요청 전후의 프록시 액세스 로그와 오류 로그를 확인하세요. 요청이 프록시에 도달하지 못한 경우, 프록시가 생성한 4xx 또는 5xx 응답, 업스트림 연결 실패, Immich에 도달했지만 애플리케이션 응답을 받은 요청을 구분하세요.

NGINX 로그 문제 해결 워크플로는 상태 코드, 업스트림 오류, 요청 시간 및 대상 로그가 로그인 페이지를 반복해서 새로 고치는 것보다 훨씬 강력한 신호를 제공하는 방식을 보여 줍니다. Caddy, Traefik 또는 다른 프록시에도 같은 원칙을 적용하세요.

프록시 로그에 업스트림 응답 성공이 표시되는데 브라우저에서 로그인이 완료되지 않는다면 리디렉션, 쿠키, TLS 및 클라이언트 상태를 점검하세요. 프록시가 업스트림에 연결하지 못한다면 라우팅 또는 서비스 준비 상태를 수정하세요. Immich 자체가 오류를 반환한다면 프록시를 원인으로 취급하지 말고 해당 서버 로그를 따라가세요.

처음 문제를 일으킨 재시작 후에도 수정 사항이 유지되는지 확인하세요

확인된 원인을 수정한 뒤, 문제를 처음 일으킨 동작을 정확히 반복하세요. 리버스 프록시만 재시작하고 상태 확인이 완료될 때까지 기다린 다음 공개 호스트 이름으로 로그인하세요. 그런 다음 기존 자산을 열고 작은 파일을 업로드하며 세션을 충분히 유지하여 정상적인 API 트래픽이 발생하는지 확인하세요.

ZimaSpace의 통제된 원격 접속 경로 가이드는 더 넓은 범위를 제시합니다. 원격 접속에서 프록시는 하나의 계층일 뿐이므로 DNS, TLS, 인증 및 비공개 업스트림을 의도적으로 구성하고 관찰할 수 있어야 합니다.

프록시를 두 번 재시작한 후에도 로그인이 유지되고, 전체 스택을 재시작한 뒤에도 동일한 설정으로 정상 시작될 때만 통과로 판단하세요. 새로운 헤더나 쿠키 규칙이 문제를 만들었다면 최근 프록시 변경 사항을 되돌리세요. 프록시 설정 차이, 요청 상태, 업스트림 오류, 서버 로그 타임스탬프 및 직접 접속과 프록시 접속 테스트 결과를 함께 제출하여 지원을 요청하세요.