FlClashのルール分岐とは、アクセス先のドメインやIPアドレスなどを条件にして、通信を「プロキシ経由」と「直接接続」に振り分ける仕組みです。FlClashではMihomoのルールエンジンを利用できるため、すべての通信を一律にプロキシへ送るのではなく、必要なサービスだけをプロキシ経由にし、国内サイトやLAN内の機器などはDIRECTで接続するといった構成を作れます。基本となる考え方は難しくありません。ルールを上から順番に評価し、最初に一致した条件の出口を使う――この原則を理解すれば、DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、RULE-SETなどの設定も整理して考えられます。Mihomoの公式ドキュメントでも、ルールは上から下へ順番に評価され、上位のルールほど優先度が高いと説明されています。
1．FlClashのルール分岐は「通信の行き先を決める仕組み」
FlClashを使い始めると、「プロキシをオンにするか、オフにするか」という二択で考えてしまいがちです。しかし、Mihomo系のクライアントを使う大きな理由の一つは、その間にある細かな制御です。
たとえば、ブラウザでは海外サービスを利用したい一方、家庭内のNASやプリンターには直接アクセスしたいケースがあります。また、国内の一般的なWebサイトは直接接続し、特定の海外サービスだけプロキシを通したいこともあるでしょう。
このとき役立つのがルール分岐です。
ルールは基本的に、
「どの通信に対して」
「どの条件で」
「どの出口を使うか」
を決めます。
Mihomoでは、DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、RULE-SETなど複数のルールタイプが用意されています。たとえばDOMAINは特定のドメインを、DOMAIN-SUFFIXはドメインの末尾を基準に判定します。公式ドキュメントでは、DOMAIN-SUFFIX,google.comの場合、google.comだけでなくwww.google.comやmail.google.comにも一致すると説明されています。
一方、出口側には一般的に「PROXY」と「DIRECT」という考え方があります。
PROXYは選択したプロキシ、またはプロキシグループへ通信を渡す方式です。DIRECTはプロキシを経由せず、通常のネットワークから直接接続します。
この違いを理解すると、「ルール分岐＝VPNをオン・オフする機能」ではないことが見えてきます。
むしろ、通信ごとに経路を整理するためのルーティング設定と考えたほうが正確です。
2．最初に覚えるべき4種類のルール
FlClashのルール設定を始めると、たくさんの項目が表示されるため、最初からすべてを覚えようとすると疲れてしまいます。実際の利用では、まず4種類を理解すれば十分です。
DOMAIN――特定のドメインだけを指定する
DOMAINは、指定したドメインを対象にするルールです。
たとえば、
DOMAIN,example.com,PROXY
のような設定なら、対象となるドメインへの通信をPROXYへ送る、という意味になります。
特定のサービスだけを明確に指定したい場合に向いています。
DOMAIN-SUFFIX――サブドメインもまとめて扱う
実際にはDOMAIN-SUFFIXを使う場面のほうが多いでしょう。
DOMAIN-SUFFIX,example.com,PROXY
とすれば、example.com配下の複数のサブドメインをまとめて対象にできます。
Webサービスは一つのドメインだけで完結せず、API、画像、認証、CDNなど複数のホスト名を利用することがあります。そのため、単純なWebサイトの振り分けでは、ドメイン単位で考えたほうが管理しやすい場合があります。
IP-CIDR――IPアドレスやネットワーク範囲で分ける
IP-CIDRはIPアドレスの範囲を条件にします。
特に家庭やオフィスのLANを直接接続したい場合に役立ちます。
たとえばプライベートネットワークでよく使われる192.168.0.0/16などをDIRECTに指定すれば、家庭内のルーターやNASなどへの通信をプロキシへ流さない構成を作れます。
GEOIP――IPの地域情報を利用する
GEOIPは、接続先IPの地域情報を利用してルーティングする方法です。
たとえば特定地域のIPをDIRECTにする、といった設定が可能です。ただし、CDNやクラウドサービスではIP所在地と実際のサービス利用地域が必ずしも一致するとは限りません。
そのため、「GEOIPだけですべてを正確に分類できる」と考えるのは危険です。
MihomoのルールにはこのほかRULE-SETやGEOSITEなどもあり、複数の条件を組み合わせた運用も可能です。
初心者の場合は、DOMAIN-SUFFIXとIP-CIDRから始め、必要になってからRULE-SETなどへ広げるくらいで十分です。
3．プロキシとDIRECTをどう使い分けるか
FlClashのルール分岐で重要なのは、単に「何をプロキシにするか」ではありません。
「何を直接接続にするか」も同じくらい重要です。
たとえば、次のような環境を考えてみます。
自宅のPCからインターネットを利用しながら、家庭内NASにもアクセスしているとします。
この場合、NASのIPアドレスが192.168.x.xのプライベートアドレスなら、通常はDIRECTにしたほうが自然です。
概念的には、
IP-CIDR,192.168.0.0/16,DIRECT
のようなルールを置きます。
その一方で、特定の海外サービスをプロキシ経由にしたいなら、
DOMAIN-SUFFIX,example.com,PROXY
のようなルールを追加します。
ここで非常に重要なのがルールの順番です。
Mihomoは基本的にルールを上から順番に評価し、最初に一致したルールを採用します。つまり、上にある広いルールが先に通信を捕まえてしまうと、その下にある細かなルールまで到達しません。
たとえば、
DOMAIN-SUFFIX,example.com,DIRECT
の下に、
DOMAIN-SUFFIX,special.example.com,PROXY
を置いたとします。
special.example.comは後者の条件にも一致しますが、先にexample.comのルールへ一致しているため、意図したPROXYへ進まない可能性があります。
だからこそ、基本的には狭い条件を上、広い条件を下に置きます。
そして最後に、
MATCH,PROXY
などの兜底ルールを置く構成が一般的です。
MATCHは、それまでのルールに一致しなかった通信を処理するための最終ルールです。FlClashの開発者向け資料でも、MATCHは通常最後に配置し、未一致の通信を受けるルールとして扱われています。
4．実際の利用シーンから考えるルール分岐
ルール設定は、設定ファイルだけを見ていると抽象的に感じます。
そこで、実際の利用場面から考えてみましょう。
自宅でWeb閲覧とNASを併用する場合
たとえばノートPCから海外の開発ドキュメントを閲覧しながら、自宅のNASに保存した写真や仕事用ファイルへアクセスしているとします。
このとき、すべての通信をプロキシへ送る必要はありません。
LAN内の通信はDIRECTにし、必要な海外サービスだけPROXYにします。
こうしておけば、ローカルネットワークへのアクセスまでプロキシ経由になることを避けられます。
開発環境でGitHubなどを利用する場合
もう一つは開発者の環境です。
ブラウザでGitHubを使うだけなら、それほど複雑ではありません。しかし、Git、パッケージマネージャー、APIクライアント、コンテナ環境などが加わると、アプリケーションごとに通信方式が違うことがあります。
この場合、ドメイン単位のルールに加えて、必要に応じてプロセス単位やIP単位のルールを検討できます。MihomoではPROCESS-NAMEやPROCESS-PATHなど、より細かな条件を利用できる構成もあります。
ただし、ここで設定を増やしすぎないことが大切です。
「GitHubに接続できないからGitHubのルールを追加する」という作業を繰り返すと、最終的にはどのルールが通信を決めているのか分からなくなることがあります。
問題が発生したときは、まずFlClashの接続ログなどから対象通信を確認し、「どのルールに一致したのか」を考えるほうが合理的です。
国内サービスと海外サービスを分ける場合
もう一つ典型的なのが、国内サービスはDIRECT、必要な海外サービスはPROXYという構成です。
この場合、GEOSITEやRULE-SETを利用する方法があります。
RULE-SETは外部のルールプロバイダーを参照する仕組みで、サービスカテゴリーなどをまとめて管理できます。Mihomoの設定例でも、Rule Providerからルールを取得し、RULE-SETによってDIRECTや特定のプロキシグループへ振り分ける構成が使われています。
これは手作業で大量のドメインを登録するより効率的です。
ただし、外部ルールを使えば必ず正確になるわけではありません。ルール提供元の更新頻度や分類方針に依存するため、自分の環境と合わない場合は個別ルールを追加する必要があります。
5．FlClashでルールを変更するときの実践的な考え方
FlClashでルールを調整するときは、一度に大量の設定を変更しないことをおすすめします。
まず現在のProfileを確認します。
次に、対象となる通信を一つ決めます。
たとえば「このドメインだけPROXYにしたい」という目的があるなら、そのドメインに対して最小限のルールを追加します。
そして通信結果を確認します。
この方法なら、設定変更と結果の関係が分かりやすくなります。
逆に、
- DNSを変更する
- TUNを有効にする
- ルールを大量追加する
- Proxy Groupを変更する
- 外部RULE-SETを導入する
といった操作を同時に行うと、問題が発生したときの原因特定が難しくなります。
特に初心者が注意したいのが、「ルールを追加すればするほど良い」という考え方です。
ルールは多さではなく、目的との対応関係が重要です。
たとえば、
LAN → DIRECT
特定サービス → PROXY
その他 → MATCH
という3段階だけでも、十分実用的な環境を作れる場合があります。
そこから必要に応じてサービス別、地域別、アプリ別へ細分化していけばよいのです。
また、IPルールを使う場合はDNSの挙動にも注意が必要です。Mihomoでは、ドメインからIPを判定するルールによってDNS解決が発生する場合があり、no-resolveの指定が関係するケースもあります。
そのため、「IP-CIDRを書いたのに思った通りに動かない」という場合は、ルールだけでなくDNSと名前解決の流れも確認する必要があります。
6．ルール分岐を使いこなすために知っておきたい注意点
FlClashのルール分岐は非常に便利ですが、万能ではありません。
第一に、ルールは通信の経路を決めるものであって、接続先サービスの仕様そのものを変更するものではありません。
第二に、プロキシ経由にしたからといって通信速度が必ず速くなるわけでもありません。プロキシサーバーとの距離、回線品質、混雑、接続先との経路などが影響します。
第三に、GEOIPやドメイン分類は現実のサービス構成と完全に一致するとは限りません。CDNやクラウドインフラを利用しているサービスでは、同じサービスでも接続先IPが変化することがあります。
そしてもう一つ重要なのが、セキュリティとプライバシーです。
FlClashやMihomoがオープンソースであることは、コードを検証できるという意味では価値があります。しかし、利用するプロキシサーバーの運営者が誰なのか、どのようなログポリシーなのかという問題は別に考える必要があります。
「オープンソースだから安全」「プロキシだから匿名」という単純な判断は避けたほうがよいでしょう。
結局のところ、FlClashのルール分岐で大切なのは、複雑な設定を作ることではありません。
自分の通信を「直接接続したいもの」「プロキシへ送りたいもの」「どちらにするか判断できないもの」に整理することです。
最初はLANをDIRECT、必要なサービスをPROXY、最後にMATCHという小さな構成から始めれば十分です。そこから実際の通信ログを見て、必要なルールだけ追加していく。そのほうが設定の意味を保ったまま長く使えます。
Mihomoのルール仕様やFlClashでの設定方法をさらに確認したい場合は、FlClashの関連ドキュメントを参照しながら、DOMAIN、IP-CIDR、RULE-SET、MATCHの関係を一つずつ確認するとよいでしょう。ルール分岐は一度理解すれば、プロキシ設定を毎回手作業で切り替えるよりも、日常の通信を自然に整理できる仕組みになります。重要なのは、最初から完璧なルールを作ることではなく、自分が実際に使う通信だけを少しずつ整理していくことです。