サブドメインルーティング

サブドメインマッピング は、HTTP の Host に基づいて複数のドメインをローカル Web サービスへ振り分ける機能で、新しいデプロイにおけるデフォルトのルーティング方式です。次の 2 種類のネットワーク構成で使用できます。

• サブドメインモード：ドメインが、到達可能な公開エントリーポイントへ直接名前解決される。
• リバースプロキシモード → サブドメインマッピング：FRP または Cloudflared が、各サブドメインのリクエストをゲートウェイへ送る。

どちらの構成でも auth.example.com をログイン用エントリーポイントとして使用し、nas.example.com、alist.example.com などのサービス用 Host で同じゲートウェイを共有します。パスマッピングは以前のデプロイとの互換性を保つための方式であり、サブドメインマッピングの前提条件ではありません。

リクエスト経路

ブラウザー -> インターネット直結またはトンネル -> fn-knock ゲートウェイ -> Host で照合 -> ローカル Target
                                                       |
                                                       +-> 認証なし / ログイン必須 / 高度な認証の一時認証情報

インターネットから直接到達し、デフォルトポートを維持する場合、通常は https://nas.example.com:7999 の形式でアクセスします。前段に EdgeOne、ESA、Cloudflared がある場合、訪問者は通常、標準の https://nas.example.com を使用しますが、オリジン側では引き続き実際のゲートウェイポートへ接続します。

設定手順

1. システム設定 → モード で サブドメインモード、または リバースプロキシモード → サブドメインマッピング を選択します。
2. サブドメインマッピング で、example.com などのルートドメインを保存します。
3. 認証サービスを追加 をクリックし、auth.example.com を作成します。
4. 公開 DNS、ルーターのポート転送、または Tunnel Public Hostname を設定し、関連するすべての Host が同じゲートウェイへ入るようにします。
5. サービス用 Host を追加し、各マッピングで ログインを必須にする を有効にするか決定します。
6. 送信元やリクエストの特徴に応じて許可する必要がある場合は、マッピング右側のメニューから 高度な認証 を開きます。
7. モバイルネットワークを使って、ログインへのリダイレクト、元のアドレスへの復帰、リクエストログのクライアント IP を検証します。

インターネットから直接接続する場合の詳しい手順については、サブドメインモードのセットアップとサブドメイン直接接続の手順を参照してください。

サブドメインモードの設定

項目	役割	推奨設定
ドメイン	サービス用 Host の親ドメイン（例：example.com）を生成	認証サービスやサービス用マッピングを追加する前に保存
現在の認証サービス	未ログイン時に使用する共通のログイン用エントリーポイント	auth.example.com を使用。作成できるのは 1 件だけ
認証サービスの公開 HTTPS ポート	ログインへのリダイレクト URL を生成するときに使用する、訪問者側の HTTPS ポート	訪問者から実際に見えるポートを入力
エッジ経由の実クライアント IP 検出	インターネット直結のサブドメインモードで、EdgeOne / ESA から訪問者のアドレスを取得	該当プラットフォームをオリジンの前段に置く場合のみ有効化

認証サービスの公開 HTTPS ポートが影響するのは外部 URL だけです。プログラムのリッスンポートを変更したり、ルーター、コンテナ、エッジプラットフォームでポートを開放したり、NAT 転送を作成したりすることはありません。

ルートドメインと Host マッピングには * を含められません。ルートドメインには example.com、サービス用マッピングには nas または nas.example.com を入力します。DNS で *.example.com のワイルドカードレコードを設定するかどうかは別の層の設定であり、fn-knock のルートドメインや Host には入力しないでください。

EdgeOne / ESA

インターネット直結のサブドメインモードでは、Tencent EdgeOne / Alibaba Cloud ESA のサポートを有効にできます。有効にすると公開 URL の :7999 を省略でき、ゲートウェイは各プラットフォームのヘッダーから実クライアント IP を取得します。

プラットフォーム	クライアント IP ヘッダー
Tencent EdgeOne	EO-Connecting-IP
Alibaba Cloud ESA	Ali-Real-Client-IP

ESA では、サイトのマネージドリクエストヘッダー変換で「実クライアント IP ヘッダーを追加」も有効にする必要があります。このスイッチが対象とするのは EdgeOne / ESA だけで、任意の CDN を一般的に信頼するスイッチではありません。Cloudflared では リバースプロキシモード → サブドメインマッピング の専用経路を使用してください。

エッジプラットフォームが外部の 80 / 443 を処理する場合でも、オリジンは fn-knock の実際のゲートウェイポートを指定します。ログインレスポンスをキャッシュするルールを無効にし、WebSocket を許可してください。証明書と名前解決については、TLS 証明書と HTTPSとDDNS 管理を参照してください。

