Clash 設定完整指南

結構參考 / 01

YAML 結構與設定來源

先辨別映射、清單與引用

設定檔不是依照顯示順序執行的一串命令，而是交由核心讀取的結構化資料。冒號左側是欄位名稱，右側是欄位值；若冒號後沒有直接填值，下一層縮排通常代表子欄位。頂層的 dns 是映射，rules 是清單，proxies 則是由多個節點映射組成的清單。先辨別資料型別再修改內容，比依介面位置猜測欄位更可靠。

縮排一律使用空格，不要混用定位字元。兩個空格是方便閱讀的習慣，並非所有位置都強制只能使用兩格；重點是同一層對齊，子層比父層縮排更深。清單項目前的連字號後要加空格，一般欄位的冒號後也要加空格。全形冒號、全形空格，以及從通訊軟體複製的彎引號看似相近，卻可能導致解析失敗。

mixed-port: 7890
mode: rule

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

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

上例中，name、type 與 proxies 屬於同一個策略群組。群組內的 proxies 存放的是名稱清單，而不是節點連線參數。底部規則中的「手動選擇」必須與群組名稱完全一致，包括空格、大小寫與標點。YAML 能夠解析，只代表檔案結構正確；若引用的名稱不存在，核心仍可能拒絕載入。

字串與重複欄位的界線

名稱包含特殊標點時，建議加上引號。密碼若含井字號、冒號或前後空格，更應明確標示為字串。雙引號會處理反斜線跳脫，單引號通常適合保留字面內容，但單引號本身需要成對跳脫。數字連接埠請使用整數，布林值請寫成 true 或 false，不要為了格式一致而替所有值加上引號。

同一個映射中不要重複指定欄位。例如檔案開頭已有一個 dns，又在底部新增另一個 dns，不同解析流程可能拒絕讀取，也可能只保留後者。將新增項目放進原有映射，比仰賴重複鍵覆寫更穩妥。註解以井字號開頭，用來說明修改目的；註解不會成為執行參數，也不能靠註解掉錯誤行來掩蓋失效的引用。

確認目前編輯的是哪個檔案

用戶端通常會同時保存訂閱原始內容、本機編輯副本與最終執行設定。訂閱原始內容是遠端更新的來源；本機副本可能僅供編輯；最終執行設定則由用戶端加入連接埠、控制介面與覆寫內容後產生。先在用戶端確認目前啟用的項目，再查看執行設定或核心記錄中的載入路徑。不要只因檔案總管裡有一個 config.yaml，就認定它是目前生效的檔案。

修改前先複製原始檔，並以清楚的檔名區分用途。編輯後先儲存，再使用用戶端重新載入；只關閉編輯器通常不會觸發核心讀取。如果介面顯示儲存成功，但行為沒有變化，先檢查啟用項目、產生路徑與重新載入結果，不要立刻懷疑規則本身。訂閱更新可能會重建原始檔，需長期保留的修改應放進用戶端支援的覆寫機制。

本頁依欄位語意編排內容，不保證每個用戶端都提供所有選項。請先確認使用的是 mihomo 核心，再對照目前核心支援的欄位；舊版 Clash 用戶端不能直接視為現行 mihomo 的實作。

遇到不熟悉的欄位時，先縮小範圍至單一設定區段，確認它屬於核心、用戶端還是外部工具。用戶端專用欄位放進核心設定後，可能遭到忽略，也可能造成異常。若需要補足基本概念，可先閱讀名詞速查，再回到相關章節，不必一次弄懂所有欄位。

執行入口 / 02

連接埠、執行模式與控制介面

本機監聽與系統代理是兩回事

mixed-port 在同一個監聽連接埠接收 HTTP 代理與 SOCKS5 代理要求，適合桌面軟體統一設定。port 是獨立的 HTTP 代理入口，socks-port 則是獨立的 SOCKS 入口。一般使用時通常保留一個混合連接埠即可，不必同時啟用所有入口。連接埠數字只代表本機監聽位置，不代表伺服器位址、節點品質或固定的協定能力。

核心開始監聽，不代表作業系統已將要求交給它。系統代理開關通常由用戶端管理，負責更新系統代理設定；有些程式會讀取這項設定，有些使用獨立設定，還有些會直接建立連線。排除問題時，先確認監聽成功，再確認應用程式是否使用該入口。不要把「系統代理已啟用」和「所有程式都經過代理」視為同一件事。

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"

