Clash 設定欄位

一、YAML 結構與設定載入

先分清設定檔與執行狀態

Clash 設定檔用來指定監聽連接埠、解析方式、可用代理及流量選擇規則。它不只是節點清單的另一種名稱：只有節點、沒有策略組與規則，通常不足以建立符合預期的分流方案。圖形介面客戶端負責匯入、儲存與啟動，核心則讀取產生後的設定並處理連線。編輯器中看到的訂閱原文、客戶端儲存的本機設定，以及核心實際讀取的檔案，可能是三個不同的內容層。

開始修改前，先在客戶端的設定頁確認目前啟用的項目，再尋找編輯、查看執行設定或開啟設定目錄等入口。不同客戶端的名稱可能不同，但目的相同：確認這次修改會套用在哪個檔案。不要只看檔名判斷，名為 config.yaml 的檔案也可能只是快取或啟動範本。修改未生效時，先確認設定是否已重新載入，不要立刻認定欄位失效。

縮排、映射與清單

YAML 以縮排表示層級關係，建議每層使用兩個空格，不要使用定位字元。冒號後留一個空格表示鍵和值，短橫線後加空格表示清單項目。頂層的 dns、proxies、proxy-groups 和 rules 各自屬於不同區段；縮排錯誤有時仍可通過解析，卻會讓欄位落在錯誤層級。因此，通過語法檢查只是第一步，還要確認結構是否符合預期。

# 本機直連基本設定：用來檢查結構與監聽連接埠
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

這份設定沒有遠端代理節點，策略組只有內建的 DIRECT，因此所有流量最後都會直連。它適合用來排除複雜訂閱造成的干擾，但無法用來確認遠端代理服務是否可用。之後新增節點時，必須同時將節點名稱加入策略組，並確認規則指向該組。只在 proxies 區段新增一筆資料，不代表現有流量會自動選用它。

字串、布林值與重複欄位

數值型連接埠通常直接填整數，開關則使用 true 或 false。含有井字號、冒號後接空格、特殊前綴，或容易被解析成其他型別的文字，建議加上引號；密碼也建議以字串處理。井字號在適當位置代表註解，註解不會參與執行。規則中的逗號屬於規則字串的語法，不是 YAML 的鍵值分隔符號，不可任意將整條規則拆成多個欄位。

同一映射層級不要重複定義相同的鍵。例如前面已經寫過 dns，檔案結尾又出現另一個 dns，這並不是可靠的合併方式：解析器可能拒絕載入，也可能只保留其中一段。應將子項放在同一個映射中。節點名稱、策略組名稱與引用字串也必須完全一致；全形空格、尾端空格及大小寫差異，都可能導致找不到引用目標。

建立可還原的編輯流程

先備份原始設定，再一次只修改一個項目，儲存並重新載入後查看記錄檔。如果客戶端提供設定檔測試功能，優先使用內建入口；使用命令列核心時，可執行下方的結構檢查。命令中的程式名稱與路徑須符合本機實際位置；檢查不會取代網路測試，也無法證明節點憑證正確。測試失敗時，先處理第一個明確錯誤；後續錯誤可能只是連鎖反應。

mihomo -t -f ./config.yaml

本手冊主要介紹 mihomo 常用的設定方式。原版 Clash、歷史分支與不同圖形介面客戶端可能存在相容性差異，不能假設適用於目前核心的設定檔也受到所有客戶端支援。若要先辨認核心與介面專案，可閱讀Clash、Clash Meta 與 mihomo 的生態關係，再決定要保留哪些欄位。

二、連接埠、模式與通用欄位

監聽連接埠決定流量從何處進入

port 用於監聽 HTTP 代理，socks-port 用於監聽 SOCKS 代理，mixed-port 則在同一個連接埠接收兩種代理請求。一般桌面使用情境只保留混合連接埠即可；是否同時設定其他入口，視應用程式需求而定。連接埠號是本機入口，不是遠端節點伺服器的連接埠；瀏覽器連上本機代理後，核心才會依照策略選擇真正的遠端出口。

