プロキシまたはDNSの変更後にJellyfinのセッションが失われるのはなぜですか？
プロキシやDNSを変更しても、通常はJellyfinのすべてのログインが自動的に無効になるわけではありません。セッションが失われるのは通常、その変更によって、既存のログイン状態が想定しているホスト名、スキーム、パス、バックエンドサーバーの識別情報、認証レイヤー、またはクライアントの経路まで変わった場合です。
まず、単純なDNSレコードの更新と、オリジンの変更を切り分けます。既知のアカウントとデバイスを1つ固定し、通常の公開ホスト名でのアクセスとLANからの直接アクセスを比較します。クライアントデータを消去する前に、最初に失敗したリクエストを記録してください。目的は、症状が消えるまでユーザーをリセットすることではなく、どの境界が変わったのかを特定することです。
まず公開オリジンが実際に変わったかを判断する
変更前後のスキーム、ホスト名、ポート、ベースパス、プロキシ経路を書き出します。DNSのAまたはAAAAレコードは、ブラウザのオリジンを変えずに同じホスト名を別のアドレスへ向けられます。一方、別のホスト名への移行やアプリケーションのベースパスの変更は、異なるクライアント境界を作ります。カスタムドメインの移行では、アプリケーションと認証経路が新しいドメインに一致している必要があります。カスタムドメイン移行チェックリストでは、このDNSとアプリケーションの連携が明確に説明されています。
認証状態は、どこで提示されるかに大きく左右されます。役立つセッションCookieのスコープ確認リストは、各認証方式に設定されたドメインとパスをマッピングすることから始まります。Jellyfinのクライアントはすべてがまったく同じ方法で状態を保存するわけではないため、ブラウザの挙動がすべてのアプリに当てはまると決めつけず、影響を受けたクライアントでテストしてください。
古いホスト名ではまだ動作するのに、新しいホスト名でログインを求められる場合は、まずは想定どおりのオリジン移行として扱ってください。同じホスト名で、プロキシ変更後にのみ全員がログアウトされる場合は、ホスト名を維持したまま、上流の識別情報、ヘッダー、プロキシ側の認証を確認します。
DNSが意図した同じJellyfinインスタンスに到達していることを確認する
LANクライアントからホスト名を解決し、リモートアクセスが重要であれば外部のリゾルバーからも確認します。返されたアドレスが意図したリバースプロキシに到達し、プロキシが古いコンテナ、テスト用インスタンス、復元クローン、または永続データベースが異なる別サーバーではなく、想定したJellyfinサービスへルーティングしていることを確認してください。
DNSの切り替えは、実際には別のバックエンドへクライアントを送っているのに、セッションの問題のように見えることがあります。認証に触れる前に、サーバーを識別できるレスポンス、ユーザーリストの挙動、ライブラリの状態、プロキシの上流ターゲットを比較してください。新しい経路が新規または復元済みのJellyfinインスタンスに到達している場合、既存のクライアント認証情報は、そのインスタンスでは有効なセッションを表していない可能性があります。
ZimaSpaceの関連ワークフローであるプロキシとセッション状態のライフサイクルを分離する方法も、ここで役立ちます。イングレスの再起動によって、アプリケーションの識別情報や既存セッションを検証する状態が、ひそかに置き換わるべきではありません。
転送されたホスト、スキーム、パス、プロキシ認証を比較する
変更後の実効プロキシ設定を記録します。公開Host値、転送されるスキーム、クライアントアドレス、WebSocketのアップグレード経路、リダイレクト、認証ミドルウェアを、最後に正常だった設定と比較してください。HTTPSから予期しないHTTPや別ホストのURLへリダイレクトされると、有効なログインが消えたように見えることがあります。
Jellyfinの前段に別の認証レイヤーがある場合は、プロキシを置き換える間も、その署名キー、Cookie名、Cookieドメイン、セッションストアを維持してください。ロードバランサー構成では、スティッキーセッションとルーティング状態を使って、リクエストを意図したバックエンドへ維持します。このレイヤーを変更すると、Jellyfin自体が正常でもログアウトやリダイレクトループが発生することがあります。
関係のないプロキシ設定例からヘッダーをそのままコピーしないでください。失敗したリクエストやリダイレクトによって現在の値が誤っていることが示された場合にのみ、1つずつ変更します。最も安全なプロキシ設定は、公開オリジンを維持し、正しいバックエンドへ一貫して到達できる最小限の構成です。
元の証拠を消去せずにクリーンなクライアントテストを行う
何かを消去する前に、失敗時刻、ブラウザまたはアプリのバージョン、リクエストのステータス、リダイレクトチェーン、プロキシログの行、Jellyfinのログエントリを保存します。その後、プライベートブラウジングウィンドウまたは別のテスト用デバイスを使い、新しい経路からサインインします。新しいログインが成功しても、古い状態が使えなくなった理由が分かったわけではありません。
次の3つの経路を順番に比較します。LAN内からのJellyfinへの直接アドレス、LAN内から通常のホスト名、LAN外から通常のホスト名です。直接アクセスは動作するのにホスト名では失敗する場合、ユーザーやデータベースの状態を変更せず、DNS、TLS、プロキシ、ミドルウェアを調査します。すべての経路で同じ正常なアカウントが拒否される場合は、問題はJellyfin内部またはその永続状態に戻っています。
リクエスト経路の証拠を記録してから、影響を受けたクライアントのサイト固有データだけを消去してください。最初の手段として、登録済みのすべてのデバイスを削除したり、すべてのセッションを取り消したりするのは避けましょう。そうすると、経路の移行とサーバー側の認証失敗を区別するための比較材料が失われます。
DNSの有効期限、プロキシの再起動、ホストの再起動を通じて変更を検証する
対応する修正を適用したら、以前のDNS TTLの期間が満了するまで待ち、プロキシだけを再起動し、その後Jellyfinサービスを再起動し、最後にホストを再起動します。各イベントの後、同じホスト名を使って、ログイン、ログアウト、再生開始、シーク、再接続をテストします。
安定した結果とは、ホスト名が意図したプロキシを解決し続け、プロキシが意図したJellyfinインスタンスへ再接続し、通常のコンポーネント再起動後も本来維持されるべき既存セッションが維持され、新しいログインも有効なままであることです。フルスタックの起動時だけ失敗する場合は、プロキシから上流への復旧経路を使って、準備完了状態と認証を切り分けてください。
最終的なホスト名、プロキシの上流名、ベースパス、証明書の取得元、プロキシ側のセッションシークレットをデプロイメントメモに記録します。今後のDNSやプロキシの変更を、ブラウザの症状から再発見するのではなく、既知の識別情報の契約に基づいてテストできるようになります。
FAQ
DNSレコードを変更しただけでJellyfinのセッションは無効になりますか？
通常、同じホスト名、スキーム、パス、Jellyfinインスタンスを使い続ける限り、無効にはなりません。DNS変更がセッションに関係するのは、別のバックエンドへ送られる場合、公開オリジンが変わる場合、TLSやリダイレクトが変わる場合、またはJellyfinの前段にある認証レイヤーが変わる場合です。
プロキシを変更した後、すべてのJellyfinセッションを取り消すべきですか？
最初の修復手段にはしないでください。失敗しているクライアントを証拠として1つ残し、新しい経路が意図したサーバーに到達していることを確認し、新しいログインを別途テストします。認証情報を意図的にローテーションした場合、トークンの漏えいが疑われる場合、または古いクライアント状態を信頼すべきでないと確認できた場合にのみ、セッションを取り消してください。
おすすめ商品
サポートとヒント
もっと読む
Home Assistantを稼働中にバックアップすべきか、それとも先にサービスを停止すべきか？
Home Assistantの組み込みバックアップは稼働中でも実行できますが、単純なファイルシステムのコピーでは、データベースを一貫性のある状態でバックアップしない限り、Home Assistantを停止または休止させる必要があります。
アイドル時間中にHome Assistantサーバーが高温になったり、うるさくなったりするのはなぜですか？
冷却やCPU制限を変更する前に、Recorder、バックアップ、連携機能、同一ホスト上のジョブと、Home Assistantのファン回転数や温度の急上昇との相関を確認してください。
Home Assistantは修理するより再構築すべきなのはいつですか？
まず、Home Assistantで最小限の故障レイヤーを修復し、次に既知の正常な状態へ復元します。永続設定を信頼できない場合にのみ再構築してください。
