Clash 設定檔參考

YAML 結構總覽與載入順序

頂層區塊如何協作

一份可以執行的 Clash 或 mihomo 設定通常由通用設定、DNS、代理節點、策略組與規則五個部分組成。它們不是彼此孤立的清單，而是一條具有引用關係的鏈路：proxies 定義可建立連線的節點，proxy-groups 將節點或其他策略組整理成可選擇的出口，rules 再把不同連線送往某個策略組、DIRECT 或 REJECT。DNS 部分負責將網域解析納入這條鏈路，通用欄位則決定監聽連接埠、執行模式、區域網路存取範圍與控制介面。

欄位位置由縮排決定。頂層鍵必須從行首開始，子欄位通常縮排兩個空格，清單項目以短橫線開頭。YAML 不使用定位字元表示層級，也不允許同一層級一下使用兩個空格、一下使用四個空格。設定能在文字編輯器中正常顯示，不代表解析器一定接受；中文標點、全形冒號、不可見定位字元與錯誤縮排都是常見的載入失敗原因。字串中包含冒號、井號、大括號或前後空格時，使用單引號或雙引號包住會更穩妥。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

proxies:
  - name: "範例節點"
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "範例節點"
      - DIRECT

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

映射、清單與純量

閱讀設定時，可以先區分三種基本資料。映射是鍵和值的組合，例如 mode: rule；清單是一組以短橫線開頭的項目，例如 nameserver 下的地址；純量則是字串、數字或布林值。true 與 false 不需要加引號，連接埠通常寫成數字，節點名稱則屬於字串。若將布林值寫成帶引號的 "false"，部分實作會將它視為一般文字，結果可能與預期不同。

YAML 也支援行內陣列，例如 proxies: [節點 A, 節點 B, DIRECT]。這種寫法適合很短的清單，但節點較多、名稱含有標點，或需要經常維護時，可讀性會明顯下降。系統化設定更適合使用逐行清單。錨點、引用與複雜型別雖然是 YAML 標準功能，卻不一定能被所有用戶端的覆寫系統完整保留；若要跨用戶端使用，優先採用一般映射與清單。

從解析到套用的檢查順序

設定載入可分成三層檢查。第一層是 YAML 語法，主要檢查縮排、冒號與清單格式；第二層是欄位結構，例如節點是否缺少 server、策略組是否引用不存在的名稱；第三層才是執行階段問題，例如遠端伺服器無法連線、DNS 上游逾時或系統代理未接管流量。看到「無法連線」後不要立即修改規則。先確認用戶端日誌是否出現設定解析錯誤，再確認目標策略組能否選取節點，最後檢查連線與 DNS，排錯效率會高得多。

通用欄位、監聽連接埠與執行模式

連接埠欄位的職責

port 表示 HTTP 代理連接埠，socks-port 表示 SOCKS5 代理連接埠，mixed-port 則在同一個連接埠上同時接受 HTTP 與 SOCKS5 請求。桌面圖形化用戶端通常只需設定 mixed-port，再由用戶端自動寫入系統代理。只有部分應用程式必須分別指定代理類型時，才需要拆成兩個連接埠。多個欄位可以同時存在，但連接埠號碼不能與系統中其他程式或另一個 Clash 執行個體衝突。

連接埠被占用的典型表現是核心啟動後立即退出，日誌中出現 bind、listen 或 address already in use。此時應先關閉殘留程序，或將設定連接埠改為未被占用的值，再同步修改瀏覽器、開發工具或系統代理中的連接埠。只修改 YAML 卻沒有更新手動設定的應用程式，會造成核心正常執行但應用程式無法連線。若用戶端提供連接埠設定介面，優先在介面中修改，因為部分用戶端會透過覆寫層覆蓋訂閱中的原始連接埠。

區域網路監聽與控制介面

allow-lan 控制其他裝置能否連線至目前裝置上的代理連接埠。設為 false 時適合僅供本機使用；設為 true 後，還要配合 bind-address 與系統防火牆判斷實際可存取範圍。開放至區域網路代表同一網路中的裝置可能嘗試連線，因此不要將控制介面與代理連接埠無條件暴露在不可信的網路中。需要暫時為手機或測試裝置提供代理時，應確認目前網路環境，使用完畢後恢復限制。

