NAT 越え：サブドメインルーティング

外部から着信可能なグローバル IP がない、ポートフォワーディングを設定できない、または FRP / Cloudflared をインターネット側の入口にしたい環境向けの構成です。外部トラフィックをトンネル経由で fn-knock ゲートウェイへ届け、アクセス先ドメインに応じて各サービスへ転送します。

• ネットワーク構成：NAT 越え / トンネル
• ルーティング方式：Host でサービスを振り分け
• 推奨ポリシー：ログイン優先
• 管理画面の場所：システム設定 → モード → リバースプロキシモード → サブドメインマッピング

NAT 越えでは、サブドメインマッピングを基本構成とします。パスモード は、旧構成との互換性を保つ場合や、パスプレフィックス配下での公開が必須のアプリに限って使用します。

作業を始める前に

次のものを用意します。

• DNS を管理できるドメイン（例：example.com）。
• FRP サーバー、または利用可能な Cloudflare Tunnel。
• 少なくとも 1 つの有効なログイン方法。
• fn-knock を実行する機器から、公開対象のサービスへ接続できるネットワーク経路。

fnOS FPK、Docker、OpenWrt、Linux、macOS、Synology DSM 7 SPK では、アプリ内でトンネルを利用できます。Windows x86_64 には FRP / Cloudflared が内蔵されていません。同じ Windows ホストでトンネルクライアントを別途動かす場合は、ローカルの 127.0.0.1:7999 をオリジンにすることを推奨します。ただし、そのトンネルの導入と運用は fn-knock の管理対象外です。Docker コンテナ内の 127.0.0.1 はコンテナ自身を指します。上流サービスがホスト上または LAN 内の別機器にある場合は、コンテナから到達できるアドレスを指定してください。

リクエストの経路

外部リクエストは次の順序で流れます。

1. auth.example.com または nas.example.com のインターネット側エンドポイント。
2. FRP または Cloudflared トンネル。
3. fn-knock の実際のゲートウェイポート。fnOS ネイティブ FPK、Docker Compose、OpenWrt、Linux、macOS、Synology DSM 7 SPK、Windows のデフォルトは 7999 です。Windows でトンネルを別途管理する場合は、同じホストのループバックアドレスをオリジンとして優先します。
4. 認証サービス、または該当する上流サービス。

トンネルは元の Host ヘッダーを fn-knock へ渡す必要があります。すべてのドメインを同じローカルゲートウェイへ向け、その後の振り分けを fn-knock が行います。

1. リバースプロキシモードとサブドメインマッピングを選ぶ

システム設定 → モード を開きます。

1. リバースプロキシモード を選びます。
2. ルーティング方式に サブドメインマッピング を選びます。
3. 設定を保存します。

保存後、サイドバーに サブドメインマッピング とトンネル関連のメニューが表示されます。

他のモードから切り替える場合は、既存のルート、証明書、認証 URL を確認してください。パスモードのマッピングを、そのままサブドメインマッピングとして使うことはできません。

2. ルートドメインと認証サービスを設定する

サブドメインマッピング を開き、サブドメインモード の設定を展開します。ドメイン に example.com を入力して保存し、認証サービスを追加 から auth.example.com を追加します。管理 Cloudflare Tunnel では標準 HTTPS 443 を使うため、公開ポート欄は表示されず、認証 URL に :7999 は追加されません。

認証サービスは、次の条件を満たす必要があります。

• 未ログインでも公開アクセスできる。
• 旧マッピングに厳格な許可リストルールが残っている場合、そのまま認証サービスには使えません。元の設定を控えたうえで、認証サービスを作り直してください。
• 現在使用する唯一の認証入口である。
• トンネル経由でローカルの fn-knock ゲートウェイへ到達できる。

認証 URL を外部ネットワークから開けることを先に確認してから、サービス用マッピングを設定します。

3. サービス用マッピングを追加する

サブドメインマッピング を開き、サービスを追加します。例：

設定項目	例
サブドメイン	nas
転送先	http://192.168.1.20:5666
ログインを必須にする	オン

保存後、外部からは https://nas.example.com でアクセスできます。

上流サービスで HTTP Basic 認証が必要な場合は、マッピングの詳細設定で Basic 認証を自動入力 を有効にし、上流用の認証情報を入力します。この認証情報は fn-knock から上流へ接続するためのもので、利用者の fn-knock ログインを置き換えるものではありません。

4. アクセスポリシーを設定する

Host マッピングの編集画面には、ログインを必須にする スイッチがあります。

設定	動作
ログインを必須にする をオフ（現在のログイン優先マッピング）	公開アクセスになります。fn-knock のログイン状態や許可リストを確認しません
ログインを必須にする をオン	有効な送信元 IP 許可がなければ、セッションと認証情報のサービススコープで続けて判定します
旧バージョンの厳格な許可リストルール	ログインを必須にする をオフにしても公開されるとは限りません。有効な送信元 IP 許可レコード（手動、またはログイン後に自動作成）だけで判定し、セッション Cookie だけでは送信元条件を満たせません

