config.yaml 設定參考

一、YAML 結構與設定檔範圍

映射、列表與純量

config.yaml 是描述核心執行方式的文字檔。頂層通常是映射，也就是由欄位名稱與欄位值組成的集合；dns 下方可再包含巢狀映射，rules 下方則是有順序的列表。字串、數字與布林值都屬於純量。先辨認這三種結構再修改內容，可避免把列表誤寫成字串，或將原本應位於頂層的欄位縮排到其他物件內。

YAML 以縮排表示父子關係，建議統一使用兩個空格，不要使用定位字元。同一層的欄位必須靠左對齊，列表項目的連字號後方要留空格，欄位名稱後的冒號通常也要加空格。以下範例中，mode 與 dns 位於同一層，enable 屬於 DNS 物件，nameserver 的兩個值則屬於同一個列表；空白行只影響閱讀，不會改變階層。

mixed-port: 7890
mode: rule

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

rules:
  - MATCH,DIRECT

布林開關使用 true 或 false，連接埠填寫整數，具識別用途的內容則視為字串處理。密碼、包含井字號的位址，以及含冒號的複雜文字，建議加上引號，以免字元被解析為註解或映射分隔符。單引號中的反斜線通常會原樣保留，雙引號則支援跳脫字元；從網頁複製 Windows 路徑時，尤其要留意反斜線的意義。註解從引號外符合語法的位置開始，以井字號標示。

頂層結構不等於執行順序

將 rules 放在檔案末尾只是閱讀習慣，不代表核心會先執行所有欄位再執行規則。真正具有順序語意的是規則列表，以及某些策略組中的候選項目順序。頂層鍵的排列通常不影響結果。同一個映射中不要重複定義相同名稱的鍵；不同解析器可能拒絕重複鍵，也可能保留後一項，不能依賴這種差異來可靠地覆寫設定。修改 DNS 時，應進入既有的 DNS 物件調整，而非在檔案末尾再新增第二個物件。

也要區分原始訂閱、用戶端儲存的設定，以及交由核心使用的執行時檔案。訂閱可能只有節點，也可能包含完整的策略組與規則。用戶端匯入後可能重新整理內容，並補上連接埠、控制介面或 TUN 設定。因此，編輯訂閱快取不一定會改變執行結果，重新啟動用戶端也可能覆蓋修改。排查問題時，先在用戶端找到目前設定、執行時設定或核心設定預覽，並記錄它與原始檔案的差異。

語法通過後，還要檢查引用

YAML 能夠解析，只代表縮排與資料格式大致正確，不保證目前核心支援其中的欄位。規則引用不存在的策略組、策略組引用拼錯的節點，都屬於設定語意問題。名稱通常區分大小寫，中文空格、結尾空格與全形標點也可能改變名稱。建議先列出策略組與節點名稱，再核對規則最後一段的策略目標，避免在錯誤位置反覆調整縮排。

本頁其餘章節的程式碼皆為局部範例。將片段加入現有設定時，請保留原有的同層欄位，並逐項合併列表。用戶端不一定使用名為 config.yaml 的檔案，啟動參數也可能指定其他名稱；應以目前核心實際讀取的路徑為準。若想了解原版 Clash 與 mihomo 的欄位差異，可繼續閱讀核心演進與相容性比較，不要假設同一份設定在不同核心中的結果必然相同。

二、通用欄位：連接埠、模式與存取範圍

輸入連接埠與系統代理是兩項不同設定

輸入連接埠是核心接收應用程式連線的入口。port 提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 則在同一個連接埠上同時支援 HTTP 與 SOCKS。一般桌面使用情境可先保留一個混合連接埠，減少維護多個入口的負擔。連接埠號碼只是本機設定，不存在所有用戶端都必須使用的固定值；應用程式中的代理位址必須與實際監聽位址一致。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

