なぜ「ルール分流」が Clash の中心なのか

従来の VPN は多くの場合、端末から出る通信をまとめてトンネルに載せます。便利な反面、国内の銀行サイトや社内 VPN、ゲームのマッチメイキングまで遠回りになり、遅延や認証エラーの原因になりがちです。Clash 系クライアント（Mihomo コアを含む）は、接続のたびにルールを評価し、ポリシーグループが示す「出口」へ振り分ける設計です。つまり「すべてをプロキシ」でも「すべてを直結」でもなく、接続単位で最適解を選べます。

本記事でいう「精密制御」とは、魔法のワンクリック設定ではなく、ポリシー名・ルール行・DNS の三つを一貫した意図で揃えることです。名前が曖昧だとメンテナンスが破綻し、ルール順が雑だと意図しない行にマッチします。ここからは、現場でその事故を減らすための組み立て方を順に見ていきます。

ポリシーグループを設計する：出口を「意味のある単位」で分ける

proxy-groups は、ルールの右側に書く名前が実体となります。おすすめは、技術用語ではなく用途または信頼境界で命名することです。例：国内直結用 DIRECT_ONLY、低遅延優先の GAME_LOWLAT、動画向けの安定ノード STREAM、フォールバック付きの汎用 PROXY などです。

代表的なタイプと使いどころ

  • select：手動で出口を選びたいとき。サブグループ（別の proxy-group）をメンバーにできるため、「とりあえず PROXY に流すが中身は url-test」といった階層化に向きます。
  • url-test：レイテンシを計測し、最も速いノードを自動選択。動画やブラウジングのデフォルト出口にしやすい一方、計測 URL がブロックされると誤動作するので、到達可能な軽量 URL を選びます。
  • fallback：可用性重視。上位が死んだら順に落ちるため、「常に一つは生きている出口」を作りたいときに有効です。
  • load-balance：同一ドメインへの複数接続を分散したい上級者向け。挙動を理解してから使うのが安全です。
ⓘ 命名のコツ
ルール側は DOMAIN-SUFFIX,example.com,STREAM のようにポリシー名だけを参照します。名前が衝突したり、PROXY が実際には select なのか url-test なのか分からないと、数か月後の自分が迷子になります。短く、役割が一意に分かる英大文字スネークケースなど、ルールを並べる人間の認知負荷を下げてください。

rules の並べ順が「すべて」：先に書いた行が勝つ

Clash の rules は上から順に評価され、最初にマッチした行で確定します。精密制御の半分は、この順序設計です。実務では次のような骨格が安定しやすいです。

  1. ローカル・LAN・社内帯域を DIRECT へ（誤ってプロキシに流すと管理画面に入れなくなります）。
  2. 明確に直結させたい国内ドメイン（決済、政府系、CDN の国内エッジなど）。
  3. ブロックしたい広告・トラッカー（方針がなければこのブロックは入れない方が無難です）。
  4. 用途別の細かいルール（開発用レジストリ、特定 SaaS、ゲームドメイン）。
  5. GEOIP や RULE-SET など、まとめて扱うルール。
  6. 最後に MATCH などのフォールバック。

「国内は GEOIP,CN で一括」とだけ書くと楽ですが、例外ドメインが増えた瞬間にルールが読みにくくなります。例外は必ず GEOIP より上に置く、という原則だけは守ってください。

RULE-SET と rule-providers：メンテナンス可能なルールにする

長大なドメインリストを rules に直書きすると、差分管理が地獄になります。rule-providers で外部リストやローカルファイルを読み込み、RULE-SET 行として参照する方法は、更新頻度の高いリストに向いています。

設定のイメージは次のとおりです（値は例示です）。

rule-providers:
  reject-ads:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject-ads,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior（domain / classical / ipcidr など）と、実体ファイルの形式は一致させる必要があります。不一致だと「ルールがあるはずなのにマッチしない」という事象に見えます。更新間隔 interval は短すぎると配信元に負荷がかかるうえ、ローカル検証中はファイルプロバイダに切り替えると安全です。

GEOIP と DNS：fake-ip 環境では「解決結果」に注意

