よくある質問

症状から問題を特定します。最初に、現在のデプロイ方法と実行モード、アクセスしているのが管理用入口かゲートウェイ入口かを確認してください。

管理用入口を開けない、またはログインできない

デスクトップアイコンとゲートウェイ入口のどちらを開けばよいか

目的	入口
設定の変更、ログの確認、モードの切り替え	飛牛デスクトップの 敲门 knock。Synology では DSM のメインメニューから 敲门 knock を開きます。OpenWrt では サービス → 敲门 Knock、Windows では fn-knock Windows 管理アプリ を使用してローカル管理画面を開きます
インターネット公開、ドメイン、トンネル、サービスマッピングの確認	実際のゲートウェイポート、または対応する外部ドメイン。デフォルトは通常 7999 です

OpenWrt のデフォルト管理ポートは 7991 で、ゲートウェイは 7999 のままです。Windows の管理画面は 127.0.0.1:7991 に厳しく制限されており、別の端末から開くことはできません。他のデプロイで使用するポートは、ポートと入口を参照してください。

Windows の管理画面を開けない

最初に fn-knock Windows 管理アプリ を開き、FnKnock サービスの状態が「準備完了」であることを確認してから、「管理画面を開く」をクリックします。初回インストール時のデフォルトアドレスは http://127.0.0.1:7991/ で、管理アプリをインストールした Windows ホストからしかアクセスできません。

サービスが準備完了にならない場合は、まずデフォルトの 5 ポートが使用中でないかを確認してください。%ProgramData%\FnKnock\config\runtime.json を直接編集せず、管理アプリからポートを変更して保存します。手順全体は Windows x86_64 へのデプロイを参照してください。

Synology で DSM セッションを読み取れないと表示される

現在の fn-knock ページを閉じ、DSM のログインがまだ有効であることを確認してから、DSM のメインメニューから 敲门 knock を開き直してください。Synology の管理用入口は、DSM デスクトップのウィンドウからセッションを取得する必要があります。launch.html や index.cgi を直接ブックマークして開いた場合や、新しいタブへ内部アドレスをコピーした場合、必要な DSM コンテキストが欠けることがあります。

管理画面を開けるのは administrators グループのメンバーだけです。それでも失敗する場合は、パッケージセンターで fn-knock が起動していることを確認し、DSM へログインし直してください。7998 を公開しないでください。入口とポートの詳細は Synology DSM 7 へのデプロイを参照してください。

管理画面にストレージエラーが表示される

現在のバージョンは SQLite を使用しており、新規インストールに Redis は必要ありません。

• 新規インストール：データディレクトリの権限、ポートの競合、サービスログを確認します。
• 初期の Redis 版からのアップグレード：古い Redis データボリュームを保持し、Docker へのデプロイにある移行手順に従います。
• OpenWrt：/etc/fn-knock/gateway と /var/lib/fn-knock が残っていることを確認します。

新規インストールのために、空の Redis を追加で作成しないでください。古いデータの移行が完了し、管理画面が正常に動作することを確認してから、古い Redis サービスとデータボリュームを削除してください。

管理パスワードを忘れた

管理パスワードと、訪問者がログインに使用する認証情報は別のものです。データディレクトリを削除せず、デプロイ方法に応じてローカルコンソールまたはコンテナからリセットします。

• Docker：Docker へのデプロイにある管理パスワードの復旧手順を参照してください。
• OpenWrt：OpenWrt へのデプロイを参照してください。
• 飛牛 fnOS FPK：まず飛牛デスクトップから 敲门 knock を開き直してください。
• Windows：まず fn-knock Windows 管理アプリ で「管理パスワードを消去」をクリックします。管理アプリを開けない場合は、アプリケーションのインストールディレクトリで管理者 PowerShell を開き、.\fn-knock-service.exe reset-panel-password を実行します。

管理画面は正常だが、外部ネットワークからアクセスできない

管理画面を開けても外部ドメインがタイムアウトする

管理画面が正常であることから分かるのは、管理サービスが実行中ということだけです。次の順序で確認してください。