修改連接埠後，記得同步更新客戶端的系統代理設定或應用程式內的代理位址。若出現位址已被使用的錯誤，表示另一個程序已佔用相同的監聽組合，也可能是舊的核心程序尚未關閉。先檢查執行中的客戶端與記錄檔，停止重複的執行個體，再決定是否更換連接埠。任意更換連接埠卻保留舊的系統代理位址，會造成核心啟動正常但網頁無法連線。

三種模式不是三種網路開關

mode: rule 依規則順序決定連線去向；global 使用全域策略選擇；direct 則讓核心將接管到的連線直接連線。這些模式的作用範圍，始終是已進入核心的流量，而不是裝置上的所有網路請求。只有規則模式、卻未設定系統代理、應用程式代理或適當的流量接管方式時，瀏覽器請求可能根本沒進入核心，自然也不會看到規則命中。

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

profile:
  store-selected: true

範例將監聽範圍限制在本機，並儲存策略組的選擇狀態。客戶端可能在啟動時依介面選項重新寫入這些欄位，因此介面顯示的模式與訂閱原文不一致時，應查看最終執行設定。切換模式也不一定會重建現有連線；驗證新選擇時請建立新連線，必要時在客戶端的連線頁面關閉舊連線。三種模式的使用情境可參閱規則、全域與直連模式說明。

區域網路共享與控制介面

allow-lan: true 允許其他裝置連線，但仍須一併檢查 bind-address、系統防火牆與所在網路的隔離設定。若只打算在本機使用，保持關閉更容易控管存取範圍。確實需要分享給手機或其他電腦時，連線目標應是執行客戶端裝置的區域網路位址，而不是其他裝置自己的迴圈位址；同時應限制可信任的來源，並視需求設定代理驗證。

external-controller 是供面板或客戶端呼叫的管理介面，用途不同於混合代理連接埠。管理介面可變更策略、讀取連線資訊，通常應綁定迴圈位址，並由客戶端管理驗證。不要為了讓網頁恢復存取，就把控制連接埠填入系統代理設定；也不要直接將它公開至公用網路。代理入口驗證與控制介面驗證是不同機制，不能互相取代。

記錄檔、IPv6 與流量接管範圍

日常使用可從 info 等級開始，排錯時暫時提高詳細程度，確認問題後再恢復原設定。過多的記錄會增加閱讀負擔，也可能包含目標網域與連線資訊，分享前請移除訂閱網址及敏感內容。頂層的 ipv6 與 DNS 區段中的同名開關作用層級不同，不要只修改其中一個欄位，就認定整個裝置的 IPv6 已停用；更不能因此省略檢查系統網路設定。

TUN 是另一種流量接管入口，涉及虛擬網卡、路由、權限與 DNS 劫持，不會在設定混合連接埠後自動生效。桌面客戶端、行動裝置的系統介面與伺服器命令列環境，也不能套用相同的授權步驟。初次設定時，建議先讓一般代理入口正常運作，再獨立驗證 TUN。如此一來，遇到權限或路由問題時，還能保留已知可用的連線路徑，避免同時修改多個層面而無法判斷問題所在。

三、DNS 與 Fake-IP 欄位

先確認由誰解析網域名稱

DNS 設定決定核心如何將網域名稱轉換成位址，以及如何保留網域與連線之間的關聯。瀏覽器、作業系統、應用程式本身與核心都可能參與解析，因此設定 dns.enable: true 不代表全裝置的請求都已交由核心處理。使用系統代理時，部分網域會隨代理請求傳入；TUN 情境則通常需要搭配 DNS 劫持與系統路由。應用程式內建的加密 DNS 也可能採用另一條解析路徑。

dns.listen 是核心提供 DNS 服務的監聽位址，不是上游解析伺服器。即使在本機高位連接埠監聽，系統也不會自動找到它；必須由客戶端或網路設定將查詢送至此處。下方範例用來說明欄位之間的關係，不包含 TUN 接管設定。範例中的加密 DNS 位址能否連線，取決於目前的網路；設定時請選擇連線穩定且符合使用環境需求的解析服務。

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:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"

Fake-IP 保留網域關聯

