為什麼加了規則卻永遠走不到？

常見原因是規則被放在全域 MATCH 或過寬的兜底規則之後，或 prepend／append 與你以為的合併順序不一致；也可能是策略名稱與 proxy-groups 不一致。請匯出執行中設定，從規則鏈由上而下對照。

Meta Mixin 覆寫、合併優先級

文章目錄

一、為什麼用覆寫，而不是改訂閱檔

遠端訂閱的本質是一份會被你或供應商更新流程覆蓋的基線：你在本機手改的 proxies、rules、甚至註解，常在下一次「更新訂閱」時消失。覆寫（Override）、Mixin、或某些用戶端口中的 patch 檔，解的是同一件事：把個人差異拆到另一份 YAML（或多段片段），讓合併引擎在載入訂閱之後把它疊上去。這樣做的好處是維持可更新性：訂閱仍由上游維護分流主幹，你只維護薄薄一層例外規則與本機節點。

在 Mihomo／Clash Meta 語意下，核心最終仍然只吃一份合成結果；「覆寫」發生在用戶端或啟動流程合併多個來源之時。也因此，遇到問題時請優先問兩個問題：（1）合併順序是什麼？（2）我看到的檔案是不是執行中那份？只看磁碟上的訂閱快取，很容易和實際載入的設定不一致——這與訂閱解析與快取的除錯思路是同一套：相信「生效中的模型」，而不是「我以為應該生效的檔案」。

實務原則：訂閱檔只管「大宗、常更新」；覆寫檔只管「小我、要保留」。需要大改結構時，寧可改訂閱來源或自建 profile，也不要在覆寫裡堆成第二份完整規則——日後除錯成本會指數上升。

二、Mixin、Override 與「最終設定」

社群口語裡，Mixin 一詞早期常與特定桌面用戶端的「額外合併檔」連結；如今 Clash Verge 系產品多稱 覆寫／Override，並支援以 YAML 或腳本生成片段。名稱不必死記，你更該確認的是：你的用戶端文件寫的「第二份檔」在合併鏈的哪一層、是否支援多個片段、以及能否預覽合成結果。

另外，核心設定檔裡也可能出現與 profile 行為相關的欄位（例如儲存選擇、儲存現況等），與「訂閱＋覆寫」是不同概念：profile 類選項偏向執行期狀態與持久化，而 Mixin／覆寫偏向靜態結構的增量修改。混淆兩者時，常見症狀是「UI 裡某開關有存檔，但 YAML 合併後行為仍怪」——請回到用戶端是否真的把該鍵寫進最終設定。

三、YAML 合併：深合併與清單欄位

多數 Clash 系合併器對對應型別（map）採類似深合併：同一路徑的子鍵會互相疊加，後載入的值覆蓋先載入的同鍵純量；巢狀物件則繼續往下合併。這解釋了為何在覆寫檔內只寫 dns: 底下要改的子鍵，就有機會在不複製整段 DNS 的情況下改到行為——前提是合併器支援且訂閱與覆寫沒有互相排斥的結構假設。

相反地，像 rules、proxies 這類序列（list）欄位，若合併策略是「整段取代」，你會一秒失去訂閱裡上千行規則；因此實務上會提供平行欄位來表達插入位置。你最常看到的，是 prepend-rules（插到規則鏈前段）與 append-rules（插到後段）。語意記法：prepend 讓特例更早被評估；append 讓兜底或寬鬆條件排在供應商規則之後——但若訂閱末段已有 MATCH，append 仍然可能永遠落在一張大網後面，請參下一節。

合併欄位類型	你該期待的行為（高階）
對應型別（map），如 `dns`、`tun`	多鍵合併為主；同名純量常被後載入覆蓋；複雜內容請用官方文件核對是否支援數組欄位特殊策略
列表（list），如 `rules`、`proxies`	避免在覆寫裡整包重寫；優先使用 `prepend-rules`／`append-rules` 或客戶端等價 UI，並以執行中設定驗證順序
provider 區塊，如 `rule-providers`	鍵名唯一性很重要；與訂閱同名鍵可能覆蓋或合併失敗，請參 rule-providers 專文

注意：不同版本與不同用戶端的合併器細節可能不同。本文描述的是概念模型；遇見歧義時，以你所安裝版本的官方變更紀錄／文件為準，並用「匯出執行中設定」驗證。

四、規則優先級：prepend 與 append

不管你從哪個介面編輯，請牢記 Clash 規則引擎的基本語意：規則鏈由上而下評估，先命中先結束。因此「優先級」不是抽象口號，而是你在合成後陣列中的索引順序。

prepend-rules 的典型用途，是把區域網、本機直連、少數一定要走特定策略的網域放到最前面，確保不會被訂閱中較寬鬆的 GEOIP 或關鍵字規則提早截走。本站設定文件中的示例也採「先把私有 IP 與常用服務放前面」的思考，與覆寫策略一致。

append-rules 則適合你把個人補丁接在供應商規則之後；但若訂閱末端是 MATCH，append 可能無法挽救——因為所有流量都會在 MATCH 結束評估。此時要嘛改上游範本讓 MATCH 不要過早出現，要嘛把補丁改走 prepend-rules，要嘛調整訂閱與覆寫的合成策略（若你的工具支援）。

# Structure example only; replace policy labels with your own.
prepend-rules:
  - DOMAIN-SUFFIX,internal.corp,DIRECT
  - DOMAIN-SUFFIX,cdn.example,My-Handpicked-Group

append-rules:
  - DOMAIN-KEYWORD,telemetry,REJECT

若你同時使用 RULE-SET 載入大量第三方清單，請記得規則集只是在鏈上佔幾個条目；命中邏輯仍遵守順序。規則集載入與 path 更新節奏可併讀 rule-providers：path 與 interval，避免「規則集已更新，但覆寫順序讓它形同浪費」。

