Jellyfinはサーバー側で同じユーザー識別・認可モデルを使用しますが、ローカルセッションとリモートセッションでは、異なるネットワーク経路を通じてその判定に到達します。
ローカルクライアントは直接アドレス指定やディスカバリーを使用できますが、リモートクライアントはDNS、ルーティング、ファイアウォール、NAT、VPN、プロキシなどの層を経由する場合があります。したがって、ログインに成功したからといって、リモート経路でスムーズに再生できるとは限りません。認証と到達性は別々の問題として扱ってください。
ユーザー識別は信頼レイヤー
サーバーは、ライブラリへのアクセス権、視聴状態、ポリシーを適用する前に、現在のユーザーを識別する必要があります。ローカルかリモートかによってユーザー識別そのものが変わるわけではなく、クライアントがサーバーに接続する方法が変わるだけです。
永続データロールのモデルを見ると、ユーザー識別を転送経路やクライアントの能力とは分けてテストすべき理由が分かります。
同じアカウントで2台のデバイスに異なるライブラリが表示される場合は、ルーティングを疑う前にセッションのユーザー識別と権限を確認してください。
ローカルセッションは通常、経路上の依存関係が少ない
LANクライアントは、プライベートアドレス、安定した帯域幅、ローカルディスカバリーを利用できます。これらの条件により、障害が発生する可能性のある外部レイヤーの数は減りますが、リクエストがJellyfinに到達した後の認可判定が変わるわけではありません。
ローカル経路を多層的な到達性モデルと比較してください。ホームネットワーク内でも、ディスカバリー、DNS、ルーティング、ポリシーはそれぞれ別の要素です。
ローカルでの成功は、1つの経路が機能していることを示すだけです。リモートホスト名、プロキシ、VPNでも同じ経路が使われることを証明するものではありません。
リモートセッションでは到達性と再生の変数が増える
リモートアクセスは、NATトラバーサル、DNS、証明書、プロキシルール、アップロード帯域幅、トランスコードを必要とするクライアントプロファイルに依存する場合があります。認証に成功しても、再生が遅い、または利用できないことがあります。
リモートログインの結果を解釈する際は、多層的な到達性モデルにおけるユーザー識別とネットワーク到達性の違いを意識してください。
ログインには成功したのに再生できない場合、次に確認すべきなのは、Jellyfinがユーザーを認識したかどうかではなく、配信経路とメディアモードです。
認証と接続性を分けたチェックリストを使う
既知のアカウント1つをローカルとリモートでテストし、表示されるユーザーとライブラリを記録したうえで、直接再生とリモート再生を別々に確認してください。経路だけを変更し、メディアと権限は同じ条件に保ちます。
Jellyfinクライアントの動作の比較は、ユーザー識別、ライブラリ付与、再生転送を1つの症状として混同しないために役立ちます。
問題がユーザー識別、認可、到達性、再生容量のいずれに属するかが明確になった時点で、調査を止めてください。それぞれ担当者も、確認すべき証拠の経路も異なります。
テック&AIハブ
もっと読む

Home AssistantはLAN接続とリモート接続でなぜパフォーマンスが異なるのですか?
LAN接続とリモート接続のHome Assistantセッションではネットワーク経路が異なります。リモート接続では、DNS、暗号化、WAN、プロキシやVPN、再接続処理による遅延が加わります。

Home AssistantはCGNATや二重NAT環境でも安定して動作しますか?
CGNATと二重NATは通常、ローカルでのHome Assistantの制御には影響しません。主に、リモートクライアントがホームネットワークへのインバウンド経路を確立する方法が変わります。

インターネット障害中、ネットワーク遅延はHome Assistantにどのような影響を与えるか?
インターネット接続の喪失とネットワーク遅延は異なる障害です。DNS、クラウド連携、ゲートウェイ、リモートクライアントが待機している間も、ローカルデバイスへの経路は高速なまま維持されることがあります。

