プロセス名ルールが向く場面とドメインルールとの違い

ドメインやIPでルールを書く方法は、ブラウザや多くの常駐アプリと相性がよく、ルール分流のベストプラクティス に沿って整理しやすい一方、次のようなニーズにはプロセス（実行ファイル）単位の方が素直なことがあります。（1）同じドメインに複数アプリがアクセスし、アプリごとに出口を変えたい。（2）ドメインが可変・CDN 分散でリスト化しにくい。（3）業務ソフトやゲームの実行ファイル名が分かっており、それを軸にしたい。ここで使うのが Clash Meta／Mihomo 系でサポートされる PROCESS-NAME タイプのルールです。名前解決や fake-ip のレイヤー整理は DNS 設定の実践記事 と線でつながりますが、本稿の主題は「どの exe から出た接続か」というメタ情報です。

モバイルでは OS 機能としてのアプリ単位プロキシが一般的ですが、Windows デスクトップではクライアント側のルールで近いことを狙う、という位置づけになります。Android 版の整理は Clash Meta for Android の分アプリ代理 と対比すると理解しやすいです。

ℹ 用語：本稿の process-name は、Mihomo のルール行で使う PROCESS-NAME キーワードを指します。コアのバージョンによっては追加のプロセス系ルール（例：パス指定）が別途ある場合があるため、アップグレード手順 付近の公式ドキュメントと突き合わせてください。

PROCESS-NAME の書式と評価順

典型的な書式は次のイメージです。カンマ区切りで、ルール種別・プロセス名（多くの場合 実行ファイル名）・送り先（ポリシー名や DIRECT）を並べます。Windows では chrome.exe のように小文字で統一して書く運用が紛れにくいですが、実際のマッチは環境・実装の大小文字の扱いに依存するため、タスクマネージャーに表示される名前とログを突き合わせて確認してください。

rules: PROCESS-NAME (illustrative) 
rules:
  - PROCESS-NAME,game.exe,PROXY-GAMES
  - PROCESS-NAME,teams.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

評価順は他のルールと同じく上から順です。より具体的な PROCESS-NAME 行を、広い DOMAIN や GEOIP より上に置くと意図どおりに拾われやすくなります。逆に、先に MATCH や広いドメインルールが当たると、そこで処理が終わります。設計の考え方は ルール分流のベストプラクティス の「順序がすべて」という整理と同じです。実際のポリシー名は 策略組と url-test／fallback で定義したグループ名に合わせます。

Windows での前提：TUN と接続の可視化

プロセス名を接続に紐づけるには、コアがその接続をプロキシチェーン上で把握できる必要があります。システムプロキシだけに頼る構成では、プロキシ非対応の exe が素通りし、ルールが効かないことがあります。多くの実運用では TUN モードを有効にし、トラフィックを仮想インターフェース側へ寄せたうえでルール評価に載せます。仕組みの背景は TUN モードの深掘り を参照してください。GUI での初回セットアップの流れは Windows 11 での Clash Verge Rev と TUN が近い文脈です。

WSL2 やコンテナから出る通信は、ホスト OS 上の別プロセスとして見えることがあり、デスクトップの exe ルールだけでは足りない場合があります。境界の整理は WSL2 と Windows ホストの Clash を併読してください。

実測手順：exe 名の確認からルール反映まで

次の順で進めると切り分けがしやすいです。（1）対象アプリを起動し、タスクマネージャーの「詳細」で実行ファイル名（例：SomeApp.exe）を確認する。（2）クライアントのライブ接続やログで、同じ名前が表示されるかを見る。表示が無い場合は TUN 未適用や別経路の可能性があります。（3）rules: に PROCESS-NAME 行を追加し、プロファイルを再読み込みする。（4）対象操作をもう一度行い、期待するポリシーに入ったかを確認する。

クライアントによっては接続一覧にプロセス列があるものとないものがあります。無い場合はコアのログレベルを上げる、または REST API／ダッシュボードで接続情報を確認する、といった手段になります。Web パネルの到達性は Clash Meta Web UI と external-controller も参照してください。

当たらないとき：子プロセス・UWP・サービス

ランチャーが launcher.exe で実体は game.exe、といった子プロセス構造では、見ている名前と実際にソケットを開いている名前が異なることがあります。更新プログラムやバックグラウンドの サービスが別 exe になるケースも同様です。Microsoft Store 系（UWP）は実行イメージの見え方が分かりにくく、期待どおりの文字列にならないことがあります。その場合はプロセスではなく ドメインルールや TUN 全体の例外を検討する段階に移ります。

ルールは増えるほど保守コストが上がるため、長期運用ではクライアントの選び方も含めて クライアントの選び方 を一度見直すとよいです。

ゲーム・Steam 周りとの併用の考え方

オンラインゲームでは UDP や複数 exe（ランチャー・アンチチート・本体）が絡みやすく、プロセス名だけでは足りない場面があります。Clash×Steam：UDP と TUN で整理しているように、PROCESS-NAME はドメイン・ポート・UDP 要件とセットで設計するのが安全です。競技用途ではレイテンシ優先で DIRECT に寄せる判断も珍しくありません。

⚠ コンプライアンス：学校・職場・ゲーム利用規約でプロキシや経路変更が禁止されている場合があります。本稿は許可された環境での設定整理を目的とし、規約回避を助長する意図はありません。

まとめ

Windows で Clash Meta／Mihomo を使い、特定 exe だけ別ポリシーへ回したいときの要点は次のとおりです。PROCESS-NAME は実行ファイル名とルールの上から順の評価が鍵で、多くの場合 TUN とライブ接続の可視化が前提になります。ドメインルールと併用し、順序を誤らないことが実務上もっとも効きます。

手元のプロファイルでルールとログを同じ画面から試したい方は、→ Clash を無料ダウンロードし、接続一覧と YAML の往復がしやすいクライアントから検証を始めてください。