なぜリバースプロキシはドメインでは動作するのに、ローカルIPでは動作しないのですか？

リバースプロキシは、ルーティングやTLSのルールが要求されたホスト名に依存することが多いため、ドメイン単位で動作します。単に宛先IPだけでなくホスト名が重要です。

ホームクライアントがhttps://app.example.comを開くと、DNSはIPを返しますが、ブラウザはTLSハンドシェイクやHTTPのHostヘッダーでドメイン名を送信します。https://192.168.1.20を開くとこれらの識別子が変わるため、プロキシはデフォルトサイトを選択したり、証明書を拒否したり、アプリケーションのルートを見逃したり、設定された公開URLにリダイレクトしたりします。正しいテストは、意図したホスト名を保持しつつネットワークの宛先だけを変更することです。

ホスト名リクエストと直接IPリクエストを比較する

ドメイン宛とローカルIP宛にそれぞれリクエストを送り、ステータスコード、証明書、レスポンスヘッダー、リダイレクト先、リバースプロキシのアクセスログを比較してください。同じイーサネットインターフェースに到達しても両者が同等とは限りません。

ホームラボのリバースプロキシ解説では、プロキシがHTTP Hostヘッダーを検査して複数のサービスを1つのIPとポートでルーティングしていることが説明されています。

ドメインリクエストがアプリケーションルートにマッチし、IPリクエストがデフォルトページや404に到達する場合、プロキシは設定通りに動作しています。次の判断は、直接IPアクセスが本当に必要か、ローカルDNSでドメインを保持すべきかです。

意図したHostヘッダーを保持してローカルIPをテストする

クライアントツールを使い、ローカルプロキシのIPに接続しつつ、Hostヘッダーにはアプリケーションのドメインを送信してください。HTTPSの場合は、IPに置き換えずTLSのサーバー名もドメインのままにします。

Server Faultでは、HTTPリバースプロキシがHostヘッダーを使って名前ベースの仮想ホストと同様にルートを選択する方法が説明されています。

強制的にHostを指定したリクエストが成功すれば、プロキシルートとバックエンドは正常です。直接IPで失敗するのはID不一致です。失敗が続く場合は、リスナー、ローカルファイアウォール、プロキシの入口、ルート優先度を確認してからDNSを変更してください。

TLSのSNIと証明書の一致を確認する

HTTPSはHTTPリクエストの前にホスト名の判定を行います。クライアントは通常TLSハンドシェイク中にServer Name Indicationを送信し、プロキシは正しい証明書とセキュアな仮想ホストを選択します。

SNIリバースプロキシの実装例では、HTTPSバックエンドはクライアントのSNIホスト名を使って選択されるため、通常のHTTPヘッダーを調べる前に決定されると説明されています。

IPでの直接アクセスは、プロキシに到達してもデフォルト証明書を提示したりホスト名検証に失敗したりします。ローカルDNSでドメインを使うか、直接IPのHTTPSが本当に必要な場合のみIPを含む管理された証明書を用意してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

デフォルトサイトとルート優先度を確認する

設定されたドメインにマッチしないリクエストをどの仮想ホストが処理するかを確認してください。デフォルトサイトはダッシュボードを返したり、別のホスト名にリダイレクトしたり、接続を切断したり、一般的なエラーを表示したりします。

Caddyの議論では、リクエストは正しいプロキシIPに到達してもHostヘッダーとTLS名が意図したアップストリームの選択を決定することが示されています。

デフォルトルートは明示的かつ安全に保ってください。IPアクセスを機能させるためだけに広範囲のキャッチオールプロキシを1つのバックエンドに追加しないでください。未知のホスト名やスキャントラフィックがドメイン制限されたアプリケーションに流れ込む恐れがあります。

アプリケーションが正規のURLにリダイレクトするか確認する

プロキシがIPリクエストを受け入れても、バックエンドは設定された公開ベースURLを強制し、ブラウザをドメインにリダイレクトすることがあります。認証クッキー、OAuthコールバック、WebSocketのオリジン、CSRFチェックも正規ホストに依存する場合があります。

プロキシログとアプリケーションログを比較し、Locationヘッダーを確認してください。ドメインへのリダイレクトはルーティング失敗ではなく、アプリケーションが1つの公開IDを期待している証拠です。

アプリが誤った外部URLを生成する場合は、転送されたHostとプロトコルヘッダーを正しく設定してください。リダイレクトを回避するためだけに正規ドメインをプライベートIPに置き換えるのは避けてください。証明書やリモートアクセスが壊れる可能性があります。

ドメインが意図したインターフェースならローカルDNSを使う

アプリケーションドメインをローカルリバースプロキシのアドレスに解決する内部DNSレコードを作成してください。ブラウザは効率的なLAN経路を使いながら、同じHostヘッダー、SNI名、証明書、クッキー、アプリケーションURLを保持します。

ZimaSpaceのリバースプロキシとプライベートアクセス経路の比較は、ドメインをローカルかつ公開の入口に残すべきか、プライベートネットワークの背後に置くべきかの判断に役立ちます。

問題は、意図的なDNS応答でドメインが内外両方で機能し、直接IPはドキュメント化されたデフォルトサイトに到達するか意図的に拒否されることで解決します。ドメインルーティングされたプロキシは、IPアドレス指定の単一サイトサーバーのように振る舞う必要はありません。