1 為什麼開 TUN 時更要談 進程匹配？
TUN 模式的本質，是把大量原本散落於「瀏覽器／系統代理／個別 App」的流量，改由虛擬網路介面集中進入Mihomo。對使用者來說這很棒：終端機、容器周邊與背景元件較不容易繞過規則；但對核心來說，每一個封包最初往往只是一組五元組與路由決策——要把這條連線對應回「到底是 Chrome、Discord，還是某個更新器」，必須再做一層行程層級的資訊補齊，才能在規則引擎裡命中 PROCESS-NAME、PROCESS-PATH 這類條件。
也因此：PROCESS-NAME「會不會準」，並不只跟你規則怎麼寫有關，而是同時依賴平台是否能提供可信的行程對照，以及你是否允許核心用對的成本去做這件事——這正是 find-process-mode 介入的位置。你可以把它理解為「進程分流開關的策略旋鈕」：off 等於告訴核心別費心找行程（域名/IP 規則仍可照常工作）；strict 偏向只在資訊可靠時才相信進程匹配，藉此降低誤判；always 則更積極解析，追求更高的命中率，但可能增加開銷，而且仍無法保證每一條連線都能對應到你心目中的那個 App。
sniffing（協定嗅探）處理的多半是「這個 TLS／HTTP 連線背後的域名或 SNI是什麼」；find-process-mode 處理的是「這條連線背後的行程是誰」。兩者常常一起出現在進階 YAML，但彼此不能互相替代——別拿嗅探結果硬貼成進程規則的替代品。
2 find-process-mode：strict／always／off 怎麼取捨？
下列語意以多數 Clash Meta／Mihomo 公開文件與社群共識為準；若你使用的是特定 GUI 內嵌打包版本，仍建議對照該版本的 Release Notes，將本文當作概念地圖而非唯一真理來源。
- strict（嚴格）：偏向「沒把握就不要硬匹配」。當核心無法取得足夠可信的行程資訊時，會避免把連線貼上錯的程式標籤，從而降低「明明是 A 軟體，卻被標成 B」這種誤判風險。缺點是你會更容易遇到「規則寫了 PROCESS-NAME，但這條連線始終走 fallback」——它其實是在逼你先確認：這條連線究竟能不能被歸因到使用者程式。
- always（積極）：偏向「盡量去找」。核心會更頻繁／更執著地做行程查找，對某些難抓的背景連線可能提升命中率；代價是更多的 CPU／系統呼叫開銷，而且在複雜場景（更新器、服務子行程、沙盒）仍可能出現邊界案例。
- off（關閉）：明確關閉進程查找。此時
PROCESS-NAME／PROCESS-PATH類規則通常不該再當作可靠手段；你若仍然放置這些規則，很多情境會退化成「形同虛設」或只在極少數例外路徑湊巧命中——這正是許多新手覺得「我的規則壞了」但其實是開關設錯的經典誤會。
實務上的推薦順序通常是：先用 strict建立可預期的基線；若你已經非常確定環境乾淨、且確實存在「必須靠進程才能把某類長連線從 DOMAIN 規則拯救出來」的需求，再評估改成 always做 A／B 對照；若你根本不做應用級分流，而是純域名/IP 策略，則可以乾脆 off減少無謂開銷。
/proc、行程控制區塊或安全軟體攔截的限制；若平台層拒絕提供對照，你再 aggressive 也只能得到「找不到」這個結果。3 YAML 怎麼寫：把 find-process-mode 放在設定頂層
在典型的 Mihomo 設定檔中，find-process-mode 屬於全域行為開關，會影響後續規則評估時是否能取得行程名稱／路徑。下列片段僅示意欄位位置與常見取值，實際鍵名請以你的發行版本為準；若你透過 Clash Verge Rev 等 GUI 生成檔案，亦可先在進階編輯器中確認該鍵是否已被覆寫。
# Example — global process lookup policy for Mihomo / Clash Meta
find-process-mode: strict
tun:
enable: true
stack: system
auto-route: true
strict-route: false
rules:
- PROCESS-NAME, Spotify.exe, PROXY_GROUP_MEDIA
- PROCESS-PATH, /usr/bin/curl, DIRECT
- MATCH, FINAL_GROUP
一旦你把 TUN 與進程規則放在同一個設定生命週期裡維護，建議你也同步檢視 tun.stack、auto-route與 DNS 相關區塊——某些「規則命中不如預期」其實是路由／DNS 回流導致連線走了另一條路徑，而不是進程辨識失效。若 DNS 行為仍讓你困惑，可再對照站內 DNS 防洩漏 與 Mihomo DNS 專文。
4 Linux 與 Windows：tun 權限與行程資訊來源並不是同一件事
很多人在論壇裡把「TUN 建立不起來」與「PROCESS-NAME 對不上」混成同一題，但其實它們對應的系統門檻常常不同。對 Linux 而言，CAP_NET_ADMIN（以及對 /dev/net/tun 這類裝置節點的可開啟權限）是經典的硬前置；若你用 systemd 託管核心，還要留心單元檔裡的 CapabilityBoundingSet、AmbientCapabilities與裝置允許清單是否真的能讓長駐服務完成路由插入。這一步若失敗，你根本不會進入「規則評估」這個階段——自然也就無從討論進程分流。
當 TUN 已经稳定運作後，進程匹配第二道門檻才是：核心是否能透過系統 API／procfs 等方式把「這個 socket」對回「哪個 PID／執行檔」。在過度沙箱化的服務（例如某些預設強 hardening 的 unit）或受限容器中，行程資訊可能不完整，使得 strict 模式下長期呈現「對不上」——這時你要優先檢查的不是規則文案，而是執行身分與安全策略是否允許對照。
對 Windows 使用者來說，典型桌面環境下管理員權限與驅動／WFP（Windows Filtering Platform）相關議題常跟 TUN／透明代理綁在一起；同時，安全軟體對「行程注入／流量重定向」的過敏也可能間接干擾連線歸因的可見度。若你只在本機測試某個 .exe，請務必確認規則匹配的是實際對外連線的那個行程名稱：許多程式會派出 updater、helper、webview host，你的規則若只寫主程式，會出現「我已經開著 App，但規則不吃」的假象。
- Linux systemd：確認 unit 没有過度的
ProtectSystem=strict／ProtectKernelTunables組合把資訊來源掐死（實際可否停用需自行权衡安全模型）。 - Windows：用工作管理員／資源監視器核对對外連線 PID，再對照規則文字是否写錯大小寫或缺少副檔名。
- 多使用者／服務帳號：核心若在 service session，對桌面使用者行程的可見度可能不同；這類問題多半要靠「改成使用者會話啟動」或調整服務模型。
5 為什麼規則「看起來正確」卻仍然漏判或誤判？
下列檢查清單多半能把問題從「玄學」拉回「可複現」：
- 規則順序：更早的
DOMAIN-SUFFIX、GEOIP、IP-CIDR規則是否已经決定了出站？進程規則若排在後面，可能根本碰不到那条連線。 - 實際行程名稱：Windows 需要對準真正的
.exe名稱；Linux 可能是python3、java這類母体進程，而不是你在 IDE 裡看到的專案名稱。 - split tunnel／例外路由：某些 VPN 或企業代理會插入更高優先路由，導致流量根本沒進入 Mihomo 的規則路徑。
- local／loopback 特例：本機服務互連有時不走你想像的 tun path；請用連線紀錄確認來源是否仍在使用者程式。
- strict 的保守策略：当資訊不足以可靠匹配時，strict 選擇「不要瞎猜」，這時應視為訊號而非 bug——你需要換模式或改規則模型。
若你把上述項目逐一排除後仍舊卡住，下一步通常是暫時調高 log-level或改用外部控制器觀察連線細節（仍請注意不要把敏感域名／token 貼到公開場合）。長期維護上，建議把「會頻繁改名的進程規則」收斂成PROCESS-PATH（若能接受絕對路徑維護成本），或退回域名規則 + sniffing的穩定組合。
6 建議的除錯流程：先看見「核心眼中的行程」，再改規則
實務上最省時間的路線，是把調参拆成「觀測 → 改設定 → 再觀測」的回合：
- 觀測：選定一個問題 App，製造一條穩定的對外 HTTPS 連線；在外部控制器／Dashboard 找到對應連線列，確認是否有行程名稱／路徑欄位。
- 調開關：若完全沒有行程資訊且你確定 find-process-mode 不是 off，先在測試環境將模式改為 always 做對照；若 always 仍長期空白，偏向权限／環境問題。
- 調規則：把 PROCESS 規則上移或改成更符合真實 exe／路徑的文字；同步檢查是否需要為 helper 行程另寫一條規則。
- 回落：若進程分流成本過高，改用域名／Geosite／Rule Provider 統一治理，把進程規則限制在少数顽固案例。
若你已經在使用 REST／面板工具，亦可複習 外部控制器與 Yacd 的安全設定，避免為了除錯而把監聽界面暴露在公開網路。
7 實務問答（對齊結構化 FAQ）
問：我只有域名規則，也需要設 find-process-mode 嗎？
若你完全不使用 PROCESS-* 規則，理論上可以設為 off減少開銷；但若 GUI 預設開啟進程能力供連線詳情顯示，維持 strict 通常也可接受。
問：為什麼儀表板看得到行程名稱，但規則仍不吃？
多半是規則順序與策略組選擇問題——連線雖然被標記行程，但在評估鏈更早的位置已經被別的條件送去 DIRECT／另一組節點。
問：always 會讓電池／CPU 很有感嗎？
在高連線數、長連線多的場景確實可能更有感；請以實測為準，並避免長期為了「心里踏实」而常驻 always。
8 總結
Mihomo 在 TUN 模式下要回答「誰在走代理」，核心鏈路是：先把流量導進來，再在規則評估時決定要不要、以及多積極地做進程查找——這就是 find-process-mode。把它設對之后，PROCESS-NAME／PROCESS-PATH 才能真正成为你手上的精密扳手，而不是一堆「偶爾生效」的許願規則；若再加上對 Linux／Windows 權限與子行程分裂的理解，你就能系统性排除漏判與誤判，而不是每次開機都像抽獎。
與純命令行或散落設定檔相比，許多桌面使用者會碰到「知其然不知其所以然」的痛點：複製了別人的規則集卻不知道進程開關仍停在 off，或在 strict 環境裡硬寫一堆 PROCESS 規則導致大量 fallback。Clash Verge Rev 這類整合 Meta／Mihomo 能力、並把 TUN、DNS、規則與連線詳情放在同一視窗裡的原生用戶端，通常能把「觀測 → 調 find-process-mode → 驗證命中」變成可複製的操作節奏，而不是論壇碎片化截圖。若你希望把本文的 YAML 與實測流程落到日常主力機，不妨先從 本站下載頁取得與教程一致的安裝來源，再在圖形介面裡對照連線詳情與規則順序——比起盲目追逐第三方修改版核心，這條路往往更能長期維護。