enhanced-mode: fake-ip 會回傳一個供映射使用的位址給應用程式，接著由核心依據映射還原網域名稱並選擇策略。這個位址不是目標網站的真實伺服器位址，因此在系統查詢結果中看到它，不代表 DNS 解析遭到污染。關鍵在於後續連線是否仍回到持有映射的核心。如果 DNS 查詢由一個執行個體處理，連線卻交給另一個執行個體，就可能出現位址存在、但無法正常存取的情況。

fake-ip-range 是位址分配範圍，不是遠端節點位址，也不建議將它加入代理繞過清單。若與本機網路、虛擬網卡或其他工具的路由衝突，應一併檢查整體設定，不要任意改成看似未使用的範圍。切換 DNS 模式或重新啟動核心後，應用程式可能仍快取舊映射；此時請重新建立連線，必要時清除應用程式與系統的相關快取，再確認修改是否生效。

fake-ip-filter 用來列出不適合回傳映射位址的網域，例如部分區域網路名稱，或需要真實位址才能運作的服務。加入清單不代表這些連線一定會直連，實際出口仍由規則決定。過度擴大過濾範圍，會改變大量網域的解析路徑，增加排錯難度。發現特定服務異常時，先確認它是否依賴真實位址，再加入範圍盡量精確的網域，不要直接排除所有網域。

上游、引導解析與節點網域

default-nameserver 主要用來解析 DNS 上游伺服器本身的網域名稱，解決加密 DNS 位址尚未有可連線位址的問題。nameserver 則是一般查詢使用的上游伺服器；兩者不能只看名稱，就當成完全相同的候選清單。若上游位址使用網域名稱，網路啟動時就需要可用的引導解析。引導階段失敗時，後續通常也無法建立加密 DNS 連線。

遠端代理節點的伺服器位址若也是網域名稱，還需要考慮節點網域如何解析。mihomo 提供 proxy-server-nameserver 等相關欄位，可指定解析節點伺服器時使用的上游。若將存取 DNS 服務的流量交給代理，而代理連線又依賴該 DNS 服務取得節點位址，就可能形成循環依賴。先確保節點網域能透過獨立可達的路徑解析，再讓其他查詢經由代理處理，通常更容易穩定啟動。

nameserver-policy 可依網域或受支援的比對方式指定上游解析伺服器，適合需要以不同解析器處理內部網域與公用網域的情境。它決定的是 DNS 查詢的去向，不是業務連線的出口；業務流量仍由 rules 決定。使用會與規則聯動的 DNS 選項前，請先確認代理伺服器的解析路徑完整，避免 DNS 策略與流量策略互相引用而形成循環。

依照現象縮小 DNS 故障範圍

只有區域網路服務失敗時，先檢查過濾清單與內部解析器；所有網域都解析失敗時，先確認上游是否可連線，以及監聽連接埠是否收到查詢；取得位址但連線失敗時，再檢查規則與出口。不要把所有逾時都歸咎於 Fake-IP；連接埠錯誤、節點驗證失敗與遠端拒絕連線，也會出現類似現象。可搭配已連線卻無法瀏覽網頁的排查清單，分別驗證入口、解析與出口。

四、代理節點與協定參數

分開理解通用欄位與協定欄位

proxies 是靜態節點清單，每個項目描述一種遠端連線方式。常見的通用欄位包括顯示名稱 name、協定類型 type、伺服器位址 server 與遠端監聽連接埠 port。這裡的連接埠由服務端提供，與本機混合連接埠無關。名稱供策略組引用，伺服器欄位則用來實際建立連線；不要把訂閱連結或管理面板登入位址填入伺服器欄位。

不同協定的驗證與傳輸欄位不能混用。Shadowsocks 常見欄位是加密方式與密碼；Trojan 使用密碼並仰賴 TLS；其他協定則可能使用使用者識別碼、流量標記或特定傳輸參數。服務提供者提供哪種協定，就依該協定支援的欄位填寫。只將 type 改成其他值，不會把現有節點轉換成另一種協定，還可能產生看似可載入、實際上必定無法完成交握的設定。

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

  - name: "示範 Trojan"
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: trojan.example.com
    skip-cert-verify: false
    udp: true