external-controller 是用戶端介面與核心通訊的控制位址，常見形式為 127.0.0.1:9090。僅供本機介面使用時，綁定回送位址即可。secret 用於控制介面驗證，設定後面板請求必須攜帶對應值。它不是代理節點密碼，也不會改變代理協定。若圖形化用戶端會自動管理控制介面，不建議在訂閱原文中反覆修改，否則可能導致介面無法讀取核心狀態。

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

Rule、Global 與 Direct

mode: rule 會依照 rules 從上到下比對，是日常使用最常見的模式。global 會略過規則判斷，將流量統一交給全域策略組；它適合短時間驗證某個節點是否可用，卻不適合用來判定規則設定是否正確。direct 則讓連線直接存取，不經過代理節點，可用來判斷問題是否來自代理鏈路。許多用戶端會在介面中切換模式，並以執行時設定覆蓋檔案中的 mode，因此排錯時要同時查看介面狀態與實際設定。

log-level 通常可在 silent、error、warning、info、debug 之間選擇。日常維持 info 較合適；定位規則命中、DNS 查詢或連線握手問題時，可暫時改為 debug。除錯日誌資訊量較大，確認問題後應恢復一般等級。ipv6 決定核心是否處理 IPv6 相關功能，但最終效果還會受到系統網路、DNS 回應與節點支援情況影響。網路本身沒有穩定 IPv6 時，關閉此欄位可以減少錯誤路徑；具備完整 IPv6 環境時，再按實際需求啟用。

DNS、Fake-IP 與解析路徑

DNS 區塊解決什麼問題

代理規則經常依賴網域，但應用程式建立連線時可能只交給系統一個 IP 位址。如果網域解析完全發生在核心之外，規則引擎就可能失去原始網域，只能按 IP 規則處理。啟用 dns.enable 的核心 DNS 模組後，網域查詢可以與規則、代理出口及快取協同運作。它不是單純將系統 DNS 換成另一個位址，而是讓解析過程成為流量處理鏈的一部分。

nameserver 是主要上游解析器，default-nameserver 主要用於解析加密 DNS 伺服器本身的網域，通常應填寫可直接存取的 IP 位址，避免形成「先解析解析器網域」的循環依賴。fallback 可提供另一組解析來源，配合過濾條件決定何時採用備用結果。較新的 mihomo 設定還支援 proxy-server-nameserver，專門解析代理伺服器網域，避免節點伺服器位址的解析路徑與一般網站查詢互相干擾。

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"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"
  proxy-server-nameserver:
    - 1.1.1.1

Fake-IP 的運作方式

啟用 enhanced-mode: fake-ip 後，核心會向應用程式回傳保留位址範圍內的映射位址，並記錄該位址對應的原始網域。應用程式隨後連線至該位址時，核心便能還原網域並繼續執行網域規則。如此一來，即使應用程式只發起 IP 連線，DOMAIN、DOMAIN-SUFFIX 與 GeoSite 類規則仍有機會準確命中。預設保留範圍通常位於 198.18.0.0/16，該位址用於基準測試網路，不應視為公網目標存取。

Fake-IP 不代表網站實際解析到保留位址，也不應直接拿保留位址測試公網連通性。它依賴流量仍經過目前的核心；如果某個應用程式繞過系統代理與 TUN，取得映射位址後卻直接向網路發送連線，存取就會失敗。因此，「解析結果看起來以 198.18 開頭」本身不是故障證據，還需要配合判斷應用程式流量是否已被接管。

fake-ip-filter 用於排除不適合映射的網域。區域網路裝置探索、印表機、遊戲連線、STUN、時間同步及某些需要真實位址的服務，可能要求回傳真實解析結果。過濾規則不宜直接從網路複製過大的清單後長期使用，因為過寬的排除範圍會削弱網域還原能力。較穩妥的方法是從最小設定開始，遇到明確相容性問題後再加入對應網域，並記錄加入原因。

Redir-Host 與 DNS 洩漏排查

redir-host 會回傳真實 IP，再嘗試透過嗅探、映射或既有解析資訊關聯網域。它對少數不相容 Fake-IP 的環境較直觀，但網域規則的穩定性更依賴請求路徑。兩種模式沒有脫離環境的絕對優劣。桌面端使用 TUN、需要完整網域規則時，通常先嘗試 Fake-IP；路由器、特殊區域網路服務或明確出現映射相容性問題時，再評估 Redir-Host。

