Clash 設定檔參考

01 / YAML STRUCTURE

YAML 結構總覽

設定檔由哪些區域組成

Clash 設定檔是一個 YAML 映射。頂層鍵值負責定義監聽連接埠、執行模式、DNS 行為、代理節點、策略組、規則以及外部 Provider。核心讀取檔案時，會先解析 YAML 語法，再檢查欄位型別與引用關係，最後建立代理、策略組與規則之間的執行鏈路。語法正確只代表 YAML 可以被讀取，不代表每個節點都能連線，也不代表策略組引用一定完整。因此排查時，需要將「文字語法」「欄位結構」「名稱引用」「網路連通性」分成四個層次檢查。

常見頂層區域包括 mixed-port、allow-lan、mode、log-level、external-controller、dns、proxies、proxy-groups、rules、proxy-providers 與 rule-providers。並非每份設定都需要完整寫入這些欄位。由用戶端介面管理系統代理時，連接埠與控制器位址可能由用戶端產生；由訂閱服務商產生設定時，節點與策略組通常會隨訂閱更新。手動設定的重點，是釐清哪些欄位屬於基本執行參數，哪些欄位會在訂閱重新整理時被取代。

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

proxies:
  - name: Example-Trojan
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: proxy.example.com

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

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

上例展示了最小的關係閉環：規則將請求交給「節點選擇」，策略組再將請求交給具體節點或 DIRECT。規則最後的目標名稱必須與策略組名稱完全一致，策略組中的節點名稱也必須與 proxies 項目一致。名稱比較通常會區分字元、空格與全形半形差異。「節點選擇」和「節點選擇 」看似接近，實際上是兩個名稱。修改名稱時，必須同步修改所有引用位置。

縮排、序列與純量

YAML 使用縮排表達層級。建議統一使用兩個空格，不要使用定位字元。以短橫線開頭的項目屬於序列，例如 proxies 下的每個節點、rules 下的每條規則。冒號後必須保留空格；當字串本身含有冒號、井字號、方括號或前後空格時，使用引號可減少歧義。密碼、UUID、網域與節點名稱適合以字串處理；連接埠、間隔與並行數量通常使用數字；開關則使用 true 或 false。

井字號在未置於引號內時，代表註解起點。例如 password: abc#123 可能只會將 abc 視為值，正確寫法是 password: "abc#123"。布林值也應使用明確的 true 與 false，避免使用容易被不同 YAML 解析器解讀為布林值的單字。節點名稱含有逗號時，不會直接破壞節點物件，但將該名稱寫入以逗號分隔的規則或部分簡寫欄位時，可能造成解析歧義。因此節點與策略組名稱宜保持簡短、唯一，且不含控制字元。

解析順序與引用檢查

設定檔的書寫順序主要是為了方便閱讀，頂層區域不必嚴格依固定順序排列，但規則清單內的順序具有執行意義。節點可以寫在策略組之前，策略組也可以寫在規則之前；核心完成整份設定解析後，才會建立引用。出現「找不到代理」或「策略組不存在」時，先複製錯誤訊息中的名稱，與定義處逐字核對，再檢查該名稱是否由 Provider 動態提供。Provider 尚未成功載入時，依賴它的策略組可能暫時為空。

測試設定時，應從完整檔案開始，而不是只驗證某個 YAML 片段。片段能通過語法檢查，不代表放回原檔後層級仍然正確。用戶端提示設定無效時，先保留原檔副本，再以區塊為單位逐步移除最近新增的區域，透過二分法定位錯誤。若問題發生在訂閱更新後，可參考訂閱連結與設定匯入說明，確認匯入的是訂閱網址、完整 YAML，還是只含節點資訊的內容。

02 / GENERAL FIELDS

通用欄位：連接埠、模式與控制介面

如何選擇監聽連接埠

port 用於 HTTP 代理，socks-port 用於 SOCKS5 代理，mixed-port 可在同一個連接埠接收 HTTP 與 SOCKS5 請求。桌面用戶端通常只需要一個 mixed-port，應用程式再將代理位址設為 127.0.0.1 與對應連接埠。連接埠只是本機監聽入口，不是遠端節點連接埠。節點物件中的 port 代表遠端伺服器連接埠，兩者名稱相同，但層級與用途不同。