規則、全域與直連模式的差異

mode: rule 依規則順序決定連線去向，是理解分流設定的起點。全域模式會將一般連線交由全域策略處理，但仍須選擇合適的出口，並不會自動修復失效節點。直連模式適合暫時繞過代理進行比較。切換模式後，已建立的長連線可能仍沿用原路徑；驗證時應重新發出要求，而不只是重新整理仍在重用連線的頁面。

log-level: info 適合日常查看啟動與連線狀態；除錯時可暫時提高詳細程度，但記錄會更密集，也可能包含存取目標等敏感資訊。排除問題後請恢復原設定，分享記錄前移除訂閱網址與驗證資訊。ipv6: false 不代表作業系統已徹底停用 IPv6，也不能單獨保證應用程式不會透過其他路徑使用 IPv6，需配合 DNS 與流量接管範圍判斷。

分開設定區域網路共享與管理介面

allow-lan 控制區域網路存取能力，bind-address 則決定監聽位址。範例限定使用回送位址，只適合本機連線；即使啟用允許區域網路存取，仍須確認監聽位址是否允許其他裝置連線。若要共享，請再明確設定對應的本機介面或監聽範圍，並依家庭或辦公網路等情境限制防火牆來源。

允許區域網路存取後，手機應填入電腦的區域網路位址與代理連接埠，而不是 127.0.0.1。手機上的回送位址指向手機本身。電腦位址變更、訪客網路隔離、裝置休眠或防火牆封鎖，都可能讓共享中斷。設定方式請參閱混合連接埠與區域網路共享說明。共享前也應確認網路使用規範，避免在不可信任的網路中開放存取。

external-controller 是用戶端或面板用來管理核心的介面，不是瀏覽器存取網際網路的代理入口。維持回送位址監聽通常就足以滿足桌面用戶端需求。若確實需要遠端控制，應另外設定強式驗證並限制網路可連線範圍，不要為了手機共享代理而順手公開管理介面。介面無法連上核心時，也要分別檢查管理連接埠與代理連接埠，避免改錯位置。

遇到連接埠占用時，優先關閉另一個正在執行的代理程式，再重新載入。若必須更換連接埠，應同步修改系統代理、應用程式的獨立代理設定及區域網路裝置設定。只修改 YAML 卻保留舊的系統入口，可能導致核心運作正常，但瀏覽器一直連線失敗。每次只調整一組相關欄位，較容易確認問題來源。

名稱解析 / 03

DNS、fake-ip 與解析路徑

先確認由誰發起解析

DNS 會將網域名稱轉換成位址，但實際解析可能由應用程式、作業系統、瀏覽器、代理核心或遠端代理伺服器進行。啟用核心 DNS 只代表核心具備解析能力，不表示所有應用程式的查詢都已送進核心。系統代理通常不會自動接管所有系統 DNS；TUN 的 DNS 劫持也有自己的匹配範圍。先釐清要求路徑再選擇參數，避免一邊修改核心 DNS，一邊測試完全繞過它的瀏覽器內建解析。

dns.enable 控制核心 DNS 模組，listen 指定監聽位址。範例使用回送位址與較高的連接埠，方便理解且不占用常見系統連接埠。只設定監聽欄位，不會讓系統自動使用這個位址。桌面用戶端可能透過 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
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

fake-ip 與真實位址模式

fake-ip 會為要求的網域建立虛擬位址映射。後續連線進入核心時，核心可依映射還原網域名稱，方便進行網域分流。範例中的位址範圍是保留給此機制使用的位址，不是可填入節點 server 的公網服務位址。若解析結果落在這個範圍，請先確認是否使用 fake-ip 模式，不要立即判定為 DNS 污染。

redir-host 通常會傳回實際解析位址，適合需要真實位址結果的情境，但不代表它能通用地修復所有解析問題。切換模式會改變位址快取與連線行為，舊快取仍可能影響觀察結果。修改後應重新載入設定，並視作業系統與應用程式狀況清除快取、重新啟動相關應用程式。先測試明確的單一目標，再逐步擴大範圍，不要同時修改模式、上游與規則。

fake-ip-filter 用來讓特定網域略過虛擬位址分配。區域網路服務、裝置探索或依賴真實位址的應用程式，可逐項加入；但過大的過濾範圍會降低網域映射帶來的便利。不同過濾模式與匹配語法各有明確語意，不能把所有項目都當成一般正規表示式。優先從確實異常的網域開始，記錄加入原因，避免長期累積難以說明的過濾清單。

