1. よくある症状
現象は大きく次の二つに分かれます。（1）設定をリロードしたのにログに PROCESS-NAME の行が一度も出ない。（2）ログには出るが出口 IP や策略が意図と違う。前者は「マッチ条件がそもそも満たされていない」可能性が高く、後者は「マッチはしているが別の理由で見かけ上ずれている」か「DNS・Sniffer・策略グループの別レイヤで上書きされている」ことが多いです。
まずタスクマネージャやクライアントのログで、実際にパケットを出しているプロセス名をメモしてください。ここがブレると、どれだけきれいな YAML を書いても当たりません。
2. PROCESS-NAME が評価される前提
PROCESS-NAME は Clash Meta／Mihomo 系で使えるルールタイプです。古いコアだけのビルドではそもそも未対応のことがあります。GUI の「バージョン情報」でコア名と版を確認し、プロセス系ルールが無効化されていないか（実験フラグや互換モード）も合わせて見てください。
また、OS がプロセスと接続の対応付けを取得できない経路（例：一部のカーネル直接路径や、コアが参照できない権限階層）では、ルールに渡る前に情報が欠落します。次節以降の「パス」「権限」は、この「コアが見えているプロセス名」とあなたがルールに書いた文字列が一致しているか、が本題です。
3. パス表記とファイル名
Windows では実行イメージは「chrome.exe」のようなファイル名のみで渡る場合と、C:\Program Files\... のようなフルパスで渡る場合の両方があり得ます。ドキュメントやサンプルが片方だけを想定していると、ここでミスマッチします。ルールでは次を試します。
- ファイル名だけ：
PROCESS-NAME,App.exe,PROXY - バックスラッシュのフルパス（環境によっては必要）：例
PROCESS-NAME,C:\Path\App.exe,PROXY - 大小文字：コアの実装では区別しないことが多いですが、ログに出た表記に合わせるのが安全です
Microsoft Store 版やランチャー経由のインストールでは、実体は WindowsApps 配下の別名になっており、ショートカットから想像した名前と実プロセス名が食い違うことがあります。タスクマネージャの［詳細］でイメージ名の列を確定させてからルールに反映してください。
スクリプトやラッパー
バッチや PowerShell、ポータブルランチャーが前に立つと、通信の主体は cmd.exe や pwsh.exe になることがあります。狙いはブラウザやゲーム本体なのに、ルールがラッチャー名に吸われる——という誤解が起きます。まずログのプロセス名が何かを事実として受け取り、必要なら二段階でルールを分けます。
# Example only — process names and policy groups must match your profile
rules:
- PROCESS-NAME,TargetApp.exe,APP_PROXY
- PROCESS-NAME,C:\Apps\TargetApp.exe,APP_PROXY
- MATCH,DIRECT4. 管理者権限と UAC
Clash 側を通常ユーザーで動かし、対象アプリだけ「管理者として実行」していると、コアがプロセス情報を揃えて取得できないケースが報告されます。逆に、片方だけ高い整合性レベルだと WFP／フィルタの見え方が変わり、期待したルール評価に届かないこともあります。
切り分けとしては、テスト時だけClash クライアントと対象アプリを同じ権限階層に揃える（両方通常、または両方管理者相当に近づける）、UAC プロンプトが出るアプリはプロンプト後に立ち上がったプロセス名を再確認する、のが実務的です。常時管理者で動かすのはセキュリティ上推奨されませんが、原因特定のための短時間の比較実験として意味があります。
5. 子プロセスと実際に通信している exe
ブラウザはタブや拡張ごとに子プロセスが分かれ、名前はすべて chrome.exe 等に見えることが多い一方、特定機能だけ別バイナリになるケースもあります。ゲームはランチャー（launcher.exe）と本体（game.exe）が分かれ、ダウンロードは前者・対戦は後者が通信する、といったパターンがあります。
PROCESS-NAME はその接続を作ったプロセスに紐づきます。ドメインルールで見えていたホストと、プロセスルールで取りたいホストが別プロセスから出ていると、「ドメインは合っているのにプロセスルールが気持ち悪い」という印象になります。タスクマネージャの「リソース モニター」や、クライアント付属の接続ビューでプロセスと宛先を一度対応させてください。
6. ルールの先取りと順序
ルールは上から順に評価され、先にマッチした行で決着します。GEOIP や巨大な RULE-SET、IP-CIDR が先にヒットすると、PROCESS-NAME の行まで到達しません。期待どおりに見せたいなら、（1）プロセス行を十分上に移動する、（2）あるいは先に当たっているルール集合を見直す、のどちらかが必要です。
また、MATCH や最終行以前に DIRECT が付いた広い条件があると、そこで止まります。トラブルシュート中は一時的にverboseで「実際にマッチしたルール名」をメモし、YAML 上の行番号と対応させると迷子になりにくいです。
7. TUN とシステムプロキシ
システムプロキシだけ有効で TUN がオフのとき、一部のトラフィックはプロキシスタックに乗らず、プロセス情報の扱いも変わることがあります。TUN は OS 全体の経路に近いため、プロセスとフローの対応を追いやすい反面、他 VPN や企業エージェントと競合しやすいです。詳細は TUN・ルート・ファイアウォールの記事を参照してください。
「プロセスルールは当たっているのに出口がおかしい」場合は、策略グループ（proxy-group の選択結果）やDNS の fake-ip、Sniffer によるホスト書き換えが別レイヤで効いていないかを疑います。プロセスで策略に乗せたあとも、ノード側のドロップで見かけが変わる点は取り違えやすいです。
8. チェックリスト
次を上から順に潰すと、原因の当たりが外れにくくなります。
- コアが
PROCESS-NAMEに対応しているか - ログに出るプロセス名と YAML の文字列が完全一致か（フルパス／
.exe含む） - Clash と対象アプリの権限階層が極端に食い違っていないか
- 通信しているのが別プロセス（ランチャー・ラッパー）ではないか
PROCESS-NAMEより前のルールに先取りされていないか- TUN／システムプロキシの組み合わせで取りこぼしが起きていないか
| ログ上の様子 | 疑うこと | 先に試すこと |
|---|---|---|
PROCESS-NAME 行が一切出ない |
文字列不一致、権限、未対応コア | プロセス名のコピー、権限揃え、ルールの上位移動 |
| 出るが策略が違う | 先取りルール、策略グループ、DNS | マッチした行を特定、rules 順序の整理 |
| ブラウザだけおかしい | プロセス名がブラウザ exe に付く | ブラウザ名でルールを分ける／ドメイン併用 |
9. Steam／Discord 記事との違い
当ブログではゲーム・ボイス向けに Steam とプロセス分流や Discord と UDPを扱っています。これらは具体アプリの典型パターン（UDP、WebRTC、ドメイン集合）が主題です。本稿はアプリ名に依存せず、PROCESS-NAME というルールタイプが期待どおり動かないときのメカニズム側（パス、権限、順序、TUN）に焦点を当てています。両方を読むと、長尾の検索意図（「書いたのに効かない」）に答えやすくなります。
10. まとめ
Windows で PROCESS-NAME が効かないときは、まずログに出るプロセス名と YAML の文字列を一致させ、次に権限階層とルールの先取りを疑うのが再現性の高い順序です。Mihomo／Clash Meta と GUI の組み合わせ差、TUN とシステムプロキシの違いもセットで見ると、見かけ上の「分流ミス」を減らせます。
同種の GUI と比較して、Clash 系はログとルールの対応を追いやすく、試行錯誤のたびに学びを蓄積しやすいのが利点です。ノード品質が揃えば、プロセス単位の整理も含めて運用が安定しやすくなります。