自訂規則教學：讓指定 App 走指定節點

自訂規則在 Clash 裡扮演什麼角色？

Clash 類核心（含 Clash Meta／Mihomo）在處理每一條連線時，會依序掃描 rules 陣列：先命中的規則決定策略，後面的規則不會再被評估。策略目標通常是一個你在 proxy-groups 裡定義的名稱（例如 Streaming-US）、內建的 DIRECT／REJECT，或某個具體代理節點名稱。換句話說，規則負責「把流量分類」，而實際走哪個節點仍取決於該策略指向的群組或節點怎麼設計。

訂閱商附的規則表往往偏通用：能涵蓋常見網域與地區判斷，但未必符合你個人的遊戲、串流或工作軟體習慣。此時在不刪除訂閱產生內容的前提下，於本機設定中「額外插入」幾條更細的規則，是社群裡最穩定的做法。若你還沒熟悉群組命名與巢狀結構，建議先閱讀Clash 代理群組（proxy-groups）完全指南，再回來寫規則會事半功倍。

最後要有一個心理準備：「指定 App」在 Clash 世界裡，多半是用行程名稱或路徑（PROCESS-NAME／PROCESS-PATH）來辨識，而不是像手機系統設定裡點選 App 圖示那麼直覺。不同作業系統上執行檔名稱也不同，需要一點對照與測試。

規則順序：先命中先贏，細則請往前放

這是最容易被忽略、卻最關鍵的一點。假設你先寫了一條很寬鬆的 MATCH 把所有流量丟進某個群組，後面再補「某個網域要走直連」，後面那條永遠不會執行，因為全部流量已經在前面被吃掉了。實務上我們會把最明確、最例外的規則放在清單越前面越好：例如特定遊戲執行檔、特定串流網域、公司 VPN 網段等；較概括的 GEOIP 或兜底用的 MATCH 則放在後面。

若你同時使用規則集（RULE-SET），也要把「只屬於你個人」的少數規則放在規則集命中之前或之後——視你想讓誰優先而定。常見做法是：自訂精確規則 → 訂閱／社群維護的大型規則集 → 最後 MATCH。這樣既不失去社群規則集的便利，又保留你自家政策的優先權。

常見規則類型：從網域到 IP

下列類型在 YAML 裡十分常見（實際可用項目仍以你所用的核心版本文件為準）。把它們想成「不同的匹配鍵」：有的看網域名稱，有的看 IP，有的看本機行程。

DOMAIN 與 DOMAIN-SUFFIX

DOMAIN 比對完整主機名稱；DOMAIN-SUFFIX 則比對後綴，適合涵蓋一整個網域樹（例如某 CDN 底下多個子網域）。寫網域規則時請注意大小寫一般無感，但拼字必須正確；部分服務會用很多不同網域做 API 與內容分流，只寫一條可能不夠。

DOMAIN-KEYWORD

關鍵字匹配威力強，但也容易誤殺：只要主機名稱裡出現該字串就命中。適合臨時測試或極少數情境；長期維護通常寧可用較精確的 DOMAIN-SUFFIX 或規則集。

IP-CIDR 與 GEOIP

IP-CIDR 以 CIDR 表示法鎖定網段，適合已知對端 IP 範圍的服務。GEOIP 則依 IP 所屬國家／地區分流，很適合「某國 IP 一律直連」這類粗粒度政策。要留意 GEOIP 依賴資料庫與解析結果，與 DNS 是否被污染、是否走代理都有關聯；進階議題可搭配我們另一篇TUN 模式深度解析一併理解。

讓指定 App 走指定節點：PROCESS-NAME 與 PROCESS-PATH

若你的目標是「只要這個程式發起的連線，都走某個群組」，核心思路是匹配本機行程名稱或執行檔完整路徑。語意上大致如下（請依官方文件與核心版本確認欄位名稱）：

rules:
  - PROCESS-NAME,chrome.exe,Browser-Proxy
  - PROCESS-NAME,Telegram.exe,HK-Auto
  - PROCESS-PATH,C:\Games\SomeGame\game.exe,DIRECT
  - MATCH,Main

其中 Browser-Proxy、HK-Auto、Main 都必須是你在 proxy-groups 或 proxies 裡已宣告且名稱一致的策略目標。Windows 上常見的是 .exe 檔名；macOS 則可能是 Unix 行程名稱，與你在「活動監視器」看到的欄位對照。若同一款軟體有多個子行程（更新程式、雲端同步、主程式），可能要分別寫多條規則，或改用路徑匹配較精準的 PROCESS-PATH。

