Clash 設定檔
YAML 與欄位參考

一、YAML 結構與設定載入

頂層欄位：先分辨物件與清單

Clash 設定通常是一個 YAML 對應。mixed-port、mode 是純量欄位，dns 是巢狀對應，proxies、proxy-groups、rules 則是清單。先辨識這幾種結構，再查看個別參數，就能避免把節點寫進策略群組，或把規則放到 DNS 底下等階層錯誤。

縮排用來表示從屬關係，建議統一使用兩個空格，不要使用定位字元。清單項目以連字號加空格開頭，同一項中的欄位也要對齊。編輯器畫面看起來整齊，不代表實際字元一致；貼上設定後，建議開啟空白字元顯示。全形標點也可能造成問題，欄位後的冒號、規則中的逗號都必須使用半形字元。

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

proxies: []

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

rules:
  - MATCH,Proxy

這份骨架呈現了完整的引用關係，但只提供直連路徑：最後一條規則指向 Proxy，而該群組內只有 DIRECT。它適合用來檢查基本結構，不會自動產生代理節點。實際使用時，請新增服務商提供的節點，或透過提供者載入節點清單；不要把結構範例當成可用訂閱。

字串、布林值與重複鍵

連接埠通常填整數，開關則填 true 或 false。名稱、密碼及含特殊符號的字串可以加上引號，尤其是包含冒號後接空格、井號，或看起來像布林值的內容。雙引號字串會解析部分跳脫字元，包含反斜線時要特別留意；不確定時，請先對照服務商提供的原始值，不要任意轉換字元。

註解從字串外的井號開始，適合記錄修改原因，但不會納入核心設定。相同的頂層鍵不要宣告兩次，例如先寫一個 dns，又在檔案末尾寫另一個 dns。不同解析器可能會報錯，也可能只保留其中一份。正確做法是將需要的子欄位放進同一個物件，而非依賴後寫的內容覆蓋先前設定。

YAML 能成功解析，只代表語法正確，不代表目前使用的核心支援所有欄位。拼錯欄位可能無法達到預期效果；存在的策略群組也可能引用不存在的節點。檢查時應分成三個層次：文字能否解析、核心是否接受，以及連線是否依預期路由。把這三者混為一談，容易將引用錯誤誤判為網路故障。

設定來源與測試順序

用戶端中的訂閱原文、本機編輯內容、覆寫結果與核心執行中的設定，可能是四份不同的文字。排錯前先確認目前啟用的 Profile，再檢查用戶端是否套用了合併或指令碼處理。介面顯示修改已儲存，不代表執行中的核心已重新載入；必要時請使用用戶端提供的重新載入功能，再查看記錄。

如果直接執行 mihomo，可以用下方指令檢查指定檔案；圖形介面用戶端則優先使用設定檢查、執行記錄或錯誤提示。指令中的設定檔路徑應指向準備測試的檔案，而不是其他資料夾中同名的檔案。測試通過後再啟用，避免直接覆蓋唯一可用的設定檔，讓後續排錯失去比對依據。

mihomo -t -f ./config.yaml

建議每次只修改一個層面：先確認骨架能載入，再新增節點，接著設定策略群組，最後調整規則與 DNS。發生錯誤時，還原上一份有效檔案，比一次修改數十個欄位更容易找出問題。多份設定檔的命名與切換方式，請參閱Profile 與本機設定管理。

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

監聽連接埠：明確指定入口協定

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

運作模式：分開看入口接管與出站選擇

mode: rule 依規則清單選擇策略；global 使用全域策略；direct 以直連為主。模式只決定已進入核心的連線如何處理，不會讓所有應用程式自動進入核心。系統代理、應用程式內的代理設定與 TUN 才屬於流量入口層，不能以切換運作模式取代入口設定。

例如瀏覽器已透過代理連線，但某個命令列工具仍直接連線，應先檢查該工具是否會讀取系統代理，或需要另外設定環境變數。反過來說，如果用戶端面板已顯示連線，卻套用了錯誤策略，才需要檢查模式、規則與策略群組。先確認連線是否進入核心，再檢查出站選擇，就能大幅縮小排錯範圍。

