DNSがPlexの接続障害の原因かどうかをテストする方法
まず直接IP接続を確認してください。PlexがIPアドレスでは動作するのに、通常のホスト名、アプリの検出、または安全な接続経路では失敗する場合にのみ、DNSを調査します。
ルーターが提供するリゾルバー、Pi-holeやUnboundのフィルタリング、クライアントに残った古い応答、スプリットDNSのルール、または`plex.direct`周辺のリバインディング保護によって、Plexの接続が妨げられることがあります。これらの障害は、サービスがIPアドレスでは到達可能であるにもかかわらず、サーバー停止のように見える場合があります。ポートフォワーディング、ライブラリ、コンテナ設定に触れる前に、問題のあるクライアント1台、既知のサーバーアドレス1つ、代替リゾルバー1つを使って名前解決を切り分けてください。
DNSをテストする前にIP接続を確認する
LAN上のPlexサーバーの既知のプライベートアドレスを使用し、ホストに到達できることと、Plexのポートが応答することを確認します。IP経路が失敗する場合、最初の原因はDNSではありません。リゾルバー設定を変更する前に、ルーティング、ファイアウォール、ホストのアドレス設定、またはサービスの可用性を修正してください。
直接IPでのアクセスが機能して初めて、DNSの診断に信頼性が生まれます。同じクライアントがPlexにアドレスでは到達できるのに、通常の名前や安全な接続経路では到達できない場合、リゾルバーの動作を切り分ける準備が整っています。
機能するIPアドレスと、失敗するホスト名またはアプリの動作を記録します。両方とも失敗する場合は、DNSのテストを中止してください。IPで成功し、通常のPlex経路で失敗する場合は、リゾルバー、安全な名前解決、またはリバインディングの確認に進む明確な分岐が得られます。
リゾルバーの応答とリバインディングの動作を比較する
問題のあるホスト名を、実際にクライアントが使用しているリゾルバー経由で問い合わせ、既知の正常なクライアントまたは一時的に信頼できる代替リゾルバーの応答と比較します。応答が異なる場合は、PlexやNATを変更する前に、DHCPで割り当てられたDNS、ローカルの書き換え、フィルタリングを確認してください。
`plex.direct`はプライベートサーバーアドレスに解決されることがあるため、Plexホスト自体が正常でも、DNSリバインディング保護によって応答がブロックされる場合があります。リバインディング保護をグローバルに無効化するのではなく、リゾルバーのログでPlex関連の問い合わせがブロックまたは書き換えられていないか確認してください。
1台のクライアントだけで一時的に1つのリゾルバーをバイパスし、同じPlexリクエストを再実行します。問題の経路を修正できた最小限の変更だけを残してください。代替リゾルバーで違いがなければ、テストを元に戻し、証明書、アプリの検出、ファイアウォール、またはリモートルーティングの確認に進みます。
両方のリゾルバーが同じ応答を返し、直接IPでの確認が引き続き成功する場合、DNSが実際の障害である可能性は低くなります。その結果を記録し、リゾルバーの例外を追加するのではなく、証明書の検証、アプリの検出、ファイアウォールポリシー、またはリモート経路を確認してください。
ローカルDNS障害とリモートアクセス障害を分ける
LANのDNS問題により、ローカルクライアントがサーバーを間接接続または利用不可として扱う一方で、外部からのリモートアクセスは正常に動作することがあります。逆に、ローカル名は正しく解決できても、パブリックポートやCGNAT経路が壊れている場合もあります。両方向をテストすることで、一方の症状がもう一方を隠すのを防げます。
プライベートドメインの例外によってローカルのリゾルバー動作を修正できる場合がありますが、インターネットからの受信経路が作られるわけではありません。リモートのみの障害は、引き続きNAT、ファイアウォール、またはISPのネットワーク構成に関する問題です。
通常のDNSを使うLANクライアント1台、同じクライアントで一時的に代替リゾルバーを使った状態、そしてモバイルデータ通信を使うリモートクライアント1台をテストします。どの組み合わせが成功したかを書き留めてください。そのパターンから、DNSの問題がローカル、リモート、または無関係のどれであるかが分かることが多いです。
キャッシュの消去や再起動後も有効な修正だけを残す
クライアントのキャッシュに古い応答が残っていたり、一時的なリゾルバーバイパスが有効なままだったりすると、DNSの修正が機能したように見えることがあります。問題に関係するキャッシュを消去または期限切れにし、クライアントのネットワーク設定を更新し、問題が解決したと判断する前にリゾルバーまたはルーターを一度再起動してください。
DNSリバインディングとNAT設定は重なる場合があるため、不要な例外をいくつも残すのではなく、どの1つの変更で問題のあるテストが解決したのかを記録してください。
DNSによって、より大きなルーターまたはサブネットの変更が明らかになっただけである場合、通常のクライアント設定を元に戻した後は、ルーター変更後のリモートアクセス経路が次に確認すべき分岐になります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
