リバースプロキシの再起動後に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、誤ったスキームへのリダイレクト、無効なパスワードは、画面に同じ一般的な接続エラーが表示されても、それぞれ異なる問題です。

プロキシ側の4つの原因には、それぞれ異なる兆候がある

一般的な分岐は、プロキシの送信元アドレスが変わり、信頼済みプロキシのルールに一致しなくなった場合、転送ヘッダーまたはスキームが変わった場合、WebSocketのアップグレード処理が壊れた場合、そして別のHome Assistantバックエンドへルーティングされている場合です。プロキシコンテナの再作成によって、Home Assistant自体が安定していても、これらのいずれかが変わることがあります。

最近のリバースプロキシのトラブルシューティング事例では、直近のプロキシを正しい信頼済み範囲に設定するまで、Home Assistantが転送トラフィックを拒否していました。この信頼済みプロキシの識別確認は、範囲を恒久的に広げるより安全です。実際にHome Assistantへ到達しているプロキシのアドレスを確認し、その境界だけを信頼してください。

以下の兆候を使い、一度に1つの分岐だけを変更してください。テスト後に広すぎる信頼済みプロキシ範囲を残さないでください。転送されたクライアントアドレスの偽装に対する重要な防御が失われます。

原因1：再起動によってプロキシの送信元アドレスが変わった

兆候：リクエストが直ちに拒否され、Home Assistantのログに信頼されていないリバースプロキシが示される。
確認：プロキシコンテナのサブネットまたはアドレスと、設定された信頼済み範囲を比較する。
IF–THEN：正しい狭い範囲の信頼設定に戻すことでログインが直る場合は、アカウントとセッションの状態を変更しない。

原因2：転送されたホストまたはスキームが公開オリジンと一致しなくなった

兆候：HTTPとHTTPS、または別のホスト名の間でリダイレクトが繰り返されるか、Cookieが予期しないオリジンに関連付けられているように見える。
確認：再起動前後で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

2回のプロキシ再起動とクリーンなクライアントで修正を検証する

適切な修正を行った後、通常のホスト名を使ってログインとログアウトを行い、ダッシュボードを十分な時間開いてWebSocketが安定していることを確認します。その後、プライベートブラウザーウィンドウまたは2台目のクライアントでも繰り返してください。コンテナのアドレスまたはネットワークが疑わしい原因に関係している場合は、プロキシを2回再起動し、プロキシホストも再起動します。

ZimaSpaceによるLANとリモートのHome Assistant経路の比較にも、同じ切り分けの原則が当てはまります。ローカルアプリケーションの正常な経路を維持しながら、リモートで使用される追加のDNS、TLS、プロキシ、ルーティング層をテストしてください。

直接ログインとプロキシ経由のログインが同じHome Assistantインスタンスに到達し、想定される狭い範囲のプロキシアドレスが信頼され、リダイレクトで意図したスキームとホストが維持され、通常の使用中もWebSocketが接続を維持し、プロキシを再起動しても結果が変わらなければ合格です。同じ正常なアカウントが直接経路でも失敗する場合に限り、Home Assistantの認証の調査へ進んでください。