區域網路共享需要一併考量 allow-lan、監聽位址、作業系統防火牆與連線裝置的代理設定。只將開關改為允許，不代表其他裝置一定能連線。若確實需要共享，請限制可信任的網段並設定適當的驗證；不要為了省略排錯步驟，把代理入口和管理介面一併公開到公用網路。

記錄、持久化與管理介面

log-level 常用 info，暫時排錯時可提高至 debug，找出問題後再恢復。詳細記錄可能包含網域、連線目標與路徑資訊，回報問題前請先刪除敏感內容。單一警告不一定代表整個用戶端失效，應依出現時間、目標連線及是否能穩定重現來判斷影響。

profile.store-selected 用來保存策略群組的選擇；能否如預期還原，也與用戶端切換設定檔的方式有關。群組名稱或節點名稱變更後，舊選擇可能找不到對應項目，導致回到預設策略。這時應檢查訂閱更新是否改了名稱，而不是立刻重裝用戶端；維持重要策略群組名稱穩定，更方便長期維護。

profile:
  store-selected: true

external-controller 是管理介面，不是用來讓瀏覽器瀏覽網站的代理連接埠。一般使用者不需要為了連線上網而開放它。若確實需要連接管理面板，應使用本機監聽或受控網路，並依用戶端要求設定驗證。把管理連接埠誤填為系統代理，通常只會出現無法連線或協定不符的錯誤。

頂層的 ipv6 與 DNS 底下的同名欄位作用不同：前者涉及核心是否使用 IPv6，後者涉及 DNS 如何處理 AAAA 查詢；兩者也都不是作業系統網路卡的開關。家用網路、節點出口與目標服務對 IPv6 的支援可能不同，調整前請保留原值並逐項測試，不要把所有異常都歸咎於 IPv6。

三、代理節點欄位與協定限制

基本欄位：名稱是引用入口

proxies 中的每個項目都代表一個特定的出站節點。通常先查看 name、type、server、port，再檢查驗證與傳輸參數。名稱主要供策略群組引用，不是伺服器網域；把節點名稱改成某個地區，不會改變出口位置。實際地區與線路狀況，仍應以服務商資訊和連線結果為準。

節點名稱應保持唯一，避免與策略群組同名，也不要使用 DIRECT、REJECT 這類內建策略名稱。複製節點後若只修改位址、忘了改名稱，可能造成引用不明或設定載入失敗。服務商頻繁更名時，手動引用特定節點的群組更容易失效；可考慮透過提供者載入節點，再於群組中篩選。

proxies:
  - name: Example-SS
    type: ss
    server: proxy.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

上方的 Shadowsocks 片段只用來說明欄位關係，位址與密碼必須替換成服務商提供的值。cipher 是協定的加密方式，必須與伺服器端一致，不能只因名稱相近就自行更換。伺服器連接埠也不一定代表常見的網站服務；即使填入四四三連接埠，也不代表節點會自動使用 HTTPS，或適合直接用瀏覽器開啟。

驗證與傳輸：依協定逐項核對

不同協定使用的驗證欄位各不相同。Shadowsocks 使用密碼與加密方式，Trojan 使用密碼並依賴相應的 TLS 設定，VMess、VLESS 則常見使用者識別欄位。欄位名稱不可跨協定照搬。排查驗證失敗時，應回頭查看原始訂閱或服務商文件，核對協定類型、帳號識別資訊與附加參數，而不是隨意補上網路上找到的欄位。

部分協定還會指定傳輸方式、路徑、主機標頭與 TLS 參數。這些欄位必須與伺服器端設定相符：WebSocket 路徑不等於網站首頁路徑，HTTP 主機標頭也不一定與連線位址相同。不要因為瀏覽器能開啟伺服器，就認定代理驗證一定正確；網頁連線只驗證了部分網路條件。

servername 通常是適用協定的 TLS 服務名稱。它可以與 server 不同，但這種差異應來自伺服器端設定，而不是隨意填入一個能連線的網域。遇到憑證錯誤，請檢查裝置時間、服務名稱與憑證鏈；不應把 skip-cert-verify 當成通用修復方式，否則會略過重要的伺服器身分驗證。