監聽連接埠不能與其他程式佔用的連接埠重複。啟動日誌出現 address already in use、bind failed 或類似訊息時，應先關閉殘留程序，或將本機監聽連接埠改為尚未被佔用的值。若用戶端介面會自動寫入連接埠設定，應以介面最後產生的執行設定為準。只修改訂閱原始檔案，而用戶端隨後又套用本地覆寫時，實際執行中的連接埠可能與檔案內容不同。

allow-lan 與監聽位址

allow-lan 控制區域網路裝置能否使用本機代理。設為 false 時，通常只服務本機連線；設為 true 後，還要配合 bind-address、作業系統防火牆與目前網路類型，判斷其他裝置是否能夠存取。分享區域網路代理時，應只在受控網路中啟用，並為控制介面與代理入口設定清楚的存取邊界。在公共網路環境中，不應將控制器或代理連接埠暴露給不受信任的裝置。

mixed-port: 7890
allow-lan: true
bind-address: 0.0.0.0
authentication:
  - "device-user:your-password"

範例中的驗證適用於代理入口，實際用戶端與核心支援驗證欄位的方式，需以實際執行設定為準。若只需要本機使用，維持 allow-lan: false 會更直接。區域網路裝置無法連線時，依序檢查本機區域網路位址、連接埠監聽範圍、防火牆入站規則、裝置是否處於同一網路，以及行動裝置是否誤填代理類型。

mode 的三種常用值

mode: rule 依 rules 從上到下進行比對，是日常使用的主要模式。mode: global 將連線交給全域策略組，適合暫時確認某個節點是否可用，但會繞過精細分流。mode: direct 讓連線直接存取，適合確認問題是否由代理鏈路引起。排錯時可以短暫切換模式進行對照，確認後應回到目標模式，不要將全域模式當作修正規則遺漏的長期替代方案。

模式只決定流量如何進入策略，不會自動解決 DNS 解析、系統代理未啟用、TUN 未接管或應用程式繞過代理等問題。瀏覽器可以存取而命令列工具無法存取時，常見原因是瀏覽器遵循系統代理，而命令列程式沒有讀取系統代理設定。此時應為程式明確設定 HTTP 或 SOCKS5 代理，或使用正確設定的 TUN 模式。

日誌、IPv6 與控制器

log-level 的常見值包括 silent、error、warning、info 與 debug。日常執行使用 info 通常已足夠；定位設定與連線問題時，才暫時改為 debug，完成排查後再恢復，避免過量日誌干擾判斷。閱讀日誌時先找最早出現的錯誤，不要只看最後一行；後續大量連線失敗，有時只是第一個 DNS 或設定錯誤引發的連鎖結果。

ipv6 決定核心相關網路行為是否啟用 IPv6。若網路本身沒有穩定的 IPv6 路由，貿然開啟可能出現解析得到結果、但連線路徑無法使用的情況。DNS 區域還有獨立的 dns.ipv6，控制是否回傳 AAAA 結果。頂層 IPv6 與 DNS IPv6 應依實際網路條件設定，而不是只修改其中一處。

external-controller 是用戶端介面與核心通訊的控制介面，常見寫法為 127.0.0.1:9090。繫結至迴路位址時，只供本機存取。若設定了 secret，控制端必須攜帶對應憑證。控制器連接埠與代理連接埠用途不同，不能將系統代理指向控制器連接埠。圖形用戶端通常會自動管理這些欄位，手動修改前應確認用戶端是否會在啟動時覆寫。

03 / DNS PIPELINE

DNS 設定與解析路徑

DNS 模組處理哪些問題

DNS 區域決定由誰解析網域、使用哪種傳輸方式、是否回傳 Fake IP，以及解析請求本身透過直連還是代理送出。瀏覽器顯示連線失敗時，節點鏈路與 DNS 鏈路需要分別檢查：節點能建立連線，不代表網域已取得正確結果；DNS 能回傳位址，也不代表該位址對應的連線路徑能夠抵達。設定 DNS 的目標，是讓解析來源、分流規則與實際連線出口保持一致。

dns.enable 啟用核心 DNS 模組。使用 TUN、Fake IP，或需要避免系統解析路徑與代理分流脫節時，通常需要啟用。listen 指定 DNS 服務監聽位址，例如 0.0.0.0:1053。桌面 GUI 可能由核心在內部接管，不要求使用者直接存取該連接埠；路由器與閘道器情境則常將區域網路裝置的 DNS 請求轉送到這裡。監聽區域網路位址時，仍需考慮防火牆與存取範圍。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

default-nameserver 與 nameserver

