Clash YAML 設定欄位參考

YAML 結構總覽

設定檔描述的是一套連線處理流程，不是可以任意拼湊的參數清單。通用欄位決定監聽方式，DNS 負責網域解析，代理節點提供實際出口，策略組管理出口選擇，規則則將連線導向相應策略。閱讀檔案時，先辨認這些頂層區塊，再追蹤名稱引用。即使檔案可以解析，只要規則引用的組名不存在，或策略組引用了錯誤的節點名稱，仍可能在載入或連線時失敗。

映射、清單與縮排

YAML 映射以鍵和值表示，清單項目以連字號開頭，層級則用空格縮排。建議統一使用兩個空格，不要混用定位字元。冒號後留一個空格，同一層的欄位保持對齊。以下設定只使用內建直連策略，可用來了解頂層結構，但不會建立遠端代理出口；適合確認設定能否成功載入，不能當成已包含節點的訂閱檔。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選擇

這裡的 proxies: [] 表示空清單，並非欄位不存在，也不是空字串。proxy-groups 是一份清單，每個項目本身又是映射；組內的 proxies 則是名稱清單。頂層節點定義與組內名稱引用雖然使用相同欄位名稱，意義卻不同。修改時要同時確認欄位所在層級，不能只搜尋某個字詞後批次取代。

包含井字號、冒號或特殊字元的文字適合加上引號，特別是密碼、訂閱網址和看起來像數字的識別碼。未加引號的井字號在特定位置會開始註解；雙引號使用不當，也可能觸發反斜線跳脫。一般文字可用單引號；若文字本身含有單引號，須依 YAML 規則連續寫兩個單引號。布林值使用 true 或 false，連接埠填整數，不要把所有值都一律改成字串。

檔案、設定檔與執行設定

圖形用戶端中的設定檔通常只是輸入資料。用戶端也可能另外加入監聽連接埠、控制介面、TUN 參數及使用者覆寫，最後才產生交給核心使用的執行設定。因此，訂閱原始內容與實際執行檔案有所差異，不一定代表匯入失敗。排查欄位未生效的原因時，先確認目前啟用哪個設定檔，再查看用戶端提供的執行設定預覽或相關記錄。

同一映射層級不應重複定義相同的鍵。例如先寫一段 dns，再於檔案末尾寫另一段 dns，並不能可靠地表示追加設定。不同解析器可能拒絕重複鍵，也可能只保留其中一段。將需要的子欄位整理到同一個映射中，才能清楚表達設定意圖。清單追加及映射遞迴合併屬於用戶端或指令碼的行為，並非 YAML 格式本身提供的統一功能。

儲存檔案時請使用 UTF-8 編碼，並保留一份可正常啟動的副本。發生錯誤後，先還原副本，再縮小修改範圍，比反覆重新安裝用戶端更容易找出原因。支援命令列測試的環境，可使用以下命令檢查設定；執行檔的實際位置與設定檔路徑須對應本機目錄。測試通過代表核心可接受該設定，不代表遠端節點、DNS 或網路權限一定可用。

mihomo -t -f ./config.yaml

原版 Clash、mihomo 與不同圖形用戶端之間，欄位支援情況可能不同。複製範例前，請先確認用戶端實際使用的核心，不要只憑應用程式名稱推斷。若想了解圖形介面與核心的分工，可參閱Clash 開源生態與用戶端關係；本手冊則以欄位間的依賴關係作為查閱主線。

通用欄位與流量接管方式

通用欄位決定流量如何進入核心，以及核心如何處理這些連線。監聽連接埠、系統代理與 TUN 是彼此相關但不同的概念：連接埠是核心提供的本機入口；系統代理是作業系統提供給應用程式的入口設定；TUN 則透過虛擬網路介面接收符合路由條件的封包。只設定監聽連接埠，不代表系統已將應用程式流量導向該連接埠。

監聽連接埠與存取範圍

連接埠號碼並非固定值，範例數字只是常見設定。若本機已有其他程序使用相同連接埠，核心可能無法監聽。處理時先查看記錄中的位址與連接埠，再修改衝突項目；若由用戶端設定系統代理，也要確認系統代理已同步使用新連接埠。只修改訂閱檔中的數字，卻讓用戶端繼續指向舊入口，就可能發生核心正常執行、瀏覽器卻無法連線的情況。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