上游解析與節點網域解析

nameserver 是一般查詢使用的上游伺服器清單，default-nameserver 可用來引導解析上游 DNS 服務的網域名稱。若所有上游都填網域，卻沒有可用的初始解析路徑，可能形成啟動相依問題。proxy-server-nameserver 用於解析代理伺服器的網域名稱，讓節點位址不必先仰賴尚未建立的代理連線。上游應依所在網路的可達性選擇，不是數量越多越穩定。

nameserver-policy 可依指定網域或匹配範圍選擇上游；fallback 與相關過濾條件則用來依條件判斷解析結果。它們並非簡單的「第一個失敗就改問第二個」。若沒有明確需求，先採用容易理解的單一路徑。若要搭配路由規則控制 DNS 上游連線，還須確認相關欄位是否受支援，以及節點網域解析的安排，避免解析與代理互相等待。

使用加密 DNS 只會改變某段解析的傳輸方式，不會自動接管應用程式，也不代表所有網路出口已統一。判讀檢測結果時，應一併查看系統 DNS、瀏覽器設定與目前的連線記錄。

排除問題時，先測試網域能否解析，再確認傳回的位址能否建立連線，最後核對要求使用的出口。若只有網域無法連線、但直接連位址可以，才比較像是解析問題；憑證錯誤與伺服器拒絕不能直接歸因於 DNS。進一步操作請參閱DNS 檢測與 fake-ip 設定實作，保留原本的上游設定，方便逐項比較與還原。

出口設定 / 04

代理節點與遠端節點集合

節點欄位必須符合實際服務

proxies 存放節點連線參數。每個節點至少需要可供引用的名稱，以及協定要求的位址、連接埠與驗證欄位。節點是實際出口，策略群組是選擇出口的方法，兩者不能互換。訂閱已提供節點時，通常不必逐一手動輸入；只有需要檢查欄位、接入自有服務或建立最小測試設定時，才應編輯節點區段，並先保留原始內容。

以下使用 HTTP 代理說明欄位結構，網域與驗證資訊皆為假資料，無法直接建立連線。server 只填主機名稱或位址，不要附加 https:// 或網頁路徑；port 是遠端服務的連接埠，不是本機混合連接埠。驗證欄位應依服務端提供的資訊設定，不能靠修改名稱或更換連接埠猜出可用設定。

proxies:
  - name: "教學出口"
    type: http
    server: proxy.example.com
    port: 443
    username: "your-username"
    password: "your-password"
    tls: true
    sni: proxy.example.com
    skip-cert-verify: false

name 在設定中作為識別名稱。更名後，必須同步更新策略群組與直接指向該節點的規則；名稱相同但參數不同，也容易在合併時造成混淆。建議為本機新增的節點使用容易辨認的前綴，但不要把密碼、訂閱識別碼或個人聯絡資訊寫進名稱。節點名稱可能出現在介面、記錄與截圖中，應視為可能被分享的資訊。

協定參數與傳輸參數不要混填

不同協定使用的欄位各不相同。Shadowsocks 常見加密方式與密碼，Trojan 使用自己的驗證與 TLS 設定，VMess、VLESS 等協定則各有身分識別與傳輸欄位。看到其他設定中有 uuid、network 或傳輸選項，不代表這些欄位適用於目前節點。先確認協定，再核對伺服器端的傳輸方式，最後確認核心支援範圍；不要把多種範例拼成同一個節點。

TLS 的伺服器名稱與憑證驗證屬於另一層檢查。使用位址連線時，伺服器憑證可能仍是簽發給網域，因此需依實際服務設定 sni，不能任意填寫。關閉憑證驗證會放棄重要的身分檢查，不適合作為日常排錯捷徑。遇到憑證錯誤時，請檢查系統時間、伺服器名稱與伺服器憑證鏈；相關處理方式請參閱HTTPS 憑證錯誤原因與處理方式。

節點欄位中的 UDP 能力也要分層判斷。核心支援某種傳輸，不代表遠端服務、所在網路與目標應用程式都支援相同路徑。HTTP 代理範例不能視為任意 UDP 出口。若網頁正常，但語音、遊戲或其他應用程式異常，應檢查實際使用的協定與遠端能力，不要只看用戶端是否顯示已連線。訂閱中不熟悉的協定擴充也應先確認，不要直接刪除。

