프록시 또는 DNS 변경 후 Home Assistant의 세션이 손실되는 이유는 무엇인가요?

프록시 또는 DNS 변경 후 세션이 손실되는 문제는 대개 손상된 사용자 계정 때문이 아니라, 클라이언트가 사용하는 URL 오리진과 이제 Home Assistant가 인식하는 경로가 일치하지 않아서 발생합니다.

브라우저에는 이전 호스트 이름의 쿠키와 프런트엔드 상태가 아직 남아 있는 반면, 휴대폰은 새 주소를 확인할 수 있습니다. 또는 프록시가 로그인 페이지는 제공하지만 인증된 WebSocket 연결에 실패할 수도 있습니다. 먼저 시크릿 브라우저 창 하나와 직접 LAN 테스트 하나로 시작하고, 각 결과의 정확한 스킴과 호스트 이름을 기록하세요. 문제가 발생한 계층을 확인하기 전에는 모든 세션을 삭제하지 마세요.

단일 클라이언트 상태와 공유 경로 장애 분리하기

의도한 최종 URL을 사용해 시크릿 창에서 Home Assistant를 연 다음, 문제가 있는 브라우저 및 모바일 앱과 비교하세요. 로그인이 완료되는지, 대시보드 연결이 5분 동안 유지되는지, 페이지를 새로 고쳐도 세션이 유지되는지를 기록하세요. 이 되돌릴 수 있는 비교를 통해 서버를 변경하지 않고 오래된 클라이언트 상태를 확인할 수 있습니다.

프록시는 로그인 페이지를 반환한 뒤 인증된 프런트엔드에서 연결할 수 없다는 오류를 표시할 수 있습니다. 이러한 로그인 성공 후 연결 실패는 HTML이 렌더링된다는 사실만으로 전체 세션 경로가 정상이라고 볼 수 없는 이유를 보여 줍니다.

기존 브라우저에서만 문제가 발생하고 시크릿 창은 안정적으로 유지된다면, 해당 클라이언트에서 기존 및 새 Home Assistant 오리진의 사이트 데이터를 삭제한 후 다시 로그인하세요. 프록시 URL에서는 모든 클라이언트가 실패하지만 직접 LAN 접근은 정상이라면 클라이언트 상태를 유지하고 프록시 경로를 점검하세요.

WebSocket 및 전달된 오리진 처리 확인하기

로그인하는 동안 브라우저의 네트워크 보기 또는 프록시 로그를 확인하고 WebSocket 업그레이드, 상태, 연결 해제 시점, 전달된 스킴, 전달된 호스트, 클라이언트 주소를 살펴보세요. 중요한 구분은 HTTP 페이지가 로드되는지와 인증된 지속 채널이 업그레이드된 후 계속 열려 있는지입니다.

Home Assistant 리버스 프록시 문제 해결 과정에서는 일반적인 HTTP 프록시와 별도로 WebSocket 전달이 필요하다는 점을 반복해서 확인합니다. 이 메커니즘은 업그레이드 경로를 해석하는 데만 사용하고, 하나의 Nginx 설정이 모든 프록시에 적합하다는 증거로 사용하지 마세요.

업그레이드에 실패한다면 로그에서 잘못된 것으로 나타난 프록시 경로, 업그레이드 헤더, 전달된 스킴 또는 신뢰할 수 있는 프록시 경계만 수정하세요. 업그레이드가 성공하고 연결이 유지된다면 프록시는 그대로 두고 DNS 및 클라이언트 오리진 상태를 조사하세요.

DNS 응답과 최종 URL 비교하기

문제가 발생한 클라이언트, 정상 작동하는 클라이언트, 프록시 호스트에서 Home Assistant 호스트 이름을 확인하세요. IPv4, IPv6, 분할 DNS 응답, 인증서 이름, 리디렉션 대상, 컴패니언 앱에 저장된 URL을 비교하세요. 클라이언트가 동일한 표준 호스트 이름으로 의도한 엔드포인트에 도달할 때에만 DNS 변경이 완료된 것입니다.

검색, 이름 확인, 라우팅 간의 더 넓은 관계는 Home Assistant 도달성 모델에 정리되어 있습니다. 이를 활용해 오래된 DNS 응답과 세션 계층 문제를 구분하세요.

클라이언트가 서로 다른 엔드포인트로 확인된다면 문서화된 TTL이 만료될 때까지 기다리거나, 문제가 있는 클라이언트와 로컬 리졸버에서만 리졸버 캐시를 삭제하세요. 임시 호스트 이름을 여러 개 만들어 경쟁시키지 마세요. 오리진이 추가될 때마다 또 다른 쿠키 및 리디렉션 경계가 생깁니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

기존 세션 경로를 다시 테스트하고 범위를 좁혀 에스컬레이션하기

최종 공개 또는 비공개 URL을 통해 로그인하고, 실시간 대시보드를 열어 둔 상태에서 중첩된 보기를 새로 고치세요. 원격 접근이 설계에 포함되어 있다면 네트워크를 한 번 전환하고, 클라이언트를 한 번 재시작한 후 다시 반복하세요. 테스트가 통과하려면 원래 문제를 유발한 상황에서도 동일한 표준 URL, 안정적인 WebSocket, 새로 고침 후에도 유지되는 세션이 필요합니다.

깨끗한 클라이언트는 정상 작동하지만 기존 클라이언트 하나만 계속 실패한다면 해당 클라이언트 프로필 또는 앱 연결만 복구하세요. 동일한 업그레이드 또는 리디렉션 증거와 함께 모든 프록시 클라이언트가 실패한다면 마지막 프록시 또는 DNS 변경을 되돌리고, 다른 변경을 시도하기 전에 로그를 보존하세요.

문제가 발생한 정확한 URL 유형, DNS 응답, 프록시 상태 코드, WebSocket 결과, 타임스탬프, 클라이언트 비교 결과를 포함해 에스컬레이션하세요. 서로 다른 두 클라이언트에서 새로 고침 및 재연결 후에도 세션이 유지되면 중단하세요. 그 이후의 추가 쿠키 또는 프록시 변경은 진단 가치 없이 위험만 높입니다.