監聽位址會決定服務綁定在哪個本機介面。若只供本機使用，入口可限制在回送位址範圍；若要與區域網路裝置共用，則須評估監聽位址、區域網路存取設定及防火牆規則。控制介面是用來管理核心，不是瀏覽器應填寫的代理連接埠。將管理介面開放給其他裝置前，必須設定存取憑證並限制網路範圍，不能因為它和代理入口都使用連接埠就混為一談。

規則、全域與直連模式

rule 模式依照規則清單決定策略；global 模式將連線交給全域策略；direct 模式則以直連方式處理流量。選擇模式不能取代節點連線檢查；全域模式也不代表所有應用程式都已接管。如果某個應用程式沒有使用系統代理，切換全域模式通常不會改變它的流量入口，應先確認接管路徑，再判斷分流結果。

TUN 模式與平台權限

TUN 適合處理不讀取系統代理設定的應用程式，但會涉及虛擬介面、系統路由及執行權限。不同用戶端可能透過服務程序、系統管理員授權或平台提供的網路延伸功能建立介面，不能將某個平台的權限步驟直接套用到其他平台。以下列出常見 mihomo 欄位關係；若圖形用戶端已管理這些欄位，應優先透過對應設定頁操作，避免產生設定時互相覆蓋。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route 用於自動設定相關路由，auto-detect-interface 用於偵測出口介面，dns-hijack 則參與接收符合條件的 DNS 要求。這些選項無法保證適用於所有網路環境：其他 VPN、虛擬機網卡、企業網路軟體或手動設定的路由，都可能改變流量路徑。啟用後若無法存取區域網路資源，應檢查路由與排除範圍，不宜關閉所有 DNS 設定來掩蓋問題。

系統代理與 TUN 可以同時使用，但排錯時建議先保留一種明確的流量接管方式。先確認瀏覽器可透過本機入口建立連線，再啟用 TUN 測試其他應用程式；若啟用後才出現故障，就著重檢查權限、介面與路由變化。還原設定前應記下目前的開關狀態，特別是系統代理是否由用戶端自動還原，避免退出應用程式後，系統仍指向已停止監聽的連接埠。

Windows 應用程式容器存取、Android VPN 授權及桌面版背景服務，都是平台流量接管層面的問題，與 YAML 語法錯誤不同。平台操作請以快速入門為起點，遇到異常可再查閱說明中心。選擇用戶端時，可先查看下載中心的 Clash Plus 平台選項，再確認需要的流量接管功能。

DNS 解析

DNS 設定需要釐清三件事：誰向核心提出解析要求、核心向哪個上游查詢，以及查詢本身經由哪條網路路徑送出。只修改一組 DNS 位址，無法自動管控瀏覽器內建的加密 DNS、系統快取及其他網路服務。分析 DNS 洩漏時，須先界定哪些要求原本應由核心處理，再依據接管方式與記錄進行驗證，不能只憑單一檢測頁面顯示的地區下結論。

監聽、上游與引導解析

enable 用來控制核心的 DNS 模組，listen 指定監聽位址，nameserver 則指定一般查詢使用的上游。如果上游位址本身是網域名稱，核心必須先取得該網域的 IP 位址，可透過 default-nameserver 進行引導解析。引導解析器必須能在目前網路中實際連線，否則可能在連上加密上游之前就陷入循環依賴。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://cloudflare-dns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - localhost

範例展示欄位結構，不代表所列的公共 DNS 服務適用於所有網路。連接埠 1053 也不會自動成為系統 DNS，仍須透過用戶端的 DNS 接管設定或其他明確的轉送機制。若桌面環境不允許系統解析器指定非標準連接埠，就不能直接把此監聽位址複製到系統設定。是否實際收到查詢，應透過核心記錄與應用程式的連線結果確認。

fake-ip 與真實位址回應

fake-ip 模式會回傳映射位址給應用程式，核心則保留位址與網域之間的對應關係，待後續連線進入核心後，再依此比對網域規則。這項功能是為了保留分流所需的網域資訊，不是把目標伺服器真的改成映射網段。若應用程式取得映射位址後繞過核心直接連線，便可能無法存取；因此須一併檢查 DNS 回應路徑與連線接管路徑。