以上僅用來示範欄位寫法，網域與密碼不能用於實際連線。尤其不要因為連接埠是常見的安全連接埠，就推斷服務一定採用特定協定或加密方式。伺服器可使用自訂連接埠；關鍵是客戶端與伺服器端的協定、驗證、傳輸及 TLS 參數必須一致。憑證資料應以可信任的服務設定為準，不要根據分享截圖猜測缺少的欄位。

TLS 名稱與伺服器位址

伺服器位址決定連線目標，TLS 名稱則會用於交握與憑證名稱驗證；兩者可能相同，也可能須依服務端要求分別填寫。Trojan 範例中的 sni 不要只因連線失敗，就任意改成常見網站的網域名稱。使用 servername 等不同欄位名稱的協定，請依該協定的定義填寫，不要把所有 TLS 名稱欄位都一併填上，期待核心自行判斷。

skip-cert-verify: false 表示保留憑證驗證。遇到憑證錯誤時，請先檢查裝置時間、伺服器名稱、憑證有效性與服務提供者的參數。直接關閉驗證雖可能改變錯誤訊息，卻會略過原本用來辨識伺服器的防護，不應當作一般修復方式。若是在私有環境部署憑證，請先確認如何建立憑證信任鏈，再選擇適當的客戶端設定方式。

傳輸層、UDP 與解析流程

部分協定還需要設定 network、ws-opts、grpc-opts 等傳輸參數。路徑、要求標頭與服務名稱都是服務端約定的一部分，不能只因網域相同就省略。WebSocket 路徑也不同於一般網站頁面的網址。發生交握失敗時，可先核對服務提供者提供的原始參數，確認訂閱轉換、複製或匯入客戶端的過程沒有遺失傳輸設定。

udp: true 表示節點允許處理相應的 UDP 流量，但不保證整條連線路徑都已支援。應用程式入口、接管方式、遠端協定能力、伺服器設定與網路防火牆都會影響結果。網頁可以開啟，但語音或遊戲連線失敗時，請分別檢查流量是否進入核心，以及遠端出口是否支援所需傳輸；不要只反覆切換節點上的 UDP 開關。部分以 UDP 為基礎的代理協定，也需要底層網路允許相應連線。

節點伺服器使用網域名稱時，必須先完成 DNS 解析才能建立遠端連線。若記錄檔顯示節點名稱正確，但伺服器位址解析失敗，請回到 DNS 章節檢查節點解析所用的上游；若已連線至位址後才遭拒絕驗證，再核對密碼與協定。依序檢查解析、連線、交握、驗證與業務請求，比籠統地判定節點無法使用更有幫助，也更容易向服務提供者描述狀況。

節點維護與資訊安全

同名節點會讓引用關係變得模糊，更新訂閱時尤其容易留下舊名稱。靜態清單中的節點名稱應保持唯一；重新命名後，也要檢查策略組與規則中的引用。需要動態管理大量節點時，優先使用後文介紹的代理集合，不要手動複製整份清單。準備更換客戶端時，可前往下載頁面依作業系統選擇；一般圖形介面客戶端可優先考慮 Clash Plus，並先確認所需協定受實際使用的核心支援。

五、策略組與出口選擇

策略組將節點整理成可供引用的目標

proxy-groups 為規則提供穩定的目標名稱。規則可以固定指向 Proxy，使用者則在組內更換節點，不必逐條修改網域規則。組內候選項可以是個別節點、其他策略組或內建策略。可將策略組理解為一張有方向的引用圖：請求先符合規則，再進入某個組，沿著組目前的選擇找到最終出口；不是所有組同時處理同一條連線。

select 用於手動選擇，適合總入口、工作情境或需要明確固定出口的服務；url-test 依探測結果自動選擇候選項；fallback 依候選順序尋找可用項目；load-balance 則依支援的策略分配連線。自動組不一定適合所有人，是否允許出口變動、是否需要維持工作階段，以及節點是否來自相同服務環境，都應納入考量。

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

  - name: 自動選擇
    type: url-test
    proxies:
      - "示範 SS"
      - "示範 Trojan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,Proxy