GEOIP,CN,DIRECT は、マッチング時に参照する IP がどこで解決されたかに依存します。enhanced-mode: fake-ip を使う構成では、アプリが最初に見る IP は偽アドレスであり、実際の地理判定はコア内部の解決タイミングとルールの組み合わせで決まります。意図せず海外 CDN のエッジに当たり、国内サイトなのにプロキシに流れる——といった「体感だけおかしい」現象は、ここがズレていることが多いです。

  • 国内ドメインを確実に直結したいなら、DOMAIN / DOMAIN-SUFFIX を GEOIP より上に積むのが確実です。
  • ストリーミング系は、IP ベースの判定だけでは足りないことがあり、サービスごとのリスト（RULE-SET）と組み合わせるほうが安定します。
  • DNS の fake-ip-filter に載せるドメインは、LAN 名や社内証明書検証に関わるホストなど、実 IP を早期に知る必要があるものに絞るのがよいです。

DNS セクションの詳しい鍵と値の意味については、設定ドキュメントの DNS・TUN まわりとあわせて読むと、ルールと矛盾しない構成にしやすくなります。

プロセス／アプリ単位で振り分ける（対応コアのみ）

Mihomo など一部の実装では、PROCESS-NAME や PROCESS-PATH 系のルールで、特定バイナリからの通信だけ別ポリシーへ逃がせます。IDE や CLI がプロキシ非対応でも、該当プロセスだけを低遅延直結や専用ノードに寄せる——といった運用が可能です。

⚠ 注意
OS やパッケージ管理により実行ファイル名が変わるため、メンテコストはドメインルールより高めです。長期運用するなら、PROCESS ルールは最小限にし、可能なら DOMAIN-SUFFIX や RULE-SET に寄せるほうが壊れにくいです。

シナリオ別：こう組むと現場で迷子になりにくい

在宅勤務＋開発

パッケージレジストリ、Git ホスト、社内 OIDC のドメインを列挙し、DIRECT か専用の低遅延グループへ。ブラウザの一般閲覧だけを PROXY にまとめると、ターミナルの遅延体感が安定します。

動画・ライブ視聴

帯域とルーティングが安定したノードを STREAM グループに集約し、サービスごとの DOMAIN ルールでそこへ流す。url-test の計測先は、そのノードから到達できる HTTP 200 が返る軽量 URL にします。

ゲームとボイスチャット

UDP と TCP が混在するため、ルールの穴が遅延に直結します。国内マッチメイキングを GEOIP や既知 CIDR で直結し、海外タイトルのみを選別プロキシへ。TUN モード併用時は、TUN モードの解説記事で述べているとおり、二重プロキシに注意してください。

挙動がおかしいときの短いチェックリスト

  • 本当にその行にマッチしているか：ログの「matched rule」相当の出力を確認。上にある広すぎる DOMAIN ルールに飲まれていないか。
  • ポリシー名の綴り：proxy-groups に存在しない名前をルールが指していないか。
  • RULE-SET の更新失敗：パスと behavior、ダウンロード失敗時のフォールバック挙動。
  • IPv6：IPv6 が迂回している場合、ルールが IPv4 だけを想定していると「半分だけプロキシ」に見える。

まとめ：ルールは「地図」、ポリシーは「出口看板」

ルール分流を極めるとは、短い設定を書くことではなく、将来の自分が読んでも意図が残る地図を描くことです。ポリシーは看板、ルールは道順、DNS は住所の読み取り方——この三つをそろえると、「なぜこの接続だけ遅いのか」が説明できるようになります。

GUI でサブスクリプションを取り込むだけの構成から一歩進みたい方は、まず rules の並べ替えと proxy-groups の階層化から手を付けるのが効果的です。ビルド済みクライアントでは、設定のバックアップとログ確認がしやすいものを選ぶと安全です。同類ツールと比べて、Clash はルール表現の柔らかさとコミュニティのルールセット資産の両面で、学習コストに見合う運用面のメリットが得られやすいと感じます。

実機での導入や各 OS 向けパッケージの入手は、配布元が整理されたページから行うのが確実です。→ Clash クライアントを無料ダウンロードし、ルール分流を試す