default-nameserver 主要用於解析加密 DNS 伺服器本身的網域，以及在建立上游連線前提供基礎解析。這裡通常填寫可直接存取的 IP 位址 DNS，不宜全部寫成仍需網域解析的 DoH 位址，否則可能形成「解析 DNS 伺服器網域時，還要先存取該 DNS 伺服器」的依賴環。nameserver 是主要上游，可以使用一般 UDP DNS、DoT 或 DoH。選擇上游時，需要考慮本地網路可達性與分流出口，並非協定名稱越複雜越合適。

proxy-server-nameserver 用於解析代理伺服器網域。若節點的 server 填寫網域，核心必須先取得該網域位址才能連線節點；若這一步錯誤地依賴尚未建立的代理，就會形成啟動循環。為代理伺服器提供獨立且可直連存取的解析上游，可以降低這類問題。節點伺服器直接使用 IP 時不需要解析，但伺服器位址變更後，將無法透過 DNS 自動更新。

nameserver-policy 可以依網域或 geosite 分類指定上游。它解決的是「某類網域交由哪組 DNS 查詢」，不是「最終連線經由哪個代理」。連線出口仍由 rules 決定。DNS 策略與流量規則可以使用相似的網域集合，但兩者作用階段不同。修改其中一處時，應確認另一處是否仍符合預期。

Fake IP 與 Redir Host

enhanced-mode: fake-ip 會為網域回傳保留位址範圍中的映射位址。應用程式連線到該位址後，核心會根據映射還原原始網域，再進行規則比對與代理轉送。這樣可保留網域資訊，減少應用程式先在系統層完成真實解析，導致分流失去網域上下文的情況。fake-ip-range 應使用專用保留位址範圍，不要與目前區域網路、VPN 或其他虛擬網路網段重疊。

部分區域網路服務、裝置探索、時間同步、遊戲平台或依賴真實位址結果的程式不適合 Fake IP，可以加入 fake-ip-filter。篩選項目過寬，會讓大量網域退回真實解析，削弱 Fake IP 的一致性；篩選項目過窄，則可能造成區域網路服務無法探索或應用程式拒絕保留位址。應根據日誌與具體網域逐項新增，而不是複製來源不明的超長清單。

redir-host 回傳真實解析位址，再由連線過程繼續比對。它與部分傳統透明代理環境的相容性較好，但在某些路徑中，網域資訊可能不足。選擇增強模式時，應先確認用戶端使用的是 TUN、系統代理還是路由器透明代理，再以實際應用程式相容性驗證。切換模式後需要清除作業系統與瀏覽器的 DNS 快取，否則舊結果可能持續影響測試。

DNS 故障的定位順序

第一步確認核心 DNS 模組已啟動，日誌中沒有連接埠佔用或設定解析錯誤。第二步直接查詢一般網域，觀察是否取得結果；在 Fake IP 模式下取得保留位址屬於預期現象。第三步測試節點伺服器網域能否透過 proxy-server-nameserver 解析。第四步觀察目標網域命中了哪條規則、連線前往哪個策略組。第五步再檢查作業系統是否仍將 DNS 請求送往其他介面。

所謂 DNS 洩漏，通常涉及「哪些解析請求繞過了預期路徑」。只看到不同 DNS 服務回傳不同結果，不能直接判斷原因。瀏覽器可能啟用獨立的安全 DNS，系統可能保留其他網路介面，應用程式也可能自行發起 DoH。排查時應先統一瀏覽器、系統與核心的 DNS 路徑，再逐項恢復所需功能。TUN 環境還要確認 DNS 劫持設定是否涵蓋 UDP 與 TCP 查詢。

04 / PROXY DEFINITIONS

代理節點欄位

節點物件的通用結構

proxies 是節點物件序列。每個物件至少需要唯一的 name、協定 type、伺服器 server 與遠端 port，其餘驗證與傳輸欄位則由協定決定。節點名稱只在本地設定中作為引用識別，不會改變伺服器端參數。為方便維護策略組與規則，名稱應反映地區或用途，同時保持穩定；若每次訂閱重新整理都改變名稱，手動策略組中的直接引用很容易失效。

server 可以是網域或 IP。網域方便伺服器遷移，但依賴 DNS；IP 可減少一次解析，但位址變更後需要更新設定。udp 表示該節點是否允許處理 UDP 流量，是否真正可用仍取決於協定、伺服器與網路路徑。只開啟用戶端中的 UDP 開關，並不能讓不支援 UDP 的伺服器取得這項能力。