範例依賴上一章定義的兩個節點，單獨複製策略組無法執行。探測網址只用來檢查可用性，不是代理伺服器，也不能完全取代實際業務網站的測試。若目前網路無法連上該網址，所有候選項都可能被誤判。請選擇適合使用環境且回應穩定的探測目標，並確認探測是透過預期節點執行；不要直接用應用程式頁面的載入時間解讀組內選擇結果。

自動探測欄位的實際用途

interval 通常以秒為單位設定探測間隔；在自動選擇中，tolerance 用來減少因些微差異而頻繁切換。探測間隔不是越短越好，過於頻繁會增加請求次數與耗電量，行動裝置尤其需要留意。部分自動組也支援惰性檢測等選項，實際觸發方式應以組別類型與核心實作為準，不要預期所有未使用的組都會以相同頻率持續檢測。

探測成功只代表節點能連上該測試目標，無法證明所有網站、所有協定與所有帳戶工作階段都能正常運作。若某項業務受地區、登入狀態或出口限制影響，請透過該業務的新連線實際驗證。自動選擇更換出口後，舊連線也可能繼續使用原路徑，因此同一時間觀察到多個出口，不一定代表設定衝突，也可能只是連線生命週期不同所致。

組間巢狀與引用限制

巢狀策略組適合將手動決策與自動選擇分開，例如在總入口手動切換自動組與直連，再由自動組選擇節點。不要讓兩個組互相引用，也不要讓組別把自己列為候選項，否則會形成循環。排查名稱錯誤時，從規則目標開始逐層確認：目標組是否存在、候選組是否存在、最終節點是否存在，一路追查到可實際連線的最末端項目。

使用 use 可讓策略組從代理集合載入候選項，使用 filter 則可篩選名稱。篩選運算式是比對條件，不是節點分類標籤；訂閱重新命名後，原本有效的條件可能會篩出空清單。自動組沒有候選項時，先檢查集合是否已載入，以及篩選條件是否過於嚴格，不要先調高探測頻率。維護時可先移除篩選，確認候選項確實存在，再逐步縮小比對範圍。

儲存選擇不代表所有流量都固定

profile.store-selected 可用來儲存手動組的選擇，但客戶端也可能有自己的狀態保存方式。更新設定後若組名改變，舊選擇不一定能對應新組；候選節點遭刪除時，也可能觸發回退。需要固定某項服務的出口時，請維持組名與節點名穩定，並將該服務規則放在通用規則之前。不要只看介面上的總組選擇，因為更精確的規則可能指向另一個獨立組。

內建的 DIRECT 代表直連，REJECT 代表拒絕，兩者都不是需要手動定義的遠端節點。將直連加入自動檢測組前，請考量它可能因探測容易成功而長期獲選，偏離原本使用代理的目的。若不確定自動選擇結果，先在手動組固定已知可用的節點，確認業務恢復後，再逐步啟用自動策略，以區分節點問題與組別邏輯問題。

六、規則語法與比對順序

由上往下比對，首次命中就停止

rules 是有順序的規則清單。核心會依清單順序檢查連線，首次命中後便套用對應策略，不會繼續尋找更精確的規則。因此，特定網域規則通常放在前面，範圍較廣的位址規則放在後面，最後再用 MATCH 處理未命中的流量。若把兜底規則放在最前面，後續大量規則便會失效；即使語法檢查通過，實際分流也會與預期完全不同。

常見寫法包含規則類型、比對內容與目標策略三部分，以英文逗號分隔。MATCH 不需要比對內容，因此只需指定目標策略。目標可以是節點、策略組或內建策略，但必須是核心找得到的名稱。名稱中若混入全形標點、不可見空格，或複製時多出的引號，可能導致引用失敗；建議依用途將規則分段，並加上簡短註解，方便日後維護。

rules:
  # 區域網路名稱與私有位址
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 示範網域交由 Proxy 處理
  - DOMAIN-SUFFIX,example.com,Proxy

  # 需要可用的地理位址資料庫
  - GEOIP,CN,DIRECT

  # 所有未命中的連線
  - MATCH,Proxy