UDP、網域解析與節點選擇

udp: true 表示節點端允許相關 UDP 轉送功能，但不保證入口、伺服器與目標鏈路都支援。應分別檢查應用程式是否送出 UDP、系統代理能否接管、節點協定是否支援，以及伺服器是否放行。網頁瀏覽正常，不代表語音、遊戲或其他即時應用也一定能運作。

當 server 使用網域時，核心在建立代理連線前，必須先將節點網域解析成位址。這個步驟發生在連線至目標網站之前。如果 DNS 設定又要求透過尚未建立的同一個節點查詢，就可能形成依賴循環。若所有節點都無法連線，應先檢查節點網域是否解析成功，再判斷是否為個別線路問題。

延遲測試成功，只代表測試請求當下完成，不表示所有目標網站或傳輸方式都正常。選擇節點時，應一併考量穩定度、目標服務所在地區、流量倍率與日常使用情境。更詳細的比較順序請參閱節點挑選方式；測試指標的限制則可參考延遲測試與實際體驗。

建立新設定時，不必一次加入所有協定。先選一個參數齊全且確認可用的節點，透過手動選擇群組完成連線，再擴充自動測試或備援線路。需要更換用戶端時，可前往下載頁面依作業系統選擇，優先考慮 Clash Plus，並確認目前用戶端核心支援所需協定。

四、策略群組欄位與選擇邏輯

select：集中管理手動選擇

proxy-groups 將節點、其他策略群組與內建策略組合成可供規則引用的出站入口。規則只需指定穩定的群組名稱，節點調整則在群組中完成，可減少重複修改。最常用的 select 由使用者選擇成員，適合日常手動切換，也適合作為自動群組與直連之間的統一入口。

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

  - name: Auto
    type: url-test
    use:
      - Main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

這段範例依賴後文定義的 Main 節點提供者；單獨貼上而未設定提供者，引用就無法成立。Proxy 是總入口，使用者可以在自動群組與直連之間選擇。為了方便排錯，群組名稱應清楚表達用途，例如一般出口、工作服務或媒體服務，不要只用難以辨識的符號。

proxies 用來列出明確的節點或群組名稱，use 則用來引入節點提供者。兩者代表的項目不同，不可將提供者名稱直接當作一般節點名稱填入。群組成員必須存在於設定中，而且不可形成循環引用；甲群組包含乙群組、乙群組又包含甲群組，不會形成備援鏈路，只會造成無效結構。

自動群組：先了解測試條件

url-test 依測試結果選擇成員；url 是測試請求網址，interval 是測試週期，通常以秒為單位；tolerance 則用來減少因細微差異造成的頻繁切換。測試網址應穩定、回應輕量，並能代表基本連線能力；請勿使用包含帳號資訊或需要登入的頁面。

自動測試不是持續下載測速。測試結果會受到測試伺服器位置、解析方式、連線重用與當下線路狀態影響。某個節點順利連上測試網址，不代表存取實際工作服務也同樣理想。若群組選擇反覆變動，請先檢查線路波動與測試條件，再適度調整容差；不要只為了讓數字看起來更即時，就縮短測試週期。

fallback 著重依成員順序選擇可用路徑，適合主備關係明確的情境。要注意的是，主線路即使能開啟測試網址，卻無法存取某個特定服務時，測試仍可能判定它可用。主備策略可以降低部分故障的影響，卻不能取代針對目標服務的規則與連線驗證；群組名稱也不應暗示絕對可用。

load-balance 會依相應策略將連線分配給不同成員，不代表一條下載連線能拆分至多個節點以累加頻寬。對登入狀態或出口位址穩定度較敏感的服務，出口頻繁變動可能觸發額外驗證。沒有明確需求時，手動群組或測試群組通常較容易理解，也適合先建立可重現的基本設定。

篩選與持久化：避免群組沒有成員

從提供者載入節點時，可以使用篩選欄位限制成員範圍。篩選通常使用正規表示式，比對的是節點名稱，而非實際地理位置。服務商更改名稱、標點或命名語言後，原有篩選可能得到空清單。正式使用前，請在用戶端查看群組中的實際成員；不要只看正規表示式似乎合理，就認定群組已可使用。