Shadowsocks 與 Trojan 範例

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

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

Shadowsocks 的 cipher 必須與伺服器端一致，密碼也要以字串處理。不同加密方法對應不同的金鑰要求，不能只修改用戶端名稱。Trojan 通常透過 TLS 建立連線，sni 用於指定 TLS 握手中的伺服器名稱，一般應填寫伺服器要求的網域。skip-cert-verify: false 表示正常驗證憑證。憑證名稱不相符時，應先核對伺服器網域、SNI、系統時間與伺服器憑證設定，不宜將關閉驗證當作長期處理方式。

VMess 與 VLESS 的身分與傳輸欄位

proxies:
  - name: Example-VMess
    type: vmess
    server: vmess.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: vmess.example.com
    network: ws
    ws-opts:
      path: /proxy
      headers:
        Host: vmess.example.com

  - name: Example-VLESS
    type: vless
    server: vless.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: tcp
    tls: true
    servername: vless.example.com
    udp: true

uuid 是驗證識別，必須保持標準格式並與伺服器端一致。範例 UUID 僅用於展示結構，不能作為真實連線參數。VMess 設定中的 alterId、cipher 等欄位，應依伺服器端提供的值填寫。VLESS 的傳輸與流控欄位取決於伺服器端方案；用戶端支援某個欄位，不代表可以自行加入後就能與伺服器相容。

network 描述傳輸層形式，例如 TCP、WebSocket 或 gRPC。使用 WebSocket 時，ws-opts.path 與 Host 請求標頭必須和伺服器反向代理設定一致。使用 gRPC 時要核對服務名稱。TLS 相關的 servername、SNI、ALPN 與指紋欄位都屬於握手參數，任何一項與伺服器入口不一致，都可能表現為連線建立後立即關閉。

協定欄位不能跨節點直接複製

節點物件沒有一套適用於所有協定的完整欄位表。相同名稱的欄位，在不同核心版本或協定實作中，也可能有不同限制。最穩妥的來源是伺服器端或訂閱產生的參數，再依目前核心支援的結構整理。將另一個節點的 TLS、WebSocket 或外掛參數整批複製過來，容易造成欄位存在但語意不相符。解析器可能接受這些欄位，連線仍會失敗。

訂閱連結通常由提供方維護節點參數。使用者需要修改的，往往是節點名稱、策略組編排與分流規則，而不是協定底層欄位。若匯入訂閱後所有節點同時無法使用，先檢查訂閱有效性、系統時間、DNS 與本地網路；若只有單一節點失敗，再核對該節點的伺服器、連接埠、驗證與傳輸設定。節點篩選方法可參考延遲、地區、倍率與協定判斷。

節點可用性與延遲測試的界線

延遲測試通常會請求一個測試位址並記錄完成時間，反映的是某個時間點、某條測試路徑的回應，不等同於所有網站的存取品質。測試逾時可能來自節點無法連線、測試位址遭封鎖、DNS 失敗或策略組引用錯誤。延遲較低也不代表頻寬、穩定性與目標地區存取一定更好。選擇節點時，應結合連續測試、實際目標網站與持續連線表現。

節點物件載入成功但策略組中看不到，通常是策略組沒有引用該節點，或 Provider 篩選條件將其排除。訂閱更新後節點名稱改變時，靜態 proxies 清單的引用也會失效。需要長期維護的設定，宜使用 proxy-providers 搭配 use，並透過穩定的篩選規則整理節點，而不是在多個策略組中重複寫入大量名稱。

05 / POLICY GROUPS

策略組欄位與選擇邏輯

策略組是規則與節點之間的中介層

proxy-groups 將節點、內建動作與其他策略組整理成可選擇的出口。規則通常不直接指向可能變動的節點名稱，而是指向穩定的策略組，例如「節點選擇」「串流媒體」「下載服務」。如此一來，訂閱節點變動時，只需調整策略組成員，不必重寫所有規則。策略組可以巢狀，但應避免循環引用：A 引用 B、B 又引用 A，會導致設定無法形成有效出口。

常見內建目標包括 DIRECT、REJECT 以及相容核心提供的其他動作。DIRECT 表示直接連線，REJECT 表示拒絕請求。規則目標可以是策略組、具體節點或內建動作。為提高可維護性，除少數固定情境外，建議讓規則指向策略組，再由策略組決定實際出口。

