FlClash 初回インストール後の初期設定ガイド｜Windows・macOS・Android共通の確認事項と注意点 | FlClash 公式サイト

1. 初回起動前：インストーラー、権限、既存のプロキシを確認

FlClashは設定、プロキシノード、接続状態を管理するクライアントで、実際の通信転送は内蔵のmihomoコアが行います。インストールが完了しても、アプリが起動できることを示すだけで、サブスクリプションの読み込みやシステム通信のコアへの転送が完了したとは限りません。初回設定ではこの3点を個別に確認し、ポート、DNS、ルーティングを一度に変更して原因が分からなくなるのを防ぎましょう。

作業を始める前に、ほかのプロキシクライアントやVPNを終了します。ウィンドウを閉じただけではタスクトレイに残っている場合があるため、トレイのメニューから終了し、システムプロキシが以前のアプリを参照したままになっていないかも確認してください。本文ではmixed-portの例として7890を使用しますが、すべてのFlClashバージョンの既定値を示すものではありません。実際のポート番号、設定名、権限の手順は、インストールしたバージョンの表示に従ってください。

OSごとのインストール確認

Windows：「設定」→「システム」→「バージョン情報」でシステムの種類を確認します。デバイスのアーキテクチャに合ったx64またはARM64のインストーラーを選んでください。まずは通常権限で起動し、TUNの有効化、サービスのインストール、仮想NICの作成が必要な場合に限り、クライアントの案内に従って権限を付与します。
macOS：Appleメニュー→「このMacについて」で、AppleシリコンかIntelプロセッサかを確認します。アプリを「アプリケーション」フォルダに移してから起動してください。起動がブロックされた場合は、まず配布元を確認し、「システム設定」→「プライバシーとセキュリティ」で表示内容を確認します。システム全体のセキュリティ機能を無効にすることをインストール手順にしないでください。
Android：APKをインストールする際は、実際に使用するブラウザまたはファイル管理アプリだけに「不明なアプリのインストール」権限を許可し、インストール後は必要に応じて取り消します。設定項目の場所はメーカーによって異なるため、設定画面で名称を検索してください。初回のVPN接続時には別途システムの許可ダイアログが表示されます。これはインストール権限とは別の設定です。

現在使えている設定があれば、あらかじめバックアップを残しておきます。サブスクリプションURLに認証トークンが含まれている場合があります。URL全体やQRコード、トークンが写ったログのスクリーンショットを公開の掲示板などに投稿しないでください。

2. サブスクリプションを追加してから、設定とノードを確認

初回起動後、まずクライアントの設定管理画面を開き、サブスクリプションURLを追加するか、ローカルの設定ファイルを読み込みます。URLを貼り付ける際は、先頭や末尾の空白、改行が入っていないか確認し、既存のクエリパラメーターはそのまま残してください。プロバイダーのログインページURLをサブスクリプションURLとして使うことはできません。サブスクリプションはユーザー自身で用意する必要があり、クライアントのインストーラーにプロキシサービスが含まれているわけではありません。

設定管理画面でリモートサブスクリプションを追加し、見分けやすい名前を付けてURL全体を貼り付け、保存します。
一度更新を実行し、ダウンロードと解析が完了するまで待ちます。エラーが出た場合は、まずその原因を解消してください。TUN、DNS、全般モードを次々に切り替えるのは避けましょう。
読み込んだ設定を現在の使用項目に指定します。リストにサブスクリプションが表示されていても、読み込み済みとは限りません。
プロキシまたはプロキシグループの画面を開き、ノードとグループが表示されることを確認します。手動選択型のグループでは実際に使うノードを選び、自動選択型のグループでは利用可能なメンバーが含まれているか確認してください。

「追加できた」と「接続できた」は別

追加が成功したということは、取得した内容を解析できたというだけです。ノードの期限切れ、認証エラー、サーバーへの接続不可などは、実際に接続したときに初めて分かる場合があります。反対に、サブスクリプションの更新に失敗しても、ノードが使えないとは限りません。更新先への接続とプロキシノードへの接続は、別の通信経路だからです。