排查 DNS 應依照請求路徑逐層確認：系統請求是否進入核心監聽連接埠，核心使用了哪個上游，上游連線走直連還是代理，回應是否被快取，最終連線命中了哪條規則。單純更換 nameserver 往往無法解決所有問題。瀏覽器可能啟用獨立的安全 DNS，系統也可能快取舊結果；修改設定後應重新載入核心，必要時清除系統與瀏覽器快取。

如果檢測結果顯示 DNS 出口與預期不一致，先確認瀏覽器的獨立 DNS 設定，再檢查 nameserver-policy、備用解析器與規則模式。詳細操作可參考Clash DNS 洩漏檢測與防洩漏設定實作。不要混淆「解析器所在地」與「連線出口」：由哪個上游回應 DNS 查詢，以及網站連線由哪個節點發出，是兩條相關但不完全相同的路徑。

代理節點欄位與協定差異

節點定義的共同骨架

proxies 下的每一項代表一個可用出口。所有節點至少需要唯一的 name、協定 type、伺服器 server 與連接埠 port，其餘欄位會隨協定而變。節點名稱不只用於介面顯示，也會被策略組以字串引用，因此改名後必須同步更新所有 proxy-groups。名稱區分大小寫，前後多出的空格也可能導致引用失敗。

server 可以是 IP 位址或網域。使用網域時，節點伺服器本身必須先成功解析，才能建立後續連線；這也是 proxy-server-nameserver 有價值的原因。連接埠應寫成數字，驗證資訊通常寫成字串。範例設定中的位址與憑證僅用於說明結構，實際使用時應以訂閱或服務提供者給出的參數為準，不要僅憑協定名稱猜測加密方式、傳輸層或伺服器名稱。

Shadowsocks、Trojan 與 VLESS 範例

proxies:
  - name: "SS 範例"
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan TLS 範例"
    type: trojan
    server: 192.0.2.20
    port: 443
    password: "your-password"
    sni: "edge.example.net"
    skip-cert-verify: false
    udp: true

  - name: "VLESS WS 範例"
    type: vless
    server: 192.0.2.30
    port: 443
    uuid: "11111111-2222-3333-4444-555555555555"
    network: ws
    tls: true
    servername: "edge.example.net"
    ws-opts:
      path: "/proxy"
      headers:
        Host: "edge.example.net"

Shadowsocks 的關鍵欄位是 cipher 與 password，兩者必須與伺服器端一致。Trojan 通常執行於 TLS 上，sni 用於握手時的伺服器名稱。VLESS 的欄位組合更多，常見差異包括 TLS、Reality、WebSocket、gRPC 與一般 TCP。設定中加入 network: ws 後，還要確保 ws-opts 的路徑與 Host 和伺服器端相符。傳輸層設定錯誤時，伺服器連接埠可能可以建立 TCP 連線，但協定握手仍會失敗。

skip-cert-verify: true 會略過憑證驗證，不應視為通用的修復按鈕。憑證錯誤可能來自裝置時間不正確、伺服器名稱不相符、憑證鏈異常或中間網路干擾。先檢查 sni、servername 與系統時間，再判斷是否確實有測試需求。正式環境中維持憑證驗證，更容易暴露實際設定錯誤。

UDP、網路介面與鏈式代理

udp: true 表示節點允許核心嘗試轉送 UDP，但實際可用性仍取決於協定、伺服器端與網路環境。啟用欄位不代表所有 UDP 應用程式都會自動運作；應用程式流量還必須被 TUN 或透明代理正確接管。遊戲、語音與 QUIC 出現問題時，應先透過日誌確認 UDP 工作階段是否進入核心，再檢查節點能力。

interface-name 可以指定輸出流量使用的系統網路介面，適合多網卡、撥號或路由器環境。一般桌面使用者通常不需要設定，錯誤的介面名稱會讓所有連線都走向不存在或無法連線的網卡。routing-mark 主要服務於 Linux 策略路由，也不適合直接照抄其他設定。

mihomo 支援透過 dialer-proxy 等機制，讓一個節點經由另一個策略建立底層連線，可用於特定鏈式出口。鏈路越長，DNS、握手與故障定位就越複雜。先確認每一段都能單獨運作，再組合鏈路；不要在基礎節點尚未通過測試時，同時疊加鏈式代理、特殊傳輸與介面綁定。