provider 是節點集合，不是策略選擇

proxy-providers 可從檔案或遠端資源載入一組節點。策略群組透過 use 引用集合名稱，再將其中節點加入可選範圍。遠端資源必須提供核心能識別的節點集合格式；完整訂閱檔不一定能與 provider 檔案互換。資源下載成功只代表取得了內容，仍須確認格式、欄位與節點清單是否有效。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: "訂閱出口"
    type: select
    use:
      - local-nodes

上例需要本機檔案存在，且檔案內容應包含相應的 proxies 清單。相對路徑通常依核心工作目錄或用戶端指定的設定目錄解析，不一定是目前編輯器開啟的目錄。下載、更新與健康檢查是不同動作：更新負責取得節點參數，健康檢查負責測試可用性，選擇策略則決定實際使用哪個節點。某一步成功，不能取代其他步驟的結果。

真實訂閱網址通常含有個人存取憑證。請勿放進公開設定、問題截圖或程式碼儲存庫；需要展示結構時，請改用明顯的假資料。更新失敗時，先檢查網路、訂閱是否有效及回傳內容類型，再處理 YAML。伺服器若回傳登入頁面或錯誤說明，即使副檔名仍是 YAML，也無法載入為正常的節點集合。

選擇邏輯 / 05

策略群組類型與引用關係

先確認手動選擇路徑可用

proxy-groups 將節點或其他策略整理成可選的出口。初次編寫時，先建立一個 select 群組，並在介面手動選擇已確認可用的節點。如此可分辨「節點連線失敗」和「自動選擇邏輯不如預期」。規則最終可指向群組名稱，由群組再解析至實際節點，形成清楚的引用鏈，不必為每個網域重複填寫節點名稱。

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - 教學出口
      - DIRECT

  - name: "網頁瀏覽"
    type: select
    proxies:
      - 手動選擇
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,網頁瀏覽
  - MATCH,手動選擇

這段範例使用前一章定義的「教學出口」。存取範例網域時，規則會先交給「網頁瀏覽」；若該群組選擇「手動選擇」，便會繼續使用後者目前選取的成員。巢狀引用可減少重複管理，但不要形成循環。甲群組引用乙群組，乙群組又引用甲群組，就無法產生明確出口。檢查設定時，從規則目標往下追蹤，直到節點或內建策略為止。

自動探測不等於實際使用體驗

url-test 依探測結果選擇成員，fallback 依候選順序使用可用成員，load-balance 則依相應策略分配連線。它們解決的問題不同，不能只因為都有自動化行為就任意替換。測速網址反映的是到該探測目標的結果，不代表某個影音網站、工作服務或帳戶登入也會有相同表現；遇到特定服務異常時，應針對該服務實際測試。

proxy-groups:
  - name: "自動探測"
    type: url-test
    proxies:
      - 教學出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

範例只放一個候選項目以展示結構；實際比較需要多個可用成員。interval 是探測間隔，tolerance 用來減少因細微差異造成的切換，lazy 會影響群組未使用時的探測行為。探測越頻繁，背景要求越多，不一定能帶來更好的體驗。行動裝置也要考慮背景限制與耗電，先採用用戶端的合理預設值，再依明確狀況調整。

自動群組切換後，既有長連線通常仍沿用原本出口，新連線才會使用新的選擇。測試時應建立新連線，並在連線面板核對實際路徑。有些服務會將登入狀態與出口環境連結，頻繁切換可能增加重新驗證的機會。若需要維持工作階段穩定，可為該服務建立獨立的手動群組，而不是讓所有連線共用相同的自動切換行為。

集合引用、篩選與保留選擇

群組中的 proxies 會明確列出成員名稱，use 則引用 provider 名稱。篩選運算式通常依名稱篩選，無法證明節點確實位於名稱所描述的位置，也不會驗證其網路屬性。訂閱更名後，篩選條件可能會找不到任何成員。先查看最終成員清單，再檢查運算式；不要因為群組名稱仍存在，就認定裡面還有可用節點。

內建的 DIRECT 代表直連，REJECT 代表拒絕連線，兩者都不是遠端節點。將直連放進自動探測群組，會讓它參與候選比較；若只想在故障時手動切換，應將它放進外層手動群組。自動備援與直連備援也不是同一回事：是否允許繞過代理是路由決策，應依實際使用情境明確設定。

