Home Assistant는 리버스 프록시 뒤에서 실행할 수 있지만, 재작성된 하위 경로에서 안정적으로 제공하는 방식은 일반적으로 지원되는 배포 경계가 아닙니다.
example.com/homeassistant의 페이지가 HTML을 반환하더라도 이후 요청은 루트 기준 에셋, 인증 경로, WebSocket 또는 통합 콜백을 계속 대상으로 지정할 수 있습니다. 첫 화면만 확인하지 말고 새 브라우저에서 테스트하고, 로그인하고, 실시간 대시보드를 열고, 중첩된 경로를 새로 고침한 다음 콜백 하나를 완료하세요. 어떤 계층에서든 접두사가 사라지면 재작성 규칙을 추가하지 말고 Home Assistant를 자체 호스트 이름으로 옮기세요.
리버스 프록시 지원과 하위 경로 지원을 구분하세요
리버스 프록시는 TLS를 종료하고 호스트 이름 루트 요청을 Home Assistant로 전달할 수 있습니다. 하위 경로에는 다른 요구 사항이 추가됩니다. 생성되는 모든 URL, 에셋, API 호출, WebSocket, 리디렉션 및 콜백이 애플리케이션이 이해하는 접두사를 일관되게 유지해야 합니다. 프록시 계층에서 성공했다고 해서 애플리케이션 계약이 성립하는 것은 아닙니다.
Home Assistant 커뮤니티 테스트는 애플리케이션이 URL 접두사 아래 배포되는 방식을 지원하지 않는다는 결론에 이르렀습니다. Home Assistant를 하위 경로에 배치하는 방법에 대한 확정된 답변은 어떤 프록시를 선택하든 서브도메인을 권장합니다.
리버스 프록시 지원의 PASS는 올바른 전달을 통해 Home Assistant가 전용 호스트 이름의 루트에서 작동한다는 뜻입니다. 제안된 하위 경로의 FAIL은 하나 이상의 애플리케이션 경로에서 접두사가 사라진다는 뜻입니다. 이 두 판정을 합쳐 리버스 프록시 자체가 호환되지 않는다고 주장하지 마세요.
첫 번째 저위험 테스트로 프런트엔드 에셋을 사용하세요
Home Assistant를 변경하기 전에 비공개 브라우저 프로필에서 제안된 하위 경로를 열고 네트워크 요청을 확인하세요. 기본 문서는 로드되지만 JavaScript, 아이콘, 매니페스트 또는 번역 파일이 호스트 이름 루트에서 경로를 요청한다면, 토폴로지는 이미 첫 번째 가역적 판별 테스트에서 실패한 것입니다.
문서화된 경로 재작성 시도에서는 메인 페이지가 반환되었지만 프런트엔드 리소스가 Home Assistant 접두사 없이 슬래시로 시작하는 URL을 요청했습니다. 이 루트 기준 에셋 실패는 프록시에 파일이 없어서가 아니라 애플리케이션 경로가 일치하지 않아서 발생합니다.
PASS는 의도한 경로에서 모든 프런트엔드 리소스가 성공적으로 반환된다는 뜻입니다. FAIL은 404 응답이나 루트 경로 요청이 나타난다는 뜻입니다. 여기서 중단하고 전용 호스트 이름을 테스트하세요. 응답 본문 치환은 취약합니다. 향후 프런트엔드 빌드에서 재작성 규칙이 처리하지 못하는 새 경로가 추가될 수 있기 때문입니다.
WebSocket, 인증 및 중첩된 경로를 테스트하세요
정적 대시보드 셸만으로는 완전한 세션을 확인할 수 없습니다. 깨끗한 프로필에서 로그인하고, 몇 분 동안 엔터티 업데이트를 확인하고, 중첩된 대시보드 URL을 새로 고치고, 로그아웃한 다음 다시 로그인하세요. 그런 다음 HTTP 업그레이드, 토큰, 리디렉션 및 경로 새로 고침이 동일한 공개 오리진과 경로를 유지하는지 확인하세요.
Home Assistant는 실시간 프런트엔드 통신에 WebSocket을 많이 사용하므로 프록시는 업그레이드 경로와 헤더를 유지해야 합니다. 한 운영자의 리버스 프록시 WebSocket 처리 경험은 HTML만 로드하는 것이 충분한 호환성 테스트가 아닌 이유를 보여줍니다.
PASS는 인증, 실시간 업데이트, 탐색 및 직접 새로 고침이 경로 변환 오류 없이 모두 작동한다는 뜻입니다. 소켓이나 리디렉션에서만 FAIL이 발생하더라도 하위 경로 설계는 거부해야 합니다. 프록시 지시문 하나를 수정했다고 해서 콜백과 향후 경로가 접두사를 인식하게 된다는 증거는 아닙니다.
안정적인 경계로 전용 호스트 이름을 선택하세요
ha.example.com과 같은 전용 호스트 이름의 루트에서 Home Assistant를 제공한 다음, 리버스 프록시를 통해 해당 호스트 이름을 내부 서비스로 라우팅하세요. 이렇게 하면 애플리케이션이 경로 접두사를 이해하지 않아도 하나의 공개 오리진을 유지할 수 있습니다. 비공개 VPN이나 터널을 사용하면 공개적으로 노출하지 않고도 동일하게 깔끔한 루트 경계를 제공할 수 있습니다.
네트워크 변경 후 기존 원격 경로가 중단되면 DNS, 공개 주소, NAT, 터널 및 프록시 라우팅을 각각 독립적으로 확인하세요. 라우터 변경 후 원격 액세스에 대한 ZimaSpace 진단은 이러한 인접 경로를 점검하는 데 도움이 됩니다.
깨끗한 브라우저에서 에셋을 로드하고, WebSocket을 연결하고, 인증하고, 중첩된 경로를 새로 고치고, 프록시 재시작 후 Home Assistant에 연결할 수 있다면 대안이 통과한 것입니다. DNS 또는 프록시 변경을 되돌릴 수 있을 만큼만 기존 경로를 유지하세요. 모호한 공개 URL 두 개를 무기한 운영하지 마세요.
전체 세션이 재시작 후에도 유지되면 중단하세요
프록시와 Home Assistant를 각각 한 번씩 재시작한 다음 LAN과 예정된 원격 네트워크에서 전체 테스트를 반복하세요. 인증서 이름, 전달된 클라이언트 주소, 신뢰할 수 있는 프록시 경계, 로그인, 실시간 상태, 로그아웃 및 통합 콜백 하나를 확인하세요. 이것이 원래 작업 부하이며, 축소된 정적 페이지 확인이 아닙니다.
모든 단계를 통과한 루트 호스트 이름 설계에 대해서만 성공을 선언하세요. 사용자 지정 응답 재작성 후에만 작동하는 하위 경로는 업데이트로 에셋이나 콜백 동작이 바뀔 수 있으므로 운영상 지원되지 않는 부채로 남습니다. 정상 작동이 확인된 호스트 이름, 업스트림 주소 및 롤백 구성을 문서화하세요.
루트 호스트 이름 설계도 계속 실패한다면 원인은 기본 경로 지원이 아니라 프록시 신뢰, WebSocket 전달, DNS, 인증서 또는 라우팅일 가능성이 높으므로 에스컬레이션하세요. 원하는 URL 형태를 유지하기 위해 보호되지 않은 포트에서 Home Assistant를 직접 노출하지 마세요.
지원 및 팁
더 읽어보기

Home Assistant가 Wi-Fi에서는 작동하지만 이더넷이나 VPN에서는 작동하지 않음
각 네트워크 경로를 개별적으로 테스트하고, 인터페이스와 라우팅 상태를 확인한 다음, 직접 IP 연결과 검색 기능을 구분하여 실패한 계층만 복구하세요.

보호되지 않은 데이터를 남기지 않고 Home Assistant를 폐기하는 방법
교체 또는 보관을 입증하고, 모든 신뢰 경로를 폐기하며, 데이터를 저장하는 각 장치를 안전하게 삭제하고, 문서화된 보호 복구 사본만 보존하세요.

홈 서버에서 Home Assistant 자동 업데이트를 사용해야 할까요?
가정에 미치는 영향, 호환성 위험, 관찰 시간, 복구 준비 상태를 고려해 수동 업데이트, 알림만 제공, 또는 단계적 자동 업데이트를 선택하세요.