設計策略群組時應控制巢狀深度。總入口連接一個業務群組，業務群組再選擇特定節點，通常已經足夠；層層包裹多個自動群組會增加理解成本。排錯時，沿著規則目標、目前群組選擇、下一層群組到最終節點逐層檢查，直到確認實際出站路徑。只看最外層群組名稱，很容易忽略內部仍選擇直連。

訂閱更新後選擇改變，可能是節點消失、名稱變更、群組結構重建，或用戶端的持久化規則所致。先確認原有成員是否仍存在，再檢查 profile.store-selected 以及用戶端是否重設了選擇。需要長期穩定引用的業務群組，可放在本機覆寫中維護；但也要確認訂閱更新後，該群組引用的成員仍然存在。

如果某個群組異常、其他群組正常，可先將同一個節點暫時放入簡單的手動群組進行比對。如果節點本身可用，問題多半在篩選、健康檢查或群組引用。這樣能將節點故障與調度邏輯分開，避免為了修復單一業務群組，就重寫整份訂閱的策略。

五、規則語法與比對順序

由上而下比對：具體規則放前面

rules 是有順序的清單，通常由上往下比對，符合條件後就採用指定策略。規則不會彙整所有條件後再投票，因此較具體的例外規則要放在範圍較廣的規則之前。排查自訂規則未生效時，先查看上方是否已有涵蓋範圍更大的規則，不要立刻更換規則類型。

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

範例中的 Proxy 必須是已定義的策略群組或節點。規則最後一個策略欄位不是自由備註，拼字、大小寫與空格都必須與實際名稱一致。編輯器自動替換標點，或複製時帶入看不見的空格，也可能造成引用失敗。修改群組名稱時，記得同步檢查所有規則與其他群組中的引用。

網域規則與位址規則的差異

DOMAIN 比對完整網域，適合單一端點；DOMAIN-SUFFIX 比對網域本身及其子網域，適合同一服務的網域群；DOMAIN-KEYWORD 依關鍵字比對，涵蓋範圍較廣，也容易誤套用到無關目標。能以明確網域表達的需求，應優先使用明確規則，減少日後難以解釋的誤判。

IP-CIDR 與 IP-CIDR6 用於比對位址網段。對於使用網域的連線，若執行到需要目標位址的規則，核心可能會觸發解析。no-resolve 的意思是避免只為這條位址規則主動解析網域，而不是禁止整條連線進行 DNS 查詢；如果連線本來就有目標位址，仍可能符合該規則。

GEOIP 依位址資料庫判斷地理歸屬，結果會受資料庫內容與更新狀況影響，不代表網站營運者所在地，也無法精確描述 CDN 每次調度的出口。啟用相關規則前，請確認核心能讀取所需資料。網域解析到不同地區的位址時，同一網站的連線路徑可能改變，原因可能是解析結果不同，而非規則隨機失效。

MATCH 是最後的兜底規則，通常放在清單末尾。若放在前面，後續一般規則就沒有機會處理連線。DIRECT 表示直連，REJECT 表示拒絕，其他名稱通常指向節點或策略群組。不要為了精簡，把業務例外全移到兜底規則後面；設定看似存在，實際執行時卻永遠不會比對到。

規則集與程序比對的限制

較長的網域清單可以放入規則提供者，再透過 RULE-SET 引用。主設定檔保留清楚的業務順序，外部清單則負責維護具體內容。請注意，規則集仍會在它出現的位置參與比對；即使清單內容完全正確，只要前面已有兜底規則，規則集就沒有機會處理連線。

程序類規則會受執行平台、程序辨識能力與接管方式影響。桌面用戶端能辨識的程序名稱，不一定能在路由器上辨識，因為路由器接收到的是其他裝置的連線。行動作業系統也可能限制相關資訊。將設定移植到其他平台時，應先確認功能限制，不要把程序規則當成通用的網域規則替代方案。