核心成功監聽，不代表系統代理已啟用。系統代理是由作業系統告知支援此機制的應用程式，連線到指定代理位址；設定中的輸入連接埠只負責接受連線。關閉系統代理後，手動填入代理位址的應用程式仍可能繼續使用核心；反過來說，核心已退出但系統代理未清除時，瀏覽器可能持續連線至無人監聽的連接埠。排查故障時，應分別確認執行程序、監聽連接埠與系統代理狀態，而非只看用戶端的總開關。

rule、global 與 direct 模式

rule 代表依規則順序為連線選擇策略；global 代表將進入核心的連線交由全域策略處理；direct 則代表直接連線至目標。模式決定流量進入核心後的處理方式，並不負責將所有應用程式流量送進核心。因此，全域模式不能取代 TUN，也無法強迫忽略系統代理的應用程式自動使用代理。應先處理流量接管範圍，再決定連線進入後該使用哪個出口。

規則模式通常適合作為日常使用的起點，因為可以分別設定直連與代理的比對條件。全域模式適合暫時排除規則因素，確認特定出口是否可用；直連模式則可用於對照測試，但入站與 DNS 等元件仍可能產生影響。測試結束後請恢復原有模式，並查看實際連線記錄。更多情境比較可參閱三種代理模式的選擇方式，不要只憑某個網頁能否開啟，就判定所有分流都正確。

監聽範圍與管理介面

allow-lan 與 bind-address 會共同影響其他裝置能否連線至輸入端口。只在目前電腦使用時，將存取範圍限制在迴路位址，較容易排查問題。若要分享給手機使用，除了允許區域網路連線，也要確認監聽位址涵蓋區域網路介面卡、兩台裝置的網路互通，且防火牆允許對應的輸入連線。開放監聽不等於可以安全地公開至網際網路；路由器的連接埠轉送會大幅改變存取範圍。

external-controller 是管理介面，不是瀏覽器代理連接埠。它供控制面板與用戶端管理核心使用，不能填入應用程式的 HTTP 代理設定。用戶端可能自行產生管理位址與驗證設定，手動覆寫容易導致介面無法連線。若無獨立管理需求，建議沿用用戶端設定；確有需要調整時，請先綁定本機位址，再設定驗證，並避免將含有管理憑證的執行時檔案貼到公開討論區。

發生連接埠衝突時，先退出其他代理程式，再確認舊的核心程序是否仍在執行。修改連接埠後，除了重新載入設定，也要同步更新應用程式中手動填寫的代理位址。log-level 可暫時調整為 debug，但詳細記錄可能包含目標網域與連線資訊；分享前請移除敏感內容。若要重新選擇用戶端，請前往下載頁面依平台查看；一般圖形介面使用者可先考慮 Clash Plus。

三、DNS：解析入口、上游與網域關聯

先釐清解析請求由誰發出、交給誰處理

DNS 設定至少涉及三個角色：應用程式或系統是查詢發起端，核心 DNS 模組負責接收與轉送，上游解析器則負責回傳結果。dns.enable 控制核心模組，listen 指定監聽位址，nameserver 則指定上游。只啟用模組並不代表系統已使用它；還需要透過系統 DNS 設定、用戶端接管機制或 TUN 劫持規則，將相關查詢送到這個入口。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

此範例將 DNS 服務限制在本機的非標準連接埠，以便與既有系統服務並存。這裡展示的是 DNS 模組結構，不會自動修改系統解析器。default-nameserver 主要用於解析上游 DNS 伺服器本身的網域，以建立連線至加密 DNS 所需的引導流程；它不是所有業務網域的預設出口。若上游使用網域名稱，但引導解析不可用，DNS 模組可能無法穩定啟動查詢。

fake-ip 與 redir-host 的差異

fake-ip 會為查詢指派用於映射的虛擬位址，核心在後續連線中藉此還原原始網域，再套用網域規則並選擇出口。這個位址並非目標伺服器的真實公網位址，應用程式查到它不代表解析故障。redir-host 通常會回傳實際解析結果，網域關聯方式也不同。選擇哪一種應考量應用程式相容性與流量接管路徑，而非將兩者視為速度等級或安全等級。

