Clash配置檔案怎麼合併？訂閱覆寫與多訂閱節點教學
簡答：Clash配置檔案不要直接拼接：訂閱加本地設定用擴充設定，多個訂閱節點用 proxy-providers；再核對規則順序、策略組引用與客戶端支援。
定義：Clash配置檔案合併，是把訂閱、本地覆寫或多個節點提供器，依照客戶端支援的結構組合成可驗證、可載入和可回復的執行設定。
先判斷：你要合併的是哪一種 Clash 配置檔案？
如果你正在搜尋「Clash配置檔案怎麼合併」，先不要把兩份 YAML 上下拼接。實際需求通常分為三類：訂閱更新後保留本地規則或 DNS 設定；把多個訂閱來源的節點放進同一個策略組；或者把兩份完整配置整理成一份獨立運行的檔案。
本文主要適用於：Clash Verge Rev 的擴充設定，以及採用 mihomo 內核並支援 proxy-providers 的配置。Clash for Windows、ClashX、Android 及其他客戶端，可能沒有相同的入口或欄位，不能直接照搬本文語法；請先核對目前版本是否支援擴充設定、覆寫或代理提供器。
| 你的目標 | 優先方式 | 主要檢查點 |
|---|---|---|
| 訂閱更新後保留自訂規則、節點或策略組 | Clash Verge Rev 擴充設定 | 擴充設定會在主配置上處理，部分由客戶端控制的欄位不能覆寫 |
| 多個訂閱來源共同提供節點 | mihomo proxy-providers | 策略組要用 use 引入提供器，提供器名稱和檔案路徑不能重複 |
| 兩份完整 YAML 合成一份 | 備份後手動整理 | 重複鍵、列表順序、節點名稱和引用關係都要重新檢查 |
Clash Verge Rev 官方文件將擴充配置用於覆寫或合併配置；mihomo 官方文件則將 proxy-providers 定義為代理集合來源。可先閱讀 Clash Verge Rev 擴充設定文件 和 mihomo proxy-providers 配置文件。
最快判斷：擴充設定、proxy-providers 還是手動合併？
訂閱加本地設定用擴充設定，多訂閱節點用 proxy-providers，兩份完整 YAML 才手動整理。不要為了「合併」而複製整份訂閱內容，因為訂閱更新後，直接修改下載檔案的內容可能會被新資料取代。
| 使用情境 | 操作入口 | 不建議做法 |
|---|---|---|
| 訂閱加本地規則 | 在 Clash Verge Rev 建立或編輯擴充設定，儲存後重新啟用並刷新 | 直接修改遠端訂閱下載檔案 |
| 多個訂閱節點 | 在主配置加入多個 proxy-providers，再由策略組透過 use 引入 | 把大量節點複製到 proxies |
| 兩份完整 YAML | 合併同名鍵、整理列表、檢查引用，再進行語法驗證 | 把兩份頂層 YAML 直接拼接 |
如果你只是想讓自訂規則在訂閱更新後繼續存在，先選擇擴充設定；如果只是想集中管理多個節點來源，先選擇代理提供器。只有在兩份檔案都包含完整運行配置，而且你需要脫離原訂閱獨立運行時，才考慮手動合併。
Clash Verge Rev：訂閱和本地設定怎麼合併？
Clash Verge Rev 官方文件顯示，v1.7.x 起，原本的 Merge 配置改名為「擴充配置」，Script 配置則改名為「擴充腳本」；原本的 prepend、append 功能移到訂閱右鍵選單中的可視化編輯器。v2.5.5 起，擴充配置中的 dns 和 hosts 處理方式也有變更。詳情以 Clash Verge Rev 擴充配置與腳本文件 為準。
- 先備份：複製目前可用的配置，並另外保存原始訂閱網址。
- 先測訂閱：確認訂閱本身可以更新並顯示節點；若原始訂閱已解析失敗，不要繼續疊加擴充設定。
- 建立擴充配置：在 Clash Verge Rev 的配置管理區域建立或開啟擴充配置。選單名稱和位置可能隨版本變化，需以目前版本介面為準。
- 只寫需要保留的內容：例如新增規則、調整策略組，或覆寫明確的 DNS 欄位，不要再次貼上整份訂閱。
- 重新啟用並刷新：儲存後重新啟用擴充配置，刷新主配置，再查看最終配置、節點列表和日誌。
若要在訂閱規則前方加入自訂規則，應優先使用目前客戶端提供的訂閱編輯器或擴充腳本流程，不要直接套用舊版教學中的 prepend-rules 位置。以下只示範規則字串的正確 YAML 列表形式：
rules:
- "DOMAIN-SUFFIX,example.org,DIRECT"
- "DOMAIN-SUFFIX,example.net,Proxy"
- "MATCH,DIRECT"
上例的 Proxy 只是策略組名稱示例，必須替換成主配置中實際存在的名稱。每條規則應該是一個完整字串；不要寫成 [DOMAIN-SUFFIX,example.org,Proxy]，否則 YAML 可能會將逗號分隔內容解析成多個列表元素。
擴充配置只會處理寫出的欄位，但不同欄位的合併規則並不相同。官方文件指出，列表和普通值可能整體替換；巢狀物件通常逐項合併；dns 下寫出的部分欄位和頂層 hosts 則要特別注意整體替換情況。若不確定，先保留原段落，再對照最終執行配置。
mihomo：多個訂閱節點怎麼合併？
多個訂閱節點不需要全部複製到 proxies。在支援 mihomo 的配置中，可以為每個訂閱建立一個 proxy-providers 條目，再讓策略組透過 use 引用這些提供器。mihomo 文件要求提供器名稱不能重複，HTTP 類型提供器需要填寫訂閱 URL，快取路徑也應保持唯一。可參考 mihomo 代理集合配置。
以下為結構示例，不能代表所有客戶端的最終運行結果：
proxy-providers:
provider_a:
type: http
url: "https://example.com/subscription-a"
path: ./proxy_providers/provider_a.yaml
interval: 86400
override:
additional-prefix: "[provider_a] "
provider_b:
type: http
url: "https://example.com/subscription-b"
path: ./proxy_providers/provider_b.yaml
interval: 86400
override:
additional-prefix: "[provider_b] "
proxies:
- name: "DIRECT"
type: direct
udp: true
proxy-groups:
- name: "節點選擇"
type: select
proxies:
- DIRECT
use:
- provider_a
- provider_b
rules:
- "DOMAIN-SUFFIX,example.org,節點選擇"
- "MATCH,DIRECT"
這個示例中，provider_a 和 provider_b 代表兩個訂閱來源，策略組「節點選擇」透過 use 引入它們。URL、快取路徑、策略組名稱和規則目標都需要替換；示例中的網域和訂閱網址不是可用服務地址。
additional-prefix 可為每個提供器的節點名稱加上固定前綴，方便區分來源並減少同名節點造成的排查困難。這個欄位及其支援方式可在 mihomo proxy-providers 文件中核對。
mihomo 的策略組文件說明，proxies 用於引用代理或其他策略組，use 用於引用代理集合。如果策略組只寫 proxies 而沒有 use，提供器中的節點不會自動加入該組。詳情可查看 mihomo proxy-groups 配置文件。
第一次配置建議只加入一個提供器，確認它能更新並顯示節點後，再加入第二個。若不同訂閱中有同名節點，先使用提供器前綴；其他重命名欄位則應以目前 mihomo 文件為準，未核實時不要自行添加。
兩份完整 YAML 手動合併：先分清標量、物件和列表
手動合併時，先把檔案分成「基礎配置」和「訂閱節點來源」，不要直接複製貼上。以下只示範整理邏輯，地址、節點和策略組都是佔位內容，不是任何訂閱的最終結果。
合併前：基礎配置，僅示意：
mixed-port: 7890
mode: rule
proxies:
- name: "本地直連"
type: direct
udp: true
proxy-groups:
- name: "預設選擇"
type: select
proxies:
- "本地直連"
rules:
- "DOMAIN-SUFFIX,local,DIRECT"
- "MATCH,預設選擇"
合併前：訂閱配置，僅示意：
proxies:
- name: "示例節點A"
type: http
server: example.com
port: 443
username: "user"
password: "password"
proxy-groups:
- name: "訂閱選擇"
type: select
proxies:
- "示例節點A"
rules:
- "DOMAIN-SUFFIX,example.org,訂閱選擇"
- "MATCH,DIRECT"
合併後：僅示意，不能代表所有客戶端的通用最終結果：
mixed-port: 7890
mode: rule
proxies:
- name: "本地直連"
type: direct
udp: true
- name: "示例節點A"
type: http
server: example.com
port: 443
username: "user"
password: "password"
proxy-groups:
- name: "預設選擇"
type: select
proxies:
- "本地直連"
- "示例節點A"
- name: "訂閱選擇"
type: select
proxies:
- "示例節點A"
rules:
- "DOMAIN-SUFFIX,local,DIRECT"
- "DOMAIN-SUFFIX,example.org,訂閱選擇"
- "MATCH,預設選擇"
這個對照只說明整理方式：頂層標量通常保留一個最終值；映射物件按鍵名整理；列表則要逐項確認順序、去重和引用。真實訂閱中的節點欄位、認證欄位和代理類型可能不同，不能把上述佔位節點直接用於連線。
| 欄位類型 | 手動處理方式 | 檢查內容 |
|---|---|---|
標量，例如 mode、mixed-port | 只保留一個最終值 | 確認該值由配置控制，還是由客戶端介面控制 |
映射，例如 dns、proxy-providers | 按鍵名合併或整段替換 | 同名鍵是否覆蓋，是否因此遺失原有子欄位 |
列表，例如 rules、proxies、proxy-groups | 逐項整理，必要時去重 | 節點名稱、策略組名稱和規則順序是否一致 |
DNS、規則和策略組：最容易出錯的地方
DNS 不要預設會逐欄位深度合併。如果新的 dns 物件覆蓋原配置，原本的 nameserver、fake-ip-filter 或其他設定可能不再存在。修改前先複製原段落；若決定覆蓋，就寫出確實需要保留的完整結構，再查看最終運行配置。
規則順序會影響匹配結果。規則通常按順序檢查，MATCH 常是兜底項。自訂規則放在 MATCH 之後，可能無法達到預期；策略組名稱也必須與 proxy-groups 中的實際名稱完全一致，包括空格、括號和特殊字元。
節點重名會增加排查難度。不同來源包含相同節點名稱時，列表中可能難以區分，也可能在部分處理方式下發生覆蓋或引用混淆。優先使用提供器分組和 additional-prefix，並在最終節點列表中確認名稱。
不要把「可以儲存」當成「已經生效」。至少要檢查配置是否成功載入、提供器是否更新、節點是否顯示、策略組是否出現，以及測試流量是否命中預期規則。
合併後報錯：備份、驗證、載入和回復順序
排查時一次只改一層。建議順序是：備份原檔案 → 單獨驗證訂閱 → 驗證擴充設定或提供器 → 載入主配置 → 查看日誌和運行結果 → 必要時回復。
- YAML 解析失敗：檢查 Tab、縮排、引號、冒號和重複頂層鍵；把複雜的行內寫法改成多行列表。
- 配置能開啟但規則不生效：檢查規則是否位於
MATCH之前，目標策略組是否真實存在，規則字串是否完整。 - 節點列表為空：先單獨更新訂閱或 proxy-provider，再檢查 URL、快取路徑、提供器名稱和客戶端是否支援該欄位。
- 策略組載入失敗：檢查
use中的提供器名稱是否完全一致，proxies中的節點名稱是否真實存在。 - DNS、TUN 或連接埠設定沒有變化：確認該欄位是否由客戶端自身控制；部分應用程式控制的欄位不能透過擴充設定覆寫。
- 無法判斷是哪一層出錯：停用擴充設定或移除第二個 provider，恢復最近一次可用備份，再逐項恢復改動。
如果使用 Clash Verge Rev，應依照目前官方文件核對擴充配置的執行順序和欄位合併規則；如果使用 mihomo，則應依照 proxy-providers 文件和 proxy-groups 文件確認欄位。文件沒有覆蓋的客戶端行為，應標記為「需核實」，不要直接套用其他客戶端經驗。
Clash 配置檔案合併結論
最穩妥的做法不是把兩份檔案直接拼接，而是先確認配置來源和更新關係：訂閱加本地設定用 Clash Verge Rev 擴充設定，多訂閱節點用 mihomo 的 proxy-providers，兩份完整 YAML 才進行備份後的手動整理。
完成後不要只看編輯器是否能儲存，還要檢查 YAML 結構、規則順序、節點與策略組引用、訂閱更新結果和最終運行配置。不同客戶端、內核和版本對欄位的支援可能不同，本文示例只能作為結構參考，實際入口和語法請按目前版本核對。
資料核驗日期：2026 年 11 月 2 日。
常見問題
Clash配置檔案怎麼合併才不會被訂閱更新覆蓋？
不要直接修改訂閱下載檔案。需要長期保留的規則或設定，優先放進 Clash Verge Rev 的擴充設定；儲存後重新啟用並刷新，再查看最終運行配置。具體入口和可覆寫欄位需按目前版本核對。
Clash 訂閱和本地配置可以直接拼接嗎？
不建議。兩份 YAML 可能出現重複頂層鍵，rules、proxies 和 proxy-groups 也涉及列表順序與名稱引用。應先判斷是訂閱覆寫、多訂閱節點，還是完整檔案合併，再選擇對應方式。
多個 Clash 訂閱怎麼合併節點？
在支援 mihomo 的配置中，為每個訂閱建立獨立的 proxy-provider，再讓同一個策略組透過 use 引用它們。提供器名稱、快取路徑和策略組引用必須一致；可用 additional-prefix 區分同名節點。
為什麼 Clash 配置合併後規則不生效？
先檢查規則是否位於 MATCH 之前，以及規則目標策略組是否真實存在。若使用 Clash Verge Rev，還要依目前版本核對擴充配置或訂閱編輯器的規則入口，不能直接套用舊版 Merge 教學。
DNS 配置合併後為什麼遺失原來的欄位？
因為不能假設所有客戶端都會對巢狀物件逐欄位合併。覆寫 dns 前應保留原段落，寫出需要保留的欄位，再對照最終運行配置確認。
Clash Verge Rev、Clash for Windows 和 Android 能通用這套配置嗎？
不能直接保證通用。本文主要覆蓋 Clash Verge Rev 擴充設定和 mihomo proxy-providers；其他客戶端的入口、內核和欄位支援需按目前版本核對，無法確認的部分應標記為需核實。
為什麼用了 proxy-providers 後，擴充腳本拿不到節點？
proxy-providers 的節點屬於動態載入的代理集合，不應直接假設它們已經出現在靜態 proxies 列表中。先確認提供器更新成功，再依目前客戶端和內核文件核對腳本可讀取的配置階段；未核實的腳本行為不要自行推斷。
相關閱讀
參考資料
- Clash Verge Rev：擴充配置與腳本（clashverge.dev）
- mihomo：proxy-providers 配置文件
- mihomo：proxy-groups 配置文件
- mihomo：代理節點通用欄位