網域規則需要核心取得網域資訊。應用程式直接連接位址、DNS 查詢未經核心，或使用某些加密解析路徑，都可能影響辨識；網域嗅探功能也有適用條件，並非所有協定都能還原網域。若連線只顯示位址，先檢查 DNS 與入口鏈路，再決定是否新增位址規則，不要盲目擴大關鍵字比對範圍。

驗證規則時，請在連線面板找到新建立的連線，查看命中類型、比對內容、策略鏈與最終節點。修改前已建立的長連線未必會重新選擇出站；必要時，請關閉該應用程式的連線後再試。如果仍有疑問，可前往疑難排解依現象繼續檢查；保留一筆成功和一筆失敗的連線記錄，比只說「規則沒生效」更有幫助。

六、訂閱、節點提供者與規則提供者

完整訂閱與節點清單並非同一種內容

用戶端的遠端 Profile 通常是一整份設定檔，可包含連接埠、DNS、節點、策略群組與規則；proxy-providers 則用來在主設定檔中引入節點集合。兩者都可能透過網址更新，但用途不同。把完整設定檔連結填入只接受節點提供者格式的位置，可能會出現內容成功下載、卻無法解析的問題。

先確認服務商提供的內容格式，再選擇匯入方式。首次使用建議透過用戶端的訂閱匯入功能建立完整 Profile；只有明確需要自行維護主設定檔時，才將節點來源拆分為提供者。用戶端的操作步驟請參閱訂閱匯入步驟；格式轉換的限制請參考訂閱轉換說明。

proxy-providers:
  Main:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

範例網址不提供真實節點。HTTP 節點提供者常見的 YAML 結構會回傳頂層 proxies 清單，不能用網頁、登入頁面或錯誤訊息代替。path 用於本機快取，通常依核心工作目錄解析，實際位置也可能受用戶端的路徑限制影響。不同提供者應使用不同快取檔案，以免互相覆蓋。

更新週期與健康檢查各自負責什麼

提供者的 interval 控制重新取得節點清單的週期；健康檢查中的同名欄位則控制測試週期，兩者用途不同。前者決定多久取得一次新的節點資訊，後者決定多久檢查現有節點是否可連線。頻繁執行健康檢查不會加快訂閱更新，反而可能增加請求量並消耗行動裝置電量。

排查更新失敗時，應沿著取得內容的流程逐步檢查：網址是否過期、是否需要重新授權、目前網路能否連線、伺服器回傳什麼內容，以及內容是否符合 YAML 結構。即使瀏覽器能開啟網址，也要確認顯示的不是帳戶頁面。請勿將完整訂閱網址貼到公開回報中，因為查詢參數常包含可直接使用的存取憑證。

如果本機快取仍有效，遠端更新失敗不一定會立即影響現有節點；但用戶端的快取策略與重新啟動行為可能不同，不能視為保證。排錯時先保留目前可用的設定，不要同時刪除快取與舊 Profile。更完整的錯誤分類請參閱訂閱更新失敗與自動更新間隔。

規則提供者：格式與行為必須相符

rule-providers 管理的是比對條件，不是代理節點。behavior 用來指定內容屬於網域、位址或傳統規則格式；format 則描述檔案格式。兩者必須符合實際檔案內容，不能只因副檔名是 YAML 就認定行為相同。主規則中的策略目標寫在 RULE-SET 引用處，方便同一份清單套用到不同出站策略。

rule-providers:
  Work:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work.yaml

rules:
  - RULE-SET,Work,Proxy
  - MATCH,DIRECT

上方的 rules 是順序範例，應整合到現有清單中，不要在檔案末尾再次宣告。同一份清單若採用網域行為，對應檔案可使用下方結構。實際儲存前，請確認用戶端允許讀取該相對路徑；無法直接管理工作目錄的行動用戶端，較適合使用其提供的本機規則或覆寫功能。

payload:
  - "+.github.com"
  - "example.com"

拆分提供者後，維護責任也會隨之拆分：主設定檔負責群組與順序，節點來源負責線路資訊，規則來源負責比對範圍。本機修改應放在負責相應內容的位置。需要保留的自訂網域，不應只暫時寫入會被遠端更新取代的快取檔案，否則下次更新就可能消失。

