本稿でできるようになること
ゴールは、特定の実行ファイル名（プロセス名）に一致するトラフィックだけを、任意の ポリシーグループ（例：PROXY や購読ルールセットが用意した選択肢）へ流し、それ以外は既存の DOMAIN-SUFFIX や GEOIP など通常のルール階層に任せられる状態です。GUI クライアントを使っていても、裏側の config.yaml では同じ rules: 配列が評価されます。ここで押さえるべきは、(1) どのプロセス名が実際にログに出ているか、(2) ルールの上から順にマッチするという Clash 共通の性質、(3) 多くの環境で プロセス情報を内核が取得できる経路（典型は TUN）が必要、の三点です。以降、Windows と macOS で名前の取り方がどう違うかを分けて説明します。
なぜドメインルールだけでは足りないのか
DOMAIN-SUFFIX や IP-CIDR は強力ですが、同一ドメインを複数アプリが共有しているときに粒度が粗くなります。典型例はブラウザです。仕事用のタブと動画サイトが同じ googlevideo.com 系を触るため、「ブラウザ全体をプロキシ」「別アプリだけ直結」のようなアプリ単位の意図をドメインだけで表現するのが難しい場面があります。逆に、あるゲームランチャーが固定の少数ホストしか使わないならドメインルールで十分なことも多いです。検索意図として多いのは「ダウンローダだけ帯域の太いノードへ」「会議アプリだけ直結で品質優先」といった出口の意図がプロセスに紐づくケースなので、そのとき PROCESS-NAME がドメインルールと補完的になります。
前提：Meta 系内核とトラフィックの取り込み方
PROCESS-NAME が機能するには、内核が接続に対してプロセス情報を付与できるフックに乗っている必要があります。クライアント実装により差はありますが、デスクトップでは TUN で仮想インタフェース側にトラフィックを載せる構成が一般的です。システムプロキシだけの環境では、一部アプリの通信が内核にプロセス名付きで見えないことがあり、その場合はルールを書いても期待どおりに振り分けられません。まず TUN モードの有効化と権限 を確認し、ダッシュボードの接続一覧にプロセス列が出るかを見るのが近道です。Windows の初期導入は Windows セットアップ記事、macOS でシステム連携が怪しいときは システムプロキシまわりの別稿 も参照してください。
整理：PROCESS-NAME は「ルールの書き方」の話であり、名前解決の設計（FakeIP・DoH など）とは別レイヤです。DNS で迷子になる症状は DNS ガイド 側で先に整えると、プロセスルールの検証が単純になります。
ルール構文の骨格
Meta 系で広く使われる書式は、rules 配列の一行に タイプ・カンマ区切りの引数・ポリシー名を並べる形式です。PROCESS-NAME は、第二引数に照合したいプロセス名（多くの場合は実行ファイル名）、第三引数に送り先ポリシーを書きます。実際のキー表記や追加のバリアント（正規表現版など）は、利用中の Mihomo / Clash Meta のバージョンのドキュメントを正とし、本稿の例は説明用のスケッチとして扱ってください。ポリシー名は、購読で入った proxy-groups の name: と一字一句一致させます。全角スペースや見た目似た別名は「効かない」典型原因です。
# Sketch — verify rule keywords against your Mihomo version
rules:
- PROCESS-NAME,chrome.exe,PROXY_GROUP
- PROCESS-NAME,firefox.exe,PROXY_GROUP
- MATCH,DIRECT
Windows：exe 名・大小文字・日本語環境
Windows では、多くの場合 実行ファイル名（例：chrome.exe、msedge.exe）がそのままプロセス名として扱われます。タスクマネージャーの「詳細」タブや、リソースモニタの「イメージ」列で実際に動いている名前を確認し、それをルールに転記するのがもっとも事故が少ないです。大小文字は環境や実装で扱いが異なることがあるため、ログに出た表記をそのままコピーする癖を付けると安全です。ストア版アプリやサンドボックス付きブラウザは、想定と違う中間プロセス名で通信が見えることがあります。その場合は接続ログで数分観察し、安定して現れる名前に合わせます。パスまで厳密に区別したい場合は、バージョンによっては PROCESS-PATH 系のルールが使えるため、ドキュメントを確認してください。
Windows でよくある対象例
- ブラウザ：
chrome.exe、firefox.exe、msedge.exeなど（チャネルにより名前が増えることあり）。 - ゲーム：ランチャー本体とゲーム本体で別 exe になることが多い。両方をログで拾う。
- ダウンローダ：
aria2c.exeや各GUIクライアントの exe 名を個別指定。
macOS：.app バンドル内のバイナリ名
macOS では、Dock に並ぶアプリ名と、内核が見るプロセス名が一致しないことがあります。ブラウザなら /Applications/Google Chrome.app/Contents/MacOS/Google Chrome のように、.app 以下の実行バイナリが実体です。アクティビティモニタでプロセスを選択し、「サンプルを取る」や「情報を見る」から実パスと名前を確認するか、接続ログの表記に合わせます。Electron 製アプリは Electron など共通名に見えることがあり、プロセス名だけでは分離が難しい場合があります。そのときはドメインルールと組み合わせるか、対応しているならパス正規表現系のルールを検討します。権限まわりで TUN が不安定な場合は、ネットワーク拡張の許可や Helper の状態を先に直す必要があります（前述の macOS 記事参照）。
ルール順：プロセスルールをどこに置くか
Clash 系は rules を上から評価し、最初の一致で打ち切りです。したがって PROCESS-NAME を入れる位置は非常に重要です。典型パターンは次のとおりです。(A) 社内ドメインやローカル向けの細かい直結例外を最上段に置き、その直後に PROCESS-NAME で「このゲームだけ PROXY」を入れる。(B) 逆に、広い GEOIP より前にプロセス例外を置き、残りを地域ルールに任せる。どちらが正しいかはポリシーの優先順位次第なので、ダッシュボードの「ルール命中」表示を見ながら一段ずつ移動して試すのが確実です。購読ルールが巨大な場合、ローカル追記の PROCESS-NAME が下すぎて到達しないというミスも起きやすいです。
# Example ordering idea (simplify for your profile)
rules:
- DOMAIN-SUFFIX,corp.internal,DIRECT
- PROCESS-NAME,game.exe,PROXY_GROUP
- GEOIP,CN,DIRECT
- MATCH,PROXY_GROUP
正規表現やパス指定が必要なとき
バージョンとビルドオプションにより、PROCESS-NAME-REGEX や PROCESS-PATH、PROCESS-PATH-REGEX などの別タイプが用意されていることがあります。同名 exe が複数製品で衝突する、フルパスでしか区別できない、といったときに有効です。正規表現は過剰マッチしやすく、将来のアップデートでパスが変わると壊れるため、運用ではまず完全一致の PROCESS-NAME で足りるかを尽くし、どうしても足りないところだけを正規表現に頼るのがおすすめです。構文の有無は必ず自分のバージョンの公式ドキュメントで確認してください。
動作確認の手順
- Rule モードで動かし、接続ログにプロセス列が出ていることを確認する。
- 対象アプリだけを起動し、通信を発生させ、ログに出たプロセス名を控える。
PROCESS-NAME行を追加し、コアをリロード。命中したルールが想定どおりかをダッシュボードで見る。- 意図と違うポリシーに落ちる場合は、より上段の別ルールに先に吸われていないかを疑う。
- DNS 由来の振る舞い差は FakeIP / DoH 設定 と突き合わせる。
よくあるつまずき
- TUN 無効：プロセス情報が付かず、ルールがヒットしない／常に別判定になる。
- 名前の取り違え：ランチャーと本体ゲームで exe が分かれる。片方だけ指定している。
- ルール順：広い DOMAIN ルールが先にマッチし、プロセス行に到達しない。
- ポリシー名の綴り：
proxy-groupsの name と不一致で設定エラーや意図しないフォールバック。 - システムプロキシのみ：一部アプリはプロキシを無視し、見かけ上「効いていない」。TUN やアプリ側設定とセットで考える。
注意：職場・学校・地域の契約ではプロキシや迂回が禁止されている場合があります。許可された環境でのみ設定し、他人のネットワークに無断で中継しないでください。
「全体プロキシ」との棲み分け
グローバルや単純な Rule モードだけでは表現しづらい「アプリ単位の例外」を、PROCESS-NAME で薄く足すイメージです。全体をプロキシにすると速い反面、国内サービスまで遠回りになることがあります。逆に全体直結では、特定アプリだけがシステム設定を読まない問題を解けません。本稿の構成は、ベースを Rule モードのままにしつつ、少数の exe／バイナリ名だけ上乗せする運用がもっともメンテナンスしやすい、という立場です。長期運用では、購読ルールの更新で順序が変わることもあるため、ローカル追記部に短いコメント（英語）を残し、チームで共有できるようにしておくと再現性が上がります。
ドキュメントとクライアント入手
ルールタイプの正式一覧と挙動の差分は、利用中の Mihomo リリースノートを正としてください。日々のクライアント入手は 公式ダウンロードページ から行い、用語整理は ドキュメント・チュートリアル も併用すると、GUI のトグルと YAML の対応が掴みやすくなります。ソースや Issue は GitHub が適していますが、インストーラの取り違えを防ぐ意味でも、配布物の第一選択肢はサイト側に寄せるのがおすすめです。
まとめ
Clash Meta／Mihomo で PROCESS-NAME を使う要点は、ログに出たプロセス名をそのままルールに写すこと、ルール順で優先度を制御すること、そして多くの場合 TUN などプロセス情報が内核に届く経路を確保することです。Windows では exe 名、macOS では .app 内バイナリ名に注意し、同名プロセスが複数あるときはパス系ルールやドメインとの組み合わせを検討します。DNS やシステムプロキシの話題は本稿の外側にあるため、つまずいたら DNS ガイド や TUN ガイド に戻って層を分けて直すと早いです。2026 年現在も、ログで事実を取り、必要な行だけを足す方針がもっとも安定します。
他の迂回ツールに比べ、Clash エコシステムはルールをテキストで差分管理しやすい利点があります。プロセス条件を少数精鋭で載せれば、帯域の使い方やレイテンシの体感を、アプリの用途に沿って細かく調整しやすくなります。