節點來自訂閱時如何修改

訂閱更新通常會整體替換節點清單。直接編輯訂閱產生的 proxies，下一次重新整理後可能遺失修改。需要固定修改 SNI、略過某個節點或調整 UDP 時，應優先使用用戶端提供的覆寫、腳本或節點轉換功能。Clash Plus、Clash Verge Rev、FlClash 與 Clash Nyanpasu 的覆寫入口組織方式不同，但原則一致：保留原訂閱作為資料來源，將本地差異放在獨立層。

策略組類型、引用關係與選擇邏輯

Select、URL-Test、Fallback 與 Load-Balance

策略組是規則與節點之間的調度層。select 由使用者手動選擇節點或下層策略組，適合「節點選擇」「串流媒體」「下載」等需要明確控制的出口。url-test 會按照測試結果自動選擇符合條件的節點，適合希望自動切換至可用連線的情境。fallback 依清單順序選擇第一個可用節點，重視優先順序而非測試結果最低。load-balance 則依策略將不同連線分散至多個節點，適合充分理解工作階段一致性影響的使用者。

自動測試通常需要 url 與 interval。測試位址應穩定、回應輕量，並能反映目標網路路徑。間隔過短會產生不必要的請求，過長則可能延遲發現節點變化。tolerance 用於減少測試值接近時頻繁切換，不應將單次測試結果理解為實際下載速度。節點測速、網頁首位元組、持續吞吐量與尖峰時段穩定性屬於不同指標。

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - "故障轉移"
      - "SS 範例"
      - "Trojan TLS 範例"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    tolerance: 80
    proxies:
      - "SS 範例"
      - "Trojan TLS 範例"

  - name: "故障轉移"
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    proxies:
      - "Trojan TLS 範例"
      - "SS 範例"

策略組可以引用其他策略組

組內 proxies 不只能寫節點，也可以引用另一個策略組，以及內建出口 DIRECT、REJECT。這種組合適合建立分層結構：底層組負責節點健康檢查，中層組負責業務選擇，頂層組則作為規則目標。例如「串流媒體」組可以包含「節點選擇」和幾個指定地區組，而地區組內部再使用自動測試。

引用關係必須避免循環。如果 A 組包含 B，而 B 又包含 A，核心便無法取得最終出口。策略組名稱也不能與節點名稱混淆。維護大型設定時，可以為組名採用一致的前綴，但不必堆疊過多符號；清晰的業務名稱比純裝飾字元更利於搜尋日誌。規則目標必須與策略組名稱完全一致，否則載入階段會報找不到策略。

使用 Provider 填充節點

當節點來自 proxy-providers 時，策略組可以透過 use 引用 Provider，不必把每個節點名稱寫入 proxies。遠端節點清單更新後，自動測試組便能接收新節點。filter 與 exclude-filter 可按名稱篩選，但篩選依賴正規表示式與訂閱命名，供應方改名後結果可能為空。應為篩選組保留檢查方法，不要假設地區關鍵字永遠不變。

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

proxy-groups:
  - name: "訂閱節點"
    type: select
    use:
      - main-subscription

  - name: "自動測試"
    type: url-test
    use:
      - main-subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 600

如何設計易於維護的組層級

策略組不是越多就越精細。每增加一層，使用者需要理解的選擇狀態與排錯分支也會增加。基礎設定可以維持三層：一個總入口組、一個自動選擇組，以及少量有明確需求的業務組。規則預設指向總入口，只有確實需要獨立出口的服務才建立業務組。如此既保留手動控制，也能避免每次匯入訂閱後面對數十個意義相近的組。

排查「規則命中了卻沒有走預期節點」時，應從日誌中的規則目標開始，逐層展開策略組：先看規則送往哪個組，再看該組目前選取了哪個子組，最後確認底層實際節點。只查看介面最上層組名，容易漏掉下層自動選擇。節點切換後，既有連線也未必會立即遷移；驗證時應重新建立連線，或關閉相關應用程式工作階段。

規則語法、比對順序與兜底策略

規則從上到下首次命中