同時使用多個來源的設定，建議記錄每個提供者的用途、格式，以及被哪些群組引用。新增來源後，先確認是否載入成功，再查看群組是否出現成員，最後測試連線。如此一來，就能區分下載失敗、格式錯誤、篩選結果為空與節點無法使用，避免把所有問題都歸咎於訂閱連結。

七、DNS、Fake-IP 與 TUN 搭配

DNS：先釐清解析依賴

dns 控制核心本身的解析行為，但只有進入這條解析鏈路的查詢才會受影響。瀏覽器可能使用內建的加密 DNS，應用程式可能指定解析器，作業系統也可能保留快取。因此，設定了新的上游位址，不代表所有程式會立即使用它。排錯前應先確認查詢從哪裡送出，最後由誰回覆。

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"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
    - 119.29.29.29

這段片段展示常見欄位之間的關係，並非適用於所有網路的通用方案。listen 只會建立監聽入口，系統不會因為它存在，就自動把 DNS 查詢送過去。在本機高連接埠監聽，也不代表路由器已提供解析服務給其他裝置；還需要分別確認用戶端的接管能力、系統設定與本機權限。

default-nameserver 常用來解析 DNS 上游本身的網域，nameserver 提供一般查詢路徑，proxy-server-nameserver 則可為節點網域指定解析器。了解這些角色，比堆疊大量公共 DNS 更重要。建立節點前所需的查詢，應有能獨立運作的解析路徑，避免查詢又依賴尚未建立的同一條代理連線。

Fake-IP：映射位址不是最終目標位址

fake-ip 會為網域配置映射位址，核心再透過映射關係還原目標網域並處理連線。看到回傳位址屬於設定的映射網段，不代表網站解析錯誤。它的前提是後續連線也會進入能辨識映射的核心；若查詢經過核心、連線卻繞過核心，應用程式可能會嘗試連線至一般網路無法直接存取的映射位址。

fake-ip-filter 可指定特定網域不使用這種映射。區域網路裝置探索或某些依賴真實位址的應用程式，可能需要個別處理，但不宜一開始就加入過大的範圍。例外範圍越廣，網域映射可提供的辨識資訊就越少；應先找出確切的異常網域，再加入最小必要範圍，並重新測試相關應用程式。

切換解析模式後，舊 DNS 快取與已建立的連線可能讓結果看起來毫無變化。可以先重新開啟目標應用程式，再依系統或用戶端提供的方法清除快取。不要同時修改上游、映射模式、嗅探與規則，否則很難判斷是哪項變更改善或破壞了連線。區域網路名稱也應檢查路由器與本機解析環境。

TUN：接管流量仍需路由與權限

TUN 透過虛擬網路介面接收流量，可涵蓋部分不讀取系統代理設定的應用程式。它不能取代規則與節點，也不保證在所有系統環境中都能直接啟用。桌面系統可能需要服務或提升權限，行動系統使用網路延伸介面，路由器則涉及閘道與轉送路徑。實際啟用步驟應以目前用戶端介面為準。

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

這是常見桌面情境的欄位片段，套用前請確認平台支援。auto-route 用來設定接管流量所需的路由，auto-detect-interface 用來偵測出站介面。多張網路卡、虛擬機器、其他 VPN 與容器網路，都可能讓自動判斷不如預期；發生斷網時，先停用 TUN 恢復原有狀態，再檢查系統路由與介面選擇。

dns-hijack 只處理符合條件的一般 DNS 流量，不會自動辨識並改寫所有 HTTPS 加密查詢。若瀏覽器使用自己的加密解析路徑，請另外確認此行為是否符合分流需求。同時啟用 TUN 與系統代理時，也應了解用戶端如何避免自身流量迴流；不要手動疊加多套來源不明的接管規則。

建議依序排查：先測試直連網路，再測試一般代理入口，接著啟用 TUN，最後檢查 DNS 與網域規則。只有啟用 TUN 才出錯時，應重點檢查權限、路由、介面與其他網路軟體的衝突；只有特定網域異常時，再檢查解析與規則。分層測試比一開始重寫整段 DNS 設定更容易找出明確原因。