有些用戶端會保存策略群組的選擇，重新載入設定後盡量恢復原選項；這通常取決於群組名稱、成員名稱與持久化機制。更改群組名稱或訂閱移除節點後，舊選擇不一定能恢復。核心的 profile.store-selected 可能與選擇保存有關，但用戶端也可能自行管理狀態。查看介面目前的值比只看 YAML 更可靠，請勿依檔案排列順序推斷最後選取的項目。

新增策略群組後，依序檢查：成員是否存在、是否形成循環、規則引用是否正確，以及目前選項是否可用。四項都確認後，策略群組才算接入實際流量路徑。

需要區分「規則」、「策略群組」與「節點」時，可將它們理解為匹配條件、選擇入口與連線參數三個層次。規則決定交給哪個群組，群組決定使用哪個節點，節點決定如何建立遠端連線。保持結構簡單，日後替換節點通常只需修改群組成員，不必重寫整套服務規則。

流量匹配 / 06

規則順序、規則集與預設規則

由上而下匹配，命中後採用指定策略

在規則模式下，一般路由規則會依順序匹配；命中後使用該條規則指定的目標。較具體的例外通常應放在較寬泛的規則之前，最後再用 MATCH 接住未匹配的連線。若把預設規則放得太前面，後續規則就不會有機會匹配。網域出現在清單中，不代表該條規則實際生效；前面可能已有涵蓋該網域的後綴規則、位址規則或規則集。

rules:
  - DOMAIN,login.example.com,手動選擇
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,example,手動選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,手動選擇

上例先將指定的登入網域交給代理，再將其他範例網域交由直連。若調換前兩條規則，登入網域會先符合後綴規則。範例的目標「手動選擇」必須已經定義。規則語法中的逗號是欄位分隔符號，不要換成中文逗號；目標名稱也不要加上額外說明。編輯規則後，先挑選一個明確目標，觀察命中的類型與策略，再測試其他網站。

網域資訊與位址資訊不一定同時存在

網域規則需要核心取得目標網域名稱。使用明確的 HTTP 代理或 SOCKS 網域名稱要求時，資訊通常較完整；若應用程式先自行解析，再連線至位址，核心看到的資訊可能不同。fake-ip 映射與嗅探有助於還原網域，但各有適用條件，無法保證辨識所有加密流量。先確認連線面板實際顯示的內容，再判斷網域規則未命中的原因。

no-resolve 適用於特定位址匹配規則，可避免只為嘗試匹配該規則就主動觸發網域解析；若連線本身已有可匹配的位址，仍可能命中。此選項不會停用所有 DNS，也不會改變應用程式自行發出的查詢。位址規則放得很前面時，是否觸發解析會影響路徑與耗時，應一併考量網域規則的優先順序，不要機械式地替每條規則加上相同選項。

規則集的宣告與使用必須成對設定

rule-providers 定義可重複使用的規則集合，RULE-SET 則將集合加入規則清單。只有宣告不會自動進行分流。behavior 決定內容依網域、位址範圍或傳統規則解讀，format 決定檔案格式；兩者必須符合實際檔案。也要區分遠端更新網址與本機快取路徑，快取存在不代表最近一次更新成功。

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,手動選擇

配套的本機規則檔可採用以下結構。這裡的項目屬於網域集合，不是完整的三段式路由規則，因此不需要附加策略名稱。若把傳統規則行放進網域集合，可能造成解析錯誤或匹配結果不符預期。移植第三方規則來源時，先查看檔案實際內容，不要只根據檔名猜測格式。

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

在路由器、容器或 TUN 流量中使用程序規則時，還需確認執行環境能否辨識程序。桌面應用程式名稱規則不能直接推定適用於路由器，因為路由器看到的是遠端裝置的連線。部署背景請參閱OpenWrt 旁路由部署概覽。規則應依可觀測的資訊撰寫，不要讓設定依賴執行環境根本無法提供的欄位。

最後驗證至少要記錄目標網域、命中規則與實際出口三項資訊。只看網頁能否開啟，無法分辨代理連線成功或是直連可達。遇到異常時，先暫時新增一條精確規則進行驗證，再決定是否擴大匹配範圍；過於寬泛的關鍵字或整段位址規則容易影響其他服務，也會讓後續問題難以重現。

持續保留修改 / 07

訂閱覆寫、合併與更新後保留

先了解設定的產生流程

