Plexの認証では、サーバーとアカウントのアイデンティティが信頼レイヤーとして機能します。一方、ローカルセッションとリモートセッションの主な違いは、サーバーへの到達方法です。
ローカルクライアントだからといって自動的に匿名になるわけではなく、ポートに到達できるからといってリモートクライアントが認証済みになるわけでもありません。通常、認証済みのPlexサーバーは認証されたアクセスを要求し、そのうえで安全な接続設定、ネットワーク検出、リモート到達性、ローカルネットワークの例外設定が接続経路を決定します。これらのレイヤーを理解しておくと、ネットワークの問題をアカウントの問題と誤認せずに済みます。
認証済みサーバーでは、Plexアカウントのアイデンティティがデフォルトの信頼レイヤーになる
最初の境界線は、Plex Media ServerがPlexアカウントに認証済みか、またはサインイン済みかどうかです。この関係が確立されると、クライアントは通常、サービスのポートに到達できるだけでアクセスを得るのではなく、Plexアカウントの仕組みを通じてサーバーに認証されます。
認証済みサーバーでは、デフォルトで認証が必要です。このデフォルト設定は信頼を判断する際に適用されるものであり、すべてのローカル接続とリモート接続が同じ検出経路やルーティング経路を通るという意味ではありません。
アカウントのアイデンティティとライブラリの権限は分けて考えてください。Plex Homeと管理対象ユーザーでは、ユーザーごとのアクセスと権限が適用されるため、「ログインできた」ことと「このユーザーがすべてのライブラリを表示できる」ことは同じではありません。
ローカルセッションは近くにあっても匿名ではない
同じホームネットワーク上では、クライアントはより少ないルーティング手順でサーバーを検出して接続できることがあります。しかし、アプリケーションは引き続きアイデンティティとサーバーのセキュリティ設定を評価します。ローカルにあることで変わるのは経路であり、サーバーが利用を許可するクライアントを把握すべきだという基本的な考え方ではありません。
Plexには、認証なしでローカルアクセスを可能にするネットワーク設定もありますが、これらの例外は信頼境界を意図的に広げます。適用範囲は狭く設定し、認証問題に対する通常の解決策として扱わないでください。
他のクライアントは動作しているのに1台のローカルクライアントだけが失敗する場合は、認証ルールを変更する前に、サインイン状態、アプリの対応状況、正確なネットワークセグメントを確認してください。VLAN間やゲストWi-Fiでの検出問題は、認証情報が正しい場合でもアカウントの失敗のように見えることがあります。
安全な接続がセッションの経路を保護する
認証は誰がサーバーを利用できるかを確認し、安全な接続はクライアントとサーバー間を移動する通信を保護します。これらは関連していますが異なるレイヤーです。そのため、有効なアカウントを使用していても、クライアントが想定された安全な経路を確立できなければ、接続問題が発生することがあります。
Plexでは安全なサーバー接続を利用できます。実際にアクセスが必要なクライアントで接続ポリシーをテストしてください。古いクライアントや特殊なクライアントでは安全な経路への対応が異なる場合があるため、どのエンドポイントが失敗しているかを特定する前に、ポリシーを全体的に緩和しないでください。
クライアントが安全にサーバーへ接続すると、認証と通信保護が連携します。クライアントがアイデンティティを証明し、サーバーがアクセス権を適用し、接続が通信を保護します。いずれか1つのレイヤーで失敗すると、同じような「サーバーを利用できません」という状態になることがあります。
リモートセッションでは、検出とインターネット境界での到達性が加わる
リモートセッションでは、まずインターネットの境界を越えてホームサーバーに到達する必要があります。ポートマッピング、NAT、ファイアウォールポリシー、トンネル、その他のリモートアクセス設計によって、接続先サーバーでアカウント認証を完了する前に、経路が存在するかどうかが決まります。
Plexのリモートアクセスでは、サーバーにサインインしたうえで、ローカルネットワーク外からの到達性を確立します。ポートマッピング、NAT、ファイアウォールの状態が経路の有無を決定しますが、Plexアカウントとライブラリの権限は、アプリケーションレベルの別の信頼レイヤーとして残ります。
診断時には、到達性と認証を分けて考えてください。リモート経路はアカウントが評価される前に失敗することがあり、サーバーに到達できても、サインインしていないユーザーや要求されたライブラリへのアクセス権を持たないユーザーは拒否される可能性があります。
ローカルとリモートの問題は、別々のレイヤーとしてテストする
まず1つの既知のアカウントでローカルアクセスを確認し、その後、同じアカウントを実際に外部の接続環境からテストしてください。ローカル認証は機能するのにリモートアクセスだけが失敗する場合は、アカウントをリセットしたりライブラリ権限を変更したりする前に、インターネット経路とサーバーの到達性を調査します。
リモート到達性では、意図したサーバーへの認証済みアクセスを維持する必要があります。Plex内部で未解決のアイデンティティや権限の問題を回避するために、トンネルや転送サービスを使用しないでください。
ルーターやネットワークを移行した後は、移行後のPlexネットワークの基本状態を確認すると、アドレス、検出、リモート到達性、サービスのアイデンティティを切り分けやすくなります。複数の信頼設定を一度に変更するのではなく、ネットワーク経路を個別にテストすると、認証の仕組みをより正確に把握できます。
テック&AIハブ
もっと読む

Plexの状態とは何か、どの部分を永続化する必要があるのか?
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。

ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか?
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。

コンテナを再起動すると、Plex の動作が異なるのはなぜですか?
コンテナの再起動によって、永続化された Plex の状態を取り巻く実行環境が再構築されるため、タイミング、マウント、デバイス、ネットワーク、キャッシュによって結果が変わることがあります。