部分區域網路服務、裝置探索功能與依賴真實位址的應用程式，可能不適合使用虛擬位址。fake-ip-filter 可讓指定網域略過這種指派方式，但篩選只會調整 DNS 回應，不等於新增直連規則。若要透過網域存取內部網路的真實位址，也要確認上游能解析內部名稱，且後續路由可抵達該網段。排錯時建議先針對一個確定的網域新增篩選，不宜直接加入範圍過大的萬用模式。

頂層的 ipv6 與 DNS 物件中的同名欄位，作用範圍不同。前者影響核心整體使用 IPv6 的能力，後者影響 DNS 模組的 IPv6 解析行為。關閉 DNS 的 IPv6 回應，不一定能清除應用程式既有快取、內建解析器或預先儲存的位址。如果網路確實支援 IPv6，可先確認路由與出口能力，再分別啟用相關功能；不應只靠隱藏 AAAA 結果，掩蓋設定錯誤的 IPv6 路徑。

分流解析與代理伺服器解析

nameserver-policy 可為特定網域選擇解析器，適用於企業內部網域或有明確解析需求的區域；它決定要向哪個 DNS 上游查詢，不會直接決定業務連線的代理策略。proxy-server-nameserver 可專門解析代理伺服器網域，降低出口尚未建立、卻需要依賴該出口解析伺服器位址而造成循環的風險。只有確認存在循環或解析差異時，才需要增加這些設定，避免同時變更多個變數。

dns:
  nameserver-policy:
    "+.internal.example.com":
      - 192.168.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

上例中的內部網域與路由器位址僅供展示結構，請替換為實際管理的內部網域，以及確實提供解析服務的位址。排查時先確認核心是否收到查詢，再測試上游是否可連線，最後檢查回傳結果與後續連線的網域關聯。若應用程式使用自帶的加密 DNS，查詢可能會略過系統設定；瀏覽器已建立的連線也不會因修改 DNS 而立即重建。必要時請關閉舊連線、清除相關快取，再以相同目標重新測試，避免將舊結果誤認為新設定的行為。

四、代理節點：協定欄位與提供者

通用欄位與協定專屬欄位

proxies 是靜態代理節點列表，每個項目描述一個出口。常見通用欄位包括名稱 name、協定 type、伺服器 server 與連接埠 port。其他參數依協定而異，不能直接搬用其他協定的驗證欄位。節點名稱供策略組與規則引用，不負責驗證身分；伺服器欄位可以填網域或位址，但網站首頁網址或包含路徑的訂閱連結都不能取代伺服器欄位。

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

此段展示 Shadowsocks 節點的結構。伺服器網域與密碼僅為教學示例，無法直接建立有效連線；加密方式、連接埠與驗證資訊都必須與伺服器端完全一致。udp: true 代表允許使用該節點的 UDP 功能，不會讓不支援 UDP 的伺服器自動具備轉送能力。應用程式是否能使用 UDP，還取決於輸入方式、策略組、伺服器端與中間網路是否都支援。

使用 TLS 類型的連線時，必須分清傳輸目標與憑證驗證名稱。連線位址告訴用戶端要連到哪裡，伺服器名稱則用於 TLS 交握與憑證驗證；特定部署中兩者可以不同，但必須使用伺服器提供的正確參數。遇到憑證錯誤時，請檢查系統時間、伺服器名稱、憑證鏈與位址，不要直接停用驗證。略過驗證會改變安全性，也可能暫時掩蓋連線到錯誤伺服器的問題。

不要混淆節點列表與完整訂閱

proxy-providers 將節點列表放在獨立來源中，主設定則透過提供者名稱引用。這樣可將節點更新與本機規則分開管理。提供者通常讀取包含 proxies 結構的內容，不代表任何訂閱文字都能直接載入。Base64 文字、單一 URI 與完整 Clash YAML 的結構各不相同；格式不相符時，請先轉換或透過用戶端匯入，詳情可參閱訂閱連結格式與轉換方式。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

