リバースプロキシで、別々のホームサーバー上にあるアプリを配信できますか？

はい。プロキシには各アップストリームへのルーティング可能で認証済み、かつポリシーで制限されたアクセスだけが必要です。アプリがプロキシホストを共有する必要はありません。

1つのHTTPSエントリーポイントから、家庭内のドメインを複数のLANサーバーまたはVLAN上のアプリケーションへルーティングする場合、これは実際の互換性に関する問題になります。まずは破棄可能なパスまたはアカウントで開始し、以前の動作状態を利用できるようにしておき、1回限りの接続テストではなく、元のワークロードに基づいて設計を評価してください。

マルチホストのリバースプロキシが機能する条件を定義する

サポート対象となる分岐は、ヘルスチェック、TLS、ファイアウォールポリシーを備えた明示的なアップストリームアドレスです。対照的な分岐は、ルーティング不能なバックエンド、信頼済みヘッダーの誤り、または管理ネットワークへの広範な公開です。どちらかの分岐を変更する前に、バージョン、ID、アドレス、マウントパス、権限、現在観測できる状態を記録してください。

関連するNGINXアップストリームプロキシが、最初の互換性の境界を定義します。これを使って主張の範囲を限定し、文書化された機能が設計全体の動作を証明するものとみなすのではなく、この正確なホームサーバーで同じ動作を検証してください。

テスト前に判断基準を記述してください。成功とは、各ホスト名が意図したバックエンドにのみ到達し、アップストリームの障害時に他へ影響を与えず、範囲を限定したエラーが返ることです。リダイレクトループが発生する、WebSocketが失敗する、クライアントIPが偽装される、またはプロキシが無関係な管理ポートに到達できる場合は失敗です。これにより、部分的な接続やコマンドの正常終了をエンドツーエンドの互換性と誤認するのを防げます。

設計を区別できる最小限のテストを実行する

制御された1つの識別テストを使います。アップストリームを1つずつ追加し、プロキシからの直接到達性をテストしてから、Hostヘッダー、WebSocket、リダイレクト、クライアントIPの処理、バックエンド障害を検証します。変更したコンポーネントだけが唯一のもっともらしい原因になるよう、クライアント、ワークロード、ファイルセット、アカウント、タイミングを一定に保ってください。

Caddyリバースプロキシを使い、この経路で重要な2つ目の観測項目を選択します。トランザクションの両側を記録してください。リゾルバーまたはルート、ネゴシエートされたプロトコル、プロセスID、終了ステータス、レイテンシー、転送バイト数、リカバリーイベントを含めます。

タイトルに示されたライフサイクルイベント（再作成、再接続、再マウント、再起動、フェイルオーバー、またはクライアント変更）の後にテストを繰り返します。古いソケット、キャッシュ、または認証情報が有効な間だけ動作する設計は、合格していません。

curl -vk --resolve app.home:443:PROXY_IP https://app.home/
# WebSocket、アップロード、リダイレクト、バックエンド停止をテスト

合格、失敗、例外のシグナルを読み取る

合格: 各ホスト名が意図したバックエンドにのみ到達し、アップストリームの障害時に他へ影響を与えず、範囲を限定したエラーが返ります。この状態を生み出した正確なバージョンとトポロジーを保存してください。結論がプロトコルのあらゆる実装ではなく、これらの条件に適用されるためです。

失敗: リダイレクトループが発生する、WebSocketが失敗する、クライアントIPが偽装される、またはプロキシが無関係な管理ポートに到達できます。どちらかの主要な分岐が原因だと判断する前に、DNS、MTU、ID、ファイアウォールの状態、ストレージのレイテンシー、キャッシュされたセッションなどの共有依存関係を確認してください。

例外: ルートを削除し、以前のプロキシ設定を復元してから、ルーティング、信頼、ファイアウォールのルールを狭めて再試行します。どの境界が失敗したかを再現可能な観測で特定するまでは、権限を拡大したり、ソースデータを削除したり、トランスポートセキュリティを弱めたり、動作中のストレージを交換したりしないでください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

実際のワークロードで判断を検証する

観測された分岐に対応するアクションだけを適用し、元のワークロードを再実行します。2回の関連するライフサイクルサイクルと想定される同時負荷の下で、各ホスト名が意図したバックエンドにのみ到達し、アップストリームの障害時に他へ影響を与えず、範囲を限定したエラーが返る場合にのみ設計を維持してください。

リバースプロキシのバックエンドネットワークを使って、最も近い依存ワークフローを検証します。新しい設計が有効な間も、そのアクセス、タイミング、復旧動作に変化があってはなりません。

リダイレクトループが発生する、WebSocketが失敗する、クライアントIPが偽装される、またはプロキシが無関係な管理ポートに到達できる場合は、停止して保存した状態に戻してください。別の回避策を追加するのではなく、タイムスタンプ、正確なバージョン、ルートまたはマウントの証拠、最小限の再現手順を添えてエスカレーションしてください。

サービスルートの分離と結果を照合し、リスクが別のネットワーク、ID、バックアップ、またはストレージ層へ移っただけにならないようにします。

したがって、マルチホストのリバースプロキシについての適切な答えは、冒頭の判断であり、無条件の「はい」ではありません。観測された合格状態が受け入れラインであり、失敗状態がロールバックラインです。

よくある質問

バックエンドはパブリックポートを公開する必要がありますか？

いいえ。プロキシから到達可能で、バックエンドのファイアウォールによって許可されたプライベートリスナーがあれば十分です。

プロキシからバックエンドへの通信にもTLSを使用すべきですか？

LANまたはVLANの経路を完全には信頼できない場合、またはバックエンドのIDを検証する必要がある場合は使用してください。

1台のサーバーの障害で、プロキシ経由のすべてのアプリが停止することはありますか？

そのような状態になるべきではありません。タイムアウトと障害分離をテストし、停止したアップストリームが自身のエラーだけを返すことを確認してください。