fake-ip-filter 可讓部分網域不使用映射位址。區域網路服務、需要真實位址的裝置探索流程，或有相容性問題的應用程式，可能需要針對性地加入過濾。不要為了處理單一網域就將範圍擴大到所有網域，否則會改變其他規則取得網域資訊的條件。加入過濾後，也應清除相關快取或重新啟動受影響的應用程式，避免新舊回應同時存在。

使用真實位址回應時，應用程式會收到實際 IP；網域規則能否生效，仍取決於核心掌握的資訊與連線入口。IP 規則可能觸發額外解析，網域嗅探也不保證能從所有協定中還原名稱。因此，比較兩種模式時，應觀察實際命中的規則、目標應用程式的行為及記錄，不宜一概認定某種模式永遠較快、另一種永遠較安全。

依網域選擇上游與查詢路徑

nameserver-policy 可為特定網域指定上游，例如將內部網域交給所屬網路的解析器處理。這項設定負責選擇 DNS 伺服器，不等於指定最終業務連線的代理出口。業務流量仍由規則與策略組處理。若使用 respect-rules 讓 DNS 連線遵循規則，也須考量代理伺服器網域的解析來源，避免解析代理所需的要求又依賴尚未可用的代理。

dns:
  enable: true
  nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - 192.168.1.1

此處的區域網路位址只表示「交由目前網路中的解析器處理」，必須替換成實際可用的位址。企業內部網域若誤送至公共 DNS，可能查不到紀錄；反過來，所有外部網域都交給內部解析器，也可能受該網路的政策影響。使用網域後綴策略時須留意比對範圍，先用一個明確的測試網域確認行為，再逐步擴大。

排錯可先比對網域與 IP：若同一目標的 IP 可連線、網域卻無法存取，優先查看 DNS 記錄；只有特定應用程式異常，則檢查其獨立的解析設定；節點網域無法解析，先修復引導及節點解析路徑。修改後以新連線重試，必要時清除系統與應用程式快取。更完整的順序請參閱節點逾時與連線失敗排查。

代理節點欄位

代理節點定義連線至遠端服務所需的協定參數。節點名稱、地區標籤與測速結果都不等同於節點設定：名稱只供引用與識別，真正決定連線行為的是協定、位址、連接埠、驗證資訊及傳輸設定。填寫前應取得服務端提供的完整參數，不能只憑伺服器位址推斷協定，也不要將其他用戶端的欄位名稱直接搬到 YAML，並假設其意義相同。

通用欄位與協定專屬欄位

常見通用欄位包括 name、type、server 與 port。name 必須與策略組中的引用完全一致，建議使用唯一且容易辨識的名稱；type 決定後續哪些欄位有效；server 可以是網域或 IP；port 是遠端服務入口，不是本機監聽連接埠。若混淆兩種連接埠，記錄會顯示連線失敗，而非 YAML 解析錯誤。

proxies:
  - name: SS 範例
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: 'your-password'
    udp: true

此片段展示 Shadowsocks 節點的欄位結構，範例網域與密碼無法用於實際連線。cipher 與密碼必須和服務端設定一致，不能為了「提高安全性」而單方面更改演算法名稱。連接埠使用 443 也不代表自動採用 HTTPS 或 TLS；協定是否包含加密與偽裝，須依具體協定及其傳輸欄位判斷，不能只看連接埠數字。

TLS、SNI 與傳輸參數

使用 TLS 的協定還須確認伺服器名稱與憑證是否相符。連線位址、TLS 的 SNI、WebSocket 的 Host 及路徑可能各有不同用途；即使服務端部署時剛好使用相同網域，也不代表這些欄位可以互相取代。部分協定使用 servername，其他協定可能採用不同欄位；應以各協定的設定結構為準，避免建立一份看似通用、實際卻無法辨識的參數表。

proxies:
  - name: Trojan 範例
    type: trojan
    server: proxy.example.com
    port: 443
    password: 'your-password'
    sni: proxy.example.com
    skip-cert-verify: false
    udp: true

遇到憑證錯誤，應先檢查系統時間、網域、憑證鏈與服務端設定，而不是直接略過驗證。關閉驗證會改變連線的身分驗證條件，無法修正填錯的 SNI。若服務提供者要求特殊憑證或專用傳輸參數，請確認說明來源，並依照對應協定設定。協定專屬欄位繁多，本手冊提供的是核對方法，不會將不同協定的所有參數塞進同一個範例。