此提供者使用本機檔案，不涉及訂閱網址。相對路徑通常以核心工作目錄或用戶端指定的設定目錄為基準，不一定是目前正在編輯的檔案所在目錄。若找不到檔案，先查看啟動參數與記錄中的最終路徑，再確認檔案是否可讀。檔案內容仍須包含節點列表；不要直接複製整份主設定，期待核心能從任意階層自動擷取節點。由用戶端管理的目錄也可能受到應用程式沙箱權限限制。

遠端提供者通常使用 type: http，並設定來源網址、快取路徑與更新間隔。來源網址可能包含存取憑證，應視為敏感設定，不要放進截圖或公開儲存庫。更新失敗時，先區分是網路請求失敗、驗證失敗、內容不是 YAML，還是協定欄位不受支援。若快取仍存在，核心可能繼續使用舊節點；因此介面上仍看得到節點，不代表最近一次更新成功。

健康檢查不等於業務可用性保證

健康檢查會透過指定網址測試節點連線狀況，結果取決於測試目標、解析路徑與伺服器回應。測試通過只代表這條檢查路徑可用，不表示所有網站、UDP 應用程式或區域服務都能存取。提供者檢查與策略組檢查也不是完全相同的層級；過於頻繁地重複檢查會增加請求量。建議設定明確的測試目標與合理間隔，先驗證單一節點，再擴大到自動選擇。

節點欄位看似完整卻無法使用時，請查看交握階段的具體錯誤。網域解析失敗屬於前置網路問題，連線逾時可能與位址、連接埠或防火牆有關，驗證錯誤通常需要核對憑證資料，協定解析錯誤則應檢查類型與核心相容性。不要一次更換所有欄位。先保留原值，逐項比對服務提供者的協定參數，再用手動選擇組固定出口測試，避免自動切換掩蓋問題。

五、策略組：引用關係與選擇機制

策略組是選擇出口的層級

proxy-groups 將節點、其他策略組與內建策略整理成可供規則引用的目標。規則通常指向名稱穩定的策略組，再由策略組決定實際出口。如此一來，節點列表更新時，就不必重寫每一條業務規則。組名是設定介面的一部分；變更名稱後，必須同步修改所有引用。名稱重複或形成循環引用，會讓設定難以理解，甚至無法載入。設計時可將引用關係繪成由規則指向策略組，再指向節點的單向圖。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT
    use:
      - local-nodes

  - name: Auto
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 50

此範例依賴上一章定義的 local-nodes 提供者。proxies 用於明確列出候選名稱，use 則用來引用提供者中的節點，兩者不能互換名稱類型。Proxy 是手動選擇組，可選擇自動組、直連或提供者中的節點。Auto 不應再引用 Proxy，否則會形成循環。拼接範例時必須保留提供者定義；若只複製策略組，將會產生未定義的引用。

手動選擇、自動測速與故障切換

select 讓使用者手動指定候選項目，適合驗證單一出口與固定業務策略。url-test 依測試結果選擇候選項目，適合希望自動管理可用出口的情境。fallback 則傾向依候選順序使用可用項目，適合主用與備用關係明確的設定。這三種策略並非由低至高的進階模式；應依業務是否允許切換、是否要求出口穩定，以及能否接受測試帶來的額外連線來選擇。

自動組中的 interval 是檢查間隔，tolerance 用於減少因測試結果差異太小而頻繁切換；它不是網路延遲目標，也不是加速開關。某個節點對測試位址的連線速度較快，不代表下載檔案或觀看影片也會比較快。load-balance 分配的是連線，不會自動將一般下載連線合併成多個節點的頻寬；不同連線使用不同出口，也可能造成業務端工作階段變動。

候選項目篩選與選擇狀態

