リバースプロキシの再起動後にPlexのログイン失敗を解決する方法
リバースプロキシの再起動後にだけPlexへのログインが機能しなくなる場合は、まずPlexへ直接ローカルアクセスできることを確認してください。直接のセッションが機能するなら、原因はプロキシ、DNS、またはTLS経路に絞り込めます。
最もありがちな誤りは、サーバー自体が正常なのにPlexの認証情報をリセットしてしまうことです。リバースプロキシでは、ブラウザーとPlexの間にアップストリームアドレス、ホスト名、証明書、リクエストヘッダー、場合によってはDockerネットワークが追加されます。これらの層を順番にテストしてください。復旧の目標は、ログインページを一度だけ表示させることではありません。Plexサーバーの識別情報を変更せず、同じプロキシ経路が、制御されたプロキシの再起動後も維持される状態にすることです。
Plex自体にまだ到達できるか確認する
通常ローカル管理に使用しているサーバーアドレスとポートを使い、LAN上からPlexに直接アクセスします。同じアカウントでサインインでき、サーバーが読み込まれるなら、Plexの認証やサーバーデータには手を加えないでください。問題がプロキシによって追加された経路にあることを、すでに切り分けられています。
Plexは、リバースプロキシやVPNなど特殊なネットワーク構成向けにカスタムサーバーアクセスURLを提供しています。Plexが公開するURLと、クライアントが使用しているホスト名またはスキームが一致しなくなると、直接ローカルアクセスが正常でも、検出や安全な接続の動作が不安定になることがあります。
直接のローカルアクセスも失敗する場合は、プロキシの再起動が原因だと決めつけるのをやめてください。まずPlexコンテナの状態、サーバーログ、データマウントを確認します。分岐ルールは明確です。直接アクセスが機能するならプロキシ経路、直接アクセスが失敗するならサーバーまたはコンテナ経路の問題です。
再起動後のプロキシのアップストリームを確認する
プロキシの接続先を調べ、現在のPlexサービスに解決されることを確認します。一時的なコンテナIPを対象に設定したプロキシは、コンテナやネットワークが再作成された後に機能しなくなることがあります。プロキシ設定にライフサイクルイベントで変化する一時的なIPを直接記述するのではなく、安定したホストアドレス、または同じ共有ユーザー定義ネットワーク上のDockerサービス名を使用してください。
Dockerのユーザー定義ブリッジの動作により、同じネットワーク上のコンテナは名前ベースで通信でき、明示的に分離できます。そのため、ライフサイクルイベント中に変わる可能性のあるコンテナアドレスよりも、サービス名のほうが永続性の高いアップストリームになります。
アップストリームを修正したら、プロキシだけを再読み込みして、プロキシ経由のPlex URLを再試行します。プロキシがPlexに到達できるようになったのにログインがループする場合、次に確認するのはコンテナ経路ではなく、公開ホスト名、TLS、または公開アクセスURLです。
セキュリティを弱めずにホスト名とTLS経路を確認する
ブラウザーが意図したHTTPSホスト名を使用していること、およびプロキシがその名前に対して有効な証明書を提示していることを確認します。証明書やホスト名の不一致を解決するために、安全な接続を全体で無効にしないでください。プロキシのドメインやパスを変更した場合は、PlexのカスタムアクセスURLを更新し、サーバー検出が実際に維持している経路をクライアントに示すようにします。
より広範なリモートアクセス設計については、ZimaSpaceのプライベートクラウド向けリモートアクセスガイドで、サービスを無制限に公開するのではなく、管理されたゲートウェイ、トンネル、明確な境界を重視しています。ここでも同じ原則が当てはまります。安全でない一時的な公開で回避するのではなく、意図した入口経路を修復してください。
ブラウザーのセッションを消去するのは、ルーティングとTLSの確認に成功してからにしてください。古いCookieがテストを複雑にすることはありますが、ネットワーク経路を修復する前に状態を消去すると、本当の障害を隠してしまう可能性があります。どこでも動作しているクライアントの状態を削除するのではなく、プライベートブラウザーウィンドウを使ってクリーンなテストを行いましょう。
プロキシを再度再起動し、最初のログインテストを繰り返す
ログインが機能するようになったら、意図的にリバースプロキシをもう一度再起動します。正常な状態になるまで待ってから、最初に失敗したときとまったく同じホスト名とクライアントを使用します。修正が成功した状態とは、アップストリームが解決され、TLSが有効で、Plexが意図したURLで検出され、再起動後に手動編集を行わなくてもアカウントへサインインできることです。
2回目の再起動で再び経路が壊れる場合は、プロキシとPlex間の起動順序と名前解決を確認します。ライフサイクルイベントのたびに人がIPを編集しなければならないなら、問題は解決していません。Dockerネットワークまたはプロキシ設定で依存関係を明示してください。
直接アクセスとプロキシ経由のルーティングがともに正常であるにもかかわらず、複数のクライアントでログイン失敗が続く場合に限り、Plexの認証についてエスカレーションしてください。その時点では、すでに検証済みのプロキシ設定を変更し続けるのではなく、時刻とアカウントおよびサーバーの詳細を含むPlexログを収集します。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