取得した内容がウェブページ、ログイン案内、アクセス制限ページの場合、HTTPステータスが200でも有効な設定ではありません。更新エラーに表示された形式や解析情報を確認し、クライアントが対応しているかプロバイダーに問い合わせてください。個人用のサブスクリプションを、見知らぬオンライン変換サイトに渡さないでください。

初回のサブスクリプション取得時には、まだ利用可能なプロキシがありません。プロキシ経由でしかアクセスできない更新先を使うと、利用開始に必要な設定を取得できない状態になることがあります。プロバイダーが案内するアクセス可能な更新先を使うか、すでに確立している信頼できる接続から設定を取得してください。ノードが使えない状態でプロキシを何度も有効にしても、この依存関係は解消しません。

3. システムプロキシとTUN：初回テストでは経路を一つに絞る

システムプロキシを使うと、OSのプロキシ設定に従うアプリのリクエストがローカルポートに送られます。TUNは仮想NICとルーティングを使って通信を取り込み、システムプロキシに従わないアプリにも対応できます。特定の設定では両方を併用できますが、初回の切り分けではどちらか一方だけを有効にし、ルーティング、DNS、プロキシ設定が影響し合う要因を減らしましょう。

利用シーン	初回に選ぶ方法	確認する項目
Windows・macOSでブラウザをテスト	システムプロキシ	コアが起動し、プロキシのアドレスと待ち受けポートが一致している
システムプロキシに従わないデスクトップアプリ	TUN	仮想NICの権限、ルーティング、DNSの取り込み状態
Androidで通常利用	クライアントのVPNによる通信の取り込み	システムVPNの許可、アプリごとの振り分け、バックグラウンド制限
コマンドラインからプロキシポートだけをテスト	プロキシを明示指定	コマンドで指定したポートとクライアントの実際のポートが一致している

Windows・macOS：まずブラウザで基準となる動作を確認

まずコアを起動し、TUNは無効のままシステムプロキシを有効にします。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認できます。macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で設定を確認します。メニュー名はOSのバージョンによって異なりますが、確認するのはプロキシのホストとポートです。

ブラウザ拡張機能、ブラウザ独自のプロキシ設定、企業ポリシーがシステム設定より優先されることがあります。初回テストではプロキシ拡張機能を一時的に無効にし、通常のブラウザウィンドウから、直接接続できると分かっているページとプロキシ経由になる想定のページにアクセスしてください。特定のブラウザだけで失敗する場合は、すぐにクライアントを再インストールせず、そのブラウザ独自の設定を確認しましょう。

Android：VPNアイコンが表示されても、すべてのアプリの通信が取り込まれるとは限らない

接続開始時にシステムのVPN接続リクエストを許可し、ほかのVPNが動作していないか確認します。通常、Androidの同一ユーザーで同時に有効にできるVPNサービスは一つです。ほかのVPNや、一部のローカルVPN方式のフィルタリングアプリがFlClashと競合することがあります。アプリごとの振り分けを有効にしている場合は、テストに使うブラウザが対象に含まれているかも確認してください。

AndroidのシステムVPNによる通信の取り込みは、デスクトップOSのシステムプロキシとは仕組みが異なります。PCの127.0.0.1:7890をスマートフォンのWi-Fiプロキシに設定してPCを参照させることはできません。スマートフォン上の127.0.0.1は、そのスマートフォン自身を指します。

4. mixed-portの確認：7890、使用中のプロセス、待ち受けアドレス