大型提供者可透過篩選條件縮小候選範圍，但篩選後必須確認仍有項目符合。正規表示式的特殊字元會與 YAML 引號規則互相影響；將節點名稱直接複製為正規表示式時，括號、加號與方括號都可能需要額外處理。先在用戶端預覽候選列表，再連線使用，比等到流量進入空策略組後才排錯更有效率。不要假設訂閱名稱永遠不變；一旦重新命名，既有篩選條件可能失效。

用戶端或 profile.store-selected 等機制可能會儲存手動組的選擇。重新載入檔案後仍保留舊選擇，不一定代表設定沒有生效，也可能只是恢復先前的執行狀態。若新增候選項目後介面沒有自動切換，請先確認目前策略組實際選擇的項目。反過來說，刪除目前節點後，核心或用戶端可能會改選其他可用候選項目，不能只憑列表中的第一項推斷最終出口。

排查策略組時，先確認規則命中了哪個組，再逐層展開該組目前選擇的下一個目標，直到看到最終節點或內建策略。若只在記錄中看到組名，卻沒有追查後續引用，容易將節點故障誤判為規則問題。建議保留一條清楚的手動測試路徑，避免多層自動組互相巢狀。若要依作業系統重新比較用戶端，可查看選型指南；不同介面的組別呈現方式，不會改變底層引用關係。

六、規則語法：比對類型、順序與規則集

由上而下檢查，首次符合即生效

rules 是有順序的列表。核心會依序檢查連線，一旦符合適用規則，就將連線交給該規則指定的策略，不會繼續尋找看起來更精確的後續規則。因此，特定業務的例外通常應放在廣泛規則之前，兜底規則則放在最後。規則排序不只是文件排版，而是實際執行邏輯；將廣泛比對項目移到最前面，可能導致後面大量規則失效。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-KEYWORD,example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

一條規則通常由類型、比對值與策略組成，並以英文逗號分隔。MATCH 不需要比對值，可直接指定最終策略。策略可以是內建的 DIRECT、REJECT，也可以是已存在的策略組或節點名稱。請勿將英文逗號換成中文逗號，也不要在策略名稱後附加說明文字。範例中的 Proxy 必須與策略組名稱完全一致，否則規則格式看似正確，仍無法建立有效引用。

網域規則與位址規則的適用範圍

DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對網域本身及其子網域，DOMAIN-KEYWORD 則依網域中出現的關鍵字比對。使用網域後綴比對，比任意使用關鍵字更容易控制範圍。規則應填寫主機名稱，而非包含通訊協定、路徑與查詢參數的完整 URL。若只想區分同一網站的特定網頁路徑，一般網域規則無法做到，因為代理路由不一定能看到加密連線內的請求路徑。

IP-CIDR 依目標 IPv4 網段比對，IPv6 網段則可使用相應的 IP-CIDR6 規則。可選的 no-resolve 表示不要為了檢查這條位址規則而主動觸發網域解析，並非強制整條連線永遠不解析網域。若連線已有可用的目標位址，仍可進行位址比對。這項參數適合避免不必要的解析，但若連線只有網域資訊，可能會略過網段規則，需依實際流量判斷。

GEOIP 依賴位址資料庫，GEOSITE 則依賴網域分類資料。分類結果反映資料庫中的分類方式，並非業務服務永久不變的屬性。網域使用跨區域 CDN 時，位址所在地與服務所屬區域可能不同。若分流結果不如預期，先確認命中的是網域規則還是位址規則，再檢查資料檔是否存在、更新是否成功；不宜一開始就更換所有節點或停用 DNS。

規則提供者與 behavior

rule-providers 將規則內容拆分到外部檔案，再透過 RULE-SET 將規則接入主規則鏈。提供者的 behavior 決定內容格式：domain 存放網域比對內容，ipcidr 存放位址網段，classical 存放含規則類型的項目。不同格式不能只改一個欄位就互換，檔案內的內容也必須相符。來源是純文字或 YAML，同樣應與格式設定一致。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

# ./rules/local-direct.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