1. 現在のネットワーク構成として、インターネットからの直接接続と NAT 越えのどちらを選ぶべきか確認します。
2. 外部トラフィックが管理ポートではなく、実際のゲートウェイポートへ到達していることを確認します。デフォルトは通常 7999 です。
3. DNS が現在のグローバル IP またはトンネルの入口を参照していることを確認します。
4. インターネットから直接接続する場合は、ルーターのポートフォワーディングとホストのファイアウォールで許可されていることを確認します。
5. NAT 越えの場合は、トンネルがオンラインで、正しいローカルゲートウェイを参照していることを確認します。
6. リクエストログ に該当リクエストが記録されているかを確認します。

インターネットからの着信を設定できない場合は、NAT 越え：サブドメインルーティングを使用してください。

Windows の 7999 へ LAN やインターネットからアクセスできない

現在の Windows 版では、7999 はデフォルトで IPv4／IPv6 のすべてのインターフェースを待ち受けます。アクセスできない場合、通常はゲートウェイがループバックしか待ち受けていないのではなく、着信経路がまだ確立されていません。インストーラーが作成する FnKnock Gateway の受信プログラムルールは、Windows の「ドメイン」と「プライベート」ネットワークプロファイルだけが対象で、「パブリック」は対象外です。

経路に沿って、Windows で現在使用中のネットワークプロファイルとサードパーティー製セキュリティソフト、ルーターまたは NAT の転送、IPv6 ファイアウォール、ISP が着信を許可しているかを確認します。管理画面の 7991 は引き続きローカルホストだけに厳しく制限され、インターネットからのオリジンには使用できません。Windows は、ログイン状態に応じたファイアウォールの動的管理や直接接続による許可に対応していません。

同じ Windows ホストで独自にトンネルまたはリバースプロキシを実行する場合、オリジンには 127.0.0.1:7999 を指定することを推奨します。ただし、そのプロセスは fn-knock の管理対象ではなく、元の Host と実クライアント IP を必ず保持する必要があります。

飛牛ネイティブ FPK の 7999 から別のポートへ転送される

飛牛システムの HTTPS 接続を強制 によって、リクエストが fn-knock へ到達する前にリダイレクトされることがあります。

飛牛のシステム設定 → セキュリティ → ポート設定 → 設定 を開き、HTTPS 接続を強制 を無効にしてから、7999 を再度テストしてください。

自動 HTTPS の起動に失敗する

自動 HTTPS を使用できるのは、現在のデプロイでこの機能が表示され、ホストに実際の着信経路とポート 80 がある場合だけです。Docker、OpenWrt、Synology DSM 7 SPK では、この設定は提供されません。次を確認してください。

• 80 が別のサービスによって使用されていないか。
• 現在の権限で、特権ポートを待ち受けられるか。
• 飛牛システムのポートリダイレクトや、他の前段入口と競合していないか。
• TLS 証明書が設定済みか。

自動 HTTPS は証明書の申請を代行する機能ではありません。Windows の 7999 はデフォルトですべてのインターフェースを待ち受けますが、この機能を有効にしても、ファイアウォール、ルーター／NAT、ISP の着信制限が自動的に開通することはありません。Docker、OpenWrt、Synology では、前段のプロキシ、エッジプラットフォーム、またはゲートウェイの外側で TLS を終端してください。TLS 証明書と HTTPSも参照してください。

ログインしていなくても元のサービスポートへ直接アクセスできる

fn-knock を迂回する入口が存在します。ルーターのポートフォワーディング、ホストのファイアウォール、IPv6 ファイアウォール、前段のプロキシを確認し、サービスを直接参照する公開ルールを閉じてください。

直接接続による許可では、認証ゲートウェイだけを公開し、ログイン後に現在の送信元 IP を一時的に許可します。Docker と Windows では、fn-knock によるホストのファイアウォール管理は利用できません。

ドメイン、サブドメイン、トンネルが動作しない

どの構成を選べばよいか