八、覆寫、合併與可回復維護

分清訂閱原文與最終執行設定

遠端訂閱更新通常會重新產生或取代設定內容。直接在訂閱原文中新增規則，可能只在下次更新前有效。需要長期保留的連接埠、業務分流或 DNS 調整，應放入用戶端支援的覆寫、合併或指令碼入口。先確認功能會套用到哪些 Profile，再決定修改位置，避免全域變更意外影響其他設定檔。

不同用戶端對「合併」的定義不盡相同。對應物件可能採遞迴合併，清單可能整體取代，也可能支援前置與附加；指令碼也可能在合併後再次修改結果。不能因為功能都叫覆寫，就假設運作方式一致。最可靠的方法是透過小規模測試檢查最終設定，而不是只看輸入框中的內容就認定已生效。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

例如，若要讓工作網域優先使用特定群組，真正要做的是把對應規則放在涵蓋範圍較廣的規則之前，而不只是把文字附加到檔案末尾。如果覆寫介面只支援附加，而訂閱中已有 MATCH，新增規則可能永遠無法命中。應改用前置入口或明確的規則插入功能，並在最終設定中確認規則位置。

跨欄位引用：合併後重新檢查關係

新增策略群組時，也要檢查它引用的節點、提供者與其他群組是否存在。保留本機群組名稱，不代表成員永遠有效；遠端訂閱可能更改節點名稱或提供者名稱。建議讓長期使用的業務規則指向穩定的本機業務群組，再由該群組引用結構清楚的來源，減少規則直接依賴遠端節點名稱。

覆寫 DNS 時，也要確認是只取代某個子欄位，還是整個物件都會重新建立。如果只想更換上游，卻連監聽位址、映射模式或篩選清單也一併遺失，連線行為可能同時改變。修改前記錄原有欄位，修改後對照最終結果；不要把另一份設定中的完整 DNS 區塊，當成只修改單一參數的操作。

路徑欄位也需要重新檢查。原訂閱使用的相對目錄、用戶端覆寫檔案所在目錄與核心執行目錄可能不同。移轉至另一台裝置後，檔案提供者與快取路徑可能失效。遇到找不到檔案的錯誤，先核對工作目錄與用戶端允許存取的位置，不要任意放寬目錄權限來掩蓋路徑問題。

驗證流程：儲存、載入、連線、回復

建議每次修改都留下簡短紀錄：修改了哪個欄位、預期影響哪些連線、用什麼目標驗證，以及失敗時要還原哪份檔案。紀錄不必複雜，但要讓一週後仍看得懂修改原因。暫時用於排錯的開關也要清楚標記，完成後及時恢復，避免詳細記錄、特殊 DNS 例外或臨時直連策略長期留在設定中。

操作順序可固定為四個步驟：先備份目前有效的設定；再執行語法與核心檢查；接著套用設定並查看載入記錄；最後使用新連線檢查命中結果。設定載入成功只是中間步驟，仍須驗證實際服務。反過來說，某個網站暫時能開啟，也不能證明新規則已生效，因為可能仍在使用原有的長連線。

測試時盡量維持其他條件不變。使用相同目標、相同入口與相同節點，只比較修改前後的一個變數。如果同時更新訂閱、更換節點、切換模式並啟用 TUN，即使結果改善，也無法確認真正原因。穩定設定的價值，在於之後每次變更都有跡可循，而不是欄位愈來愈多。

也應事先規劃回復流程，並視為正常操作的一環。保留最近一份有效 Profile、對應的覆寫內容與必要的用戶端設定；還原後重新載入，並確認系統代理或 TUN 狀態與原先一致。備份檔案包含節點與訂閱資訊，應存放在受控位置。向他人求助時，提供刪減過的相關片段與錯誤資訊即可。

維護設定的原則，是讓每個欄位都有明確歸屬：訂閱管理節點來源，本機覆寫保存個人需求，策略群組組織出站路徑，規則決定流量選擇，DNS 與入口則確保連線資訊進入正確鏈路。初次操作仍以快速入門指南為主；長期使用時再依本頁章節逐步擴充，不必一次啟用所有功能。