Plexは一部のリバースプロキシのサブパス構成でも動作しますが、Plex専用のホスト名を割り当てる場合よりも壊れやすくなります。
問題は、単純なHTTP転送だけではありません。PlexのWebアセットやリダイレクトはルート相対パスを前提とする場合があり、WebSocket、ヘッダー、整合性チェックの動作もバージョンによって変わる可能性があります。サブパスが必要な場合は、ログインページが正常に表示された時点で終わりにせず、プロキシまたはPlexを更新するたびにWeb全体と再生フローを検証してください。
まずプロキシなしでバックエンドが動作することを確認する
Plexのバックエンド自体に問題がある場合、プロキシのテストには意味がありません。書き換えルールを追加する前に、ローカルからのWebアクセスと再生を確認してください。
Plex専用のプロキシホスト名を使えば、サブパス構成で必要になるパスプレフィックスの書き換えの多くを避けられます。
LAN上からPlexに直接アクセスし、既知のファイルを再生して、公開プロキシURLをテストする前にサーバーが正常であることを確認してください。直接アクセスでも失敗する場合は、まずPlexを修正し、プロキシは変更しないでください。
ルート相対パスが難所になることを想定する
サブパスのプロキシには、/plexをポート32400にマッピングするだけでは不十分です。HTML、静的アセット、リダイレクト、クライアント検出が、プレフィックスを迂回するルートパスを指し続ける場合があります。
Plexのサブパスプロキシでは、パスの書き換えが必要になり、Webアセットの整合性チェックと干渉することがあります。
ブラウザーの開発者ツールを開いた状態でページを読み込み、404エラー、プレフィックス外へのリダイレクト、WebSocketエラー、アセットのブロックがないか確認してください。Webアプリがレスポンスの繰り返し書き換えに依存する場合は、その構成がアップデートの影響を受けやすいものとして扱い、ロールバック手順を文書化してください。
Web UIだけでなく、再生と検出もテストする
ページが正常に表示されたからといって、クライアントが同じURL経由で検出やストリーミングを行えるとは限りません。Plexクライアントは独自の検出および接続ロジックを使用することがあります。
ポートフォワーディングしたPlexの経路は、CGNAT、二重NAT、ルーターのルール、外部からの到達性が原因で失敗することがあります。
ブラウザーでの再生、少なくとも1台のネイティブクライアント、外部ネットワークからの接続をテストし、それぞれのセッションがどのアドレスを使用しているかを確認してください。ネイティブクライアントがプロキシを迂回したり、別の経路にフォールバックしたりする場合、サブパスだけがリモートアクセスの経路ではありません。
サブパスによる書き換えの負担が増えるなら、サブドメインを優先する
サブドメインを使えば、パスプレフィックスの書き換えの大部分をなくせるため、アップグレード時にも構成を把握しやすくなります。運用上の問題は、共有ドメインが必要という要件に、互換性の問題が増える価値があるかどうかです。
Plex専用のプロキシホスト名を使えば、サブパス構成で必要になるパスプレフィックスの書き換えの多くを避けられます。
複雑なフィルターに時間をかける前に、同じバージョンのPlexをサブドメインとサブパスの両方で比較してください。サブドメインが安定して動作し、サブパスでコンテンツの書き換えが必要になる場合は、共有パスが絶対条件でない限り、より単純な方法を選びましょう。後から接続障害とサーバー障害を切り分けられるよう、選択したプロキシ経路をPlexのリモートストリーミング経路と併せて記録してください。
サポートとヒント
もっと読む

ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。

データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。

オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。

