Clash 設定檔完整參考

一、YAML 結構總覽

Clash 設定檔通常以 config.yaml 為入口。它不是一串彼此獨立的開關，而是一棵具備層級的映射結構：頂層欄位決定監聽連接埠、執行模式與網路能力；proxies 定義可用代理；proxy-groups 將代理組織成可手動選擇、自動測試或故障轉移的策略；rules 再把各類請求指向特定策略組。理解這條引用鏈，比記住單一欄位更重要。規則指向不存在的策略組，或策略組引用未定義的節點，都可能導致設定載入失敗或產生非預期結果。

縮排、序列與映射

YAML 使用空格表示層級，建議統一使用兩個空格縮排，不要混入 Tab。冒號左側是鍵，右側是值；以短橫線開頭的是序列項目。dns 後方的縮排欄位屬於 DNS 映射，而 rules 底下每一行短橫線都是一條規則。字串通常可以不加引號，但包含冒號、井號、逗號，或容易被辨識為布林值的內容時，加上引號更穩妥。註解以井號開頭，僅供閱讀，不會參與執行。

# 頂層映射
mixed-port: 7890
mode: rule
log-level: info

# 巢狀映射
dns:
  enable: true
  listen: 0.0.0.0:1053

# 物件序列
proxies:
  - name: "範例節點"
    type: socks5
    server: 127.0.0.1
    port: 1080

# 字串序列
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,節點選擇

上例展示的是語法關係，不代表一定要使用本機 SOCKS 節點。實際訂閱通常會提供完整的 proxies 或 proxy-providers。手動編輯時，應保留節點名稱的精確拼寫，因為策略組會透過名稱引用節點。名稱中的空格是有效字元，但前後空格容易造成肉眼難以察覺的差異；因此節點名稱與策略組名稱建議加上雙引號，並避免在結尾留下空格。

最小閉環與載入順序

一個用於規則模式的完整設定，至少需要監聽入口、可用出口、策略組與兜底規則。解析器會先讀取 YAML，再驗證欄位型別與引用關係，最後建立監聽連接埠、DNS 模組與代理組。能通過 YAML 解析，不代表執行邏輯正確：例如已啟用 mode: rule，但規則末尾缺少 MATCH，未命中的流量可能沒有明確的兜底去向；又或者只定義節點，卻沒有將節點放入策略組，規則便無法透過統一的策略名稱切換。

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "本機測試"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "本機測試"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,節點選擇

檢查結構時，可沿著「規則目標 → 策略組 → 節點或其他策略組」的方向逐級查找。每一級名稱都必須存在，也不能形成無意義的循環引用。若編輯器支援 YAML 語法檢查，便能提前發現縮排與重複鍵；客戶端日誌則更適合找出不支援的欄位、連接埠遭佔用、代理集合下載失敗等執行期問題。遇到具體錯誤時，也可對照疑難排解中的設定載入分類。

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

通用欄位決定客戶端如何接收系統流量，以及進入代理協定細節前的基本行為。圖形客戶端往往會在介面中管理這些值，因此手動修改前，應先確認客戶端是否使用覆寫機制；否則檔案中的設定可能在啟動時被介面選項覆蓋。最常見的入口是 mixed-port，它會在同一個連接埠接收 HTTP 與 SOCKS5 請求，適合統一設定瀏覽器、命令列工具與系統代理。

規則、全域與直連模式

rule 模式會依 rules 從上到下比對，適合長期使用；global 模式將流量統一交給全域策略組，常用於暫時測試某個出口；direct 模式讓流量直接連線，可用來確認問題是否由代理鏈路引起。模式只是總開關，不會刪除原有規則。切回規則模式後，規則仍會依原順序生效。三種模式的情境比較可繼續閱讀規則、全域、直連三種代理模式怎麼選。

區域網路監聽與控制介面

啟用 allow-lan 後，其他裝置能否連入仍取決於監聽位址、防火牆與所在網路。僅將欄位改為 true，不足以保證連線成功。若只希望本機使用，應維持關閉；需要為同一個可信任區域網路中的裝置提供代理時，再明確設定監聽位址並檢查系統防火牆。控制介面 external-controller 用於讓圖形介面或外部面板管理核心，與代理連接埠用途不同，不應將控制連接埠填入系統代理。

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

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"