節點定義與實際連線能力

udp: true 只表示設定允許使用相應功能，不會讓原本不支援 UDP 的服務端突然具備此能力。應用程式也可能受系統代理類型、TUN 接管、電信網路與防火牆限制。若網頁可用，但語音或遊戲異常，應分別驗證 TCP 與 UDP 路徑；單次 HTTP 測試成功，不代表所有傳輸類型都已具備連線條件。

節點加入檔案後，還須由策略組或規則實際引用。只在 proxies 下新增項目，不代表目前出口會自動切換過去。檢查連線頁時，應同時查看命中的規則、經過的策略組及最終節點；若規則仍選擇直連，就不必先懷疑新節點的密碼。反過來，若策略已指向節點但交握失敗，才進一步核對位址、驗證資訊與協定參數。

訂閱通常包含存取憑證，截圖和記錄也可能顯示完整節點位址。分享排錯資訊時，只保留必要欄位，並遮蔽密碼及訂閱網址中的敏感內容。比較原始連結、YAML 與其他設定格式時，應逐項確認協定是否完整保留，不能把「轉換成功」等同於所有功能都已保留。相關差異請參閱訂閱格式比較與轉換。

策略組

策略組位於規則與節點之間。規則通常不必直接指定某個遠端節點，而是指向用途固定的組名，再由策略組決定採用哪個出口。如此一來，更換訂閱或切換節點時，規則本身可以維持不變。設計策略組時，應先釐清選擇邏輯與引用關係，而非一開始就堆疊大量以地區命名的層級；每增加一層巢狀結構，都應能說明它解決了什麼選擇問題。

手動選擇、自動測試與故障轉移

select 提供手動選擇，適合作為面向使用者的總入口；url-test 依據指定目標的測試結果選擇出口；fallback 按候選順序選擇可用項目；load-balance 則依設定的策略分配連線。這些功能的目標各不相同。測試耗時較短，不一定代表更適合特定服務；故障轉移也不等於將多個節點的頻寬合併使用。

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT

  - name: 自動選擇
    type: url-test
    use:
      - 主要訂閱
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

此片段會引用後文定義的 主要訂閱 provider。use 用來引用遠端節點集合，proxies 則引用具體節點、內建策略或其他策略組；不能只因為兩者都顯示名稱，就把它們當成相同欄位。編排設定檔時，可依閱讀習慣安排頂層區塊，但所有引用都必須存在於最終設定中，名稱的空格、符號與大小寫也要一致。

url 是測試目標，interval 是檢查間隔，tolerance 則可用來減少因細微測試差異造成的頻繁切換。範例數值只用於說明參數單位與關係。若目標在目前網路或部分節點上受到限制，測試結果主要反映的可能是目標能否存取，而非節點整體品質。不要因為單一測試網站無法連線，就直接認定服務端完全無法使用。

候選範圍與名稱穩定性

訂閱節點數量較多時，可使用受支援的篩選欄位限制候選範圍。篩選通常依名稱比對，會受到訂閱提供者的命名方式影響；當地區文字、符號或標籤改變時，原有運算式可能找不到任何節點。調整篩選後，應確認策略組的實際成員，而不只是檢查 YAML 是否通過測試。使用正規表示式時，也須同時考量 YAML 引號與運算式本身的跳脫規則。

同一份設定中，不宜讓用途不同的組或節點使用相同名稱。若要讓規則長期穩定，可為業務組採用明確名稱，例如「工作服務」或「媒體服務」，再由下層出口組負責選擇實際節點。這樣變更節點來源時，不必重寫大量規則。但若所有業務最後都走相同出口，通常保留一個入口組就足夠，不必為了視覺分類而增加重複結構。

巢狀結構、快取與切換驗證

策略組可以引用其他組，但不能形成循環，例如甲組引用乙組，乙組又回頭引用甲組。遇到複雜引用時，應從規則目標開始，逐層畫出實際出口路徑，直到抵達節點或內建策略。若某一層最後又回到已經經過的組，就需要重新拆分。等核心報錯才發現循環不利於維護，尤其多個覆寫檔分別加入組成員時更容易遺漏。