規則集內通常不會指定最終策略，而是由主設定中的 RULE-SET 決定。上例將整組項目交給 DIRECT，方便在主規則鏈控制出口。遠端規則更新失敗時，快取仍可能繼續生效，因此「仍能比對」不代表「已成功更新」。驗證規則時，請選擇明確的目標，關閉舊連線後重新存取，並查看命中項目、策略組與最終出口。既有長連線不會因規則文字變更，就自動依新順序重新建立。

七、TUN：虛擬網卡、路由與 DNS 接管

TUN 負責流量入口，不會取代規則

TUN 透過虛擬網路介面與路由設定，將原本不使用系統代理的流量送進核心。它與 mode 所屬層級不同：TUN 負責流量如何進入，規則負責進入後如何處理。啟用 TUN 後仍可使用規則模式，也可能因路由排除、介面選擇或權限問題而漏接部分流量。確認接管是否成功，不能只看開關狀態，還應觀察目標程式是否產生對應的核心連線記錄。

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

enable 用於啟用虛擬介面，stack 指定網路堆疊的處理方式，auto-route 會要求自動設定相關路由，auto-detect-interface 則用於自動偵測出口介面。mixed 是 mihomo 支援的網路堆疊選項之一，不代表它在所有作業系統上都是最佳選擇；其他堆疊的可用性與實際行為，請以目前核心和平台為準。排錯時每次只更換一種堆疊選項，並保留記錄供比較，避免混淆路由變更與堆疊變更。

DNS 劫持與加密 DNS 的界線

dns-hijack 中的 any:53 用於接管經由此路徑、目標為一般 DNS 連接埠的查詢，再交由核心 DNS 處理。它不是通用的加密 DNS 攔截器。應用程式透過 HTTPS 傳送的 DNS 查詢看起來像一般加密連線，不會因為目標不是此連接埠，就被這項規則自動轉換。若瀏覽器啟用了獨立解析功能，排查時應先確認查詢實際經過的路徑，而非一再修改核心上游。

TUN 通常需要與 DNS 模組搭配使用，但兩者並非由同一個開關控制。如果 DNS 模組未啟用、監聽衝突或上游無法連線，可能會發生流量已接管卻無法解析的情況。反過來說，DNS 回應成功也不能證明業務路由正常。可分別測試已知位址的連線能力與網域存取，先釐清是「位址連線失敗」還是「名稱解析失敗」，再進一步檢查策略、出口與路由。

不同平台的權限與路由衝突

桌面系統通常需要管理員權限、特權服務或相應的系統授權，才能建立介面與調整路由。用戶端可能會代為管理這些功能，直接修改 YAML 無法取代系統授權流程。Android 用戶端通常透過 VpnService 取得流量接管能力；系統顯示的 VPN 授權與桌面虛擬網卡的運作方式並不完全相同。iOS 用戶端則透過自身支援的網路延伸機制運作，不應將桌面欄位逐項照搬到行動版介面。

企業 VPN、虛擬機器網路、容器網路橋接器與其他代理工具，都可能同時修改路由。自動偵測若選到不適合的介面，可能造成流量繞行或迴圈。先退出其他網路接管工具，記錄目前路由資訊，再單獨啟用一個用戶端測試。若確實需要並行使用，應明確指定哪些網段交由企業 VPN、哪些流量交由代理核心處理；不要只靠反覆重新啟動碰運氣，否則下次網路介面順序變動時，問題仍會再次發生。

啟用更嚴格的路由限制，可能會改變區域網路存取、熱點分享與其他 VPN 的行為，不要把相關開關當成通用修復方法。先建立最精簡可用的 TUN 設定，再依已確認的問題增加排除項目或平台選項。從休眠喚醒或切換網路後，也要確認系統代理與虛擬介面是否恢復到預期狀態。具體啟用步驟請參閱TUN 原理與流量接管步驟；若 Android 背景服務遭系統停止，可查看VpnService 與省電白名單說明，這類問題不一定出在 YAML。