log-level 常見值包括 silent、error、warning、info 與 debug。日常使用保留 info 即可；排查連線建立、DNS 查詢或規則命中問題時，可暫時切換至 debug，完成後再恢復，避免日誌快速增長。是否啟用 ipv6，應依據本地網路、DNS 回應與代理節點的支援情況決定。如果網路沒有穩定的 IPv6 路徑，卻讓 DNS 回傳 IPv6 位址，應用程式可能先嘗試無法連線的位址，造成首次連線緩慢。

圖形客戶端中的「系統代理」通常只是將作業系統代理位址指向 Clash 的監聽連接埠；「TUN 模式」則透過虛擬網路裝置接管更廣泛的流量，兩者並非同一個欄位。只需要瀏覽器與支援系統代理的軟體時，系統代理通常已足夠。若遊戲、命令列程式或不讀取系統代理的應用程式也需要納入分流，再評估 TUN。設定 TUN 還涉及權限、路由與 DNS 劫持，不能只憑一個開關判斷是否成功。

三、DNS 設定與解析鏈路

DNS 設定決定網域名稱先由誰解析、回傳何種格式的位址，以及規則引擎能否在適當階段取得網域資訊。許多「網頁偶爾打不開」、「規則看似正確卻走錯策略」的問題，並非代理節點故障，而是 DNS 請求繞過客戶端、解析結果污染快取，或 fake-ip 與特定區域網路裝置不相容。排查時，應分開觀察應用程式發起查詢、Clash 接收查詢、上游解析器回傳結果，以及建立連線這四個階段。

基本欄位與上游伺服器

dns:
  enable: true
  listen: 0.0.0.0: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
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

default-nameserver 主要用於解析 DoH、DoT 等上游伺服器本身的網域名稱，因此通常填入可直接存取的 IP 位址，避免形成「解析 DNS 伺服器網域時，又需要先存取該 DNS 伺服器」的循環。nameserver 是主要解析來源，可以使用一般 UDP 位址，也可以使用受支援的加密 DNS 位址。fallback 是否參與以及如何篩選結果，取決於核心能力與後續過濾欄位。不要簡單堆疊大量上游；來源越多，越難判斷某次回應來自何處，也可能增加結果不一致的情況。

fake-ip 與 redir-host

fake-ip 模式不會立即將真實位址直接交給應用程式，而是從保留位址區段分配一個映射位址。應用程式連線至該位址時，核心會據此還原原始網域名稱，再進行規則比對與真實解析。它通常能保留更多網域資訊，讓規則命中更穩定。代價是部分依賴真實區域網路位址、區域網路探索或特殊 DNS 行為的軟體，需要加入過濾清單。redir-host 更接近傳統解析流程，相容性思路直觀，但在某些連線階段可能只剩下 IP 資訊。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "localhost.ptlogin2.qq.com"

過濾項目並非越多越好。只有確認某類網域必須取得真實位址時才加入，並記錄加入原因。遇到區域網路印表機、投放或路由器管理網域異常時，可先在日誌確認查詢網域，再加入精確的後綴進行驗證。一次複製很長的過濾清單，會掩蓋真正的相容性關鍵，也會讓原本可由網域規則處理的請求提早走向不同的解析路徑。

依網域指定解析器

支援 nameserver-policy 的核心可依網域集合選擇上游。它適合將區域網路網域交給路由器、將特定區域網域交給相應解析器，或讓規則集合與 DNS 策略保持一致。鍵的比對寫法與核心版本能力有關，遷移設定時應先用少量網域測試，不要直接假設所有舊語法都能原樣運作。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

判斷 DNS 是否生效，不能只看網頁最後能否開啟。應檢查客戶端日誌中是否出現該網域查詢、命中了哪個 DNS 策略、連線階段使用網域名稱還是 IP，以及系統是否仍透過其他網卡的 DNS 直接發送請求。啟用 TUN 時，還要確認 DNS 劫持設定與系統權限。修改後先清除作業系統與瀏覽器快取，再用新的網域或無痕視窗測試，避免舊回應干擾判斷。

四、代理節點欄位