用戶端可能會記住手動選擇，設定也可透過 profile.store-selected 儲存相關狀態。不過，儲存狀態不代表更名後仍能正確還原：舊名稱消失時，用戶端或核心可能會改選預設候選項。訂閱更新後，應檢查目前選項是否仍指向預期出口；特別是使用獨立組處理固定業務的設定，避免誤把選擇變動當成規則順序異常。

切換策略主要影響新建立的連線，已建立的長連線可能繼續使用原出口。驗證時應重新整理應用程式工作階段或重新建立連線，再查看連線頁的實際路徑。若需要關閉舊連線，應先評估對下載、會議或其他持續作業的影響。介面按鈕的位置可參閱用戶端代理頁、設定頁與連線頁說明。

規則語法

規則的核心原則是由上而下比對，第一條命中的規則決定處理策略。維護規則時，順序通常比數量更重要：精確例外應排在寬泛規則之前，最終兜底則放在末尾。規則目標可以是策略組、節點或內建策略，但必須在目前的執行設定中有效。即使某條規則本身正確，只要一直被前面的寬泛規則攔截，仍無法達到預期效果。

網域、位址與兜底規則

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出口選擇
  - DOMAIN-KEYWORD,example,出口選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,出口選擇

DOMAIN 比對完整網域，適合單獨處理某一主機；DOMAIN-SUFFIX 比對指定網域及其子網域；DOMAIN-KEYWORD 則依網域中的關鍵字比對，範圍較廣，應謹慎使用。範例先讓登入網域直連，再處理整個網域後綴。若把後綴規則排在前面，登入網域就不會再比對後面的精確例外。

IP-CIDR 依目標位址所在網段比對，常用於區域網路位址與固定服務位址。no-resolve 表示這條規則不會為了比對而主動觸發網域解析，不代表全域停用 DNS，也不代表已有目標 IP 時會略過比對。它適合減少不必要的解析；但若設定需要先經網域解析才能命中某個位址規則，就須了解由此造成的比對限制。

MATCH 是最終兜底，會接收前面都未命中的連線。若將它放在清單最前面，多數後續規則就沒有比對機會。兜底選擇應清楚表達預設路徑，而不是將「未分類」視為錯誤。維護時可先使用少量可驗證的規則及一條兜底，確認比對結果後再加入大型規則集，避免同時排查入口、DNS、節點與規則四個變數。

程序規則與平台差異

程序類規則可依應用程式區分流量，但前提是目前平台、權限與流量接管路徑允許核心取得程序資訊。透過其他裝置轉送進來的連線，不一定能對應到遠端裝置上的應用程式程序；部分平台的網路介面也不會提供相同資訊。因此，在另一台電腦上有效的程序規則，不能直接視為適用於手機或路由器的通用規則。

網域規則也有資訊方面的條件。應用程式若直接連線至 IP、使用自己的解析流程，或透過特定轉送方式進入核心，連線記錄可能不會包含預期網域。此時反覆新增網域後綴規則未必有效，應先檢查 DNS 接管與連線中繼資料。嗅探在部分情況下可補上名稱，但會受協定及加密方式限制，不宜取代明確的解析與路由設計。

規則提供者與實際比對結果

RULE-SET 引用的是 rule-providers 中定義的規則集合，可用於網域集合、位址集合或傳統規則集合，但資源格式必須與提供者的行為類型相符。若把完整設定檔當成網域清單載入，或把包含策略目標的規則逐行放進只接受網域的資源，都會造成格式錯誤。資源定義與載入方式請見下一章。

排查錯誤分流時，先選一個穩定且明確的目標，建立新連線後查看命中的規則名稱與策略路徑。若目標命中不該套用的前置規則，應縮小該規則範圍或調整順序；若已命中正確規則但仍無法存取，再檢查最終節點與解析結果。這樣可以區分「選錯出口」和「出口無法使用」，避免把節點問題歸咎於規則語法。

大型規則集會隨上游更新而變動，維護時應保留少量本機例外，並明確標示插入位置。不要在遠端規則資源中臨時手動修改，期待更新後仍保留變更。需要長期固定的規則，應放入獨立覆寫或本機資源，並在訂閱更新後重新確認最終順序。關於模式與規則的常見疑問，可繼續查閱說明中心。

