アップストリームへの転送時に Host ヘッダーを維持
リバースプロキシはデフォルトで、アクセス元のリクエストに含まれる Host をアップストリームへ維持します。たとえば https://nas.example.com へアクセスすると、アップストリームでも Host: nas.example.com として認識されます。アプリはこの情報を使って、外部リンクの生成、Cookie ドメインの設定、仮想ホストの選択、コールバック URL の検証を行えます。
システム設定 → ゲートウェイ → Host ヘッダー は、Host ルーティングを使うサブドメインモードでのみ編集できます。これには、グローバル IP から直接公開するサブドメインモードと、トンネル → サブドメインマッピング が含まれます。パスモードと直接接続モードでは利用できず、認証サービスの Host も編集対象には表示されません。
無効にする場合
アップストリーム側で自身のアドレスを Host として使用する必要がある場合を除き、デフォルトの有効状態を維持してください。代表的な例は次のとおりです。
- アップストリームの Web サーバーに、内部用の仮想ホスト名しか設定されていない。
- アプリが Host の許可リストを検証しているが、外部ドメインをすぐには追加できない。
- 古いアプリが外部 Host を受け取ると、
400、誤ったリダイレクト、または別のサイトを返す。
無効にすると、ゲートウェイは外部 Host を強制的に維持しなくなり、アップストリームではリバースプロキシの転送先アドレスに基づいて Host が処理されます。これによりアップストリームの Host 検証を通過できることがありますが、アプリが 127.0.0.1、コンテナのサービス名、または内部ドメインを含むリンクを生成する可能性もあります。変更後は、ログイン時のリダイレクト、絶対 URL、Cookie、WebSocket を必ず確認してください。
Target 単位で適用
画面上のスイッチは Host ごとに表示されますが、実行中のゲートウェイではアップストリームの Target 単位で設定が反映されます。次の 2 つの Host は同じ Target を共有しています。
photos.example.com -> http://127.0.0.1:8080
files.example.com -> http://127.0.0.1:8080どちらか一方の Host で維持を無効にすると、この共有 Target 全体に影響します。異なる設定が必要な場合は、2 つの Host に別々の Target アドレスを設定してください。最終的に同じアプリへ到達する場合でも、異なるリッスンアドレス、ポート、またはリバースプロキシ層を使って区別できます。
パス別応答のリバースプロキシアクションでも、実際の Target に基づいて同じランタイムルールが適用されます。固定レスポンスにはアップストリームがないため、Host ヘッダーの維持は関係しません。
確認とトラブルシューティング
- 変更後、保存と同期の完了が画面に表示されるまで待ちます。
- 実際のサービス用ドメインからアクセスし、ステータスコード、リダイレクト先、ログインフローを確認します。
- リクエストログで、一致した Host、ルート種別、アップストリーム Target を確認します。
- アップストリームのアクセスログで受信した Host を記録し、アプリの想定どおりかを確認します。
- 複数の Host が同時に変化した場合は、同じ Target を共有していないか確認します。
Host ヘッダーの維持は、fn-knock がクライアント IP を識別する方法を決定するものではなく、TLS 証明書や DNS を変更するものでもありません。クライアントの送信元情報はプロキシヘッダーで伝達します。詳しくは上流へプロキシヘッダーを転送を参照してください。