Clash カスタムルール完全ガイド：指定アプリを指定ノードへ振り分ける
検索で「Clash アプリごと プロキシ」「PROCESS-NAME 設定」と調べてきた方向け。購読に入っているデフォルトのrulesだけでは、特定サービスだけ別地域ノード、特定アプリだけ直結、といった細かい意図までは届きません。ここではrulesの読み方、ドメイン指定とプロセス指定、proxy-groupsとのつなぎ方、そして詰まりやすいポイントを日本語で整理します。
そもそも「ルール」は上から順に一本道
Clash（および多くの Mihomo／Clash Meta 系コア）では、接続が発生するとrulesの先頭から順に評価され、最初にマッチした行のポリシー先（プロキシグループ名、DIRECT、REJECTなど）が採用されます。だから「下のほうに丁寧に書いたのに効かない」というときは、より上の行ですでに別のルールに吸われていないかを最初に疑うのが近道です。
また、ルールが参照する名前はproxy-groupsに実在するグループ名と一字一句一致している必要があります。名前を変えたらrules側もまとめて直す、というのは proxy-groups の解説 で触れたのと同じ原則です。全体の流れは Clash のチュートリアル で一度押さえておくと、用語のつながりが掴みやすくなります。
ドメイン・IP ベース：サービス単位で出口を変える
アプリを直接指定する前に、多くの用途は接続先のドメインや IPで足ります。動画配信やクラウドストレージは、接続先ホスト名が比較的安定しているので、DOMAINやDOMAIN-SUFFIX、必要ならIP-CIDRやGEOIPで振り分けます。購読がすでに大きなRULE-SETを読み込んでいる場合は、自分用の行をその上か下のどちらに置くかで意味が変わるため、意図に合わせて順序を設計してください。
例として、あるサブドメイン配下だけを「ストリーミング用」グループへ送るイメージです。実際のドメインやグループ名は自分のプロファイルに合わせて置き換えます。
rules:
- DOMAIN-SUFFIX,example-video.com,Streaming
- DOMAIN-KEYWORD,cdn-stream,Streaming
- IP-CIDR,203.0.113.0/24,DIRECT,no-resolveno-resolveは、ドメインルールと IP ルールの相互作用でループや誤マッチを防ぐためのオプションです。購読テンプレートにすでに含まれている行を真似るのが安全です。
RULE-SET でメンテ負荷を下げる
ドメインを数十行ベタ書きするより、公開されているルール集合（RULE-SET）を取り込み、自分のプロファイルでは例外だけを短く書く方が更新に強いです。Mihomo 系ではリモートのルールセットとローカルファイルの両方が使えることが多く、behavior（domain / ipcidr など）の指定もセットの形式に合わせます。
ルールセットは「たくさんの行を束ねたもの」なので、結局リストの中のどの行が先にマッチするかは、あなたのrulesブロック全体の順序の中で決まります。カスタム行を「確実に効かせたい」なら、競合しそうな広いパターンより上に置く、というのが基本戦略です。
プロセス名・パスで「このアプリだけ」指定する
「ブラウザはプロキシのまま、ゲームランチャーだけ直結」のように、接続元プロセスで分けたい場合は、コアがサポートするPROCESS-NAMEやPROCESS-PATH（環境によっては表記・挙動が異なる）を使います。プラットフォームごとにプロセス名の取り方が違うため、Windows では実行ファイル名（例: game.exe）、macOS ではバンドルやパス表記が絡むことがあり、クライアントのログで実際に認識されている名前を確認してから書くのが確実です。
システムプロキシだけに頼る構成では、プロキシを無視するアプリにはそもそも Clash が流量を握れないことがあります。その場合は TUN モード など、より下のレイヤでトラフィックを捕捉する話とセットで検討します。逆に、ブラウザのように OS のプロキシ設定を尊重するアプリでは、プロセスルールよりドメインルールの方が安定することが多いです。
rules:
# Example: send traffic from a specific process to a group (names vary by OS)
- PROCESS-NAME,SomeApp.exe,GameDirect
- PROCESS-PATH,/Applications/SomeApp.app/Contents/MacOS/SomeApp,GameDirectproxy-groups を先に用意してからルールを書く
ルールの最後のカラムに書くのは、実ノード名ではなくプロキシグループ名であることがほとんどです。「米国のストリーミング用にだけ使うselect」「ゲーム用にDIRECTと低遅延ノードだけを並べたselect」のように、用途別グループを あらかじめ定義 しておくと、rules側は読みやすく保てます。
購読が毎回proxiesを上書きする運用では、グループが参照するノード名が変わることがあります。カスタムグループのメンバーに購読ノードを直書きしている場合は、更新後に存在しない名前を参照していないかを確認する習慣があると安心です。
よくあるつまずきと切り分け
- ルール順：広い
MATCHや包括的なルールセットが先にあり、細かい意図の行に届かない。 - 綴り違い：グループ名と
rulesのターゲットが微妙に不一致（大文字小文字・全角半角含む）。 - プロセス名の誤認：ランチャーと本体で実行ファイルが別、サンドボックス配下の別名、など。
- DNS とルール：ドメインが解決される前後でマッチが変わる。購読テンプレの
dns設定とセットで見る。 - クライアントの再読み込み：YAML を保存しただけでは古いプロファイルが残ることがある。明示的な再読み込みや再起動を試す。
実運用での組み立て方（イメージ）
現実的な作り方は、(1) 購読のデフォルトを土台に残す、(2) 自分の例外だけを短いカスタムブロックとして先頭付近に置く、(3) 動かないときはログで「どのルールに当たったか」を追う、の三段です。一度に大量の実験ルールを足すより、一行ずつ効果を確認した方が、ルール順のバグに早く気づけます。
セキュリティと規約の観点では、プロバイダの利用条件やローカル法を踏まえ、不要な迂回や第三者への影響が出ない範囲で運用してください。技術的な「できること」と「してよいこと」は別問題です。
よくある質問
アプリ単位のルールは必ず使うべき？
必須ではありません。多くの場合、接続先ドメインで目的は達成できます。プロセスルールは、ドメインが分散しているアプリや、同一ブラウザ内で別扱いが難しいときの次の手段、という位置づけが現実的です。
ルールを追加したら遅くなった気がする
ルール行数が極端に増えると評価コストは上がりますが、通常はボトルネックよりノード品質や DNS の方が大きいです。遅延が気になるときは、不要な重複ルールを減らし、RULE-SETの重複読み込みがないかも確認してください。
設定の編集はどこで行う？
GUI クライアントでは「プロファイル編集」や「設定ディレクトリ内の YAML」から行います。購読で上書きされるファイルに直接追記すると更新で消えるため、オーバーライド／マージ機能があるクライアントではそちらにカスタムを寄せる運用が安全です。
カスタムルールは、購読が用意した「平均的にうまくいく経路」に、あなたの例外だけを上書きするための仕組みです。試行錯誤のしやすさは、ログの読み方とクライアントの使い勝手に大きく依存します。メンテの続くビルドを安定して試せるよう、クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事や版の対応関係も追いやすくなります。