1 TUN とプロセス情報は別レイヤです
Mihomo／Clash Meta において TUN は、ざっくり言えばトラフィックをユーザ空間のコアへ引き込むための仮想 NIC と iptables／ルートまわりの仕組みです。一方 PROCESS-NAME ルールは「そのフローがどのアプリから発ったか」というメタデータに依存します。ドキュメントを読み飛ばしていると「TUN を付けたから PROCESS ルールも自動で賢くなる」という誤解につながりやすいのですが、実際にはスタックが変わるほどカーネルから見える情報の見え方も変わるため、mixed-port の明示プロキシでうまくいっていたルールが TUN だけズレる、という報告は珍しくありません。
検索ワードとしてよく出てくる「誰がプロキシに乗っているか」を把握したい場合、ダッシュボードの接続一覧とログは強い味方ですが、そこに表示されるプロセス名がルール評価時の名前と一字一句同じとは限りません。Electron アプリが chrome.exe や helper 系プロセスを挟む、コンテナ内のプロセスがホスト名として見える、サンドボックス越しに別実行体になる、といったパターンはどの OS にもあります。だからこそ find-process-mode は「探す／探さない／どれだけ探すか」を切り替えるスイッチとして設計されています。
2 find-process-mode の意味と現実的な選び方
設定キーはルート直下の find-process-mode で、値は実装の進行とともに細部が増えていますが、現場で押さえるべきは負荷と精度のトレードオフです。off に近い挙動ではプロセス探索自体を諦めるため、PROCESS-NAME を書いても効きません。strict は「必要なときだけ／コストを抑える」方向のデフォルト寄りの振る舞いで、ノート PC のバッテリー消費や大量短時間接続との相性が比較的よい一方、環境によってはプロセス名が空や別名になりルールがすり抜けることがあります。always は解決を積極的に試みるモードで、精度は上がりやすいがその分オーバーヘッドも増えやすい、という整理が実務では扱いやすいです。
実際の運用では「mixed-port ではうまくいくが TUN だけ PROCESS がブレる」「ゲームだけ名前が変わる」「Docker for Desktop 越しに別プロセスが見える」といった症状が出たタイミングで、まずログレベルを上げてコアが認識しているプロセス文字列を確認し、期待と違えば always へ一時的に上げて差分を見るのが早いです。差がなければ権限や別ユーザーのデーモン経由など、モード以外の要因を疑います。
# Process matching aggressiveness (always / strict / off — follow your core version docs)
find-process-mode: strict3 PROCESS-NAME が「書いたのに効かない」典型パターン
まず疑うべきはルールの順序です。上流で MATCH に吸われていたり、GEOIP／DOMAIN 系が先にヒットしていれば、PROCESS 行まで到達しません。初心者向けの購読セットは PROCESS をほとんど置かない構成も多く、自力で追記した行がファイル末尾にありつつ優先度が足りない、という単純ミスが意外と多いです。次に DNS と Fake-IP の相互作用です。名前解決フェーズと転送フェーズで見えている情報がズレると、ダッシュボード上の表示だけ綺麗でもルールとは別物に見えることがあります。DNS まわりの整理は並行して読んでおくと安全です。
さらに実務では「プロセス名ではなくパスで縛りたい」ケースがあります。同じ python.exe が複数環境に存在すると名前だけでは区別できず、PROCESS-PATH に逃げるほうが誤爆が減ります。逆に PATH を書きすぎるとメンテナンスが地獄になるので、ディレクトリ単位のワイルドカードやルールプロバイダへの外出しなど、運用コストとのバランスを見ます。
- ブラウザ：本体ではなくサブプロセスや GPU プロセスが見える。
- ストアアプリ／サンドボックス：パッケージ配下の実行体名が想定と異なる。
- WSL／コンテナ：ゲスト側プロセスがホストからどう見えるかが環境依存。
- システムサービス：ユーザーが直接触っていないデーモンが発信元になる。
4 Linux：権限・名前空間・実測のコツ
Linux で Mihomo を systemd ユニットや自作スクリプトから動かす場合、TUN デバイスの作成権限と他ユーザーのソケット情報を読める権限がセットになります。ディストリビューションによっては公式パッケージが capability を付けてくれるため root なしでも成立しますが、ソースからビルドして単にユーザ権限で実行していると、プロセス探索が部分的に失敗し続けることがあります。症状はログに薄く出るだけなので気付きにくく、結果として「PROCESS ルールがランダムに効かない」ように見えます。
また Flatpak や Snap、ユーザー名前空間を使うコンテナランタイムでは、ホスト側から見たプロセス情報が抽象化されます。これはセキュリティ上の正しい挙動ですが、プロセスマッチの観点では不利です。対策としてはホスト側ネイティブバイナリでコアを動かす、ルールをドメイン／UID ベースへ寄せる、あるいは別のマーク（policy routing + cgroup）へエスカレーションする、といった設計判断が必要になります。stub resolver と TUN の共存を分解している記事と合わせると、名前解決経路とプロセス経路の両方を同時に点検しやすくなります。
5 Windows：管理者昇格と実行ファイル名の落とし穴
Windows では WFP／プロバイダまわりとサービス権限の話がつきまといます。一般的な GUI クライアントは UAC 昇格を誘導してくれるため体験としては簡単ですが、コマンドラインでコアだけを引っ張ってきた場合、権限不足でプロセス照会が半截になることがあります。また実行ファイル名は大小文字や Unicode の見え方、ストアアプリのエイリアス、ワーカープロセス分裂などでタスクマネージャに表示されるラベルとルールに書くべき文字列が一致しないことがあります。
実務では Resource Monitor やプロセスエクスプローラで実際のイメージパスを確認し、まず PROCESS-PATH で絞ってから PROCESS-NAME を単純化するのがミスが少ないです。ゲームランチャが自作ランチャを挟む場合は、実際にソケットを開いているプロセスがプレイ中に切り替わる点にも注意してください。Windows 向け PROCESS 分流記事で触れている exe 名の拾い方と併せて使うと調査が速くなります。
6 YAML：最小スニペットとルール順の鉄則
以下は説明用の骨格です。実運用では購読ルールと競合しないよう、PROCESS 系は上流の汎用ルールより手前に置くのが基本です。ゲームだけ別ノード、開発ツールだけ直結といったチューニングでは、否定形よりも専用プロキシグループへ寄せた方が読みやすいことが多いです。
find-process-mode: strict
rules:
- PROCESS-NAME, chrome.exe, DIRECT
- PROCESS-PATH, D:\Games\SomeGame\game.exe, ProxyGames
- DOMAIN-SUFFIX, company.internal, DIRECT
- MATCH, ProxyDefault
PROCESS-PATH はドライブレターが変わる端末で複製すると破綻するので、ポータブル運用なら名前ベース＋別ルールで補強するか、テンプレートを機械生成する運用にします。また WSL から Windows 側ホストへ向かう通信では、プロセスの見え方が Linux と Windows のどちらになるかは経路次第です。検証時は片側だけログを見ないことが重要です。
7 ログとダッシュボードで実測する
設定を変えたら必ず同一アプリ・同一サーバへの再現手順を決めてログを取ります。ブラウザならシークレットウィンドウとプライベート DNS オフをセットに、CLI ツールならキャッシュを無効化するなど、ノイズを減らしてください。log-level と接続ログの記事では DNS とルール評価の見方がまとまっているので、プロセス名が出力されるオプションやダッシュボードの列をそのまま突き合わせます。
find-process-mode を always に上げた瞬間にログが静かになるなら、そもそも PROCESS ルールが到達していない可能性が高いです。逆に負荷だけが増えて挙動が変わらないなら、権限やプラットフォーム制約で探索が失敗しているサインです。その場合はモードをいじる前に OS 側の昇格やサービス構成を直した方が効率的です。
8 よくある質問
プロセスルールだけ DIRECT にしたいが、bypass 設定も必要ですか
アプリによっては TUN 全域を捕捉したうえで PROCESS で例外を切るより、最初からその宛先 IP を IP-CIDR で直結させた方が安定することもあります。運用ポリシーと監査要件が許すなら二段構えにするとブレが減ります。
サブスクリプション更新 interval の記事とどう違いますか
購読の interval や lazy はプロバイダ取得タイミングの話であり、本稿の対象であるプロセス解決とは独立です。ネットワーク全体の遅さと勘違いしやすいので、症状を切り分けるときはログの種類ごとに棚卸ししてください。
9 まとめ
Mihomo／Clash Meta で TUN と PROCESS-NAME を同時に使うときの鍵は、仮想 NIC がトラフィックを運ぶレイヤとプロセス名を解決するレイヤが別だという認識です。find-process-mode はその解決の激しさを制御するスイッチであり、strict で十分な環境もあれば、権限やサンドボックスのせいで always が必要な環境もあります。Linux と Windows では権限モデルがまったく異なるため、片方でうまくいった YAML をもう一方へコピペしただけでは再現しないことも珍しくありません。
コマンドライン愛好者にとって raw コアは自由度が高い反面、Capability／UAC／サービス登録といった OS 固有の壁を自分で越える必要があります。対してサードパーティの断片的なスクリプトは権限まわりがブラックボックスになりがちで、トラブル時にログが足りないという不満も聞かれます。こうした摩擦をまとめて減らしたい場合、Mihomo コアと TUN／ルール編集 UI を一体で抱える Clash Verge Rev は、プロセスルールの検証サイクルを短くするうえで現実的な選択肢です。手元の環境で PROCESS がブレるなら、モード変更より先にログの一行を疑い、必要なら ダウンロードページから自分の OS 向けビルドを試してダッシュボードと YAML を同じ画面から往復する運用へ切り替えてみてください。