Host マッピング

各マッピングには、少なくとも Host と Target が必要です。

nas.example.com   -> http://127.0.0.1:5666
alist.example.com -> http://127.0.0.1:5244

項目	動作
Host / サブドメイン	リクエストの Host と照合。ルートドメインを保存済みの場合は nas だけを入力可能
Target	HTTP / HTTPS のアップストリームアドレス。fn-knock の実行環境から到達できる必要がある
ログインを必須にする	未ログインの場合は認証 Host へ移動し、完了後に元のアドレスへ戻す
無効化 / 有効化または無効化を予約	手動で公開を停止するか、サーバーのローカル時刻に基づいて毎日の公開時間を制御
グループ	サービス用 Host を既存のグループへ配置。認証サービスはグループ化不可
ポータルを表示	ログイン後のページに、アプリ切り替えとログアウトの入口を表示するかを制御
表示タイトル	一覧、ポータル、ブックマークに表示する名前を上書き
アプリアイコン	自動取得したアイコンを使うか、現在のサービス用 Host にカスタムアイコンをアップロード
Basic 認証を自動入力	アップストリームへのリクエストへ Basic 認証のユーザー名とパスワードを挿入
公開範囲	グローバルルールを継承するか、現在の Host のルールで上書きするか、現在の Host だけ公開範囲の制限を無効にする
WAF を有効にする	サービス用 Host ではデフォルトで有効。無効にすると、現在の Host はグローバル WAF をスキップ

サービスは可能な限り、ループバックまたはプライベートネットワークのアドレスだけをリッスンさせ、ゲートウェイを迂回されないようにしてください。Docker 内の 127.0.0.1 はコンテナ自身を指します。ホスト上のサービスをプロキシする場合は、コンテナから到達可能なホストのアドレスを使用します。Docker デプロイの Target 欄には、検出された到達可能な LAN IP 候補が表示されますが、候補を選んでもコンテナネットワーク、公開ポート、アップストリームのリッスン範囲は変更されません。

認証サービスは特殊な Host マッピングです。常に公開する必要があり、ログイン必須や Basic 認証の自動入力を有効にしてはいけません。有効にすると、ログイン用エントリーポイントがループするか、自身によってブロックされます。

グループ表示

一覧上部の グループ表示 を有効にすると、グループを管理 でグループの作成、名前変更、並び替え、削除ができます。サービス用 Host は個別編集、一括移動、ドラッグ＆ドロップでグループへ配置できます。作成できるグループは最大 32 件です。名前は 1～40 文字で、大文字と小文字を区別せず重複できません。マッピングを含むグループを削除しても Host は削除されず、「未分類」へ移動します。

グループと Host の順序は、ログイン後のポータルと組み込みの /__select__ 選択ページへ同期されます。ブラウザーブックマークのエクスポートでも対応するグループフォルダーが作成されます。一覧表示へ戻してもグループの割り当ては保持されますが、ポータル、選択ページ、新しくエクスポートしたブックマークはフラットな順序になります。検索中は一致するグループと Host だけを表示し、結果を一時的に展開します。折りたたみ状態は現在のブラウザーにだけ保存されます。

グループ化で変わるのはナビゲーションと管理上の順序だけです。認証、公開範囲、WAF、Target は変更されません。認証サービスは常にグループの外に置かれ、実際のアクセス可否は引き続き認証情報の Host サービス範囲で判定されます。

Basic 認証はアップストリーム認証情報の挿入

Basic 認証を自動入力 で保存するのは、転送先サービス自身の Basic 認証情報です。ゲートウェイは、リクエストのプロキシ、ページタイトル、favicon の取得時に認証情報をアップストリームへ送信し、ブラウザーに Basic 認証ダイアログが再表示されないようにします。

fn-knock のアカウントを作成する機能ではなく、auth.example.com でのログインにも代わりません。また、ログインを必須にする や既存の strict_whitelist ルールも変更しません。認証情報は機密設定として扱い、本当に必要な場合だけ保存してください。

ユーザー名とパスワードは両方入力する必要があり、ユーザー名には半角コロンを使用できません。不完全または無効な設定を保存すると、システムは一部だけを残さず、この機能を無効にして認証情報を消去します。

アプリアイコン

通常のサービス用 Host を編集するときに アプリアイコン を開くと、現在の取得元をプレビューし、アップストリームのアイコンを再取得するか、カスタム画像をアップロードできます。PNG、JPG、WebP、AVIF、SVG、ICO に対応し、元ファイルの上限は 5 MB です。ブラウザーは SVG の外部コンテンツを削除し、サーバーも安全でない DOCTYPE またはエンティティ宣言を含む SVG を拒否します。その後、画像を切り抜かずに正方形のキャンバスへ収め、128 KiB 以下の埋め込みアイコンへ変換します。