八、覆寫、合併與執行時驗證

先確認設定來源，再定義合併方式

覆寫是用戶端載入訂閱或本機設定時，替換、補充或重新整理部分欄位的過程。這不是 YAML 語言內建的通用功能，也沒有所有 Clash 用戶端都遵循的統一合併順序。同一個介面名稱，在不同用戶端中可能分別代表淺層替換、遞迴合併或指令碼處理。修改前先閱讀該用戶端的覆寫說明，確認設定入口是套用於目前設定或所有設定，以及訂閱更新後是否仍會執行。

映射與列表尤其需要分開檢查。遞迴合併 DNS 物件可能保留未修改的上游欄位；整個物件替換則會刪除原物件中的其他設定。若替換規則列表，訂閱原有的分流規則就會遺失；若採用追加方式，原有的 MATCH 可能已提前兜底，導致新增規則永遠不會命中。節點與策略組列表還涉及名稱引用，不能只把兩份檔案拼在一起，就認定結果有效。

# 原始設定中的 DNS 物件
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# 希望透過用戶端覆寫的欄位片段
# 這是另一份輸入，不應直接追加成第二個 dns 鍵。
# dns:
#   ipv6: false

上例預期的結果是在原有 DNS 物件中新增 ipv6: false，而非刪除原本的啟用狀態、解析模式與上游。能否如此合併，取決於用戶端的實作方式。儲存後務必開啟執行時預覽，確認四個欄位都存在。若用戶端只支援整段替換，就應在覆寫物件中明確填入需要保留的欄位，避免依賴未明確說明的行為來維持網路可用性。

訂閱更新與本機修改的儲存位置

直接編輯訂閱下載的快取檔案，通常會在下次更新時被遠端內容覆蓋。較穩定的做法是將個人規則、DNS 偏好與連接埠設定放進用戶端支援的持續性覆寫入口，或是維護獨立的本機設定，再透過提供者引用遠端節點。兩種方式各有取捨：前者依賴用戶端的合併機制，後者則需要自行管理策略組與規則。選擇前應先釐清哪些欄位由訂閱維護，哪些由本機管理。

重新命名節點或策略組時，應將名稱視為跨區段引用的介面。先產生最終節點與策略組，再核對規則目標；刪除項目前，先搜尋它是否仍被其他策略組引用。訂閱轉換服務也可能重新產生名稱、規則與分組，因此轉換前後的文字並非相同結構。處理含敏感資訊的訂閱網址時，優先使用可信任的本機處理方式，分享設定前則應移除網址中的驗證資訊。

語法測試、載入確認與連線複測

若有命令列核心，可使用測試參數檢查目前的執行檔是否能讀取設定。測試時必須使用與用戶端實際相同的核心及相關資料目錄；另一個執行檔測試成功，不代表圖形介面用戶端的核心也支援這些欄位。若設定包含提供者檔案與地理資料，也要確認測試環境能存取這些依賴項。測試結果可協助發現設定問題，但不能取代實際網路連線驗證。

mihomo -t -f ./config.yaml

驗證流程可分為四步：先備份並完成語法測試，再透過用戶端重新載入設定，接著檢查記錄是否明確顯示新設定已接受，最後關閉舊連線並測試目標。查看執行時檔案可確認欄位是否保留，查看連線記錄則可確認規則與出口是否符合預期。若只按下儲存按鈕，卻沒有觸發載入，或目前設定並非正在編輯的檔案，網路狀況自然不會改變。

保留修改記錄很有幫助：記下這次變更的欄位、預期結果、實際結果與復原方式。每次只處理一個層級，確認通過後再繼續。只在排查期間開啟詳細記錄，分享前移除訂閱憑證、伺服器驗證資訊與不必要的存取記錄。若用戶端狀態本身異常，可回到使用指南重新確認匯入、模式與連線步驟；若要更換用戶端，再前往下載頁面選擇適用平台，不要把所有問題都歸因於設定檔損壞。