条件	構成
インターネットから着信でき、主に Web サービスへアクセスする	グローバル IP からのサブドメインルーティング
インターネットから着信できない	NAT 越え：サブドメインルーティング
SSH やリモートデスクトップなどの元のポートを保護したい	元のポートへ直接アクセスする
従来のパスプレフィックスを残す必要がある	NAT 越えのパスモード。互換性維持にだけ使用します

最初にネットワーク構成から入口を選び、次に Host、パス、TCP／UDP のいずれかでルーティング方法を選び、最後にサービスのアクセスポリシーを設定してください。

トンネルモードに DDNS は必要か

通常は必要ありません。

• FRP はサーバーアドレスと外部ポートを使用します。
• Cloudflared は Cloudflare Tunnel に割り当てたドメインを使用します。

トンネルの入口自体が動的なグローバル IP に依存する場合だけ、その入口へ DDNS を設定してください。

FRP と Cloudflared のどちらを選べばよいか

• すでに FRP サーバーがあり、外部ポートとトラフィックを自分で制御したい場合：FRP を使用します。
• Cloudflare を利用中で、インターネット上のサーバー運用を減らしたい場合：Cloudflared を使用します。

どちらの場合も、認証用ドメインとサービス用ドメインを fn-knock ゲートウェイへ転送し、元の Host を保持する必要があります。NAT 越えとトンネルも参照してください。

Cloudflared のオリジンには HTTP と HTTPS のどちらを指定するか

• fn-knock のローカルゲートウェイに証明書を設定していない場合：http://...:<実際のゲートウェイポート> を使用します。
• ローカルゲートウェイに有効な証明書が設定され、Cloudflared がその証明書を信頼する場合：https://...:<実際のゲートウェイポート> を使用します。

Cloudflared と fn-knock が別々のコンテナにある場合、localhost は誤ったコンテナを指します。相互に通信できるコンテナ名または LAN アドレスを使用してください。Cloudflared トンネルも参照してください。

サブドメインから別のサービスが開く

次を確認してください。

1. 前段のプロキシまたはトンネルが元の Host を保持しているか。
2. ルートドメインとサブドメインマッピングが一致しているか。
3. 重複するマッピングやフォールバックマッピングが先に一致していないか。
4. インターネット側のオリジンが実際のゲートウェイポートを参照しているか。

管理用入口をサービスのオリジンとして使用することはできません。

パスマッピングでリソースが 404 になる、またはログインがループする

アップストリームのアプリケーションが、パスプレフィックス、リダイレクト、Cookie、WebSocket を正しく処理できていません。新しい設定では、独立したサブドメインへ移行してください。アップストリームがプレフィックス配下でのデプロイに明示的に対応する場合だけ、パスモードを使い続けてください。

ワンクリック検出でサービスが見つからない

まず、対象が fn-knock の実行環境からアクセス可能なローカル IPv4 の HTTP サービスであることを確認します。サービス検出は、インターネット、IPv6、ドメイン、HTTP 以外のプロトコルをスキャンしません。Docker の 127.0.0.1 は、コンテナ自身だけを指します。

スキャンする CIDR を対象の実ネットワークへ絞り、CIDR が 16 件以内、ホストの合計が 1024 台以内であることを確認してから、fn-knock の実行環境から対象ポートへ直接アクセスしてください。TCP ポートが開いていても、HTTP として解析できなければ候補は生成されません。範囲とスキャン強度の設定については、サービス検出と一括登録を参照してください。

EdgeOne または ESA でログインループやページ異常が発生する

次を確認してください。

• オリジンが fn-knock の実際のゲートウェイポートを参照しているか。
• サブドメインマッピングで、対応するプラットフォームのサポートが有効になっているか。
• キャッシュが無効で、WebSocket が有効になっているか。
• 実クライアント IP のリクエストヘッダーが正しく渡されているか。
• デュアルスタックのオリジンが、リクエストを異なる入口へ分散していないか。

設定方法は、Tencent Cloud EdgeOneとAlibaba Cloud ESAを参照してください。

自宅の Wi-Fi に戻ってもインターネット側を経由する