rules 是有順序的清單。核心從第一條開始檢查，遇到第一個符合項目後便停止繼續搜尋，並將連線交給規則末尾指定的策略。因此，規則順序比規則數量更重要。精確網域、特殊業務與需要拒絕的項目通常放在前面，範圍較大的網域後綴、IP 網段與地理規則放在後面，最後使用 MATCH 處理未命中的連線。

將 MATCH 放在中間，會讓其後所有規則失去作用。把過寬的 DOMAIN-SUFFIX 放在精確例外之前，也會提前攔截本應採用其他策略的子網域。修改規則時，不只要看這一條是否正確，也要檢查它前面是否已有更寬泛的比對。日誌中的規則類型與策略名稱，是判斷實際命中位置的直接依據。

rules:
  - DOMAIN,api.example.com,節點選擇
  - DOMAIN-SUFFIX,example.net,節點選擇
  - DOMAIN-KEYWORD,stream,串流媒體
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - GEOSITE,private,DIRECT
  - GEOSITE,category-ads-all,REJECT
  - MATCH,節點選擇

網域規則的差異

DOMAIN 只比對完整網域，例如 api.example.com，不會自動比對其他子網域。DOMAIN-SUFFIX,example.com 可比對根網域及其子網域，適合整個網站採用相同策略。DOMAIN-KEYWORD 只要網域中出現對應片段就可能命中，範圍較寬，短關鍵字容易誤傷無關網站。能使用完整網域或後綴時，不要優先使用關鍵字規則。

GEOSITE 引用分類資料庫中的網域集合，適合維護規模較大的服務類別。其比對結果取決於本機 GeoSite 資料是否存在、規則集名稱是否正確，以及資料是否及時更新。資料庫過舊時，新網域可能無法命中；分類名稱寫錯則會在設定載入或規則初始化時暴露。相關維護方法可參考GeoIP 與 GeoSite 資料庫更新指南。

IP 規則與 no-resolve

IP-CIDR 比對 IPv4 網段，IP-CIDR6 比對 IPv6 網段。規則末尾的 no-resolve 表示目前連線尚未取得目標 IP 時，不為了比對這條規則而額外發起 DNS 查詢。它常用於區域網路網段與已知 IP 集合，能減少不必要的解析，也可避免在網域規則之後再次觸發查詢。但如果某條 IP 規則必須依賴網域解析結果才能判斷，就不應機械式加入此參數。

GEOIP 會根據目標 IP 所屬的地理資料庫分類處理連線。它發生在 IP 層級，與 GEOSITE 的網域分類不同。某個網域可能使用全球分散式位址，解析結果也可能隨網路位置改變，因此 GeoIP 不一定能表達某項服務的業務歸屬。需要按網站或服務分流時，優先考慮網域集合；需要按實際目標網段處理時，再使用 IP 規則。

DIRECT、REJECT 與 MATCH

DIRECT 讓連線從本機網路直接發出，適合區域網路、系統服務或明確需要本地出口的目標。REJECT 會拒絕連線，常用於已確認的廣告或追蹤網域。拒絕範圍過寬會造成頁面資源缺失、登入失敗或應用程式反覆重試，因此需要配合日誌逐條調整。MATCH 是最終兜底，不判斷網域或 IP 條件，任何此前未匹配的連線都會進入此策略。

一個易於理解的預設方案是：區域網路與私有網域直連，明確拒絕項目依需求放行或拒絕，特定服務進入業務組，其餘流量交給總入口組。不要把大量來源不明的規則直接合併後期待一次生效。規則之間可能互相覆蓋，不同清單也可能對同一網域給出相反策略。新增規則集後，應選擇幾個代表性網域查看日誌，驗證其命中順序。

代理 Provider、規則集與外部檔案

Provider 解決的維護問題

當節點與規則數量持續增加時，把所有內容塞進一份 YAML 會變得難以更新。proxy-providers 用於載入節點集合，rule-providers 用於載入規則集合。主設定只保留來源、快取路徑、更新間隔與引用關係，遠端內容更新後不需要重寫整份主檔案。Provider 適合訂閱與公共規則集，但也引入下載、快取與格式三類依賴；排錯時要區分主設定解析失敗與遠端檔案更新失敗。