カスタムアイコンはサブドメイン一覧とポータルで優先表示され、ブラウザーブックマークのエクスポートにも埋め込まれます。自動取得に戻す を選ぶとカスタム上書きが消去され、Target から再取得されます。Target がアイコンを返さない場合は未取得と表示されます。認証サービスではカスタムアイコンを使用できません。アイコンは設定と .knock バックアップに含まれるため、機密性のある社内画像を通常の調査用添付ファイルとして共有しないでください。

Host ごとの公開範囲と WAF

グローバルのゲートウェイ公開範囲を有効にすると、サービス用 Host の詳細設定で グローバル公開範囲を継承、カスタム、無効 のいずれかを選択できます。カスタムルールはグローバルルールを置き換え、無効にすると現在の Host だけが公開範囲の確認をスキップします。認証 Host はグローバルルールを継承する必要があります。設定方法とロールバックの推奨事項については、ゲートウェイの公開範囲を参照してください。

サービス用 Host では WAF がデフォルトで有効で、個別に無効にするとグローバル WAF をスキップできます。グローバル WAF 自体が無効な場合、このスイッチだけでは保護されません。認証 Host は Host 設定から WAF を迂回できません。詳しいポリシーについては、Web Application Firewall（WAF）を参照してください。

高度な認証

ログインを必須にする が有効な HTTP / HTTPS のサービス用 Host では、右側のメニューに 高度な認証 が表示されます。送信元 IP、地域、URL パス、リクエスト Header、Query パラメータ、HTTP メソッドに基づいて、現在の Host だけで使える一時認証情報を発行できます。どのルールにも一致しないリクエストは、通常のログインフローへ進みます。

ルールに一致すると、条件を発動させたパスやリクエストだけでなく、現在の Host 全体へのアクセスが許可されます。システムへのログインではないため、ポータルは作成されず、他の Host へのアクセス権限も付与されません。設定前にサブドメインの高度な認証を参照してください。

アクセスポリシーと local_exempt

現在の画面設定	許可されていないインターネット側のリクエスト
ログインを必須にする を無効（現在のログイン優先マッピング）	アップストリームへ直接アクセス
ログインを必須にする を有効	有効な送信元 IP のアクセス許可またはセッションがない場合、認証 Host へ移動
ログインを必須にする と高度な認証を有効	ルールに一致すると現在の Host 用の一時認証情報を発行。一致しない場合は送信元のアクセス許可とログインを引き続き確認

バックエンドは、既存設定の strict_whitelist ルールにも引き続き対応します。このルールがある場合、ログインを必須にする が無効でも必ずしも公開されず、手動またはログイン後に自動作成された有効な送信元アクセス許可に基づいて判定されます。ブラウザーセッション Cookie だけでは送信元の条件を満たせません。現在の Host 編集画面には、厳格なホワイトリストルールを新規作成または切り替えるためのコントロールはありません。このルールを解除するには、マッピング全体を記録した上で、現在の画面から作成し直してください。新しいマッピングでは、手動の送信元アクセス許可によって個別に許可できます。IP の自動許可でも通常は同じ送信元からアクセスを継続できますが、サービススコープによる拒否が伴う場合、それを上書きすることはありません。ホワイトリスト は、送信元を厳格に制限するためのスイッチではありません。リクエストがマッピングへ到達する前に送信元を絞り込む場合は、ゲートウェイの公開範囲または外部ネットワーク層のルールを使用してください。

ログイン認証情報には、アクセスを許可する Host の範囲を設定できます。1 つの認証情報でログインに成功しても、すべてのサービス用サブドメインへ自動的にアクセスできるわけではありません。

認証サービスは、まずゲートウェイが識別した送信元 IP を確認します。ループバック、プライベートネットワーク、リンクローカルなどの送信元は local_exempt となり、通常のログインと厳格なホワイトリストの確認をスキップします。つまり、LAN はデフォルトの信頼境界に含まれます。

• 既存の厳格なホワイトリストルールがあっても、LAN 内の送信元にログインを強制できません。
• 認証情報の Host サービススコープも、ローカル例外の送信元を制限しません。これはネットワークの信頼境界なので、認証情報のスコープ検証には適していません。
• LAN 内のテストでは、インターネット側のポリシーが機能していることを証明できません。
• 前段に FRP、Cloudflared、EdgeOne、ESA がある場合は、実際のグローバル IP がゲートウェイまで伝わっていることをリクエストログで確認してください。プロキシのプライベートアドレスが訪問者の送信元と誤認されると、認証結果が変わります。

