FlClash 入門ガイド
サブスクリプション・モード・接続確認
4ステップで基本の設定を完了します。まずアプリ1つの通信がプロキシに正しく入ることを確認し、その後でTUN、DNS、カスタムルールを設定します。サブスクリプションが有効でネットワークに接続できる状態なら、約10分で初期設定できます。
プラットフォームごとの操作について:この記事では、FlClashの「設定 → プロキシ → 接続」という機能の流れに沿って説明します。バージョンによって項目名や配置が異なる場合があります。デスクトップ版ではサイドバーまたは設定画面、Android版では画面のナビゲーションや設定メニューを確認してください。他のClashクライアントでも、ボタンの位置ではなく同じ機能を探して操作できます。
Windows、macOS、Linuxで初回テストを行う場合は、まずシステムプロキシを使います。Androidでは通常、接続時にシステムのVPN許可が必要です。iOSでは、まずインストールファイルのページで対応するクライアントを選び、そのアプリの設定読み込み手順に従ってください。デスクトップ版のシステムプロキシ手順は適用できません。
開始前に、有効なサブスクリプションURLか、信頼できる入手元のYAML設定ファイルを用意してください。サブスクリプションにはノード、ポリシーグループ、ルールなどが含まれます。クライアントをインストールしただけでは、利用可能なプロキシ接続は作成されません。まだインストールしていない場合は、インストールファイルのページでOSに合ったソフトを選んでください。設定をすでに用意している場合も、最初のステップで有効化を確認しましょう。
ステップ1:サブスクリプションを追加
FlClashの「設定」画面を開き、設定の追加メニューを探します。リモートのサブスクリプションを使う場合は、URLから読み込む項目を選び、サービス提供元が案内するサブスクリプションURLを入力欄に貼り付けます。名前には「普段使い」など、用途が分かるものを指定できます。名前は端末内での管理用で、ノード接続には影響しません。保存する前に、URLの前後に空白や改行、チャットアプリが追加した句読点が含まれていないか確認してください。
サブスクリプションURLには個人用の認証情報が含まれることが多いため、パスワードと同じように管理してください。URL全体を公開フォーラムに貼ったり、アドレスのパラメーターが見える状態でスクリーンショットを共有したりしないでください。ブラウザーで開けるアカウントページが、サブスクリプションURLとは限りません。Clashまたはmihomo対応としてサービス提供元が明示しているURLを使います。複数の形式が案内されている場合は、クライアントのカーネルが読み込める形式を選んでください。
取得・解析・有効化の状態を確認
保存または読み込みを実行したら、クライアントが取得を終えるまで待ちます。成功すると、設定一覧に先ほど付けた名前の項目が表示されます。画面によっては更新日時やサブスクリプション情報も表示されますが、これらはサーバーから返される内容によって異なります。項目が表示されても、有効化されているとは限りません。項目をタップするか有効化操作を行い、現在の設定にしてください。その後「プロキシ」画面を開き、ポリシーグループとノードが表示されることを確認します。
このステップの完了条件は、現在の設定が選択され、プロキシ画面に対応する内容が読み込まれていることです。設定名だけが表示され、想定したポリシーグループが見当たらない場合は、TUNを有効にする前に設定一覧へ戻り、読み込み結果を確認してください。ノードだけを含み、クライアントの設定テンプレートでルールを補うサブスクリプションもあれば、設定一式を含むものもあります。画面の表示は異なる場合があるため、サービス提供元の案内と実際の読み込み結果を基準にしてください。
ローカルファイルの読み込みとエラーへの対処
ローカル設定を使う場合は、ファイル読み込みを選び、システムのファイル選択画面から実際のYAMLファイルを開きます。ウェブページをファイルとして保存したものはプロキシ設定ではないため、読み込まないでください。読み込み後は設定を有効化し、同じようにプロキシ画面を確認します。外部ルールセットやプロキシグループを含む設定では、初回読み込み時に追加のダウンロードが必要なことがあります。その取得先にもアクセスできる必要があります。
リクエストがタイムアウトする場合は、まず現在のネットワークからサブスクリプションサービスにアクセスできるか確認してください。解析エラーが表示された場合は、返された内容がログインページ、期限切れの案内、エラーページに変わっていないか確認します。追加操作を繰り返して項目を重複させたり、個人用サブスクリプションを不明な変換サイトに渡したりしないでください。形式を確認する手順は、サブスクリプションを読み込めない・解析エラーのセルフチェックを参照してください。
読み込みが終わったら、今回のテストにはこの設定だけを使います。ほかのサブスクリプションを追加したり、追加の上書き設定を読み込んだりしないでください。モード選択時にポリシーグループの出所が明確になり、問題が起きても元に戻しやすくなります。
ステップ2:プロキシモードを選択
ホーム画面または設定画面に戻り、「モード」または「接続モード」を探します。初回は「ルール」を選択します。設定ファイルの項目では mode: rule に相当します。ルールモードでは、設定内のルールに従って通信を直接接続、ポリシーグループ経由、または別の経路に振り分けます。アプリの使用頻度で自動判定する機能ではなく、すべてのウェブサイトがプロキシ経由になるわけでもありません。
モードとノードは別々の設定です。まずルールモードを選び、「プロキシ」画面でルールが使うメインのポリシーグループを探します。グループ名は設定によって異なり、用途を示す日本語の場合も、任意の名前の場合もあります。「メインノード」という固定名の項目を探す必要はありません。ポリシーグループを開き、利用可能なノードを選んで、そのグループの接続先に設定してください。
まず接続先を1つ固定し、自動選択は後から使う
初回の動作確認では、手動選択グループから明確なノードを1つ選ぶのがおすすめです。メインのポリシーグループが別のグループを参照している場合は、さらに開き、最終的に利用可能なノードが選ばれていることを確認してください。DIRECTのまま、または接続拒否の経路になっていないことも確認します。自動選択グループは検出ルールに従ってメンバーを選ぶため、設定が安定してから使うのに適しています。初回のトラブルシューティングではノードを固定すると、設定変更の影響を判断しやすくなります。
クライアントに遅延テスト機能がある場合は、補助的な確認として一度実行できます。結果が示すのは、選択したノードから指定されたテスト先までの状態です。すべての接続先にアクセスできることや、ブラウザーの通信がプロキシに入っていることを保証するものではありません。失敗の原因にはテスト先、ノードの状態、ネットワークなどが考えられます。テストに成功しても、その後の接続と実際のアクセス確認が必要です。
ルール・グローバル・ダイレクトの使い分け
「グローバル」モードでは通常、カーネルに入ったリクエストをグローバルポリシーグループに送ります。ルールの振り分けが原因かどうかを短時間で確認する際に使えます。切り替え後も、グローバルグループの接続先を確認してください。そこがダイレクトに設定されている場合もあります。「ダイレクト」モードでは通常、カーネルに入ったリクエストを宛先へ直接接続します。明示的に直接接続したい場合に使います。ダイレクトに切り替えてもクライアントが終了するわけではなく、OSのプロキシ設定が自動的に解除されるわけでもありません。
普段はルールモードのまま使い、ルールセット、DNS、ノードのプロトコル設定を同時に変更しないでください。画面がルールモードになっていても、アプリの通信が必ずクライアントに入るとは限りません。次のステップで接続を開始し、通信を取り込む方法を選びます。proxy-groups、rules、ルールの評価順序については、設定項目リファレンスを参照してください。
このステップの完了条件は、ルールモードが選択され、ルールが使うポリシーグループに接続先が明確に設定されていることです。ルールモードでは一部の通信が直接接続されるため、「すべてのサイトで出口が変わったか」は判断基準にしないでください。
ステップ3:接続する
ホーム画面に戻り、接続スイッチを操作してクライアントのカーネルを起動し、現在の設定を読み込みます。バージョンによって、接続操作とシステムプロキシの設定が連動する場合と、個別のスイッチになっている場合があります。「カーネルが起動していること」と「アプリの通信が取り込まれていること」をそれぞれ確認してください。ホーム画面のスイッチがオンになっているだけでは、ブラウザーがプロキシを使っているとは判断できません。
デスクトップ版:まずシステムプロキシを有効にする
Windows、macOS、Linuxでは、まず「システムプロキシ」の設定を探して有効にし、TUNはオフのままにします。システムプロキシを使うと、OSのプロキシ設定に従うアプリがローカルの待ち受けポートへリクエストを送ります。最初のテストには通常ブラウザーが適しています。ただし、独自のプロキシ設定を持つアプリやシステム設定を無視するアプリもあるため、基本の接続確認が済んでから個別に設定してください。
接続する前に、システムプロキシやVPNを制御しているほかのソフトを終了し、複数のクライアントがOS設定を上書きし合わないようにしてください。ブラウザーにプロキシ切り替え拡張機能がある場合は、別の接続先を強制していないか確認します。初回の確認ではプロキシの入口を1つだけにしてください。複数の拡張機能、手動プロキシ、TUNを同時に有効にして、どの設定が影響したか分からなくならないようにしましょう。
ポート競合が表示された場合は、設定画面に表示される混合ポートを確認します。一般的な設定例は mixed-port: 7890 ですが、サブスクリプション、クライアント、既存の設定によって異なるため、現在の値を基準にしてください。まず同じポートを使用している別のクライアントを終了します。ポートを変更する場合は、アプリに手動入力したプロキシアドレスも合わせて変更してください。接続先ノードを切り替えても、ローカルの待ち受けポートの競合は解消しません。
Android:システムのVPN接続を許可する
Androidで初めて接続すると、通常はシステムのVPN接続リクエストが表示されます。接続を開始したアプリが、インストールして使用しようとしているクライアントであることを確認してから許可してください。許可後にクライアントへ戻り、動作中になっているか確認します。すでに別のVPNが動作している場合は、通常、先に切断してから今回の接続を開始する必要があります。2つのシステムVPNを同時に動かすことは、基本設定として想定されていません。
アプリ内でアプリ別プロキシを設定している場合は、テストに使うブラウザーが対象に含まれているか確認します。対象外なら、クライアントが正常に動作していてもブラウザーは直接接続する可能性があります。接続後にシステムのVPNアイコンが表示されても、それが示すのはシステムトンネルが確立したことだけです。リモートノード、ルール、DNSがすべて正常とは限らないため、ステップ4で確認してください。
TUNを有効にするタイミング
システムプロキシでブラウザーが正常にアクセスできる一方、プロキシ設定に従わないアプリがある場合にTUNを検討します。デスクトップ版のTUNは仮想ネットワークインターフェースでより多くの通信を取り込みます。管理者権限やクライアントのサービスが必要な場合があり、ルーティングやDNSの動作も設定の影響を受けます。初回からTUNを接続問題すべての解決スイッチとして使わず、ノードが使えないときに何度も切り替えることもしないでください。
起動に失敗したらログを開き、接続を開始した直後に出た最初の明確なエラーを確認します。設定の読み込み失敗、待ち受けアドレスの競合、権限不足は、それぞれ原因と対処が異なります。エラーが長い場合は必要な項目だけを残し、個人情報を隠してから、mihomoのログエラーから原因を特定する方法を参考にしてください。
現在の設定、ルールモード、選択したノード、明確な通信の取り込み方法がそろっているはずです。設定はそのままにして、次は新しいアクセスを行い、通信が実際にどの経路を通ったか確認します。
ステップ4:動作を確認する
ブラウザーで新しいタブを開き、現在のネットワークからアクセスできる確認対象を開きます。読み込み済みの古いタブだけを見ても確認になりません。古いページがキャッシュを表示していたり、既存の長時間接続が以前の経路を使い続けたりすることがあります。必要であれば古いタブを閉じて開き直し、今回の設定後に発生した新しいリクエストを確認できるようにしてください。
ウェブアクセスと接続ログを照合する
対象のページにアクセスしながら、クライアントの「接続」画面を開きます。ドメイン名または直近の記録から該当するリクエストを探し、宛先、適用ルール、実際の接続先を確認してください。設定のルールで直接接続に振り分けられた場合、ダイレクトと表示されるのは正常です。プロキシノードを確認する際は、すべてのリクエストで同じ出口を求めるのではなく、現在のルールでプロキシグループに送られる宛先を選んでください。
出口確認サイトは補助として使えますが、まず確認リクエスト自体がどの接続先を通ったか確かめてください。確認用ドメインがルールで直接接続に設定されている場合、ローカルネットワークの出口が表示されてもクライアント全体の不具合とは限りません。より確実なのは、新しいリクエストが接続ログに記録され、想定したルールとノードが使われ、対象ページの読み込みが完了することです。ノードの遅延テストやホーム画面の稼働表示だけでは、これらの確認に代わりません。
失敗したら通信の取り込み、ルール、ノードの順に確認
アクセスに失敗し、接続一覧に該当する新しいリクエストがない場合は、まずシステムプロキシが有効か、ブラウザーが独自のプロキシ設定を使っていないか、Androidのアプリ別設定にブラウザーが含まれているか確認します。キャッシュや既存の接続の影響も除外してください。リクエストがまだカーネルに入っていない可能性があるため、この段階ではDNSより先に通信の取り込みを確認します。
接続ログに記録があるのに接続先が想定したノードではない場合は、ステップ2に戻り、モードとポリシーグループの選択を確認します。ルールが別のグループへ振り分けているか、グループ内でダイレクトが選ばれている可能性があります。接続先が正しいのにログでタイムアウトが表示される場合は、モードを変えず、利用できることが分かっている別のノードだけを試してください。ドメイン名の解決エラーが明確に出ている場合は、設定のDNS動作を確認します。関連する項目とFake-IPの仕組みは設定項目リファレンスを参照してください。初期設定では、これらを同時に書き換える必要はありません。
変更は一度に1項目だけにし、同じ宛先へ再度アクセスして結果を記録してください。そうすれば、ノードの変更で直ったのか、通信の取り込み方法の変更で直ったのかを切り分けられます。サブスクリプションを変え、TUNを有効にし、グローバルモードに切り替え、DNSも変更すると、一時的にアクセスできても原因が分かりません。後から設定を戻した際に、再び接続できなくなるおそれがあります。
動作確認後の日常的な操作
動作を確認できたら、現在有効な設定を維持し、サブスクリプション提供元の案内に従って更新します。更新は既存の設定項目を再読み込みすればよく、毎回新しい設定を追加する必要はありません。更新後はポリシーグループを確認してください。ノード名やグループの構成が変わると、以前の選択を変更する必要がある場合があります。自動更新の間隔はクライアントとサービス提供元によって異なります。制限を確認せず、短い間隔で更新を繰り返す設定は避けてください。
使い終わったら、まずシステムプロキシをオフにするか、クライアントの通常の切断操作で通信の取り込みを解除してからアプリを終了します。アプリが異常終了した後にブラウザーからネットワークへアクセスできなくなった場合は、システムプロキシが停止済みのローカルポートを指したままになっていないか確認してください。AndroidではVPN接続が切断済みか確認します。アプリを終了することとOSのネットワーク設定を解除することは、常に同じ操作とは限りません。
完了の目安:現在の設定が使え、モードとポリシーグループの接続先が明確で、新しいリクエストが想定したルールに従ってアクセスを完了できることです。ここまで確認できたら、TUN、LAN共有、カスタムルールを必要に応じて1つずつ追加してください。入門手順を完了するために、すべての設定を先に変更する必要はありません。
設定項目やマージの動作を確認する場合は設定項目リファレンスを参照してください。インストール時の権限や初期設定を確認し直す場合は、初回インストール後の設定チェックリストをお読みください。このページの4ステップは、端末の変更後や設定の再読み込み後の確認にも使えます。