proxies 是靜態節點清單，每個序列項目至少包含名稱、協定類型、伺服器位址、連接埠，以及該協定所需的驗證參數。訂閱產生器通常已完成這部分，手動維護則較適合本機測試、固定出口或理解欄位。節點協定不同，欄位集合也不同，不能只替換 type 就將一個節點改成另一種協定。服務提供者給出的驗證資訊、傳輸層設定與 TLS 參數，必須作為一個整體核對。

通用欄位與名稱引用

節點名稱不僅用於顯示，也是設定內部的主鍵。兩個節點同名時，客戶端可能拒絕載入，也可能讓策略組的引用結果難以判斷。名稱可以包含地區、線路用途與協定提示，但不應將頻繁變動的資料寫入名稱，否則每次訂閱更新都可能使策略組的固定引用失效。更穩妥的做法是讓代理集合透過篩選器動態加入策略組。

SOCKS5 與 HTTP 範例

proxies:
  - name: "本機 SOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    username: "user"
    password: "your-password"
    udp: true

  - name: "辦公室 HTTP 代理"
    type: http
    server: proxy.example.com
    port: 8080
    username: "user"
    password: "your-password"
    tls: false

驗證欄位應依伺服器端的實際要求填寫。沒有使用者名稱與密碼的服務，不需要保留空欄位。tls 表示與 HTTP 代理伺服器端的連線是否使用 TLS，並不等同於透過代理存取的目標網站是否為 HTTPS。若伺服器位址使用網域名稱，啟動時也依賴 DNS；因此若所有策略組都無法使用同一批網域節點，應檢查節點伺服器網域的解析路徑，而不是逐一修改節點。

TLS、SNI 與傳輸參數

使用 TLS 的協定通常還涉及伺服器名稱驗證。設定中的 servername 或同類欄位，用於指定握手時的伺服器名稱，應與伺服器端憑證及部署設定一致。跳過憑證驗證會改變安全邊界，不應作為長期解決連線失敗的通用方法。正確的排查順序是確認系統時間、網域解析、伺服器名稱、憑證鏈與傳輸參數，再判斷是否屬於測試環境中的特殊憑證。

WebSocket、gRPC 等傳輸方式通常還會帶有路徑、Host 或服務名稱。它們是伺服器端路由的一部分，少寫一個字元也可能出現連接埠可連線但握手失敗的情況。匯入訂閱後若只有個別節點失效，應對照原始節點資訊檢查傳輸欄位；若所有節點同時失效，更應優先檢查本地網路、系統時間、DNS、訂閱是否過期，以及核心日誌。

客戶端選擇也會影響可用欄位。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等圖形客戶端可能使用不同核心或不同的覆寫介面；停止維護的 Clash for Windows 與 ClashX Meta，對新欄位的支援範圍也可能有限。設定來自 mihomo 環境時，不應預設舊版客戶端能識別所有欄位。需要更換客戶端，可前往下載頁查看對應平台選項。

五、策略組與選擇邏輯

策略組是規則與具體節點之間的中間層。規則最好指向用途穩定的策略組，例如「節點選擇」、「串流媒體」、「下載直連」，而不是直接指向某個節點。如此一來，節點更新、訂閱名稱變更或臨時切換出口時，便不必重寫整套規則。策略組可以包含節點、其他策略組，以及內建目標 DIRECT、REJECT。設計時要避免循環引用，並確保最底層最終能連到真實節點或內建目標。

select：手動選擇

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - "故障轉移"
      - "本機 SOCKS"
      - DIRECT

select 不會主動測試或切換，而是保留使用者目前的選擇。它適合作為規則的統一入口，也適合需要手動指定地區的情境。將自動測試組放入手動選擇組，可以同時保留自動與手動控制。需注意的是，圖形客戶端儲存的選擇狀態可能獨立於 YAML；重新匯入、清除設定或重新命名策略組後，選擇狀態可能回到第一項。因此第一項應是合理的預設策略，而不是只供暫時排錯使用的目標。

url-test：依測試結果選擇

  - name: "自動選擇"
    type: url-test
    proxies:
      - "本機 SOCKS"
      - "備用節點"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

url-test 會定期向指定位址發起測試，並依結果選擇可用節點。測試結果反映的是節點到測試目標的連線表現，不等同於所有網站的實際速度。interval 太短會產生不必要的請求，太長則無法及時反映線路變化；tolerance 可減少數值輕微波動造成的頻繁切換。啟用 lazy 後，未使用的策略組可減少主動測試。測試位址應穩定、回應內容小，並與主要使用情境具備一定關聯性。

