一、PROCESS-NAME 在解什麼題
在 Mihomo／Clash.Meta 相容設定裡，PROCESS-NAME 的作用是：當資料封包已經被核心接手，核心嘗試把連線對應到發起程序的映像檔名稱時，套用你為該程式指定的策略組或出站。它補足了「只知道網域卻分不清是哪個程式」的情境，例如多部瀏覽器、遊戲啟動器與共用後台服務並存時。
也因此，它不負責「讓不喜歡走 HTTP 代理的程式忽然願意把流量交過來」。若程式直接綁定 NIC、使用 raw socket、或由服務身分在另一隔離環境發起連線，你首先要確認該類流量是否真的經過 Clash 的轉發路徑；否則 PROCESS-NAME 再精準也不可能被評估。
二、規則順序與「完全被別條搶走」
使用者最常忽略的，是規則列表自上而下先到先得：DOMAIN-SUFFIX、GEOIP、甚至可能過寬的 DIRECT 區段若放在前面且已對目標放行或轉發，底部的 PROCESS-NAME 根本不會進入評估。若你懷疑如此，可先暫時把對應的網域名規則註解或上移 PROCESS-NAME 測試，或在日誌中核對規則命中紀錄看是否早於預期被吃掉。
另一類情況是策略組層級還包了 url-test／fallback／relay。即使 PROCESS-NAME 命中，出站仍可能被父層級再分配；若你希望「這支程式鎖某一節點」，通常要搭配專門的策略組並避免再上層自動切換。完整語法請以你正在使用的 Mihomo／Meta 發行版本的說明為準。
載入順序備忘
- 訂閱與規則模組載入錯誤時，可能被靜默回退或使用預設集；請在客戶端確認「載入無錯誤」。
- 規則表末段的
MATCH請放在全部PROCESS-NAME規則之後；若順序倒置，底下的程式規則永遠輪不到。 - 多份設定或使用 profile 時，請肯定目前啟用的是你正在編輯的那份。
三、Windows 路徑與檔名字元
在 Windows，可執行檔常以 字母大小寫不敏感 的比對暴露給使用者，但設定檔中建議仍與工作管理員中顯示的名稱一致，例如 chrome.exe，避免依賴對大小寫寬鬆的實作細節。PROCESS-NAME通常配合不含路徑的檔名字串較為常見；若你改用 PROCESS-PATH 或核心支援路徑比對的版本，才把完整資料夾寫進去。
若你使用完整磁碟路徑，請注意 YAML 裡對反斜線 \ 的逸出：常以單一反斜線寫為 C:\Program Files\... 並搭配引號，或改用正斜線 C:/Program Files/...（多數解析器相容）以避免被當跳脫序列吃掉。複製來自社群範例的路徑時，也要確認對方是為 macOS/Linux 撰寫，還是真正針對 Windows。
四、實際對外連線的是哪個執行檔
許多程式表面只有一個圖示，背後會啟動子程序或更新程式，例如 Chromium 類瀏覽器常見數個同名 chrome.exe，而遊戲客戶端可能由啟動器拉主程式。你只鎖其中之一時，另一部分連線仍会走別的策略。解法是在工作管理員「詳細資料」開啟指令列欄，觀察實際對外發 TLS 的那一個 PID，對應到真正的路徑與檔名。
Microsoft Store 或 AppX／沙箱發佈的包，可能在虛擬化路徑下執行；此時映像名稱與桌面版 MSI 載入並不相同。本文與本站 Steam／遊戲情境專文的差異，在於本篇以「規則完全沒中」為主題；若你是單機遊戲與UDP 語音並存，請再搭配該文在 UDP／TUN 下的實務經驗。
副檔名永遠是 .exe；若你誤將服務宿主或腳本解譯器當成目標程式，命中率自然為零。
五、系統代理與 TUN：誰才能把流量送進規則引擎
僅開啟 HTTP／HTTPS 系統代理並執行程式規則時，對「尊重 WinINet／WinHTTP／系統 Proxy 設定」的應用程式有效；但大量遊戲、自定義網路堆疊、或僅對特定網埠綁線的程式，仍可能繞過。此時需要使用 TUN／虛擬網卡將流量統一送入核心，再配合路由或例外清單，PROCESS-NAME 才有被評估的機會。《Windows TUN 與路由排查》對常見斷網與防火牆問題有逐步說明，可在啟動 TUN 後仍對照該篇排除。
若你已開 TUN 但程式仍直連家裡對外網際網路的 IP，首先思考是否該目標被列入 bypass 或相當的清單、或規則層級在更早處將目標國碼視為國內直連。請勿把「國內直連規則」視為互不影響。
- 系統代理：適合主流瀏覽器與許多取用系統設定 API 的工具。
- TUN：適合你希望「不依賴應程式自願支援代理」的情境，與許多進程級規則搭配。
六、管理者權限與身分隔離
若 Clash／Mihomo 以一般用戶執行，而目標程式以系統管理者啟動，部分環境會使行程列舉與資料擷取不完整，或對映像來源取得失敗——表現為 PROCESS-NAME 偶發不準或視為無法判斷。反向亦可能成立：你希望系統級服務也走規則，但客戶端因權限不足無法攔該來源。
處理原則是對齊權限邊界：要嘛讓程式與客戶端在相同身分模型下運作，要嘛把必須提權的程式改在非提權目錄下安裝、或評估將 Clash／TUN 元件以可分派權限的方式安裝（仍須評估資安）。企業環境若有 AppLocker、HVCI／Device Guard，額外的映像載入規則也可能阻止虛擬網卡特徵。
七、情境對照與優先順序
下面整理常見徵狀對應的檢查清單；建議由上往下掃過，多數問題可在前三步鎖根因。
| 你看到的情況 | 優先確認 |
|---|---|
| 日誌從來沒有任何 PROCESS 規則命中紀錄 | 流量是否根本未經 Clash；是否要改 TUN？是否有更早的規則直接結束評估。 |
| 規則顯示命中卻換錯組 | 策略組層級的 url-test／別名引用；複製時名稱與別名縮不一致。 |
| 同名 exe 許多 PID | 對照指令列區分；必要時對子程序改用更準的路徑或場景級網域規則補強。 |
| 僅部份網站走對、部份仍走預設 | 該類網站是否在前面被 DOMAIN／GEOIP 規則配至另一出站。 |
| 換成管理員身分啟動後才發生 | 對齊提權；檢視客戶端與 TUN 元件權限與身分模型。 |
九、結語
當你已按教學寫好PROCESS-NAME卻發現規則「像沒寫」，請優先質疑三件事：流量是否真的進 Mihomo／Clash（模式與 TUN）、規則排序是否太早被吃掉、以及映像檔名字與身分是否對齊 Windows 現實，而不是馬上質疑核心瑕疵。對齊之後再談細部策略組調校，才能把長尾排錯時間壓下去。
與只靠預設模版切換出口的簡易客戶端相比，相容 Mihomo 生態的策略表較有可塑性；先穩妥地理清行程與權限，再疊規則，日常使用會順手得多。
若你希望自本站取得對應系統的包與相容版本，並在純原生 Windows 環境裡復現這些檢查步驟，建議直接使用下方連結進入本站下載區取得安裝檔後再逐段核對上文。