mixed-portは、同じポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。アプリ側のポートは、コアが実際に待ち受けている値と一致させる必要があります。以下は各項目の意味を示す例であり、サブスクリプションを置き換えられる完全な設定ではありません。また、これらの値を手動で変更する必要があるという意味でもありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890：プロキシを手動設定するアプリでは、同じポートを指定します。7891に変更する場合は、ブラウザ、ターミナルなど、ポートを手入力したツールもすべて更新してください。
allow-lan: false：初回はこの端末だけで使うため、LANからのアクセスを無効のままにします。LAN接続を許可するには、待ち受けアドレス、ファイアウォール、認証の設定も必要です。端末内の接続問題を解決するためだけに、安易に公開しないでください。
mode: rule：ルールに従って通信の出先を選択します。これは通信の振り分け方を制御する設定であり、システムプロキシを有効にしたり、TUN用の仮想NICを作成したりするものではありません。
log-level: info：通常の起動や接続の確認に使います。一時的にdebugへ変更した場合は、調査後に元へ戻してログが増え続けないようにしてください。

Windows：ポートを使用しているプロセスを特定する

起動ログにaddress already in useと表示された場合は、PowerShellで次のコマンドを実行します。1つ目で待ち受けポートとプロセスIDを一覧表示し、2つ目でIDからプロセス名を確認できます。何も表示されなくても、その確認時点で該当するTCP待ち受けが見つからなかったことを示すだけで、コアが正常に起動したとは限りません。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

macOS：ローカルの待ち受け状態を確認する

lsof -nP -iTCP:7890 -sTCP:LISTEN

どのアプリのプロセスか確認してから、古いクライアントを終了するかポートを変更するか判断してください。正体が分からないプロセスを、いきなり強制終了しないでください。ポート競合は別のプロキシアプリだけでなく、コアを二重に起動した場合にも起こります。クライアントの設定からポートを変更した場合は、コアを再起動して実際の待ち受けポートを確認します。サブスクリプションの更新で直接編集したファイルが上書きされることがあるため、変更を維持するにはクライアントが対応する設定方法やオーバーライド機能を使ってください。

5. ルールモード、DNS、接続テストの進め方

初期設定ではルールモードをおすすめします。ルールは通常、上から順に評価され、最初に一致したルールが接続先のポリシーを決めます。次にポリシーグループが使用するノードを選択します。全般モードでも選択したポリシーとノードの利用可否に左右されるため、ノードのパスワード、ポート、通信方式の誤りは解決できません。直結モードでは、プロキシノードが正常かどうかを判断できません。

4つの層に分けて確認し、遅延の数値だけで判断しない

コア層：起動後に設定の解析エラー、待ち受けエラー、権限エラーがないことを確認します。ウィンドウが表示されていても、コアが正常に動作しているとは限りません。
ノード層：現在のポリシーグループに含まれるノードの遅延をテストします。結果はテスト先と実行時点の状況を示すだけで、実際のダウンロード速度ではありません。また、すべての接続先での動作を保証するものでもありません。
アプリ層：ブラウザからリクエストを送信し、クライアントの接続一覧またはログで、接続先ドメイン、適用ルール、出力先のポリシーを確認します。リクエストが記録されない場合は、まず通信の取り込み経路を確認してください。
接続先層：リクエストがコアに届いているのにアクセスできない場合は、DNSの結果、ノードの接続エラー、接続先サービスの応答を確認します。ページに表示される403、429、接続タイムアウトは、それぞれ異なる問題です。

Windowsでは、HTTPプロキシを明示指定して比較テストすることもできます。次のコマンドはmixed-portが実際に7890の場合に使用できます。macOSではcurl.exeをcurlに置き換えてください。例示したドメインがルールによって直結に振り分けられている場合、成功してもローカルのプロキシ入口を通ったことが分かるだけで、プロキシノードが使えることの証明にはなりません。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

DNSは、まずサブスクリプションとクライアントに設定されている方式を維持してください。mihomoのFake-IPモードでは、たとえば198.18.0.0/16の範囲にあるアドレスがアプリに返される場合がありますが、これだけでDNSが改ざんされているとは限りません。TUNを有効にして名前解決に失敗する場合は、DNSの取り込み、上流DNSサーバーへの接続、ほかの暗号化DNS設定を確認します。複数のパブリックDNSを同時に切り替えるのは避けてください。

ブラウザ内蔵のセキュアDNSによって名前解決の経路が変わることはありますが、必ず問題が起きるわけではありません。比較テストで現在の通信の取り込み方式と競合すると確認できた場合に限り、一時的に無効にして再テストします。設定は一度に一つだけ変更し、変更前の値も記録してください。

