리버스 프록시를 다시 시작한 후 Home Assistant 로그인이 실패하는 이유는 무엇인가요?

에바 왕

IceWhale author

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

Why Does Home Assistant Login Fail After a Reverse Proxy Restart? - Zima Store Online

역방향 프록시를 다시 시작한 후에만 Home Assistant 로그인이 실패한다면, 먼저 직접 LAN 로그인을 테스트하고 프록시 경로가 분리될 때까지 사용자 데이터베이스를 변경하지 마세요.

프록시를 다시 시작하면 Home Assistant 비밀번호를 변경하지 않아도 컨테이너 주소, 전달된 클라이언트 정보, WebSocket 처리, DNS 대상 또는 업스트림 백엔드가 달라질 수 있습니다. 따라서 계정 삭제나 일괄 세션 초기화는 우선 시도하기에 적절하지 않습니다. 직접 Home Assistant URL과 일반적인 프록시 호스트 이름을 비교하고, 브라우저 및 프록시 오류를 저장한 다음, 인증 전에 실패하는지, 로그인 요청 중에 실패하는지, 아니면 프런트엔드가 지속 연결을 열 때 실패하는지 확인하세요.

Home Assistant 인증과 프록시 경로를 분리해 확인하기

동일한 정상 계정을 사용해 직접 연결하는 로컬 Home Assistant 주소와 공개 또는 내부 프록시 호스트 이름으로 각각 로그인하세요. 직접 로그인은 되지만 프록시 경로가 실패한다면 계정과 Core 인증 상태는 그대로 두어도 될 가능성이 높습니다. 두 경로 모두 실패한다면 Home Assistant, 복원된 상태 또는 자격 증명 자체를 다시 조사하세요.

한 역방향 프록시 로그인 사례에서는 WebSocket 및 프록시 세부 설정을 수정하기 전까지 직접 연결과 Apache 경로의 동작이 달랐습니다. 이러한 직접 연결과 프록시 비교가 비밀번호를 반복해서 변경하는 것보다 문제를 진단하는 데 효과적입니다.

설정을 변경하기 전에 HTTP 상태 코드, 리디렉션 체인, 브라우저 콘솔 오류, 프록시 업스트림 응답 및 해당 Home Assistant 로그의 타임스탬프를 기록하세요. 신뢰할 수 없는 프록시에서 발생한 400 오류, 실패한 WebSocket, 잘못된 스킴으로의 리디렉션, 잘못된 비밀번호는 화면에 동일한 일반적인 연결 불가 메시지가 표시되더라도 서로 다른 문제입니다.

네 가지 프록시 측 원인은 서로 다른 증상을 남깁니다

일반적인 원인은 변경된 프록시 소스 주소가 더 이상 신뢰할 수 있는 프록시 규칙과 일치하지 않는 경우, 전달 헤더 또는 스킴이 변경된 경우, WebSocket 업그레이드 처리가 중단된 경우, 잘못된 Home Assistant 백엔드로 라우팅되는 경우입니다. 프록시 컨테이너를 새로 만들면 Home Assistant 인스턴스 자체는 안정적으로 유지되는 동안 이 중 하나가 변경될 수 있습니다.

최근의 역방향 프록시 문제 해결 사례에서는 즉시 연결되는 프록시를 올바른 신뢰 프록시 범위에 배치할 때까지 Home Assistant가 전달된 트래픽을 거부했습니다. 이 신뢰할 수 있는 프록시 식별 확인은 범위를 영구적으로 넓히는 것보다 안전합니다. 실제로 Home Assistant에 도달하는 프록시 주소를 확인하고 해당 경계만 신뢰하세요.

아래 증상을 활용해 한 번에 하나의 원인만 변경하세요. 테스트가 끝난 후에는 넓은 신뢰 프록시 범위를 그대로 두지 마세요. 위조된 전달 클라이언트 주소에 대한 중요한 보호 기능이 사라집니다.

원인 1: 다시 시작하면서 프록시 소스 주소가 변경됨

증상: 요청이 즉시 거부되고 Home Assistant 로그에 신뢰할 수 없는 역방향 프록시가 표시됩니다.
확인: 프록시 컨테이너의 서브넷 및 주소를 설정된 신뢰 범위와 비교합니다.
IF–THEN: 올바른 좁은 신뢰 범위를 복원해 로그인이 해결된다면 계정과 세션 상태는 변경하지 않습니다.

원인 2: 전달된 호스트 또는 스킴이 공개 출처와 더 이상 일치하지 않음