訂閱更新會重新取得遠端內容，直接編輯下載檔案的修改可能因此遺失。用戶端提供的覆寫、合併、擴充設定或指令碼，通常會在原始內容上進一步加工，但執行位置與合併方式各不相同。先確認訂閱原始內容、用戶端通用設定、訂閱專屬覆寫與最終執行設定的先後關係，再決定修改應放在哪一層。

連接埠、系統代理與 TUN 等項目通常由用戶端介面管理，訂閱中的同名欄位可能會被覆蓋。規則與策略群組則可能透過訂閱專屬擴充新增。不要在多個入口同時修改同一欄位，否則下次重新載入後很難判斷最後生效的是哪一項。先指定單一負責入口，修改後查看實際執行設定確認結果；介面顯示的輸入內容只代表設定意圖，不一定等於核心最後讀取的值。

分別確認映射與清單的合併方式

映射可逐欄位遞迴合併，也可能整體取代。例如覆寫只寫入 dns.enable，某些機制會保留原有上游，另一些則可能取代整個 DNS 區段。清單更需要謹慎處理：規則、節點與策略群組可能被附加、插入前方、依名稱合併或整體取代。不能一概認定「合併 YAML 就一定會保留原清單」，應以目前用戶端的說明與產生結果為準。

# 原始設定中的一個片段
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

# 覆寫目的：只修改這個項目
# 請填入用戶端的獨立覆寫入口，不要重複附加到原始檔
# dns:
#   enhanced-mode: redir-host

上例以註解表示覆寫目的，是為了避免複製後在同一映射中產生重複欄位。實際操作時，請在用戶端的獨立覆寫入口填入相應欄位，再檢查 nameserver 是否仍保留。若已遺失，代表目前的機制無法依預期遞迴合併，必須明確保留整個 DNS 區段。測試時不要順便修改上游，才能將結果歸因於合併方式。

規則插入前方、去重與名稱衝突

本機例外規則通常必須放在訂閱規則前面，才能在寬泛規則或 MATCH 之前命中。若工具只支援附加，將例外加在清單末尾可能完全不起作用。先檢查產生後的規則順序，確認預設規則仍在最後，再測試實際匹配結果。不要為了「去重」而任意調整規則順序；路由清單的先後順序本身就有語意，依字母排序會改變行為。

新增策略群組時，最好使用不易與訂閱發生衝突的名稱。若訂閱更新後出現同名群組，依名稱合併可能改變其成員，整體取代則可能刪除原有選擇。使用節點名稱篩選時，也要考慮遠端節點可能改名。將重要服務綁定至穩定的本機策略入口，再由入口選擇訂閱群組，通常比讓每條自訂規則直接依賴遠端節點名稱更容易維護。

指令碼覆寫更有彈性，也更容易破壞設定結構。修改前應先確認指令碼取得的是物件還是文字、回傳值是否必須是完整設定，以及發生錯誤時用戶端會保留舊設定還是停止載入。不要複製來源不明且會讀取外部資源的指令碼。設定可能包含訂閱網址與驗證欄位，應將擴充指令碼視為能接觸這些資訊的程式，而不是一般註解。

透過一次更新測試修改是否保留

完成覆寫後，先重新載入並驗證功能，再手動執行一次訂閱更新。比較更新前後的執行設定，檢查自訂規則、群組名稱、DNS 上游與連接埠是否符合預期。更新成功不代表覆寫成功；舊設定仍在執行，也不代表新設定已載入。留意記錄中的產生與重新載入結果，確認測試的是目前檔案，而不是更新失敗後保留下來的舊執行個體。

建議保存三份資料：可用的原始設定、獨立覆寫內容，以及修改原因記錄。需要復原時，先還原原始設定，再單獨啟用覆寫，避免將訂閱變更與本機修改混在一起排查。

記錄不必很長，但應說明修改欄位、預期結果與驗證目標。例如「為區域網路裝置保留真實解析結果」比「最佳化 DNS」更清楚。日後問題再次出現時，可依目的判斷這項修改是否仍有必要。用途不明的舊覆寫應逐項停用並驗證，不要長期保留後又不斷疊加修補。

更換用戶端時，不要只複製產生後的執行檔。舊用戶端注入的控制介面、檔案路徑與面板設定可能不適用於新環境。先從用戶端下載頁面選擇適合的平台，一般使用者可優先考慮 Clash Plus；重新匯入原始訂閱後，只移轉確實需要的本機覆寫，最後依本頁的驗證流程逐項檢查。