送信元ネットワークの設定については、IP 許可リストとゲートウェイの公開範囲を参照してください。

一括登録とメンテナンス

サービスを検出 は、許可されたローカル IPv4 ネットワークをスキャンして Host の候補を生成します。スキャンでは最大 16 個の CIDR、合計 1024 台のホストを指定できます。対象はループバック、ネットワークインターフェース、Docker ホスト、既存のマッピング、手動で保存したローカル範囲に限られ、インターネットのスキャンには使用されません。

スキャンウィンドウでは、デバイスの推奨に従う（デフォルト）または低、中、高、最大のスキャン強度を選択できます。レベルが変えるのは同時実行数、速度、デバイス負荷だけで、スキャン範囲や検出結果は変わりません。デフォルトでは CPU、使用可能なメモリ、ファイル記述子の予算をもとに、より安全なレベルが選ばれます。NAS やルーターなどリソースが限られたデバイスでは、自動または低強度を優先してください。

スキャン対象ポート、許可される CIDR 範囲、Docker のネットワークから見える範囲、一括保存のルールについては、サービス検出と一括登録を参照してください。

一覧で利用できる操作は次のとおりです。

• アイコンとタイトルを更新：アップストリームのメタデータを再取得します。
• 到達不能なサービスを整理：先に HEAD、失敗した場合は GET で HTTP / HTTPS アップストリームを確認し、管理者の確認後に到達不能なマッピングを削除します。
• ブックマークとしてエクスポート：サービス用 Host をエクスポートし、認証サービスは含めません。
• すべての設定をクリア：2 回の確認後に認証サービスとすべての Host マッピングを削除し、ルートドメインなどのモード設定は維持します。

各 Host のトラフィック詳細では、リアルタイムトラフィックとアクティブ IP を確認し、不審な送信元をグローバルブロックリストへ追加できます。

Host ルーティングを補完する機能

• パス単位の固定レスポンスは、特定の Host に少数の特殊なパスを追加します。どのルールにも一致しない場合は、その Host のデフォルト Target へ戻ります。
• TCP / UDP ストリームプロキシは、インターネット直結のサブドメインモードに TCP / UDP ポートを追加します。リバースプロキシモードのサブドメインマッピングでは利用できません。
• fnOS 共有リンクのパススルーは、正規の FNOS /s/... 共有経路だけをバイパスし、サイト全体を公開するものではありません。

これらの機能を使用しても、Web のメインルートが Host であることは変わりません。

プラットフォームごとの制限

• Host ルーティングは、FNOS FPK、Docker、OpenWrt、Linux、Synology DSM 7 SPK、Windows で使用できます。インターネットから実際に到達できるかどうかは、各プラットフォームのポート公開とネットワーク経路によって決まります。
• ホストのファイアウォールへの自動書き込みとスマート接続には、ホスト管理機能が必要です。Docker ではこれらの機能を利用できません。
• プロトコルマッピングは、インターネット直結のサブドメインモードでのみ表示されます。Docker で追加ポートを公開しても、fn-knock がホストのファイアウォールを管理することはありません。
• OpenWrt では、ホスト上の root 権限があればファイアウォールを管理できます。スマート接続には既存の dnsmasq と、メイン設定から /etc/dnsmasq.d/ を読み込む設定が必要です。ページの apt-get 自動インストールは使用できません。また、SSH セキュリティ、Web ターミナル、アプリ内 FPK 更新には対応しません。
• fn-knock はアップストリームサービスの既存の公開リッスン状態を自動的に停止せず、アップストリームの更新、バックアップ、最小権限設定にも代わりません。

検証とトラブルシューティング

リクエスト経路に沿って確認します。

1. DNS または Tunnel Public Hostname が、現在の Host を正しいゲートウェイポートへ送っているか。
2. リクエストログの Host とクライアント IP が正しいか。
3. 認証サービスが存在し、ログイン必須または Basic 認証が有効になっていないか。
4. サービス用マッピングが有効で、現在時刻が公開時間内か。
5. fn-knock の実行環境から Target へ到達できるか。
6. ログイン認証情報で現在の Host が許可されているか。高度な認証を有効にしている場合は、ルールグループ、条件、一時認証情報の状態も確認する。
7. 過去の厳格なホワイトリストルールがある場合、現在のグローバル IP が許可されているか。
8. HTTPS 証明書が現在の Host をカバーし、前段のプラットフォームが WebSocket を許可し、認証レスポンスをキャッシュしていないか。

まず 1～2 個のサービスを登録して外部ネットワークからの検証を完了し、その後、一括検出とアクセスポリシーの厳格化を行ってください。