select、url-test、fallback 與 load-balance

select 最容易理解，成員順序決定介面顯示順序，目前選擇則由用戶端儲存。url-test 會定期請求指定 URL，並依結果自動選擇。interval 控制檢測間隔，tolerance 用於減少結果接近時的頻繁切換。檢測過於頻繁會增加節點請求，間隔過長則無法及時反映鏈路變化。測試位址應穩定、回應內容較小，並能代表預期的網路路徑。

fallback 依成員順序保留優先級，目前節點無法使用時選擇後續可用成員，適合主備關係明確的設定。load-balance 在多個節點之間分配連線，具體分配行為由 strategy 等欄位決定。它不會將單一下載連線拆分到多個節點，也不能突破單一節點與目標伺服器的頻寬限制。需要讓同一目標工作階段維持穩定出口時，應選擇能維持一致性的策略。

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - 故障切換
      - DIRECT

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

  - name: 故障切換
    type: fallback
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

策略組巢狀與業務分層

一套清楚的分層通常包含「總入口—地區或自動選擇—具體節點」。例如規則將一般代理流量交給「節點選擇」，「節點選擇」包含「自動選擇」「故障切換」與若干地區組，地區組再包含對應節點。如此一來，使用者既能使用自動策略，也能手動固定地區。巢狀層級不宜過深，否則介面選擇路徑與故障定位都會變長。

業務組用於表達出口需求，不應只是複製節點清單。例如「串流媒體」可以引用地區組，「開發服務」可以引用主要選擇組，「直連服務」則可以只包含 DIRECT。多個業務組引用同一個地區組時，節點維護可集中在一處。若每個業務組都重複列出數十個節點，訂閱更新後容易出現成員差異與遺漏。

Provider 成員與篩選

策略組可以使用 use 引用一個或多個 proxy-providers，從外部節點集合動態取得成員。部分核心還支援 filter、exclude-filter 等篩選方式。篩選通常使用正規表示式，應先以少量名稱驗證。地區關鍵字可能同時出現在方案說明、倍率標記或其他節點名稱中，過於寬泛的表示式容易誤收，過於嚴格則可能得到空組。

proxy-groups:
  - name: 香港節點
    type: url-test
    use:
      - subscription-main
    filter: "(?i)香港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 節點選擇
    type: select
    proxies:
      - 香港節點
      - DIRECT
    use:
      - subscription-main

同時寫入 proxies 與 use 時，策略組會依核心支援方式組合靜態成員與 Provider 成員。若介面出現大量重複節點，請檢查同一節點是否既被靜態寫入，又由 Provider 引入。自動策略組為空時，先確認 Provider 是否下載成功，再檢查篩選表示式，最後核對 Provider 中的節點名稱是否符合預期。

06 / RULE ENGINE

規則語法與比對順序

由上至下，比對到即停止

rules 是有順序的規則序列。連線到來後，核心從第一條開始檢查；命中後便將請求交給該條規則指定的策略，不再繼續檢查後續項目。因此具體規則應放在寬泛規則之前，兜底規則則放在最後。將 MATCH 寫在中間，會使其後規則無法執行；將廣泛的網域後綴規則放在精確網域之前，也可能遮蔽後面的特殊處理。

多數規則採用逗號分隔結構：規則類型、比對內容、目標策略，部分規則還可以附加額外參數。例如 DOMAIN-SUFFIX,example.com,節點選擇 會將 example.com 及其子網域交給「節點選擇」。規則中的目標名稱必須存在。若名稱含逗號，會破壞分隔結構，因此策略組名稱不宜使用逗號。

rules:
  - DOMAIN,api.example.com,節點選擇
  - DOMAIN-SUFFIX,example.com,節點選擇
  - DOMAIN-KEYWORD,example,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

網域規則的差異

DOMAIN 只比對完整網域，適合處理明確的 API 主機或需要特殊出口的單一服務。DOMAIN-SUFFIX 比對指定網域及其子網域，適合整體分流某個網站。DOMAIN-KEYWORD 只要網域含有關鍵字就可能命中，涵蓋範圍較廣，也更容易誤傷。能使用精確網域時，不應為了少寫幾行設定而改用寬泛關鍵字。

