実行モードを選ぶ

システム設定 → モード では、ネットワーク構成とルーティング方式を組み合わせた複数の動作モードから選びます。設定前に、「トラフィックをどう機器まで届けるか」「ゲートウェイからサービスへどう振り分けるか」「誰にサービスへのアクセスを許可するか」の 3 点をそれぞれ決めてください。

Web サービスには Host ルーティングを基本とします。パスモードは、既存のパス形式の入口を維持する場合や、移行できないアプリのために残された互換モードです。新規構成には推奨しません。

このページにあるアプリ内トンネルの手順は、管理画面から実際に FRP または Cloudflared を利用できるデプロイ方式だけが対象です。Windows の 7999 はデフォルトで全インターフェースを待ち受けるため、グローバル IP からの直接公開や自前で管理するトンネルのオリジンにできます。ただし、FRP、Cloudflared、直接接続の IP 許可、ホストファイアウォールの動的管理は内蔵していません。外部から到達できるかどうかは、Windows ファイアウォールのプロファイル、ルーター / NAT、IPv6、ISP のポリシーにも依存します。詳しくは Windows x86_64 へのデプロイを参照してください。

1. ネットワーク構成を選ぶ

条件	管理画面での選択	外部トラフィック
機器に外部から到達可能なグローバル IPv4 / IPv6 がある	サブドメインモード	ドメインからゲートウェイへ直接入る
機器にインターネット側の入口がない	リバースプロキシモード	FRP または Cloudflared でリクエストをゲートウェイへ届ける
ログイン後にサービス本来のポートへ接続する必要がある	直接接続モード（非推奨）	先にゲートウェイでログインし、ファイアウォールで送信元 IP を許可する

グローバル IP の有無で決まるのは入口の構成だけであり、Web サービスをパス形式で公開しなければならないわけではありません。トンネルを使う NAT 越え構成でもサブドメインマッピングを選べます。

2. ルーティング方式を選ぶ

Host ルーティング：Web サービスの標準構成

グローバル IP から直接公開する サブドメインモード と、リバースプロキシモード → サブドメインマッピング では、リクエストを Host で振り分けます。

auth.example.com  -> 認証サービス
nas.example.com   -> http://127.0.0.1:5666
alist.example.com -> http://127.0.0.1:5244

サービスごとにルートパスをそのまま使えるため、静的ファイル、WebSocket、コールバック URL が正しく動作しやすい構成です。2 つのネットワーク構成は同じ サブドメインマッピング 設定を使いますが、利用できる機能が異なります。

• グローバル IP から直接公開するサブドメインモードでは、ホストのファイアウォール、スマート接続、プロトコルマッピングを利用できます。
• NAT 越えのサブドメインマッピングでは FRP / Cloudflared を利用できますが、スマート接続とプロトコルマッピングは提供されません。

設定手順はサブドメインモードのセットアップを参照してください。

パスルーティング：互換構成

リバースプロキシモード → パスモード では、1 つの Host 配下でパスプレフィックスを使ってサービスを振り分けます。

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

アプリによっては、プレフィックスの除去、HTML の書き換え、ルートディレクトリ互換の設定が必要です。それでも絶対パス、Service Worker、コールバック URL が原因で動作しないことがあります。既存のパス構成は引き続き使えますが、新しく公開するサービスには Host ルーティングを優先してください。設定手順は NAT 越えのセットアップを参照してください。

TCP / UDP とサービス本来のポート

• プロトコルマッピング は、SSH、データベース、DNS などの非 HTTP サービス向けに TCP / UDP ポートを追加で待ち受けます。グローバル IP から直接公開するサブドメインモードでのみ利用できます。詳しくは TCP / UDP ストリームプロキシを参照してください。
• 直接接続モード はサービスを転送しません。ログイン後に現在の送信元 IP を許可し、5666 や 22 などサービス本来のポートへ接続できるようにします。詳しくは直接接続モードのセットアップを参照してください。

3. アクセスポリシーを選ぶ

現在の Host 編集画面には ログインを必須にする スイッチがあります。オフなら公開アクセス、オンならログイン優先になります。

設定	外部リクエストの処理	向いている用途
ログインを必須にする をオフ（現在のログイン優先マッピング）	上流へそのままプロキシ	明示的に一般公開するサービス
ログインを必須にする をオン	有効な送信元 IP 許可またはセッションがない場合は auth.example.com へ移動し、認証完了後に元の Host へ戻る	ほとんどのプライベート Web サービス