驗證流程 / 08

設定檢查、連線驗證與復原

先檢查語法，再確認接管範圍

儲存檔案後，先使用用戶端內建的檢查或重新載入功能，查看是否有解析錯誤、無效引用或檔案路徑異常。獨立執行 mihomo 時，可在正確的工作目錄執行以下測試命令。請依本機實際位置調整執行檔名稱與路徑；命令檢查成功不代表每個遠端節點都能連線，也不能取代系統代理與 TUN 接管驗證。

mihomo -t -d . -f ./config.yaml

錯誤訊息包含行號時，請從該行往前檢查同層縮排，以及前一行的引號與冒號。解析器指出的位置可能只是發現問題之處，真正原因也許是更早出現的字串未關閉。若提示策略不存在，請依序核對節點、群組與規則中的名稱；若提示資源檔案不存在，請檢查工作目錄、相對路徑與存取權限。看到錯誤文字時，不要立刻整段取代設定。

使用最小直連設定排除本機問題

以下是一份獨立的最小直連測試設定，只用來驗證核心監聽與基本規則路徑。它不包含遠端代理，也不會自動將目標流量改為代理出口。建議另存並單獨載入，避免覆蓋原有訂閱。若原用戶端正占用相同連接埠，請先停止原執行個體，或明確更換測試連接埠並同步修改測試命令。

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

rules:
  - MATCH,DIRECT

若最小設定也無法啟動，請優先處理連接埠占用、權限與執行檔問題。啟動成功後，再透過明確代理要求測試目前網路原本就能存取的位址。不同作業系統對 curl 的命令對應可能不同；在 Windows 上可明確使用 curl.exe。以下命令不會修改系統代理，只測試指定的本機 HTTP 代理入口。

curl --proxy http://127.0.0.1:7890 --head https://example.com

收到 HTTP 回應，代表這次要求已完成對應的連線路徑，但仍須依目標網站判斷回應狀態。連線本機連接埠遭拒時，請著重檢查監聽與連接埠；成功連上代理後逾時，則檢查 DNS、路由與出口；出現憑證驗證錯誤時，請轉而檢查憑證與系統時間。不要將所有失敗都歸因於「節點不可用」，也不要關閉憑證驗證來掩蓋原因。

逐層恢復至實際設定

最小測試成功後，恢復原有設定，先只驗證一個已知節點與一個手動群組，再加入 DNS 設定、規則集與覆寫。每新增一層，就重複測試相同目標並記錄記錄差異，藉此找出問題從哪一層開始出現。明確代理能連線、一般瀏覽器卻無法連線時，問題較可能出在應用程式代理設定或接管範圍，不應立即重寫節點參數。

TUN 也涉及虛擬網卡、路由、權限與 DNS 接管。啟用後應分別測試網域要求與位址連線，並確認區域網路資源是否仍可存取。其他 VPN、虛擬機器與安全軟體也可能修改路由，不宜同時切換多種網路工具。桌面系統代理與 TUN 適用於不同情境；先選定一條明確路徑完成驗證，再依應用程式需求決定是否搭配使用。

驗證規則時，請查看新建連線命中的規則與最終出口，不要只看總開關狀態。瀏覽器快取、連線重用與背景要求可能讓一次頁面重新整理包含多種結果，必要時先關閉目標應用程式再重試。分享截圖時，請遮蔽目標帳戶、訂閱網址與節點驗證資訊，只保留排除問題所需的欄位、錯誤訊息與相關設定區段。

無法連線時先復原，再繼續排查

復原順序是先關閉新啟用的接管功能，再還原系統代理，最後載入先前保存的可用設定。退出用戶端後仍無法連線時，請檢查系統是否留下指向已關閉連接埠的代理設定；TUN 或其他工具留下的路由也要依正常關閉流程復原。不要接連安裝多個用戶端來試圖蓋過問題，這只會增加連接埠與系統設定衝突。

網路恢復後，再從最近一次修改開始逐項重做。訂閱更新、切換核心、變更規則與調整系統網路，應盡量分開進行。若持續出現「連線成功但網頁無法開啟」，可依八步無法上網排查清單核對訂閱、出口、系統入口與 DNS；需要重新走過主要操作流程時，請返回訂閱匯入與連線教學。

完成設定修改的標準是：檔案可以載入、目標要求依預期匹配、訂閱更新後修改仍保留，而且已知道如何復原。完成這四項後，再繼續下一項調整。