クライアントが、引き続きインターネット側の DNS 結果を使用しています。飛牛ネイティブ FPK または OpenWrt でスマート接続を使用する場合は、次を確認してください。

• システム設定 → 機能 → スマート接続 が有効か。
• ローカルホストの LAN IP が正しいか。
• ルーターの DHCP DNS またはクライアントの DNS が、fn-knock を実行するデバイスを参照しているか。
• クライアントの DNS キャッシュを更新したか。

OpenWrt では、dnsmasq がインストールされ実行中であること、メイン設定に /etc/dnsmasq.d/ が含まれていることも確認します。画面からの自動インストールは apt-get を呼び出すため、OpenWrt には適していません。スマート接続は、サブドメインモードで LAN の DNS を最適化する機能であり、インターネット側の DNS は変更しません。Docker ではこの機能を利用できません。スマート接続も参照してください。

ログインまたはセッションの異常

TOTP、パスワード、パスキー、QQ のどれを選べばよいか

• TOTP：デフォルトのログイン方法であり、パスキー、QQ、その他の外部アカウントを連携する基盤でもあります。利用可能な復旧手段を必ず残してください。
• ユーザー名とパスワード：認証アプリを使いにくいメンバーに適しています。
• パスキー：既存の TOTP 認証情報に、便利なログイン方法を追加します。
• QQ：1 つの QQ アカウントを既存の TOTP へ連携してクイックログインを提供します。その TOTP のサービススコープを継承し、独立したユーザーにはなりません。

ユーザー名とパスワードのログインモードへ切り替えると、ログインページにパスキー、QQ、その他の外部アカウントの入口は表示されません。認証とログインおよび QQ クイックログインの連携を参照してください。

ログインページのボット対策はどこで設定するか

システム設定 → チャレンジ を開きます。PoW と Turnstile の違いはチャレンジ、Cloudflare の設定は Turnstileを参照してください。

「ログイン状態を保持」はセッションへどう影響するか

セッションの有効期間は システム設定 → セッション で設定します。「ログイン状態を保持」を有効にすると、長期セッションの有効期間が使用されます。IP 許可をセッションに連動させている場合は、対応する許可も延長されます。

長期セッションは、個人用の信頼できる端末でだけ使用してください。

TOTP を削除すると他のログイン方法も使えなくなる

特定の TOTP を削除すると、紐付いたパスキー、QQ、その他の外部アカウントの連携も同時に無効になります。削除前に別の利用可能な認証情報があることを確認してください。削除後は、関連するログイン方法を再度連携する必要があります。

ログインに成功してもログインページへ戻る

次の順序で確認してください。

1. 認証用ドメインとサービス用ドメインが、同じ公開プロトコルを使用しているか。
2. ルートドメイン、Cookie のスコープ、パスキーの RP ID が一致しているか。
3. ブラウザーが Cookie をブロックしていないか。
4. エッジプラットフォームがログインレスポンスをキャッシュしていないか。
5. 前段のプロキシが正しい Host、X-Forwarded-Host、X-Forwarded-Proto を渡しているか。
6. システム時刻が正確か。

同じ認証ページまたは同じ転送先へのループが続くと、システムは自動リダイレクトを一時停止します。その場合は、元のサービス用 Host からアクセスし直し、認証コールバックのアドレスを繰り返し更新したりコピーしたりしないでください。

飛牛アプリへアドレスを直接入力するとログインできない

飛牛アプリが Web 認証のリダイレクトを処理して Cookie を再利用できるかは、クライアントのバージョンによって異なります。ブラウザーのセッションがネイティブアプリへ自動的に共有されるとは限りません。

• サブドメインまたは NAT 越え：先にモバイルブラウザーで同じ外部ドメインを開き、ログインします。
• 直接接続による許可：先にブラウザーで実際のゲートウェイポートを開き、その後アプリへ戻って元のアドレスへ接続します。

手順全体は、飛牛アプリを使用するを参照してください。

ネットワークを切り替えると突然アクセスできなくなる

モバイル回線、プロキシ、自宅のインターネット接続では、送信元 IP が変わることがあります。認証用入口を開き直してログインし、システム設定 → セッション で IP 変更履歴 を確認してください。