バックエンドは、旧設定に残る strict_whitelist も引き続き認識します。このルールでは ログインを必須にする をオフにしても公開されるとは限らず、有効な送信元 IP 許可レコード（手動、またはログイン後に自動作成）で判定します。ブラウザーのセッション Cookie だけでは送信元条件を満たせません。現在の画面には、厳格な許可リストルールを新規作成したり切り替えたりする操作項目がありません。解除する場合はマッピング全体を控えたうえで、現在の画面から作り直してください。新しいマッピングでは、手動の送信元 IP 許可だけでもアクセスできます。自動 IP 許可も通常は同じ送信元からの継続アクセスを許可しますが、認証情報に設定されたサービススコープによる拒否を上書きしません。IP 許可リスト は、送信元を厳密に限定するスイッチではありません。リクエストがマッピングへ到達する前に送信元を絞る場合は、ゲートウェイの公開範囲または外部ネットワーク側のルールを使用します。

ログイン認証情報には、アクセス可能なサービススコープも設定できます。ブラウザーに有効なセッションがあっても、認証情報のスコープ外にある Host へのアクセスは拒否されます。

Basic 認証を自動入力 は fn-knock のアクセスポリシーではありません。上流へ送るリクエストにユーザー名とパスワードを付加し、転送先サービス自体の Basic 認証を通過するための機能です。fn-knock が利用者へ提供するログイン方法ではありません。

ローカル送信元の例外

ゲートウェイが送信元をループバック、プライベートアドレス、リンクローカルのいずれかと認識すると、認証結果は local_exempt になり、通常のログインと厳格な許可リストの確認を通過します。これは LAN を信頼境界の一部として扱う動作です。

• LAN 内のテスト結果だけで、外部公開時の認証が機能していると判断しないでください。
• トンネルまたは前段プロキシは、実際のクライアント IP を正しく渡す必要があります。設定が誤っていると、すべての利用者が同じプロキシ送信元に見えたり、ローカル送信元と判定されたりするおそれがあります。
• モバイル回線から、ログイン、許可リスト、ログアウト後の実際の動作を確認してください。

推奨構成

シナリオ	ネットワーク構成	ルーティング	アクセスポリシー
グローバル IP とドメインがある Web サービス	サブドメインモード	Host	ログインを必須にする をオン。入口の送信元も絞る場合は、別途ゲートウェイの公開範囲を設定
グローバル IP がなく、Cloudflared を使う	リバースプロキシモード → サブドメインマッピング	Host	ログインを必須にする をオン
グローバル IP がなく、FRP を使う	リバースプロキシモード → サブドメインマッピング	Host	ログインを必須にする をオン。PROXY Protocol で送信元 IP が保持されることを確認
移行途中の旧パス構成	リバースプロキシモード → パスモード	パス	マッピングごとにログインの要否を設定
多数の元ポートへ接続する必要がある	直接接続モード（非推奨）	元のポート	ログイン後に送信元 IP を許可

モード切り替え時に維持・停止される機能

• パスモードからサブドメインルーティングへ切り替えると、パスマッピングは非表示になります。グローバル IP から直接公開するサブドメインモードへ切り替える際は、パスルールを削除するか画面で確認されます。
• リバースプロキシモードのサブドメインマッピングとパスモードは、どちらも FRP / Cloudflared を利用できます。リバースプロキシモードから切り替えると、実行中のトンネルを停止しようとします。
• グローバル IP から直接公開するサブドメインモードを終了すると、プロトコルマッピング機能が無効になりリスナーも停止しますが、保存済みのルールは保持されます。このモードへ戻って機能を有効にすると復元できます。
• 直接接続モードはホストのファイアウォールに依存します。Docker、Synology DSM 7 SPK、Windows、ホストを管理できないデプロイ方式では選択できません。
• Docker はホストのファイアウォールを書き換えず、スマート接続にも対応しません。OpenWrt は SSH セキュリティ、Web ターミナル、アプリ内 FPK 更新には対応しませんが、スマート接続は利用できます。OpenWrt でスマート接続を使うには、既存の dnsmasq が有効で、設定から /etc/dnsmasq.d/ を読み込む必要があります。画面から apt-get を使って依存パッケージを自動インストールすることはできません。
• Windows は、直接接続の IP 許可、アプリ内からのホストファイアウォール管理、スマート接続、内蔵 FRP / Cloudflared、Web ターミナル、SSH セキュリティに対応していません。Web の更新画面から Windows 版を更新することもできません。
• Synology DSM 7 SPK は内蔵 FRP / Cloudflared に対応しますが、直接接続の IP 許可、ホストのファイアウォール管理、スマート接続、Web ターミナル、SSH セキュリティ、Web 画面からの更新には対応していません。

切り替え後は、画面が開くかどうかだけで済ませず、実際の外部ネットワークから入口、Host、クライアント IP、許可の種類、上流の転送先を確認してください。