IPでは動作するがドメインでは動作しないリモートアプリのトラブルシューティング方法
アプリがIPアドレスでは動作するのにドメインでは動作しない場合、サーバーには到達できており、問題は通常、DNS、ホスト名ベースのルーティング、TLS、またはリダイレクトにあります。
IPアドレスによるリモートアクセスが成功することは、何らかのネットワーク経路でホームサーバーに到達できていることを示します。ただし、ドメインへのリクエストには、DNS、TLSサーバー名、HTTP Hostヘッダー、アプリケーションに設定された公開URLによる追加の識別情報が含まれます。最も速い診断方法は、リバースプロキシ、証明書、DNSレコードを同時に変更するのではなく、同じクライアント、ポート、サーバーを使い、各識別レイヤーを順番に確認することです。
IPテストが意図したサービスに到達していることを確認する
リモートから正常に動作する正確なIPアドレス、ポート、プロトコル、レスポンスを記録します。IPアドレスで開いているのが実際のアプリケーションなのか、リバースプロキシのデフォルトページなのか、ルーターのログイン画面なのか、それとも同じパブリックアドレスを共有する別のサービスなのかを確認してください。
ホームラボ向けのリバースプロキシ解説では、プロキシがリクエストされたHostヘッダーを調べてからアップストリームサービスを選択するため、1つのアドレスで複数のアプリをホストできると説明しています。
IPアドレスでデフォルトサイトにしか到達しない場合、プロキシに到達できることは証明できますが、対象アプリのルートが機能していることまでは証明できません。ページタイトルやヘッダーなど、既知のレスポンスマーカーを1つ決めておき、後のテストで正しい仮想ホストを識別できるようにしてください。
パブリックDNSと正常に動作するIPアドレスを比較する
権威ネームサーバーと、少なくとも1つの外部再帰リゾルバーを使ってドメインを問い合わせます。すべてのAレコードとAAAAレコードの応答、TTL、CNAMEが別のホスト名を指しているかどうかを記録してください。
セルフホスティングのガイドでは、キャッシュされた応答は以前のTTLが切れるまで残る可能性があるため、権威レコードを修正した後も、最近の変更によって一部のクライアントが古いDNS宛先を使い続ける場合があると説明しています。
Aレコードが正常に動作するIPアドレスと異なる場合は、レコードまたはDDNSアップデーターを修正します。Aレコードが正しくても、AAAAレコードが到達不能なIPv6経路を指している場合は、アドレスファミリーごとに個別にテストし、壊れたレコードを削除または修正してください。
ドメインを維持したまま正常に動作するIPアドレスへ接続する
既知の正常なIPアドレスに接続しながら、HTTP HostヘッダーとTLSサーバー名にはドメインを送信できるクライアントを使用します。これにより、プロキシと証明書が想定する識別情報を維持したまま、接続先だけを変更できます。
Server Faultでは、HTTPリバースプロキシが、名前ベースの仮想ホストと同じようにHostヘッダーを使ってルートを選択できると説明しています。
ドメインを維持したリクエストが成功するなら、問題のレイヤーはDNSです。プロキシには到達するものの、別のサイトや404が返る場合は、仮想ホストのマッチングとルートの優先順位を確認します。HTTPの前にTLSが失敗する場合は、SNIと証明書の選択を確認してください。
TLSのSNIと証明書の識別情報を確認する
ドメインに対して返される証明書と、IPアドレスに対して返される証明書を比較します。サブジェクト名、発行者、有効期限、プロキシがデフォルト証明書を提示しているかどうかを記録してください。
SNIは、暗号化されたHTTPリクエストより前にTLS ClientHelloでホスト名を伝えるため、プロキシはセキュアな仮想ホストを選択できます。そのため、同じリスナーに到達していても、IPアドレスだけを使ったリクエストでは、TLSの選択に使われるホスト名が欠落する場合があります。
プライベートIPや動的IP用の証明書を期待するのではなく、ドメインの証明書とSNIルートを修正してください。CDNやTCPプロキシが前段にある場合は、意図したホスト名のSNIを転送または終端していることを確認します。
内部DNSと外部DNSが異なる経路に送信していないことを確認する
モバイルデータ、パブリックリゾルバー、ホームLANからドメインを解決した結果を比較します。スプリットDNSによって、自宅ではプライベートプロキシのアドレスを、外部からはパブリックアドレスを意図的に返すことはできますが、どちらの応答でも同じ論理ホスト名のルートに到達できなければなりません。
Level1Techsのホームラボに関する議論では、パブリックDNSとホームネットワークのルーティングが異なる内部経路と外部経路を取る場合、ローカルのリバースプロキシへのアクセスに独自のDNS設計が必要になることを示しています。
1つのリゾルバーだけが誤ったアドレスを返す場合は、そのDNSビューを修正します。パブリックアドレスへのIPアクセスは成功するのにドメインがどこからでも失敗する場合は、スプリットDNSではなく、Host、SNI、証明書、アプリケーションの識別情報に焦点を当ててください。
DNSが解決したと判断する前に正規URLとリダイレクトを確認する
ドメインがアプリに到達した後のすべてのリダイレクトを確認します。リバースプロキシまたはアプリケーションが、内部ホスト名、古いドメイン、誤ったスキーム、プライベートポート、または古いコールバックURLへクライアントを送信している可能性があります。
の記事では、スプリットDNSで自宅内だけの障害を修復できるかについて、ホスト名は正しいものの、場所によって経路が異なる隣接ケースを解説しています。
権威DNSが意図したアドレスを返し、ドメインが正しい証明書とプロキシルートを選択し、リダイレクトがパブリックホスト名を維持し、IPアドレスに置き換えることなくリモートで一連の処理が完全に成功して、初めて問題は解決したと言えます。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