fallback 與 load-balance

  - name: "故障轉移"
    type: fallback
    proxies:
      - "主要節點"
      - "備用節點"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "連線分配"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "節點 A"
      - "節點 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

fallback 會依清單優先順序使用第一個可用節點，適合明確的主備關係；它不是單純選擇數值最低的節點。load-balance 會將不同連線分配至多個節點，適合能容許多個出口的工作，但帳號登入、工作階段綁定，以及對來源位址敏感的網站，可能不適合頻繁變更出口。consistent-hashing 傾向讓相同目標維持較穩定的節點映射，但仍不能理解為將單一連線的頻寬疊加。

策略組的分層設計

一套易於維護的結構通常分為三層：底層由靜態節點或代理集合提供出口；中層依地區、用途或測試方式組織；頂層則提供規則穩定引用。例如「香港節點」從訂閱中篩選名稱，「自動選擇」引用多個地區組，「節點選擇」再同時包含自動選擇與手動地區組。業務規則只指向「節點選擇」、「串流媒體」等頂層組。訂閱變更時，只需維護篩選條件與中層結構。

proxy-groups:
  - name: "香港節點"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|港|HK"

  - name: "節點選擇"
    type: select
    proxies:
      - "香港節點"
      - "自動選擇"
      - DIRECT

正規表示式篩選應由寬到窄逐步驗證。節點名稱由訂閱提供者決定，過度依賴表情符號、固定空格或複雜前後綴，會降低穩定性。發現策略組為空時，先查看代理集合是否更新成功，再核對篩選表示式；不要直接刪除篩選條件並長期使用全部節點，因為這可能將測試、到期提示或特殊用途項目混入正式策略。

六、規則語法、順序與兜底

rules 會依從上到下的順序比對，通常命中第一條後便停止繼續檢查。因此，規則不僅要寫對類型與參數，也要放在正確位置。精確網域應位於寬泛後綴之前，特殊直連或拒絕項應位於涵蓋範圍更大的集合之前，最後使用 MATCH 兜底。規則目標必須是已存在的策略組、節點或內建目標。

網域規則的範圍差異

DOMAIN 只會比對指定的完整網域，適合介面網域或需要例外處理的單一主機。DOMAIN-SUFFIX 會涵蓋根網域及其子網域，是網站分流的常用選擇。DOMAIN-KEYWORD 的範圍更廣，關鍵字過短時可能誤傷無關網域，因此應謹慎放置。若要讓 api.example.com 直連，其餘 example.com 走代理，精確規則必須寫在後綴規則之前。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - DOMAIN-KEYWORD,stream,串流媒體
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

IP 規則與 no-resolve

IP 規則用於比對連線目標位址。某些核心在處理 IP 類規則時，可能為了判斷網域最終對應的位址而觸發解析；加上 no-resolve 可阻止該條規則主動解析網域，適合區域網路等明確只需處理既有 IP 的規則。它不是提升所有規則速度的通用參數，也不能加在不支援該參數的規則類型後方。使用前應先了解目前核心的規則解析行為。

GEOIP 依賴本地地理資料庫，比對的是目標 IP，而不是網域本身的屬性。資料庫是否存在、是否更新，以及 DNS 回傳哪個位址，都會影響結果。需要更細緻的網域分類時，可搭配規則集合或 geosite 類能力，而不是只依賴 GEOIP。中國大陸與其他地區分流的完整寫法及驗證流程，可參考Clash 中國大陸與其他地區分流規則設定實戰。

PROCESS 與連接埠規則

桌面環境中的部分核心支援依程序名稱、程序路徑或目標連接埠比對。程序規則依賴作業系統權限與核心取得程序資訊的能力，跨平台設定不一定能維持相同行為。連接埠規則只描述連接埠，不代表應用程式身分；多種協定都可能使用同一個連接埠。撰寫時應先確認需求是「某個應用程式使用指定策略」，還是「所有存取某個連接埠的連線使用指定策略」，避免混淆兩者。

rules:
  - PROCESS-NAME,curl,DIRECT
  - DST-PORT,22,節點選擇
  - DOMAIN-SUFFIX,example.net,節點選擇
  - MATCH,節點選擇