この履歴には、セッションが元の IP から新しい IP へ移行した処理が記録されます。通常のリクエストログではありません。

セッションの横にある飛牛アイコンは何を示すか

そのログインセッションに飛牛トークンが紐付いていることを示します。飛牛アプリや Web ページが現在のログインを引き続き利用している場合によく表示されます。強制終了、ログアウト、セッションの有効期限切れが発生すると、紐付いたトークンも無効になります。セッション管理も参照してください。

ルーティング、セキュリティ、ログの異常

ログインに成功してもホワイトリストにないと表示される

まず、この Host が従来の strict_whitelist ルールを継承していないか確認してください。

• ログインを必須にする を無効：現在のログイン優先マッピングでは公開アクセスとなり、ログインもホワイトリストも確認しません。従来の厳格なホワイトリストマッピングには当てはまりません。
• ログインを必須にする を有効：手動の送信元許可だけでもアクセスできます。通常、自動 IP 許可でも同じ送信元から継続してアクセスできますが、リクエストに含まれるサービススコープの拒否を上書きすることはありません。利用できる送信元許可がない場合に、セッションを確認します。
• 従来の厳格なホワイトリストルール：ログインを必須にする を無効にしても公開されるとは限りません。有効な送信元許可の記録（手動、またはログイン後に自動作成）だけで判定され、ブラウザーセッションの Cookie だけでは送信元の条件を置き換えられません。

現在の Host 編集画面には、厳格なホワイトリストを選択する項目がありません。従来のルールが残っている場合は、現在の送信元 IP に対応する手動または自動の許可記録を確認してください。手動の送信元だけを許可する場合は、ログイン後の IP 自動許可を無効にし、残っている自動記録も確認します。このルールを解除するには、最初にマッピング設定をすべて記録し、現在の画面でマッピングを作り直してください。ログインを必須にする を無効にするだけでは公開されません。

飛牛の共有リンクがブロックされる

飛牛の共有リンクパススルーは、サブドメインルーティングと NAT 越えで使用でき、直接接続モードには対応していません。/s/... に対して実際に選択されたルートが飛牛を参照していることを確認してください。別のパスルールや誤ったデフォルトルートがリクエストを引き受けると、パススルーは機能しません。fnOS 共有リンクのパススルーも参照してください。

リクエストログはどこで有効にするか

システム設定 → ログ で有効にします。有効にするとサイドバーに リクエストログ が表示され、日付ごとに一致した Host、アップストリーム、レスポンスの状態を確認できます。リクエストログも参照してください。

CPU またはメモリ使用率が高くても、イベントセンターにアラートがない

現在のデフォルトでは、使用率が 80% 以上の状態で約 30 秒間継続したときにアラートが生成されます。一時的なスパイクからすぐにイベントが生成されることはなく、復旧にも 60% 以下の状態が継続する必要があります。Windows ではシステムリソース監視を利用できません。Docker の値は、コンテナの実行環境から見えるリソース範囲に基づきます。

まず、現在のプラットフォームが対応していること、イベントシステムとリソースイベントが正常であることを確認します。そのうえで、「リソースイベントが生成される条件」と「通知ルールが発火する条件」を区別してください。後者は生成済みのイベントをいつ送信するかだけを決め、サンプリングのしきい値は変更しません。イベントセンターと通知も参照してください。

共通ブラックリストとスキャナーのブラックリストの違い

• スキャナーのブラックリスト：未認証の異常なパス探索に基づいて、自動的にブロックします。
• 共通ブラックリスト：管理者がログまたはブラックリストの画面から、IP を明示的にブロックします。

共通ブラックリストに追加できるのは、正確な IPv4 または IPv6 アドレスだけで、CIDR には対応していません。ネットワーク範囲や地域を制限する場合はゲートウェイの公開範囲、個別の異常な IP をブロックする場合はグローバルブロックリストを使用してください。

HTTPS を早い段階で設定すべき理由