訂閱與遠端資源

訂閱不一定都是相同格式的檔案。有些網址會回傳完整 Clash 設定，有些只提供節點集合，另一些則是編碼後的節點分享連結文字。圖形用戶端可能提供訂閱轉換或預處理功能，但核心的 proxy-providers 不會自動將所有格式辨識為可用節點。設定前應先確認回應內容的結構，再決定由用戶端匯入完整設定，或由核心載入為遠端節點資源。

節點提供者

proxy-providers:
  主要訂閱:
    type: http
    url: 'https://subscription.example.com/nodes.yaml'
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 出口選擇
    type: select
    use:
      - 主要訂閱

rules:
  - MATCH,出口選擇

type: http 表示從遠端網址取得資源，url 是資源網址，path 是本機快取位置，interval 是更新間隔。範例網址僅供教學，必須替換成實際回傳相容節點集合的訂閱網址。快取路徑通常與核心工作目錄有關，不一定相對於訂閱檔所在位置；桌面版與手機版用戶端可寫入的目錄也可能不同。

節點提供者的資源通常包含頂層 proxies 清單，而非完整的連接埠、DNS 與規則設定。以下展示資源檔的結構，參數仍為無法實際連線的教學資料。若訂閱回傳的是網頁、登入提示或錯誤訊息，即使 HTTP 要求成功，也不會取得可用節點；應透過用戶端記錄確認回應內容類型與解析錯誤。

proxies:
  - name: 訂閱範例節點
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: 'your-password'
    udp: true

更新間隔與健康檢查間隔是兩種不同機制。前者用來取得節點設定的變更，後者則測試既有節點是否可用；縮短健康檢查間隔，不會讓新節點更早出現在訂閱中。節點數量較多時，頻繁測試也會增加網路要求。設定時應考量資源變動頻率、裝置電量與實際選擇需求，不要一味將所有間隔都調得很短。

規則提供者

rule-providers:
  業務網域:
    type: http
    behavior: domain
    format: yaml
    url: 'https://rules.example.com/business.yaml'
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,業務網域,出口選擇
  - MATCH,DIRECT

behavior 決定如何解讀規則資源，常見的 domain、ipcidr 與 classical 分別對應不同內容。format 決定檔案格式，不能只依副檔名猜測。網域類型的 YAML 資源通常以 payload 包含項目；傳統規則資源可表達更多規則類型，但同樣須遵守對應格式，不能混入完整設定檔的頂層欄位。

payload:
  - '+.example.com'
  - api.example.net

資源名稱與快取路徑應各自唯一。兩個提供者共用同一個本機檔案，可能造成後續更新覆蓋前一份內容，出現資源看似載入成功、實際規則卻不屬於目前集合的情況。變更資源類型或格式後，也要留意舊快取是否仍在使用。不要直接清除整個用戶端資料目錄；先依據記錄找出特定快取檔，並保留可還原的副本。

更新失敗、引導依賴與隱私

遠端資源更新失敗時，核心可能繼續使用現有快取，也可能因首次執行時沒有可用檔案而無法載入，實際情況須以記錄為準。若取得訂閱必須經過某個代理，而該代理又只能從這份訂閱取得，就會形成啟動依賴。解決方法是提供可連線的更新路徑或獨立的引導出口，而不是反覆按下更新，期待尚未取得的節點能完成下載。

訂閱網址通常包含存取憑證，不應放進公開儲存庫或公開轉換服務。需要轉換格式時，先了解轉換服務能讀取哪些內容，再確認輸出是否保留協定、傳輸設定與分組資訊。多裝置同步也要區分「同步同一個訂閱網址」與「同步完整執行設定」：後者可能帶入不適用於其他平台的監聽、路由與路徑設定。

跨裝置使用時，較穩妥的方式是共用節點來源與業務規則，平台相關設定則留給各自的用戶端處理。關於私有儲存庫、訂閱網址與覆寫檔的搭配方式，可參閱電腦與手機共用設定的取捨；實際資源合併順序仍須依照下一章的方法檢查最終執行結果。

覆寫、合併與驗證

