キャッチオールルール追加後に、リバースプロキシが1つのドメインを間違ったアプリへ転送する問題を解決する方法

リバースプロキシでは、新しいキャッチオールルートがより広い範囲に一致するか、意図したホストルールより優先されることで、1つのドメインが誤ったアプリに送られることがあります。

これは、一般的な誤ったドメインへのリダイレクトやDNSの問題よりも限定的なケースです。重要な確認点は、正しいドメインが引き続き想定されたプロキシIPと証明書に到達しているにもかかわらず、新しいデフォルトルートの追加後にだけ、プロキシが誤ったバックエンドを選択しているかどうかです。DNS、アプリケーションのベースURL、証明書を変更する前に、ルートの一致状況と優先度を比較してください。

キャッチオールルールによってバックエンドの選択が変わったことを証明する

新しいキャッチオールまたはデフォルトルートだけを無効にし、その前後で同じドメインへのリクエストを送信します。プロキシのアクセスログ、選択されたルーターまたはサーバーブロック、バックエンドアドレス、レスポンス識別子、証明書を記録してください。

実用的なNginxのデフォルトサーバーガイドでは、複数の明示的なバーチャルホストがすでに存在していても、キャッチオールルールがトラフィックを捕捉する可能性があると説明されています。

フォールバックを無効にするとすぐに意図したアプリへ戻る場合は、DNSとバックエンドアプリケーションを変更しないでください。次の作業は、不明なホスト名に対する安全なフォールバック動作を維持しながら、特定のルートが優先されるようにすることです。

特定のホストルールが引き続き正確に一致するか確認する

リクエストされたホスト名と意図したルートルールを、文字単位で比較します。サブドメイン、ワイルドカードの境界、テストツールでの末尾ドットの有無、さらにキャッチオールと同じHTTPまたはHTTPSのエントリーポイントでルールが待ち受けているかどうかも確認してください。

マルチアプリのリバースプロキシガイドでは、ホスト名ルールが異なるバックエンドを選択するのは、受信ホストがプロキシに実際に読み込まれたルールと一致する場合だけだと説明されています。

優先度を調整する前に、不完全または誤記されたホストマッチャーを修正してください。一度も一致しないルールの優先度を上げても、設定を理解しにくくするだけです。

キャッチオールとのルート優先度を比較する

明示的または自動的に決定される優先度をサポートするプロキシでは、特定のホストと広範なフォールバックの両方が同じリクエストに一致する場合に、どのルールが勝つかを確認します。設定ファイルの順序だけでなく、実際に評価されたルールを記録してください。

Traefikのキャッチオールの例では、通常のアプリケーションルートが先に評価されるよう、フォールバックに実際のルートより低い優先度を意図的に設定しています。

フォールバックを、意図したすべてのアプリケーションルートより下位に設定して再テストしてください。すべてのルーターに根拠のない非常に大きな数値を割り当てて解決しようとしないでください。将来アプリを追加しても維持できる、シンプルで文書化された優先度の仕組みにします。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Nginx系プロキシでデフォルトサーバーを確認する

Nginxや類似の構成では、ホスト名が一致しない場合に、そのリッスンアドレスとポートでどのサーバーブロックがデフォルトになるかを確認します。明示的なデフォルトが定義されていない場合、最初に読み込まれたブロックがフォールバックになることがあります。

詳しいNginxトラブルシューティング記事では、一致しないホストがデフォルトサーバーに到達する理由を、単に拒否されるわけではない仕組みとともに説明しています。

実際のアプリケーションをフォールバックにするのではなく、中立的なデフォルトレスポンスまたはエラーサービスを使用してください。そうすれば、未知のホスト名や入力ミスによって、別のセルフホストアプリが意図せず公開されることを防げます。

HTTPとHTTPSのフォールバックを個別に確認する

ポート80に追加したキャッチオールが、ポート443でも自動的に同じ動作をするとは限りません。TLSルーティング、SNI、別々のエントリーポイント、または2つ目のキャッチオールによって、HTTPSリクエストだけが誤ったアプリに到達することがあります。

Caddyのトラブルシューティング事例では、スキームによってキャッチオールの動作が異なるケースを説明し、スキーム固有のルートを直接テストする必要性を示しています。

同じホスト名でHTTPとHTTPSの両方にリクエストを送り、選択されたハンドラーを記録してください。動作しているプロトコルの経路を変更するのではなく、影響を受けているエントリーポイントのフォールバックを修正します。

フォールバックを中立化し、既知のすべてのドメインを再テストする

一致範囲または優先度を修正した後、未知のホスト名を本番アプリへ転送するのではなく、中立的な404、421、または制御されたエラーページを返すようフォールバックを設定します。その後、既知の各セルフホストドメインを1回ずつテストしてください。

リバースプロキシのアーキテクチャ概要では、プロキシがバックエンドを決定するのはリクエストがプロキシに到達した後だと説明されています。そのため、DNSが正しいだけではルーティングが正しいことの証明にはなりません。

既知のすべてのホスト名が意図したアプリに到達し、未知のホスト名が中立的なフォールバックだけに到達すれば、修正は完了です。プロキシが正しいバックエンドを選択しているにもかかわらず、アプリケーションが後からドメインを変更する場合は、リバースプロキシが別のドメインへリダイレクトするケースに関する関連ZimaSpace記事を参照してください。

よくある質問

DNSが原因でキャッチオールルートが勝つことはありますか？

DNSによってリクエストが誤ったプロキシIPへ送られることはあります。しかし、正しいプロキシが意図したホスト名を受け取った後のルート一致は、プロキシの判断です。両方の層を個別に確認してください。

キャッチオールをダッシュボードアプリへプロキシすべきですか？

通常はおすすめしません。中立的なエラー送信先のほうが安全です。入力ミスや未知のホスト名によって、実際の管理アプリやメディアアプリが意図せず公開されるのを防げるためです。

なぜHTTPSだけが誤ったアプリに到達するのですか？

HTTPSでは、HTTPとは異なるリスナー、SNI経路、証明書サイト、またはフォールバックルールが使用されることがあります。グローバルなルーティングを変更する前に、両方のエントリーポイントを個別にテストしてください。