規則維護應盡量依「例外、區域網路、業務分類、地區分類、最終兜底」分段，並在每段上方寫上簡短註解。每次修改少量規則後立即重新載入並驗證，比一次加入數千行後再定位問題更可靠。拒絕規則也應明確用途：REJECT 會直接終止符合條件的連線，誤寫寬泛後綴可能導致相關登入、靜態資源與介面一併失效。

七、代理集合與規則集合

代理集合 proxy-providers 用於從外部檔案或訂閱網址載入節點，規則集合 rule-providers 用於載入可重複使用的規則。兩者都解決「主設定不應塞入大量頻繁變動內容」的問題，但資料格式與引用位置不同：代理集合由策略組透過 use 引入；規則集合則由 RULE-SET 規則引用。將節點訂閱誤填為規則集合，或將規則檔案誤填為代理集合，都會導致解析失敗。

代理集合設定

proxy-providers:
  provider-main:
    type: http
    url: "https://subscription.example.com/clash.yaml"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: "訂閱節點"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|新加坡|日本|HK|SG|JP"

type: http 表示從遠端網址更新，path 是下載後的本機快取位置，interval 是更新間隔。更新成功不代表所有節點都可用，因此可以另外設定健康檢查。健康檢查位址與間隔應控制在合理範圍；訂閱節點很多時，檢查過於頻繁會同時建立大量連線。若訂閱需要特殊請求標頭，部分核心允許設定相應欄位，但應依訂閱服務要求填寫，不要將敏感驗證內容分享至公開設定。

策略組中的 use 可以引用一個或多個代理集合，並搭配 filter、exclude-filter 等功能篩選節點。篩選表示式通常是正規表示式。建議先使用客戶端顯示的實際節點名稱做小範圍驗證，再擴充關鍵字；中英文地區名稱、縮寫與大小寫可以透過組合表示式涵蓋。篩選結果為空時，策略組便無法提供出口，日誌通常會指出對應的集合或策略組問題。

規則集合設定

rule-providers:
  private:
    type: http
    behavior: domain
    format: yaml
    url: "https://rules.example.com/private.yaml"
    path: ./ruleset/private.yaml
    interval: 86400

  local-network:
    type: file
    behavior: ipcidr
    format: text
    path: ./ruleset/local-network.txt

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,節點選擇

behavior 描述集合內規則的行為類型，常見方向包括網域、IP 網段與經典規則。它必須與遠端檔案內容相符。format 則說明檔案採用 YAML、純文字或核心支援的其他格式。僅修改副檔名不會改變內容格式；載入失敗時應開啟檔案檢查實際結構。遠端規則集合也會快取至 path，各路徑應彼此獨立，避免兩個集合寫入同一檔案。

網域行為的 YAML 規則檔案可以採用負載列表結構：

payload:
  - "example.com"
  - "+.example.org"
  - "full:api.example.net"

不同核心與規則專案對前綴語意可能有所差異，使用第三方集合時應以其說明為準。若需要完全可控的規則，可以自行維護少量高價值項目，並將大型公共分類作為補充。外部集合越多，更新鏈路越複雜；當某個遠端網址無法使用時，本機快取是否存在會影響啟動結果。重要設定應確保即使某個附加集合暫時更新失敗，核心直連、代理與兜底邏輯仍然清楚。

更新與持久化邊界

主設定、代理集合快取與規則集合快取應分開管理。客戶端更新訂閱時可能重寫主設定，但不一定刪除本機覆寫；更換設定目錄後，舊快取也可能不再被讀取。排查「訂閱明明更新，節點清單卻沒有變化」時，應確認目前啟用的設定、集合更新時間、實際快取路徑，以及策略組引用的是否為同一個 provider 名稱。

Linux 無桌面環境通常會直接執行 mihomo 核心，設定目錄與服務使用者權限會直接影響集合快取寫入。使用 systemd 部署時，應讓服務使用者對設定目錄具備讀取權限，並對 providers、ruleset 等快取目錄具備必要的寫入權限。相關部署流程可閱讀Linux 命令列部署 Clash 核心。

八、覆寫、合併、驗證與回退