6. 3つのOSで初回起動時によくある問題

Windows：システムプロキシを有効にしても、コマンドラインは直結する

コマンドラインツールの中にはWindowsのシステムプロキシを参照せず、独自のプロキシ引数や環境変数を使うものがあります。まず前のセクションにあるプロキシ明示指定コマンドで確認し、その後、使用するツールのドキュメントを調べてください。ターミナルの通信が取り込まれないからといって、システムプロキシの設定が機能していないとは限りません。TUNを使う場合は、まずブラウザで正常に動作することを確認してから、必要な権限を付与し、ルーティングをテストしてください。

macOS：ネットワークを切り替えるとプロキシが使えない、終了後もネットに接続できない

macOSのプロキシ設定はネットワークサービスごとに管理されます。Wi-FiからEthernetに切り替えた場合は、現在使っているサービスのプロキシ設定を確認してください。クライアントを終了する前にシステムプロキシを無効にし、直接接続が復旧したことを確認します。アプリが異常終了してコアが停止しても、システム側にローカルポートを参照するプロキシ設定が残っていると、ブラウザにプロキシサーバーへ接続できないというエラーが表示されます。その場合は残った設定を解除してください。サブスクリプションを何度も追加し直す必要はありません。

Android：画面ロック後に切断する、または一部のアプリだけ接続できない

画面点灯中は使えても、しばらくロックすると切断される場合は、まずバッテリー最適化とバックグラウンド実行の制限を確認してください。「設定」→「アプリ」→FlClashのバッテリー関連画面で、必要に応じてバックグラウンドでの実行を許可します。メーカー独自のOSでは、自動起動を別途許可する必要がある場合もあります。省電力の制限とノードのタイムアウトを混同せず、切断までの時間とクライアントのログを照らし合わせてください。

LAN内のデバイス、画面ミラーリング、仕事用プロファイルのアプリだけに問題が起きる場合は、アプリごとの振り分け、LAN通信のバイパス、仕事用プロファイルの分離設定を確認します。LAN内の接続先には正しいローカルルートが必要です。すべての通信をリモートノードに送ると、プリンター、NAS、社内ネットワークにアクセスできなくなる場合があります。まず接続先のアドレスと適用ルールを記録してから、必要な直結ルールを追加してください。

7. 初期設定完了後のチェックリスト

初期設定は、すべてのスイッチを有効にすることではなく、同じ手順で動作を再確認できることを完了条件にしましょう。問題の原因を説明できる最小限の設定を保ち、スタートアップ時の自動起動、アプリごとの振り分け、カスタムルールなどは後から一つずつ追加してください。

サブスクリプションを更新し、現在使う設定を選択済み。プロキシグループ内に利用可能なノードがある。
コアが正常に動作し、実際の待ち受けポートを記録済み。ポート競合のエラーがない。
デスクトップではまずシステムプロキシをテストする。TUNが必要な場合は、権限、ルーティング、DNSを個別に確認する。
AndroidでVPN権限を許可済み。テスト対象のアプリが通信の取り込み対象に含まれ、必要なバックグラウンド実行が許可されている。
直結先とプロキシ経由の接続先をそれぞれテストし、接続履歴から適用されたポリシーを説明できる。
接続を終了すると通常のネットワーク接続に戻る。クライアントを再起動しても設定とノード選択が想定どおりに保たれる。
サブスクリプションの自動更新とOS起動時の自動起動は、基本の接続が安定してから有効にする。複数の自動化設定を一度に追加しない。

mixed-port、mode、ルールの構文を項目ごとに確認する場合は、設定項目リファレンスを参照してください。インストールから操作までの手順は入門ガイドをご覧ください。後から問題が起きた場合は、発生時刻、OSのバージョン、クライアントに表示されるバージョン情報、エラーの原文、直近に変更した設定を記録してください。何度も再インストールするより、原因の特定に役立ちます。