五、patch 路徑與檔案放置

使用者問「patch 路徑在哪？」，通常其實在問兩件事：（1）GUI 讓你把覆寫檔放在哪個目錄；（2）覆寫檔裡若引用本地資源，相對路徑是相對誰。第一點請直接查你所用的 macOS／Windows 用戶端說明——沙盒、權限與同步資料夾都會改變實際位置。第二點則多半以設定檔工作目錄或核心指定的 -d 目錄為基準，與 rule-providers 的 path 很類似：你不只在寫「檔名」，而是在寫「核心找得到的一條路」。

實務上建議你把覆寫檔控制在可版控的小檔案，並在檔頭用註解寫上用途與日期（註解請用英文以利 diff）。需要引用本機規則集時，優先確認 rule-providers 的 path 與實際落點一致，再於 rules 或 prepend-rules 內以 RULE-SET 連回該鍵名。對 純 systemd／無 GUI 部署，通常是你自己在啟動腳本把多個 YAML 合成後餵給核心；這種模式沒有「Mixin 按鈕」，但概念仍是合併順序，可參考本站 Linux systemd 部署 Mihomo 類文章的工作目錄習慣。

六、實務片段與命名習慣

為了降低與訂閱節點名稱碰撞，自訂節點與策略組建議加可辨識前綴（例如 LOCAL-、MY-）。策略組內引用名稱時，請逐字一致：Clash 不會幫你猜「這個節點大概是同一個」。當你在覆寫檔新增 proxy-groups，也要同步確認 rules／prepend-rules 內的策略標籤指向存在且可選到節點。

想微調 DNS 或 fake-ip 卻不想碰訂閱，可在覆寫裡只動 dns 相關子鍵；但若同時調整規則與 DNS，請用單變因實驗，並對照 DNS nameserver 與 fallback 教學，否則會出現「規則顯示走代理，解析卻像直連」的假性矛盾。

若你的痛點是自動選擇節點的穩定性，覆寫可能會改到 url-test 參數（interval、tolerance）；此時請延伸閱讀 url-test 調優，不要把問題誤判成「覆寫沒吃到」。

# Example: local node + group + high-priority rule (comments in English)
proxies:
  - name: "LOCAL-EXIT-HK"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-128-gcm
    password: "replace-me"

proxy-groups:
  - name: "PICK-HK"
    type: select
    proxies:
      - "LOCAL-EXIT-HK"
      - "fallback-from-subscription"

prepend-rules:
  - DOMAIN-SUFFIX,chatgpt.com,PICK-HK

七、除錯：匯出與驗證

取得執行中設定：優先使用用戶端提供的「複製執行中設定／Debug 匯出」，不要只盯訂閱原始檔。
檢查合併後的 rules 前後文：確認你的 prepend 是否真的插在預期位置；append 是否落在 MATCH 之後。
全域搜尋鍵名：對 rule-providers、proxy-groups 名稱做重複檢查；覆蓋而非合併時，錯誤會很安靜。
連線層驗證：用單一目標網域或 App 實測，對照連線紀錄與命中的規則名稱。
分段還原：先保留最小覆寫（例如只有一條 prepend），確認機制通了再逐步加回需求。

這套流程與你在調 TUN、程序規則、或 外部控制器 時的習慣應一致：先確認「核心看到的 YAML」，再談網路症狀。當你把合併順序想清楚後，多數「覆寫好像沒作用」其實是順序與兜底規則的問題，而不是 patch 檔沒被讀取。

八、常見問題

prepend-rules 與直接改 rules 有什麼不同？

直接改 rules 若遇整段取代合併，風險是丟失訂閱規則；prepend-rules 類欄位則明確表達「插在鏈首」。實際欄位名稱與支援度請以你的用戶端／版本文件為準。

Mixin 和 Profile Override 是同一回事嗎？

不一定。兩者常被混用來指「訂閱之外的第二層 YAML」，但實際合併點與 UI 路徑依產品而異。建議以工具文件的名稱為準，並用匯出檔驗證。

為什麼規則加了卻永遠走不到？

多數是順序問題：規則落在 MATCH 之後，或被更早的寬鬆規則截斷；少數是策略名拼寫不一致。請從執行中設定逐行往下看。

覆寫會影響訂閱自動更新嗎？

正常不會；訂閱仍按原本 URL 更新。但若你把覆寫與訂閱綁成單一檔案管理，心智上容易搞混——建議在檔名與註解上清楚區分。

九、小結

Clash Meta／Mihomo 的生態裡，Mixin、patch、Profile 覆寫描述的是「如何在不整份改寫訂閱的前提下，把個人差異安全地合進生效設定」。理解 對應型別深合併與 rules 這類清單的插入語意之後，你就能正確使用 prepend-rules／append-rules，並以 執行中設定匯出 校對合併優先級。搭配 rule-providers、DNS、url-test 等主題文章，你的 Meta 配置會更好維護、也更好除錯。

市面上不少代理工具要嘛把「細粒度覆寫」藏進專屬格式，要嘛乾脆希望你整包匯入供應商範本；一旦與訂閱更新打架，使用者就只能反覆手動合併。相形之下，Clash 系把規則與節點拆成可理解的 YAML 結構，並透過覆寫與 provider 機制讓你能小步迭代；成熟的跨平台用戶端也讓同一份概念在桌面與行動裝置之間延續。若你希望長期維護一份乾淨、可更新又好除錯的設定，從今天就養成「訂閱歸訂閱、覆寫歸覆寫」的習慣，會比到論壇找整包懶人包更省時間。

→ 立即免費下載 Clash，開啟流暢上網新體驗