type: http 表示從網路位址拉取，type: file 表示讀取本機檔案。path 是快取或檔案位置，通常使用相對於執行目錄的路徑。不同用戶端的設定目錄不同，不要直接複製其他裝置上的絕對路徑。interval 以秒為單位控制更新間隔；過短會頻繁請求，過長則延遲接收變更。用戶端手動更新訂閱時，也可能觸發 Provider 重新整理。

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

  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: "./rules/private-network.yaml"
    url: "https://rules.example.net/private-network.yaml"
    interval: 86400

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

behavior 與檔案內容必須相符

behavior: domain 表示規則集主要包含網域項目，內容可以是完整網域、後綴或相應的網域規則形式；ipcidr 表示 IP 網段；classical 則允許在規則集中保留較完整的經典規則語法。行為類型與實際內容不一致時，規則可能無法解析或無法按預期比對。選擇類型應根據規則來源提供的格式，而不是只依檔名判斷。

常見的 YAML 規則集會將項目放在 payload 下。domain 行為的簡化項目可使用網域後綴形式，classical 行為則可寫入帶類型的完整規則。主設定透過 RULE-SET 指定策略，因此 Provider 檔案通常只描述比對內容，不在每一行重複策略組。若規則來源已包含策略欄位，應確認其格式是否確實要求 classical。

payload:
  - "example.com"
  - "+.example.net"
  - "service.example.org"

更新、快取與失敗回退

遠端規則更新失敗時，核心通常會嘗試繼續使用既有快取，但首次載入且本機沒有快取時，相關 Provider 可能無法使用。日誌中的 HTTP 狀態、逾時、檔案權限與格式錯誤分別指向不同問題。可以先在瀏覽器或命令列確認位址是否可存取，再檢查用戶端是否能寫入 path 指向的目錄，最後驗證下載內容確實是預期的 YAML 或 MRS 格式，而不是登入頁或錯誤頁面。

快取檔案不應由多個執行個體同時寫入。同一裝置啟動兩個用戶端，且使用相同設定目錄時，可能發生連接埠衝突，也可能爭用 Provider 檔案。遷移設定時，應連同所需的本機規則檔案一起遷移，或確保遠端來源在新環境中可存取。只複製主 YAML 卻遺漏本機 Provider，會出現主設定引用存在、實際檔案缺失的情況。

規則集順序仍由主設定決定

Provider 將許多項目包裝成一個引用，但不會改變從上到下首次命中的原則。兩個規則集範圍重疊時，排在前面的 RULE-SET 會先取得比對機會。大型規則集不應無條件放在所有精確規則之前，否則會掩蓋本地例外。需要覆蓋公共規則集時，可以將少量精確規則放在對應的 RULE-SET 前面。

規則來源越多，衝突審查越重要。建議記錄每個規則集的用途、behavior、更新來源與目標策略，刪除長期未使用或功能重複的集合。出現服務分流異常時，暫時停用最近加入的 Provider，比在數萬條遠端規則中盲目搜尋更有效率。資料庫與規則集更新後，也應重新驗證幾個關鍵網域，而不是只看下載狀態是否顯示成功。

覆寫、合併、訂閱更新與系統排錯

為什麼要將本地修改放在覆寫層

訂閱設定的生命週期通常是「遠端產生、用戶端下載、本機載入、定期重新整理」。直接編輯下載後的原始檔案，下一次重新整理時很容易被替換。覆寫層用於儲存本地差異，例如固定連接埠、調整 DNS、增加少量規則、修改策略組預設選項。如此一來，訂閱負責提供節點與基礎結構，本地層負責裝置相關設定，兩者職責更清楚。

不同用戶端對覆寫的稱呼與能力不完全相同，可能顯示為覆寫、擴充、合併、腳本或前處理。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等圖形化用戶端通常都提供設定管理入口，但支援的合併語意應以目前用戶端介面與文件為準。簡單的鍵值覆蓋較容易理解，陣列合併則要特別謹慎，因為 rules、proxies 與 proxy-groups 都是具有順序或引用關係的清單。

映射覆蓋與陣列合併的差異

映射欄位通常按鍵覆蓋。例如基礎設定中 log-level: info，覆寫層設為 debug 後，最終值只有一個。巢狀映射可能採用深度合併，也可能整個區塊替換；如果覆寫系統將整個 dns 區塊替換，只寫 ipv6: false 便可能讓原有的 nameserver 消失。套用覆寫後，應查看用戶端產生的最終設定，而不是只閱讀覆寫片段。