ほとんどのトンネル構成では ログインを必須にする をオンにします。現在の画面では厳格な許可リストを新たに選べません。旧ルールを解除するには、現在の画面からマッピングを作り直す必要があり、ログインを必須にする をオフにするだけでは公開されません。Cloudflare、FRP、その他のプロキシノードの送信元 IP を利用者の固定 IP として許可リストへ追加しないでください。すべてのリクエストが同じ送信元と見なされるおそれがあります。

5. トンネルを設定する

まず システム設定 で FRP または Cloudflared のリソースを用意し、続いてトンネル画面でトンネルを作成して起動します。

Cloudflared を使う

1. システム設定 → Cloudflared で実行リソースを準備します。
2. トンネル → Cloudflared で Tunnel、Zone Read、DNS Edit 権限を持つ推奨の Cloudflare Account API Token を接続します。
3. 推奨の専用 Tunnel を選び、プレビュー で Tunnel、*.example.com Ingress、プロキシ CNAME を確認します。
4. 競合を解消して適用します。fn-knock が Tunnel Token を取得して Cloudflared を起動します。

適用後、auth.example.com、nas.example.com などの Host はワイルドカード Tunnel からゲートウェイへ入ります。Cloudflare Zero Trust で Host ごとに Public Hostname を作成する必要はありません。利用者は :7999 を付けず https://nas.example.com へアクセスします。

上級者は手動 Tunnel Token も使用できます。Public Hostname と実オリジンポートを自分で設定するのは、手動または外部管理 Cloudflared の場合だけです。詳しくはCloudflared トンネルの設定を参照してください。

FRP を使う

FRP サーバーでは、外部の HTTP / HTTPS トラフィックを fn-knock の実際のゲートウェイポートへ転送し、元の Host ヘッダーを保持します。認証用ドメインとサービス用ドメインは、同じゲートウェイ入口を共有できます。

外部ポート、証明書、DNS は、FRP サーバー側の構成に合わせて設定します。fn-knock の管理入口を、FRP のサービス用オリジンとして公開しないでください。

6. HTTPS と公開認証 URL を確認する

エッジプラットフォームで TLS を終端する場合、ブラウザーから見える公開 URL は HTTPS にし、fn-knock の認証リダイレクト URL も一致させる必要があります。公開 URL とローカルオリジンへの接続プロトコルが異なる場合でも、利用者に見える認証 URL へローカルの HTTP アドレスを設定してはいけません。

FRP で HTTPS を直接提供する場合は、FRP サーバーまたは fn-knock ゲートウェイに、すべてのサブドメインをカバーする証明書を設定します。証明書については TLS 証明書と HTTPSを参照してください。

7. 外部ネットワークから検証する

スマートフォンのモバイル回線を使い、次の順序でテストします。

1. auth.example.com を開き、ログインページへ到達できることを確認します。
2. nas.example.com を開き、認証フローへ進むことを確認します。
3. ログイン後、サービスの画面へ戻ることを確認します。
4. トンネルの状態と fn-knock の リクエストログ を確認し、正しい Host と上流サービスに一致していることを確かめます。

パスモードは互換目的に限る

リバースプロキシモード → パスモード は、現在の画面で非推奨と表示されます。使用するのは次の場合だけです。

• 既存のパスマッピングを残す必要があり、すぐには移行できない。
• 外部公開に使えるドメインが 1 つしかない。
• 上流アプリがパスプレフィックス配下での公開を明示的にサポートしている。

たとえば、https://example.com/nas/ を NAS へ転送する構成です。上流アプリがパスプレフィックス、リダイレクト、Cookie、WebSocket を正しく処理できなければ、静的ファイルの 404、ログインループ、ルートパスへの意図しないリダイレクトが発生しやすくなります。

新しい構成では、サービスごとに専用サブドメインを割り当ててください。旧構成からの移行方法は、NAT 越えとパスマッピングを参照してください。

よくあるトラブル

症状	最初に確認する項目
トンネルはオンラインだがドメインがタイムアウトする	Cloudflare 同期競合、ワイルドカード DNS、Ingress、FRP の入口、ローカル Host マッピング
どのサブドメインも同じサービスへ入る	トンネルまたは前段プロキシが Host ヘッダーを保持しているか
502 が返る	トンネルからゲートウェイへ接続できるか、ゲートウェイから上流サービスへ接続できるか
リダイレクトがループする、または :7999 が付く	管理 Cloudflared のサブドメインマッピングと標準 HTTPS を確認し、元のサービス Host からアクセスし直す
Cloudflared で TLS エラーが出る	オリジン接続のプロトコルまたは証明書の信頼設定
パスモードで静的ファイルが 404 になる	上流がパスプレフィックスに対応していません。サブドメインマッピングへの移行を優先します

トラブルシューティング全体は FAQを参照してください。

関連ドキュメント

• デプロイ方法とアクセス構成を選ぶ
• サブドメインマッピング
• サービス検出と一括登録
• NAT 越えとパスマッピング
• 認証とログイン
• リクエストログ