網域比對依賴核心在連線階段取得網域資訊。系統代理中的 HTTP 請求、帶有 SNI 的 TLS 連線以及 Fake IP 映射，通常都能提供網域上下文；純 IP 連線只能進入 IP 類規則。應用程式自行解析後直接連線到 IP 時，網域規則可能無法命中。若日誌只顯示目標 IP，應檢查 DNS 是否由核心接管，以及應用程式是否繞過系統代理。

IP、GEOIP 與 no-resolve

IP-CIDR 用於 IPv4 網段，IP-CIDR6 用於 IPv6 網段。區域網路、迴路、鏈路本地等位址通常應直接連線，避免交給遠端代理。CIDR 前綴長度決定範圍，寫錯一位可能將範圍擴大到遠超預期的位址段。修改網段規則前，應先確認目標位址屬於哪個網路，不要根據單次解析結果直接加入過寬範圍。

no-resolve 表示比對該 IP 規則時，不主動進行 DNS 解析。它適用於已取得目標 IP，且不希望為了規則判斷額外解析網域的情況。若規則必須透過網域解析才能取得 IP，加入 no-resolve 會改變比對條件。此參數不是通用的效能開關，應依規則類型與目前連線上下文使用。

GEOIP 依 IP 資料庫分類，比對的是位址歸屬資訊，不等同於網域類別。資料庫需要隨核心資源更新，分類結果也可能存在邊界差異。需要穩定控制某項業務時，網域規則或維護明確的規則集通常更直接；GEOIP 更適合作為接近兜底位置的大範圍分流條件。

程序、連接埠與網路類型規則

相容核心可提供程序名稱、程序路徑、目標連接埠、入站類型等擴充規則。程序規則依賴作業系統權限與核心取得程序資訊的能力；行動平台、容器環境及部分沙箱應用程式可能無法提供完整資訊。程序名稱也可能隨更新變更，因此應在執行日誌中確認實際識別結果。

連接埠規則適合協定範圍明確的情境，但同一連接埠可以承載不同服務，單獨依賴連接埠分流容易過於寬泛。網路類型規則可以區分 TCP 與 UDP，適合處理特定 UDP 應用程式或需要直連的本地服務。複雜規則應寫明用途註解並控制數量；半年後仍能理解其存在原因，比追求極短設定更重要。

自訂規則的插入位置

自訂規則是否生效，關鍵在於它被插入最終規則清單中的哪個位置。需要覆蓋訂閱預設行為的精確規則，應放在對應寬泛規則之前；本地直連網段應位於代理兜底之前；MATCH 始終位於最後。許多用戶端提供「規則前置」「規則追加」或腳本覆寫。前置適合高優先級例外，追加則適合補充訂閱未涵蓋、且不會被既有兜底規則提前命中的規則。

驗證規則時，不要只看設定文字，還應查看執行日誌中的規則命中資訊。先存取一個明確目標，再確認網域或 IP、命中的規則類型、目標策略組及最終節點是否符合預期。若日誌命中較早的規則，就調整順序或縮小前一條規則的範圍。更多常見問題可在常見問題中依「使用技巧」與「故障排查」分類繼續查詢。

07 / PROVIDERS

Proxy Provider 與 Rule Provider

為什麼要將外部內容拆分為 Provider

Provider 用於將經常更新的節點或規則集合從主要設定中分離。proxy-providers 提供節點物件，供策略組透過 use 引用；rule-providers 提供規則內容，供 RULE-SET 呼叫。主要設定負責執行框架與策略關係，Provider 負責外部資料更新。如此可避免每次節點或規則變更時，都必須替換整份主要設定。

Provider 不是策略組。節點 Provider 下載成功後，仍需要被某個策略組引用；規則 Provider 下載成功後，仍需要在 rules 中透過 RULE-SET 指定目標。只定義 Provider 而沒有引用，不會自動改變流量。反過來，規則引用不存在或載入失敗的 Provider，也會使對應集合無法比對。

proxy-providers 結構

proxy-providers:
  subscription-main:
    type: http
    url: "https://subscription.example.com/api/client?token=xxxx"
    path: ./providers/subscription-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - subscription-main
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT
    use:
      - subscription-main

type: http 表示從遠端位址取得內容，url 是訂閱位址，path 是本地快取路徑，interval 是更新間隔。路徑應位於用戶端允許寫入的設定目錄中。多個 Provider 不應共用同一個快取檔案，否則更新時可能互相覆蓋。訂閱位址屬於存取憑證，應保存在用戶端設定與受控備份中，不要發布到公開文件或截圖。