陣列更複雜。追加規則必須考慮插入位置：需要優先命中的本地例外應放在公共規則集之前，一般兜底規則不能追加到 MATCH 之後。策略組陣列若整體替換，原訂閱中的組可能全部消失；若單純追加，又可能產生同名組。節點陣列按名稱去重還是按位置追加，也取決於實作。無法確認合併行為時，先用一份最小測試設定驗證，再套用至主要訂閱。

# 基礎設定
mode: rule
log-level: info
rules:
  - GEOSITE,private,DIRECT
  - MATCH,節點選擇

# 本地目標
# 1. 保留原有私有網域規則
# 2. 在 MATCH 前加入精確例外
# 3. 僅將日誌等級暫時改為 debug

上面的本地目標不能只靠「在檔案末尾追加一條規則」實現，因為原有的 MATCH 會提前兜底。正確做法是在用戶端支援的規則前置區加入例外，或產生一份合併後的完整規則陣列。若用戶端只能整個替換 rules，就需要將希望保留的原有規則一併寫入覆寫結果。

一套可重複執行的排錯流程

第一步檢查設定是否成功解析。注意 YAML 行號、未知欄位、重複名稱與引用不存在等錯誤。第二步檢查核心是否啟動並監聽預期連接埠；若啟動後立即退出，優先檢查連接埠占用、設定目錄權限與控制介面衝突。第三步檢查應用程式流量是否進入核心，透過日誌確認能否看到目標網域或連線。看不到連線時，應檢查系統代理、TUN 與應用程式本身的代理設定，而不是修改節點。

第四步查看規則命中情況。日誌應顯示網域或 IP 命中了哪類規則、進入哪個策略組。若策略不正確，檢查規則順序與 Provider 內容；若策略正確，再展開策略組確認底層實際節點。第五步檢查 DNS。網域無法解析、Fake-IP 未被接管、瀏覽器使用獨立 DNS，都可能表現為網頁無法開啟。第六步檢查節點連線階段：逾時通常表示路徑無法到達，拒絕連線常見於連接埠未監聽，TLS 錯誤需要檢查伺服器名稱與時間，驗證錯誤則檢查憑證資訊。

每完成一步都應留下明確結論。例如「設定解析成功，7890 正在監聽，瀏覽器連線已進入核心，命中節點選擇組，但 TLS 握手失敗」。這樣的記錄能將問題範圍縮小到節點欄位，而不是在所有設定區塊之間反覆修改。啟動閃退還可參考Clash 用戶端啟動閃退排查清單，不熟悉介面入口時可閱讀代理、設定、日誌三大頁面說明。

訂閱更新後的回歸檢查

訂閱重新整理可能帶來節點改名、策略組變化、規則目標變更與 Provider 位址更新。重新整理後至少確認四項：原有本地覆寫仍已啟用；規則引用的策略組仍然存在；自動選擇組中仍有可用節點；DNS 與連接埠沒有被訂閱欄位意外覆蓋。若某個策略組突然變空，檢查篩選正規表示式是否仍能匹配新的節點名稱。

長期維護時，盡量減少對訂閱內部結構的強依賴。例如讓規則統一指向一個穩定的本地總入口組，再由該組引用訂閱節點，比讓數十條規則直接寫入具體節點名稱更能適應更新。節點變化由訂閱處理，策略意圖由本地設定表達，兩者分離後，遷移到其他用戶端也更容易。

最終設定自我檢查清單

• YAML 使用空格縮排，頂層鍵與清單層級清楚，沒有定位字元或全形標點。
• 監聽連接埠沒有衝突，系統代理或 TUN 指向實際執行中的核心。
• 每個策略組引用的節點、下層組與 Provider 都存在，組之間沒有循環引用。
• 規則依精確到寬泛排列，所有兜底規則位於末尾，規則目標名稱正確。
• DNS 上游可連線，Fake-IP 過濾項目維持必要範圍，瀏覽器獨立 DNS 已納入檢查。
• 套用覆寫後的最終設定仍保留原訂閱所需欄位，重新整理訂閱後完成一次回歸驗證。

完成欄位核對後，可返回使用指南，依照匯入、選擇策略、連線與驗證的主線操作；需要更換用戶端時，前往用戶端下載頁。常見現象與簡短答案集中在常見問題，適合在確認錯誤階段後快速尋找對應處理方法。