網域規則與位址規則

DOMAIN 比對完整網域名稱，適合只處理單一主機；DOMAIN-SUFFIX 比對指定網域及其子網域；DOMAIN-KEYWORD 則比對網域名稱中的關鍵字，範圍較廣，也容易命中非目標服務的網域。若要涵蓋某項服務，不要只因名稱相似就使用過短的關鍵字。服務也可能依賴多個網域；首頁命中預期規則，不代表登入、圖片與 API 請求也會使用相同出口。

IP-CIDR 依位址網段比對，IPv6 網段通常使用 IP-CIDR6。業務連線最初以網域名稱進入時，部分位址規則可能需要先解析才能比對。結尾的 no-resolve 用來避免只因這條位址規則而主動觸發解析，但不會清除已存在的目標位址，也不保證連線不會經過其他解析流程。若在所有規則後一律加上它，可能改變原本預期依靠位址比對的行為。

GEOIP 與 GEOSITE 需要相應的資料資源，使用前請確認核心已載入支援的資料。地區或網站分類是由資料維護者定義，不能永久保證服務歸屬、實際伺服器位置或連線效果。若分類不符合特定業務需求，可在前面新增更精確的網域規則，不要在系統中同時疊加多組互相矛盾的寬泛規則。

程序規則與入口資訊的限制

mihomo 也支援依程序名稱、程序路徑等條件比對，但能否取得程序資訊，取決於作業系統、權限、接管方式與查找設定。桌面本機應用程式可能可以識別程序；來自區域網路其他裝置的代理請求，通常無法取得該裝置完整的程序資訊。規則寫法正確卻未命中時，先確認連線記錄中是否真的包含要比對的資訊，不要直接認定規則類型無法使用。

應用程式名稱不一定與實際發起連線的程序名稱相同。瀏覽器輔助程序、更新服務及背景元件都可能獨立連線，因此不要只根據視窗標題填寫程序規則。若要為工作應用程式固定出口，可先用明確的業務網域驗證，再評估程序規則是否能涵蓋其餘連線。基礎分流驗證完成後，再加入複雜邏輯規則，並保留可獨立測試的簡單條件。

透過連線記錄驗證規則

驗證前先確認目前使用規則模式，再開啟客戶端的連線或記錄檔頁面，建立新的目標請求，查看命中的規則與最終策略鏈。只觀察網頁是否開啟，無法判斷它是依規則使用代理、直連，還是透過既有連線快取完成。修改規則後也應重新建立連線，必要時關閉目標應用程式的長連線；否則既有連線繼續使用原出口，可能被誤認為規則沒有更新。

發生誤命中時，先檢查上方是否有範圍更廣的規則，再確認網域是否來自預期資訊來源，最後核對目標組目前的選擇。不要直接將整份設定永久改成全域模式；這頂多能協助確認問題是否與規則路徑或出口有關。若全域模式可用、規則模式卻失敗，請依命中記錄調整具體規則；相關模式差異請參閱代理模式說明。

規則集的順序同樣重要；主設定中引用規則集的位置，則決定它與其他規則的比對先後。維護個人例外時，可將少量穩定規則放在公用規則集之前，再保留清楚的兜底規則。每新增一條規則，都應考量它會覆蓋哪些既有規則，尤其是關鍵字、地區與全連接埠條件。能以精確網域解決的問題，通常不必擴大到整個網路或所有應用程式。

七、代理集合與外部規則集

將更新資源與主設定分開管理

proxy-providers 用來宣告代理集合，rule-providers 則用來宣告規則集。兩者都能將經常更新的內容從主設定分離，但載入的資料格式不同，不能把完整訂閱檔直接當成規則集，也不能把網域清單當成節點清單。主設定負責說明資源位置、載入方式與引用方式；資源本身則提供節點或規則。只有引用關係完整，內容才會參與實際運作。

初次排錯時，建議先使用本機檔案，確認格式與引用正確後，再接入遠端更新。如此可分辨是網路下載失敗，還是內容解析失敗。本機路徑會依核心工作目錄及客戶端的路徑限制解析，不一定相對於目前在編輯器中開啟的位置。有些客戶端會將檔案複製到自己的設定目錄，修改原始檔後不會自動同步，因此請確認執行設定中的路徑最終指向何處。