health-check 會對 Provider 中的節點執行可用性檢測。它與策略組自身的 url-test 有關聯，但並不完全相同：Provider 健康檢查負責維護節點狀態，策略組測試則用於選擇成員。檢測位址、週期與網路環境都會影響結果。節點數量較多時，不宜將週期設定得過短，以免產生密集請求。

rule-providers 的 behavior

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

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

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

behavior 描述規則集的內容類型。domain 用於網域類項目，ipcidr 用於位址網段，classical 可以承載含規則類型的經典格式。Provider 檔案內容必須與 behavior 相符。將完整的 DOMAIN-SUFFIX,example.com 項目放入只接受網域載荷的集合，或將純網段放入不相符的格式，都會導致載入錯誤或項目失效。

網域 behavior 的 YAML 載荷通常寫成 payload 序列，具體項目格式依核心約定而定。經典格式則保留完整規則類型。選擇 behavior 時，應先查看規則來源提供的實際格式，不要只根據檔名判斷。遠端位址回傳網頁、登入頁或錯誤訊息時，即使 HTTP 請求成功，內容也不是有效規則檔案。

Provider 更新與快取

遠端更新失敗時，核心可能繼續使用本地快取，因此「目前仍能執行」不代表 Provider 已完成本次重新整理。日誌中應區分下載失敗、解析失敗、寫入失敗與快取讀取成功。下載失敗通常檢查網路、位址與存取權限；解析失敗檢查回傳內容格式；寫入失敗檢查目錄權限與路徑；快取損毀則可在備份設定後刪除對應快取，讓用戶端重新取得。

更新間隔以秒為單位。節點訂閱與規則集不必使用相同週期：節點可能變動較頻繁，穩定的規則集可以降低更新頻率。用戶端啟動時是否立即更新、失敗後如何重試，取決於核心與 GUI 的管理方式。不要透過設定極短週期來取代手動排錯，持續失敗只會反覆產生請求與日誌。

多個 Provider 的整理方式

同時使用多個訂閱時，應為每個 Provider 使用獨立名稱、快取路徑與健康檢查。策略組可以依來源直接引用，也可以先按名稱篩選，再按地區組合。來源名稱適合管理訂閱，地區策略適合日常選擇，兩者不應混在同一命名層級。例如 Provider 使用「subscription-main」，策略組使用「香港節點」「自動選擇」，使用者介面會更清楚。

規則 Provider 也應依用途拆分，例如私人網路、開發服務、媒體服務與攔截清單。拆分過細會產生大量遠端請求與複雜順序，拆分過粗則不便指定不同策略。應以「是否需要獨立更新、獨立策略或獨立優先級」作為判斷標準。多個 RULE-SET 之間仍遵循由上到下首次命中的規則邏輯。

08 / OVERRIDE AND MERGE

覆寫、合併與設定維護

先辨識設定的來源層級

圖形用戶端中的最終執行設定通常由多個來源組成：訂閱原始內容、用戶端產生的基礎參數、使用者介面設定、本地覆寫檔案、腳本處理結果以及執行時補充欄位。使用者看到的訂閱 YAML 不一定等於核心最後載入的設定。修改沒有生效時，第一步應在用戶端中尋找「執行設定」「設定預覽」或日誌輸出，確認最終值來自哪一層。

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等用戶端，對覆寫介面的命名與執行順序可能不同；行動版也可能只開放部分欄位。桌面與行動裝置優先使用用戶端提供的覆寫入口，避免直接編輯由訂閱管理的快取檔案。訂閱快取通常會在重新整理時重建，手動修改很容易被下一次更新覆蓋。

映射、序列與純量的合併差異

YAML 頂層值可以分為映射、序列與純量。dns 是映射，內部還有多層鍵；rules、proxies 與 proxy-groups 通常是序列；mode、mixed-port 則是純量。覆寫系統處理這三類值的方式可能不同。純量通常直接取代，映射可能依鍵遞迴合併，序列則可能整體取代、前置、追加或依名稱處理。

這項差異決定覆寫是否安全。只想增加一條規則時，如果覆寫機制對 rules 採用整體取代，就會遺失訂閱中的全部規則；只想修改 dns.enhanced-mode 時，如果系統進行淺層取代，整個 dns 映射可能只剩一個欄位。操作前必須查看用戶端對 merge、prepend、append、override 的定義，不能假設所有用戶端都採用同一種演算法。

合併規則時要處理 MATCH