覆寫可將需長期保留的本機設定意圖，與定期更新的訂閱內容分開。例如訂閱負責提供節點與基本策略，本機覆寫則負責區域網路例外、業務規則或平台流量接管參數。這不是 YAML 統一規定的通用頂層欄位，而是用戶端產生設定時執行的處理流程。不同用戶端中名稱相同的「合併」、「覆寫」或「指令碼」功能，可能在執行階段與清單處理方式上各有不同。

先確認合併規則

映射合併與清單合併必須分開理解。純量欄位通常會由後寫入的值取代；巢狀映射可能遞迴合併，也可能整體取代；清單則可能追加、前置或直接取代。不能因為某個用戶端保留了原有 DNS 子欄位，就推斷它也會保留原有規則清單。操作前應查看用戶端提供的說明與預覽，依最終結果而非功能名稱判斷行為。

# 基本設定片段
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://cloudflare-dns.com/dns-query

# 想加入的欄位片段
# 請使用用戶端支援的合併方式處理，不要直接重複貼上 dns 鍵。
# dns:
#   fake-ip-filter:
#     - '*.lan'

若用戶端會整體取代 dns，只提交 fake-ip-filter 就可能讓原有上游設定消失；若採遞迴合併，清單是否保留仍取決於實際實作。穩妥的做法是先測試一個風險較低的欄位，查看執行設定中的完整 DNS 區塊，再套用真正需要的變更。測試期間，請分別保留基本設定與覆寫檔的副本。

規則前置與名稱遷移

本機規則通常須插入遠端規則之前，特別是訂閱已包含兜底規則時。若用戶端只將本機清單追加至末尾，新規則就會排在 MATCH 之後；語法雖然正確，卻不會命中。應明確使用用戶端支援的前置操作，或透過指令碼控制插入位置。修改後應直接檢查最終規則清單的開頭與結尾，而不只是查看覆寫編輯器中的內容。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出口選擇
  - MATCH,出口選擇

以上只表示期望的最終順序，不是通用於所有用戶端的覆寫指令。若本機規則引用「出口選擇」，訂閱更新後該組被更名或刪除，仍會造成引用失效。可由本機維護穩定的組名，再連接訂閱提供的節點集合；也可在更新後核對引用關係。不要因為介面曾顯示過該名稱，就認定它仍存在於目前的執行設定中。

最小幅度變更與分層驗證

建議每次只調整一個層面：先確認檔案可解析，再檢查名稱引用，接著確認監聽與流量接管，最後驗證業務分流。若同時變更 DNS、TUN、節點協定與規則順序，即使問題暫時消失，也無法判斷是哪個變更生效。記錄每次變更的目的、修改欄位與測試目標，可減少日後訂閱更新時重複排查的時間。

1. 儲存目前可用的設定，記下啟用中的設定檔與主要開關。
2. 檢查 YAML 縮排、重複鍵、資料型別與名稱引用。
3. 查看產生後的執行設定，確認本機欄位未被覆蓋。
4. 建立新的測試連線，檢查規則、策略組與最終節點。
5. 更新訂閱並重新載入，確認本機設定仍依預期保留。

驗證時至少應涵蓋一條直連路徑與一條代理路徑。若只測試某個網頁能否開啟，可能會漏掉所有流量都被錯誤地直連或代理的情況。調整 DNS 時，還須確認網域解析與連線是否一致；調整 TUN 時，則要檢查區域網路、其他 VPN，以及裝置從休眠恢復後的行為。設定測試命令可檢查語法及部分語意，實際網路驗證仍須另外進行。

在不同平台之間移轉設定時，應移除本機檔案路徑、網卡名稱、控制連接埠及平台專屬的流量接管參數。共用的重點應是節點來源與分流意圖，而不是把一台裝置的所有執行細節複製到另一台裝置。使用 Clash Plus 等圖形用戶端時，可先透過下載中心選擇對應平台，建立基本環境後再依需求移轉設定，避免同時遇到安裝與欄位相容性問題。

最終要維護的是一套關係清楚、便於說明的設定：每項遠端資源都有明確來源，每個組名都有穩定用途，每條例外都有對應的測試目標，每次合併都能檢視結果。初次使用可返回快速入門完成連線流程；若已確認設定可載入但仍有異常，請前往說明中心或連線失敗排查文章，依序檢查入口、解析、規則與出口。