HTTPS はログイン認証情報とセッション Cookie を保護し、パスキーを正常に使用するためにも必要です。公開ドメイン、FRP、Cloudflared の外部入口には、いずれも信頼された証明書を使用してください。TLS 証明書と HTTPSも参照してください。

インストール、アップグレード、データの異常

OpenWrt でインストールとアップグレードを行う方法

OpenWrt は、対応するアーキテクチャの .ipk パッケージと .apk パッケージに対応しています。インストール後の入口は サービス → 敲门 Knock です。

アップグレードするときは、新しいバージョンのパッケージをインストールします。アプリ内の FPK アップデートは OpenWrt には適用されません。通常のアップグレードでは、/etc/config/fn-knock と /var/lib/fn-knock が保持されます。コマンド全体は OpenWrt へのデプロイを参照してください。

Docker のアップグレード後にデータが空になった

これ以上データを書き込まないようにし、古いデータボリュームが残っていることを確認してください。現在のバージョンは SQLite を使用します。Redis から SQLite への従来の移行を行うのは、初期の Redis 版からアップグレードするときだけです。

古いボリュームを削除したり、空のボリュームで元のマウントを上書きしたり、新規インストールへ Redis を追加したりしないでください。Docker へのデプロイにあるバックアップと移行の手順に従って復元します。

.knock バックアップをインポートできない、またはインポート後に警告が表示される

ファイルが元の .knock 拡張子のままで、サイズが 128 MiB 以下、エクスポート元のバージョンが現在のインスタンス以下であることを確認してください。対象のバージョンは、エラーメッセージに表示される対応範囲内に収まっている必要もあります。アーカイブ内の JSON を編集して、バージョンを偽装しないでください。

インポート成功後の警告は、設定項目は復元されたものの、ゲートウェイ、WAF、TLS などの実行状態を同期する一部の処理が失敗したことを示します。インポート全体が自動的にロールバックされたという意味ではありません。管理用入口を維持し、警告を 1 つずつ確認して対応する設定を手動で保存し直してください。同じファイルをすぐに繰り返しインポートしないでください。バックアップ・復元・データ消去も参照してください。

Windows を更新する方法、またはデータを完全に削除する方法

fn-knock Windows 管理アプリ またはシステムトレイの「更新を確認」から Windows 版を更新します。Web 画面の バージョン情報 / 更新 では、バージョンと説明だけが表示されます。アップグレード前にバックアップをエクスポートしてください。インストーラーは、新しいバージョンの起動に失敗すると、以前のプログラムとデータを復元します。

Windows アプリをアンインストールしても、復元できるよう %ProgramData%\FnKnock は保持されます。ここには SQLite、証明書、設定が含まれます。復元が不要であることを確認してから、管理者権限でこのディレクトリを別途削除してください。

アップデート後、機能の入口が古いドキュメントと一致しない

まず、現在のデプロイで利用できる機能を確認してください。

機能	飛牛 fnOS FPK	Docker	OpenWrt	Linux サービス	Synology DSM 7 SPK	Windows x86_64
ホストのファイアウォールと直接接続による許可	対応	非対応	対応	非対応	非対応	非対応
自動 HTTPS	対応	非対応	非対応	対応。ポート 80 と着信経路が必要	非対応	対応。ファイアウォール、NAT、着信経路の設定は別途必要
ACME DNS-01	対応	対応	対応	対応	対応	対応。内蔵クライアントを使用し、Let's Encrypt に固定
スマート接続	対応	非対応	対応。既存の dnsmasq と設定の include が必要	非対応	非対応	非対応
SSH セキュリティ	対応	非対応	非対応	非対応	非対応	非対応
Web ターミナル	対応	非対応	非対応	対応。tmux が必要	非対応	非対応
内蔵 FRP／Cloudflared	対応	対応	対応	対応	対応	非対応
アップデートのインストール	Web 画面から更新	新しいイメージを取得	IPK／APK をインストール	sudo knock update	DSM パッケージセンター／SPK	Windows 管理アプリで実行

デプロイごとの制約と推奨する入口については、デプロイ方法とアクセス構成を選ぶを参照してください。