為什麼有時寫了 PROCESS-NAME 仍沒效？常見原因包括：該 App 的連線並非由你看見的那個執行檔發起（例如背景服務）、核心或平台不支援該規則類型、或流量未經過 Clash 所攔截的路徑（未開系統代理、或未使用 TUN／透明代理環境）。若你發現只有瀏覽器遵守規則，而獨立程式卻繞過，很可能要檢查是否需啟用 TUN 或作業系統層的強制導流。

與 proxy-groups 搭配：先有名稱，再寫規則

實務上我們會先定義幾個「用途向」的群組，例如：Streaming（手動選美國／日本節點）、Game（低延遲自動）、AI-Tools 等，再在 rules 裡把特定網域或行程指到這些群組。請不要讓規則裡出現一個從未在群組裡定義過的名稱，否則載入可能失敗或行為未定義。

若訂閱更新後節點大改名，你只需確保群組成員清單仍有效；規則裡引用的是群組名，不是單一節點名時，通常較能抵抗上游改名帶來的衝擊。這也是為什麼老手喜歡「規則 → 穩定群組名 → 群組內再 url-test」的分層結構。

RULE-SET：用外部規則集減少 YAML 膨脹

當網域清單很長時，全寫進主設定會難以閱讀。Clash Meta 系支援以 RULE-SET 引用本機或遠端下載的規則集（格式依核心而定，常見為 .yaml 或 .mrs 等）。好處是模組化：社群或專案可以獨立維護「廣告攔截」「串流網域」等清單，你的主檔只保留少數個人規則與 MATCH。

使用規則集時，仍要回到上一節的原則：排序與優先權。若兩個規則集都會命中同一流量，先出現的那個贏。建議把個人例外放在規則集之前；若你希望規則集覆蓋你的例外，則順序要反過來——但這通常較少見。

合併訂閱、覆寫與「不要洗掉我的規則」

圖形客戶端常提供「訂閱」「覆寫」「合併」等功能：訂閱負責節點與基底規則，你在 UI 或額外 YAML 裡追加的片段則應在合併後仍位於正確順序。實務上請養成習慣：每次上游大版本更新後，抽查幾條關鍵自訂規則是否還在；若客戶端提供「僅更新 proxies」類選項，優先使用可降低誤覆蓋風險。

從其他工具搬家時，也可參考從 Clash for Windows 遷移到 Clash Verge Rev 完整指南中關於備份與匯入的段落，避免只複製了半套規則。

Android 與桌面環境的差異

在 Windows／macOS 上，PROCESS-NAME 類規則與系統代理、TUN 的配合是桌面使用者最常玩的組合。相對地，Android 上的 Clash 客戶端常提供依應用程式分流的介面選項，語意上接近「指定 App」，但實作細節與純 YAML 的 PROCESS-NAME 不盡相同。若你主要在手機上操作，請以該客戶端文件為主，並理解 VPN／透明轉發等模式對「哪些流量會經過核心」的影響。

無論哪一平台，先確認流量真的有進核心，再談規則是否命中，會省下大量瞎猜時間。可善用連線日誌、即時連線列表，對照規則命中結果。

除錯與驗證建議

• 從少到多：先寫一條簡單規則（例如單一 DOMAIN）確認策略目標正確，再擴充到行程或規則集。
• 對照名稱大小寫與全形半形：群組名、節點名與規則中字串需完全一致。
• 注意 DNS 與 SNI：有些連線在規則階段看到的資訊與你想像不同，尤其 HTTPS 與 QUIC 情境下，必要時查官方文件或社群案例。
• 版本差異：Clash Premium 與 Clash Meta 在規則類型與規則集格式上可能有差，升級核心後請重讀 Release Note。

若你希望環境安裝與基礎操作一次整理，可搭配Clash 使用教學對照裝置權限與模式設定。

常見問題

把規則、群組與訂閱的邊界劃清楚之後，你會發現 Clash 的強項正在於可預期的長期維護：比起一次性的「全機翻牆」，細緻分流更能配合工作與娛樂並存的現實需求。若你正在找一款能穩定承載這套設定的客戶端，不妨從本站取得對應平台版本，親自體驗規則命中與節點切換是否順手——→ 立即免費下載 Clash，將自訂分流付諸實行。