規則覆寫最常見的問題是兜底位置。訂閱規則通常已經以 MATCH 結束，若簡單將本地規則追加到末尾，這些規則就不會被執行。正確做法通常是將本地高優先級規則插入訂閱規則之前，或在腳本中暫時取出末尾的 MATCH，插入附加規則後再放回。最終清單只保留一個明確的兜底目標。

# 前置規則示意
rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,dev.example.com,節點選擇

# 最終設定仍應接續訂閱規則，並以一個 MATCH 結束
# - RULE-SET,...
# - GEOIP,...
# - MATCH,節點選擇

前置規則應盡量精確。若在最前面加入過寬的 DOMAIN-KEYWORD、大範圍 CIDR 或地區規則，訂閱中的細分策略會被提前截斷。每次新增規則後，至少驗證一個應命中的目標與一個不應命中的相鄰目標，並在日誌中查看實際命中項目。

策略組與節點的名稱合併

策略組序列的合併不能只看物件位置。部分工具會依 name 尋找並修改既有組別，部分工具則只是將新物件追加到清單。若追加同名策略組，核心可能回報名稱重複，也可能由用戶端預處理時保留其中一個，結果難以預測。需要修改既有組別成員時，應使用用戶端明確提供的依名稱覆寫方式；若不支援，產生完整的目標策略組序列會更容易控制。

節點清單也存在同名衝突。訂閱中已有「香港 01」，本地又新增同名節點時，引用便無法清楚區分來源。自建節點應使用穩定前綴，例如「LOCAL-」或用途名稱。Provider 篩選器依賴名稱時，也要確認前綴不會被地區正規表示式誤選。

DNS 覆寫要保留完整依賴

修改 DNS 時不能只關注 nameserver。使用網域形式的 DoH 上游時，需要可正常運作的 default-nameserver；節點伺服器使用網域時，需要檢查 proxy-server-nameserver；使用 Fake IP 時，還要保留位址範圍與篩選項目。看似只替換上游位址的淺層覆寫，可能意外刪除這些依賴欄位。

更穩妥的方法，是先匯出最終 DNS 區塊，複製為本地維護版本，再一次修改並驗證。確認用戶端採用遞迴合併後，才使用最小子鍵覆寫。切換 DNS 方案後，重新載入設定、清除快取並測試節點網域與一般目標網域，不要只以用戶端顯示「設定成功」作為完成標準。

建立可復原的修改流程

每次修改只處理一個主題，例如先改 DNS，再改策略組，最後改規則。修改前保留目前可執行的設定；修改後進行語法載入、Provider 更新、策略組成員檢查、規則命中與實際存取五項驗證。一次同時替換多個區塊，發生錯誤後很難判斷是哪一層造成。

設定檔中可以用註解記錄修改目的、來源與依賴，例如「必須放在訂閱規則之前」「需要 Provider subscription-main」「僅供區域網路位址直連」。註解不應包含訂閱憑證或節點密碼。長期維護時，比對結構變化比單純比對整行文字更有效，因為訂閱可能調整節點順序與名稱。

訂閱更新後啟動異常時，先切回保留的可執行設定，確認用戶端與核心本身能夠啟動，再比較新舊設定的頂層欄位、策略組名稱與規則目標。若用戶端一啟動便退出、視窗不顯示或更新後崩潰，可繼續查看用戶端啟動閃退排查順序。需要重新完成首次連線驗證時，返回使用指南，依訂閱、節點、系統代理與連線狀態逐步檢查。

最終設定自我檢查清單

載入前檢查 YAML 縮排、冒號空格、引號與序列層級；載入後檢查連接埠是否成功監聽、DNS 是否啟動、Provider 是否取得有效內容。接著確認每個規則目標都有對應策略組，每個策略組至少存在一個有效成員，巢狀關係沒有循環，最終規則清單只有一個位於末尾的 MATCH。最後分別測試直連網域、代理網域、區域網路位址、節點伺服器網域以及需要 UDP 的應用程式。

設定通過一次測試，不代表所有網路環境都相同。切換 Wi-Fi、行動網路、公司網路或 IPv6 環境後，DNS 可達性、MTU、防火牆與系統代理行為都可能改變。排查時保留同一份設定，只改變一個環境變數，才能判斷問題來自設定還是網路。需要更換用戶端時，可在下載中心查看 Windows、macOS、Android、iOS 與 Linux 的對應選項；一般使用者優先選擇 Clash Plus，再匯入同一份訂閱進行對照測試。