Clash Meta 用 mixin 覆寫遠端訂閱：注入自建規則不被更新覆蓋（逐步操作）
許多人手上只有機場提供的遠端訂閱連結，卻想在不直接修改訂閱 YAML 本文的前提下，額外加上去廣告、國內網段直連、或自訂策略組與規則順序。最大的擔心是：每次按下「更新訂閱」，本機辛苦寫好的段落會不會被整份覆蓋？在 Clash Meta（Mihomo） 生態裡，正確做法是讓訂閱維持「上游單一真實來源」，把您的客製化放在profile／mixin 覆寫層，由核心或客戶端在載入時合併成最終生效設定。本篇用實務語彙整理合併順序、常見YAML 寫法，以及訂閱刷新後如何驗證規則仍在。
為什麼「手改訂閱檔」一定會痛
遠端訂閱的本質是一份由機場維護的設定：節點清單、預設策略組、以及他們打包好的規則段落。客戶端每次更新時，通常會重新下載整份內容並取代快取檔案。若您把去廣告或 GEOIP 直連直接寫進這份被同步的檔案，下一次更新幾乎必然整段消失，頂多靠運氣多撐一兩次手動備份。工程上較健康的模型是：訂閱檔唯讀，您的差異化以覆寫層表達，讓「下載」與「客製」兩條線互不踩腳。
這與「用 Subconverter 先把訂閱轉成單一 YAML」不同：Subconverter 偏向離線或半自動產物，而 mixin／profile 覆寫偏向執行期合併。若您還在找「只有連結、沒規則」的起點，可先讀 Subconverter 轉 Clash 並匯入 Meta；本篇則假設您已能穩定載入訂閱，接下來要處理的是長期維護時的覆寫策略。
觀念釐清：profile、mixin 與「合併後設定」
不同圖形介面對同一概念有不同叫法：有的叫 Profile、有的叫 Merge／覆寫、有的把檔案放在獨立目錄。對 Mihomo（Clash Meta） 核心而言，重點是載入流程末端會得到一份已合併的完整設定樹，其中包含 port、dns、proxies、proxy-groups、rules、rule-providers 等鍵。您可以把遠端訂閱視為基底層，把 mixin 視為覆蓋與補強層：基底負責節點與機場預設分流，覆寫層負責您個人的去廣告、直連、以及策略組命名習慣。
記一個心智模型
訂閱更新只應改變「機場想給您的節點與其預設規則」；您想永久保留的段落，應放在核心會再次合併進來的 mixin／覆寫檔，而不是訂閱快取本體。
合併順序與規則陣列
對於一般鍵值型欄位（例如開關類選項），覆寫層常採深層合併：同名鍵由後載入者取代。對於規則陣列 rules:，實際行為會依核心版本與客戶端包裝方式略有差異：有的介面提供「規則前置／後置」兩欄，把您的清單拆成永遠先匹配或永遠殿後；有的則把 mixin 裡的 rules 與訂閱規則做串接。實務上請以合併後完整 YAML（若客戶端有預覽或匯出）為準，並用連線日誌確認命中順序。
分流邏輯永遠記得：規則由上而下匹配，先命中先贏。因此若您希望「去廣告／國內直連」不被訂閱裡較寬鬆的規則蓋掉，通常要把這類條目放在清單前段；若您希望保留機場對特定域名的特殊處理，再視情況調整插入點。這比盲目複製整份機場規則更容易維護。
mixin 覆寫 YAML 該怎麼寫（示意）
以下為結構示意，欄位名稱請對照您實際使用的核心版本與客戶端文件。重點是：把會長期維護的內容放在 mixin，讓訂閱檔維持乾淨。
# mixin fragment — merged on top of subscription profile at runtime
# Replace group names with your real policy group tags.
rule-providers:
reject-ads:
type: http
behavior: classical
url: "https://example.com/rules/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
rules:
- RULE-SET,reject-ads,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,cn,DIRECT,no-resolve
# subscription rules follow after merge — verify final order in UI
若您大量使用 rule-providers，下載路徑與更新週期往往是除錯熱點，可搭配 rule-providers 下載與 path 專文 一併校準。若 mixin 內新增的策略組名稱必須與 rules 中引用的一致，否則載入階段會直接報錯。
同名鍵會互相覆蓋
若 mixin 與訂閱都定義了同一個 proxy-groups 條目名稱，最終保留哪一方，取決於合併策略。建議不要在 mixin 裡重複定義機場已管理的同名策略組，改以新名稱擴充，或在規則層引用既有名稱，以降低衝突。
圖形客戶端要對到哪個選單
純命令列部署可參考 Linux 無頭環境的 Meta 與 systemd 一文 的「設定檔分層」思維。桌面端常見流程是：
- 在訂閱分頁只負責 URL 與更新週期，不在此處長期手改正文。
- 在「覆寫／Merge／mixin」類分頁建立片段，內容為合法 YAML 片段，儲存後由程式在啟動或重載時合併。
- 若介面提供「訂閱編輯器」與「覆寫檔」兩個入口，請習慣把穩定需求放在後者。
Windows 與 macOS 首次安裝與權限路徑可對照 Clash for Windows 教學 與 Clash Verge Rev macOS；本篇不重複按鈕截圖級教學，但合併觀念可跨客戶端沿用。
常見客製場景怎麼落在覆寫層
| 需求 | 建議放進 mixin 的內容 | 注意 |
|---|---|---|
| 去廣告／追蹤封鎖 | rule-providers 指向公開規則集，再在 rules 前置 RULE-SET |
過激清單可能誤傷影音或登入流程，需逐步放寬 |
| 國內網站直連 | GEOSITE,cn／GEOIP,cn 置於個人化區塊前段 |
與 DNS 假 IP 模式連動，異常時先查 DNS 專文 |
| 自訂策略組 | 在 mixin 新增 proxy-groups，並讓規則引用新名稱 |
節點引用須與訂閱產生的 proxies 名稱一致 |
| 微調 DNS／嗅探 | 在 mixin 覆寫 dns 或 sniffer 子鍵 |
大改前先備份，避免與機場預設互相打架 |
訂閱更新後的驗證步驟（建議養成習慣）
每次更新訂閱後跑這四步
- 在客戶端檢視「合併後／生效中」YAML，確認您的 mixin 段落仍存在。
- 搜尋
rules:區塊，確認自訂規則列仍在預期相對位置（通常靠前）。 - 開啟連線或日誌面板，造訪一個應被
REJECT或DIRECT的測試目標，確認命中策略符合預期。 - 若使用
url-test／fallback等進階策略組，可再對照 url-test 與 fallback 專文 檢查健康檢查 URL 是否仍合理。
若合併後載入失敗，多半是 YAML 語法、重複鍵、或規則引用到不存在的策略組名稱。此時應先還原最近一次可用的 mixin，再分段加回差異，避免一次塞入過多未驗證片段。
常見問題
mixin 會不會把訂閱節點弄丟？
正常情況下不會：訂閱仍負責提供 proxies 本體，mixin 只補額外欄位或規則。若您誤在覆寫層寫了與訂閱衝突的同名結構，才可能出現「覆蓋」而非「追加」的意外。這也是為什麼建議新增名稱勝過硬改機場同名條目。
為什麼我的去廣告規則不生效？
優先檢查規則順序：較寬鬆的 MATCH 或機場內建域名規則若排在前面，會先攔走流量。其次檢查 rule-providers 是否成功下載（快取路徑、權限、更新失敗）。
我可以在訂閱編輯器裡改嗎？
短期測試可以，長期維護不建議。任何寫進「會被 URL 更新覆蓋的檔案」的內容，遲早會與 mixin 方案重複且互相矛盾。把客製化收斂到單一覆寫來源，日後除錯較省時間。
結語
Clash Meta 的強項在於設定可讀、可層疊：當您把「機場維護的訂閱」與「自己維護的 mixin」拆清楚，就不必在每次更新後重寫去廣告或直連段落。先把合併後 YAML看清楚，再用日誌驗證命中，就能把「怕沖掉」的焦慮轉成可重複的流程。