プロキシまたはDNSの変更後、クライアントが別のホスト名、経路、証明書、またはキャッシュされたエンドポイントを通じて再接続すると、Plexのセッションが失われることがあります。
接続経路をテストする間は、サーバーとメディアを変更しないでください。クライアントによってアドレスや認証状態のキャッシュ方法が異なるため、既存のセッションは新しいセッションより長く維持される場合があります。ローカル接続とプロキシ経由の接続を1つずつ再現し、DNS解決、リダイレクト、WebSocketの動作、そしてクライアントが実際に使用しているアドレスを比較してください。
Plexへの直接アクセスが引き続き機能することを確認する
バックエンドが正常に動作していることを確認できていれば、プロキシの問題をより簡単に切り分けられます。証明書やデータベースの状態を変更する前に、LAN上で同じアカウントとメディアを直接テストしてください。
Plexのリバースプロキシ経路によって2つの経路が分離されている場合は、パブリックホスト名とは別にバックエンドをテストできます。
Plexを直接開いて既知の項目を再生し、サーバーアドレスを記録してください。直接アクセスも失敗する場合は、バックエンドが動作するまでDNSとプロキシのルールを変更しないでください。
認証の前にDNSを確認する
新しいホスト名やアドレスによって、ログインエラーがアカウントの問題に見えていても、クライアントが誤ったエンドポイントに接続されることがあります。特にキャッシュやスプリットDNSを使用している場合は、各クライアントが解決するアドレスを比較してください。
インターフェースのルートメトリックによって、DNS更新後に使用されるネットワーク経路が変わることもあるため、名前解決と経路選択の両方を確認してください。
影響を受けているクライアントと正常に動作しているクライアントから、パブリック名とローカル名を解決してください。誤った結果を記録してから、問題が発生しているクライアントのキャッシュだけを消去します。
プロキシの書き換えとWebSocket経路を確認する
サブパスの書き換え、ヘッダー、リダイレクト、WebSocketのアップグレードは、単純なWebページが読み込める場合でも、プロキシ変更後にセッションを壊すことがあります。クライアントの一連の動作全体をテストする必要があります。
Plexプロキシパスの書き換えが関係する場合、プロキシの変更はルート相対アセットや整合性チェックの動作に影響する可能性があるため、単純なポート転送の問題ではありません。
ログインと再生中に、ブラウザーのネットワークエラーとプロキシログを監視してください。プロキシ経由の経路が失敗し、直接アクセスが機能する場合は、ユーザーをリセットする前にプロキシ層を修正してください。プロキシが安定したら、外部ネットワークから同じリモートPlexストリーミング経路を確認し、今後のDNSやエッジ設定の変更に備えて、その結果を基準として保存してください。
既知の1つのセッション経路で再テストする
DNSとプロキシの動作が安定したら、新しいセッションを作成し、クライアントが意図したホスト名を使い続けることを確認してください。これにより、古い経路のキャッシュによって壊れた設定が正常に見えることを防げます。
サービス接続自体が有効でも、返信トラフィックがリクエストを受信したインターフェースではなくVPN経路から送信されると、接続に失敗することがあります。
同じアカウントを使用して、外部ネットワークとローカルネットワークから1回ずつテストしてください。一方の経路だけでセッションが切断される場合は、サーバーの状態ではなく、ルーティングとエッジポリシーの確認を続けてください。
サポートとヒント
もっと読む

Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか?
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。

誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか?
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。

Jellyfinは修理より再構築すべきタイミングとは?
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。