# 主設定中的相關片段
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

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

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

代理集合檔案應包含自己的 proxies 清單；若服務端回傳的是完整設定，能否作為代理集合讀取，取決於其內容與核心的處理方式，不要預期所有頂層設定都會一併套用。最穩妥的做法是讓集合只負責提供節點資料。集合中的節點名稱若有變動，會影響手動選擇與篩選運算式；更新後請再次確認組內候選項，而不是只看更新成功的提示。

# ./providers/nodes.yaml
proxies:
  - name: "示範 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

規則集行為必須符合內容格式

behavior: domain 適用於網域資料，ipcidr 適用於位址網段，classical 則使用傳統規則類型的寫法。format 指定檔案格式，例如 YAML 或支援的文字、二進位格式。行為與格式是兩個不同面向，不能因為副檔名看起來像 YAML，就認定內容一定符合網域規則集的格式。發生解析錯誤時，應檢查實際載入的資料，而不是只修改主設定中的名稱。

# ./rules/direct.yaml
payload:
  - "example.org"
  - "+.example.net"

上方的網域資料使用適用於網域規則集的格式，其中帶有加號的項目可涵蓋網域及其子網域。若使用 classical，資料通常會寫入規則類型與比對條件，例如網域後綴規則；出口策略則在主設定的 RULE-SET 引用處指定。若直接將附帶策略的完整規則照搬至集合，容易重複指定目標或造成格式錯誤；轉換前請先確認目標行為的要求。

遠端更新不只是填入網址

使用 HTTP 類型的集合時，通常還要設定下載網址、儲存路徑與更新間隔；間隔一般以秒為單位。網址必須回傳預期的資源內容；即使網路層顯示成功，若回傳的是登入頁面、存取提示或錯誤文件，內容仍可能無法解析。訂閱網址也可能含有個人存取憑證，請只保存在自己的設定中，不要放進截圖、公用儲存庫或公開的問題回報。

每項資源都應使用獨立的快取路徑，避免不同集合寫入同一檔案而互相覆蓋。遠端更新失敗時，核心能否繼續使用快取，取決於快取是否存在、是否有效及客戶端如何管理。新裝置首次匯入時沒有舊快取，啟動失敗的情況可能與已使用一段時間的裝置不同。不能因為某台裝置暫時可用，就認定訂閱伺服器一定正常。

代理集合的健康檢查用來判斷集合中節點的連線狀況，與策略組的自動選擇探測有關，但兩者並不完全相同。同時啟用多處高頻檢查，可能產生重複探測。請先確認哪一層負責更新、哪一層負責檢查、哪一層負責選擇，再設定合理的間隔。是否透過代理下載遠端資源，也須考量啟動時代理節點尚未載入的先後順序，避免形成必須先下載資源才能下載資源的循環依賴。

將更新失敗分成兩類處理

若記錄檔顯示請求逾時、網域解析失敗或憑證錯誤，先檢查資源的取得路徑；若已收到內容，卻提示欄位或資料格式錯誤，先檢查內容格式。遇到第二種情況，不要反覆重設網路；遇到第一種情況，也不要盲目更改規則集行為。更多訂閱下載情境可參閱訂閱更新失敗與自動更新設定；修復後請重新載入並確認規則是否命中，而不只是確認下載完成。

八、訂閱覆寫、合併與排錯

分清來源設定、覆寫與最終設定

訂閱更新通常會重新取得來源檔案，因此直接修改訂閱快取，可能在下次更新時遭到覆蓋。覆寫的用途是將個人設定獨立保存，再由客戶端產生執行設定時套用。這個流程主要由圖形介面客戶端實作，並非所有核心都有通用的覆寫開關。使用 Clash Plus、Clash Verge Rev 或 FlClash 時，請分別確認各自的設定管理入口與合併方式，不要將某個客戶端的指令碼直接複製到另一個客戶端。