訂閱設定會在更新時重新產生，直接在訂閱內容中手動修改，下一次更新後往往會遺失。因此圖形客戶端通常提供覆寫、合併或腳本處理功能：訂閱負責節點與基本設定，本機覆寫負責連接埠、DNS、策略組補充與自訂規則。不同客戶端對「合併」的定義並不完全相同，有些依鍵覆蓋，有些對陣列追加，也有些允許在指定位置插入規則。遷移客戶端時，應先用小型設定驗證合併結果。

映射覆蓋與陣列處理

對於 mode、mixed-port 這類純量欄位，後載入的值通常會覆蓋先前的值；對於 dns 這類映射，可能逐層合併，也可能整體取代；對於 rules、proxies 與 proxy-groups 這類陣列，追加、置頂與替換會產生完全不同的結果。尤其是規則陣列：自訂例外若追加在訂閱的 MATCH 後方，便永遠沒有機會命中。

# 本機覆寫示意，具體入口以客戶端為準
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

撰寫覆寫前，先明確目標是「替換訂閱欄位」還是「補充訂閱欄位」。連接埠與日誌層級通常適合覆蓋；自訂規則往往需要置於規則陣列前方；本機策略組可能需要追加，同時確保它引用的 provider 存在於最終設定中。不要只查看覆寫檔案本身，應查看客戶端合併後交給核心的最終設定。許多問題正是由「覆寫看起來正確，但最終順序不同」造成。

規則置頂與策略組補充

假設需要讓公司內部網域直連，自訂規則必須位於寬泛代理規則與 MATCH 之前。若客戶端提供 prepend、append 等獨立區域，應放在前置區域。新增策略組時，還要確認組名不會與訂閱既有組別重複；同名物件的覆蓋方式取決於實作，有時會替換原組的全部內容。穩妥做法是使用含義清楚且不易衝突的名稱，並在合併後檢查引用鏈。

# 預期的最終規則順序
rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - RULE-SET,applications,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

分階段驗證

修改複雜設定時，不要同時更換 DNS、策略組與全部規則。第一階段只驗證 YAML 能否載入；第二階段確認監聽連接埠與控制介面啟動；第三階段確認 DNS 查詢進入核心；第四階段檢查策略組中確實有可用節點；第五階段用少量網域驗證規則命中；最後再匯入大型規則集合。如此每一步只增加一個變數，錯誤範圍更小。

1. 儲存基線：保留一份目前能正常啟動並連線的設定，記錄目前啟用的設定名稱。
2. 檢查語法：確認縮排、冒號、引號與陣列結構，重點查看編輯器標示的重複鍵。
3. 讀取日誌：先處理第一個明確錯誤，後續錯誤可能只是前一個錯誤引發的連鎖結果。
4. 核對引用：逐項檢查規則目標、策略組名稱、節點名稱、provider 名稱與本機路徑。
5. 驗證行為：用日誌確認實際命中的規則與最終策略，而不是只憑網頁開啟速度判斷。

常見錯誤分支

出現「設定檔格式錯誤」時，優先檢查縮排、Tab、未閉合引號與冒號後的空格；出現「找不到代理組」時，核對名稱大小寫、全形半形符號與尾端空格；出現「provider 更新失敗」時，檢查網址可達性、快取目錄權限與檔案格式；出現「連接埠監聽失敗」時，查看是否遭其他客戶端或舊核心程序佔用；出現「規則始終未命中」時，確認目前模式、規則順序、連線是否重用，以及日誌取得的是網域還是 IP。

如果設定能載入但所有節點都無法連線，可以暫時使用 DIRECT 驗證本地網路，再測試單一靜態節點，最後恢復策略組。若只有某類網站異常，應從規則日誌與 DNS 查詢開始，而不是重新安裝客戶端。若啟用 TUN 後才出現問題，還應檢查系統權限、虛擬網卡、路由表、防火牆與 DNS 劫持。Android 背景執行也會受到 VpnService 授權與省電策略影響，可參考Android VpnService 與省電白名單設定。

最終設定應做到三點：入口清楚，所有應用程式都知道應連線至哪個連接埠；引用閉合，每條規則都能沿著策略組找到真實出口；更新可控，訂閱變更不會覆蓋本機關鍵邏輯。達到這三點後，再考慮細分地區組、DNS 策略與大型規則集合。設定複雜度應服務於明確需求，而不是追求欄位數量。遇到仍無法歸類的問題，可繼續查看疑難排解；需要重新完成匯入與連線流程時，回到Clash 設定教學逐步核對。