증상: 리디렉션이 HTTP와 HTTPS 또는 다른 호스트 이름 사이를 오가거나, 쿠키가 예상하지 못한 출처에 연결된 것처럼 보입니다.
확인: 다시 시작하기 전과 후의 Host 및 전달된 스킴을 비교합니다.
IF–THEN: 해당 값을 수정해 리디렉션 및 로그인 반복이 해결된다면, 문제는 Home Assistant 사용자 계정이 아니라 수신 경로의 식별 정보였습니다.

원인 3: 로그인 페이지는 로드되지만 WebSocket 업그레이드가 실패함

증상: 정적 UI는 로드되지만 프런트엔드 연결이 끊기거나 초기화를 완료하지 못합니다.
확인: 브라우저의 WebSocket 요청과 프록시 업그레이드 헤더를 확인합니다.
IF–THEN: 직접 연결에서는 WebSocket이 열린 상태로 유지되지만 호스트 이름을 통한 연결에서는 그렇지 않다면 계속 프록시 계층을 조사합니다.

원인 4: 프록시가 다른 백엔드 또는 새로 생성된 백엔드를 가리킴

증상: 서버가 새로 구성된 것처럼 보이거나, 기존 사용자가 사라지거나, 프록시를 통한 서버별 상태가 달라집니다.
확인: 업스트림 주소, 인스턴스 식별 정보 및 구성 경로를 비교합니다.
IF–THEN: 프록시가 잘못된 컨테이너 또는 복원된 인스턴스에 연결된다면 인증 데이터를 변경하기 전에 라우팅을 수정합니다.

WebSocket 동작을 확인해 프런트엔드 문제를 로그인 실패로 오인하지 않기

Home Assistant 프런트엔드는 초기 HTTP 교환 후 지속적인 WebSocket 연결을 사용합니다. 따라서 프록시가 로그인 페이지는 정상적으로 제공하면서도 잠시 후 연결 업그레이드 또는 연결 유지에 실패할 수 있습니다. 이 과정이 자격 증명을 제출한 직후 발생하기 때문에 사용자는 이를 로그인 실패라고 설명하는 경우가 많습니다.

Synology의 Home Assistant 역방향 프록시 구성 사례에서는 로그인 경로에 도달했지만 WebSocket 업그레이드 처리를 수정하기 전까지 계속 실패했습니다. 프록시된 WebSocket 업그레이드 동작을 확인하면 HTTP 로그인 경로가 이미 정상인데도 사용자를 재설정하는 낭비를 막을 수 있습니다.

소켓이 실패한다면 HTTP/1.1 업그레이드 처리, 시간 초과, TLS 종료, 호스트 이름, 그리고 프록시 앞단의 CDN 또는 인증 미들웨어를 확인하세요. 변경 범위는 좁게 유지하세요. 실패한 요청을 통해 필요한 이유가 입증되지 않았다면 다른 프록시 스택에서 복사한 관련 없는 헤더를 추가하지 마세요.

-15% OFF

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

Single board computer zimaboard2

프록시를 두 번 다시 시작하고 클린 클라이언트에서 수정 사항을 검증하기

일치하는 수정 사항을 적용한 후 일반 호스트 이름을 통해 로그인 및 로그아웃하고, 대시보드를 충분히 오래 열어 WebSocket이 안정적으로 유지되는지 확인하세요. 그런 다음 시크릿 브라우저 창 또는 두 번째 클라이언트에서 반복합니다. 컨테이너 주소나 네트워크가 의심되는 원인에 포함된다면 프록시를 두 번 다시 시작하고 프록시 호스트도 재부팅하세요.

ZimaSpace의 LAN 및 원격 Home Assistant 경로 비교도 동일한 분리 원칙을 적용합니다. 원격 연결에 사용되는 추가 DNS, TLS, 프록시 및 라우팅 계층을 테스트하는 동안 정상적인 로컬 애플리케이션 경로는 유지하는 것입니다.

직접 연결과 프록시 연결 모두 동일한 Home Assistant 인스턴스에 도달하고, 예상되는 좁은 프록시 주소가 신뢰되며, 리디렉션이 의도한 스킴과 호스트를 유지하고, WebSocket이 정상 사용 중에도 유지되며, 프록시를 다시 시작해도 결과가 달라지지 않으면 통과입니다. 동일한 정상 계정이 직접 연결에서도 실패할 때만 Home Assistant 인증 문제로 확대 조사하세요.