常見的設定層次是：遠端訂閱提供節點與基礎規則，客戶端補上監聽連接埠、控制介面等執行參數，個人覆寫再調整 DNS、策略或例外規則。實際套用順序由客戶端決定，也可能允許多份覆寫依序處理。最終應以執行設定為準，而不是只看某個編輯頁面中的文字。若介面設定遭到覆蓋，先釐清各個層次，找出最後寫入該欄位的是哪一層。

映射合併與清單取代並不相同

純量欄位通常會被新值覆蓋；映射可能遞迴合併；清單則可能整份取代、追加，或依特定規則處理。這些行為並非 YAML 格式本身為所有客戶端統一規定。尤其是 rules、proxies 與 proxy-groups，若誤以為整份取代會自動追加，可能導致訂閱規則或節點全數遺失。儲存前務必確認目前入口接受的是完整設定，還是補丁片段。

# 僅表示預期覆寫的欄位，並非通用覆寫檔案格式
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

上方片段適合用來表達修改意圖，能否直接貼上使用，須依客戶端的覆寫說明而定。如果該入口會整份取代 dns 映射，原有上游與過濾清單可能會被清除；如果採用遞迴合併，未提及的欄位則可能保留。操作後請查看最終 DNS 區段，確認上游設定仍完整。不要將簡短範例當成適用所有訂閱的通用方案，也不要用重複的頂層鍵來模擬合併。

明確指定規則插入位置

新增個人規則時，應分清楚要放在前面還是後面。精確例外通常要放在公用規則之前；兜底規則只能放在最後。如果客戶端只提供清單追加功能，將個人網域規則加在既有 MATCH 之後，即使儲存成功也不會執行。請使用客戶端支援的前置規則或完整清單取代機制，並在執行設定中確認實際位置。若需要重建清單，務必保留仍然需要的原有規則。

節點與策略組也有相依順序上的限制：新規則引用的組必須存在，組引用的節點或集合必須能夠載入，刪除節點前則須先移除相關引用。重新命名應視為一次引用遷移，而不只是修改顯示名稱。訂閱自動更新後找不到目標，通常是因為個人規則仍引用舊組名。以穩定的個人組名作為中介，可降低上游節點改名對規則的影響，但仍須確認候選項有效。

分四個階段驗證修改

第一階段檢查解析：縮排、型別、重複鍵及不支援的欄位是否導致啟動失敗。第二階段檢查引用：規則目標、策略組候選項、集合名稱與資源路徑是否存在。第三階段檢查接管：請求是否進入目前的核心、系統代理連接埠是否一致，以及 TUN 權限與路由是否正常。第四階段檢查網路：依序確認節點解析、遠端連線、TLS、驗證與目標業務。每次只處理一個階段，避免略過前面的基礎問題。

若設定可以載入，但請求完全沒有出現在記錄檔中，先檢查應用程式代理與流量接管入口；若有請求卻套用錯誤策略，檢查規則順序與組內選擇；若策略正確但無法連線，再檢查節點與 DNS。記錄檔中的錯誤時間也很重要，舊記錄不一定代表本次修改仍然失敗。重新載入後記下時間，再發出新的測試請求並查看相關記錄，比連續切換多個節點後才回頭翻查更容易判斷。

系統休眠、網路切換或客戶端異常結束後，也要檢查系統代理是否殘留、虛擬網卡是否恢復，以及舊核心是否仍佔用連接埠。切換到其他客戶端前，先結束前一個執行個體，避免兩套流量接管同時運作。平台安裝與權限問題不應混在設定欄位中反覆修改；需要重新安裝時，請前往客戶端下載頁；首次恢復連線則回到快速入門流程。

保留可重現的還原記錄

每次修改後，保留修改前的備份、修改目的與驗證結果即可，不必複製所有歷史快取。若問題出現，先還原最近一次變更，確認是否恢復，再逐項重新修改。分享排錯資訊時，請提供使用的客戶端、核心類型、接管方式、錯誤階段，以及已移除敏感資訊的相關片段；不要公開完整訂閱內容。清楚指出是哪個請求、命中哪條規則、在哪個步驟失敗，比只說無法上網更容易找出原因。