プロキシやDNSの変更後にHome Assistantのセッションが失われるのはなぜですか？
プロキシまたはDNSの変更後にセッションが失われる場合、通常はユーザーアカウントの破損ではなく、クライアントが使用するURLのオリジンと、現在Home Assistantが認識しているルートの不一致が原因です。
ブラウザーには古いホスト名のCookieやフロントエンドの状態が残っている一方で、スマートフォンは新しいアドレスを解決している可能性があります。また、プロキシがログインページは配信できても、認証済みWebSocketに失敗することもあります。まずプライベートブラウザーウィンドウを1つ開き、直接LAN接続で1回テストして、それぞれの結果について正確なスキームとホスト名を記録してください。問題の層を特定するまでは、すべてのセッションを削除しないでください。
単一クライアントの状態と共有経路の障害を切り分ける
意図した最終URLを使ってプライベートウィンドウでHome Assistantを開き、影響を受けているブラウザーやモバイルアプリと比較します。ログインが完了するか、ダッシュボードが5分間接続されたままになるか、ページを更新してもセッションが維持されるかを記録してください。この可逆的な比較により、サーバーを変更せずに古いクライアント状態を検証できます。
プロキシはログインページを返しても、認証後のフロントエンドで接続できないと表示されることがあります。このログイン成功後の接続失敗は、HTMLが表示されることだけではセッション経路全体が機能している証明にならない理由を示しています。
古いブラウザーだけが失敗し、プライベートウィンドウが安定している場合は、そのクライアントで古いHome Assistantオリジンと新しいHome Assistantオリジンのサイトデータを削除してから、再度サインインしてください。プロキシURLではすべてのクライアントが失敗する一方、直接LAN接続は機能する場合は、クライアントの状態を保持したままプロキシ経路を調査します。
WebSocketと転送オリジンの処理を確認する
ログイン中にブラウザーのネットワーク表示またはプロキシログを確認し、WebSocketアップグレード、ステータス、切断までの時間、転送されたスキーム、転送されたホスト、クライアントアドレスを確認します。重要なのは、HTTPページが読み込まれることと、認証済みの永続チャネルがアップグレードされて開いたままになることを区別することです。
Home Assistantのリバースプロキシのトラブルシューティングでは、通常のHTTPプロキシとは別にWebSocket転送が必要だと繰り返し指摘されています。この仕組みはアップグレード経路を解釈するためだけに使用し、1つのNginx設定がすべてのプロキシに適合する証拠とはみなさないでください。
アップグレードに失敗する場合は、ログから誤りが確認できるプロキシルート、アップグレードヘッダー、転送スキーム、または信頼済みプロキシの境界だけを修正します。成功して接続が維持される場合は、プロキシを変更せず、DNSとクライアントのオリジン状態を調査してください。
DNSの応答と最終URLを比較する
問題が発生しているクライアント、正常なクライアント、プロキシホストからHome Assistantのホスト名を解決します。IPv4、IPv6、スプリットDNSの応答、証明書名、リダイレクト先、コンパニオンアプリに保存されているURLを比較してください。DNSの変更が完了したといえるのは、クライアントが同じ正規ホスト名で意図したエンドポイントに到達できるようになったときです。
検出、名前解決、ルーティングの関係については、Home Assistantの到達性モデルで詳しく説明されています。これを使って、古いDNS応答とセッション層の障害を切り分けてください。
クライアントごとに異なるエンドポイントが解決される場合は、記録されているTTLが経過するのを待つか、影響を受けているクライアントとローカルリゾルバーだけでリゾルバーキャッシュを消去します。競合する一時的なホスト名は作成しないでください。オリジンを追加するたびに、別のCookieとリダイレクトの境界が生まれるためです。
元のセッション経路を再テストし、必要な範囲だけエスカレーションする
最終的な公開URLまたはプライベートURLからサインインし、ダッシュボードを開いたままにして、ネストされたビューを再読み込みします。リモートアクセスが設計に含まれる場合は、ネットワークを1回切り替え、さらにクライアントを1回再起動して再テストします。合格条件は、同じ正規URL、安定したWebSocket、そして元のトリガー後も更新と再接続をまたいでセッションが維持されることです。
クリーンなクライアントでは成功するのに、既存のクライアントの1つだけが失敗し続ける場合は、そのクライアントのプロファイルまたはアプリ接続だけを修復します。すべてのプロキシクライアントが同じアップグレードまたはリダイレクトの証拠とともに失敗する場合は、別の変更を試す前に、直前のプロキシまたはDNS変更をロールバックし、ログを保存してください。
正確な失敗URLの種類、DNS応答、プロキシのステータスコード、WebSocketの結果、タイムスタンプ、クライアント間の比較結果を添えてエスカレーションしてください。2台の異なるクライアントで、更新と再接続を行ってもセッションが維持されることを確認できたら終了します。それ以上Cookieやプロキシを変更しても、診断上の価値よりリスクのほうが大きくなります。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
