Clash YAML 設定手冊

一、YAML 結構與設定生效方式

Clash 設定檔不是逐行執行的指令碼，而是一組有層級的資料。頂層欄位用來設定監聽方式、代理來源、策略組與規則；核心讀取整份檔案後，才建立相應物件。理解這點很重要：把規則寫在檔案最後，不代表它最後才建立；真正影響比對先後的是 rules 清單內的順序。檔名可以不同，副檔名也可能是 .yml；用戶端實際載入哪一份檔案，則以目前選取的設定為準。

先辨識映射、清單與字串

冒號用來連接欄位名稱與值，冒號後通常要加一個空格；連字號表示清單項目。縮排代表從屬關係，建議統一使用兩個空格，不要使用 Tab。以下的 proxies 是策略組中的候選項目，不是頂層代理節點清單。兩者雖然同名，所處層級卻不同。遇到解析錯誤時，先檢查錯誤行前後的縮排，而不只是該行文字。

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

proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選擇

這是一份用來理解結構的直連設定：它會開啟混合代理連接埠，但所有連線最後都會直連，不具備遠端代理功能。用它確認核心能否讀取檔案，比一開始就匯入複雜規則更容易找出語法問題。清單中的 DIRECT 是內建輸出，不必另外宣告。策略組名稱必須與規則引用的名稱完全一致；空格、標點或大小寫不同，都可能導致引用失敗。

區分訂閱原文與執行設定

在 Clash Plus、Clash Verge Rev 等用戶端中，遠端訂閱通常只是設定來源。用戶端還可能加入連接埠設定、TUN 開關、全域擴充功能和目前訂閱的覆寫，最後產生供核心執行的檔案。因此，直接修改暫存產生的檔案通常無法永久保留：下次切換訂閱、儲存設定或重新啟動時，都可能再次產生新檔案。請先確認目前編輯的是訂閱副本、持久覆寫，還是僅供檢視的執行結果。

一般 YAML 檔案即使通過語法檢查，也不一定符合 mihomo 的欄位要求。例如把 proxy-groups 寫成字串，一般解析器可能接受，但核心需要的是清單。反過來說，檔案語法與結構正確，也不代表節點一定連得上：網域、驗證資訊和遠端服務仍須另外確認。排錯時將「能讀取」、「能啟動」和「能建立連線」分開檢查，可減少反覆修改無關欄位。

儲存前檢查三個細節

第一，請使用 UTF-8 儲存，避免編輯器把中文組名轉成亂碼。第二，包含冒號加空格、井字號或特殊標點的字串應加上引號；引號外以井字號開頭的內容是註解，不屬於值。第三，同一層映射不要重複使用相同鍵名。不同解析器處理重複鍵的方式可能不同，有些會報錯，有些只保留最後一項，不能把這種行為當成可靠的合併方式。

調整前先保留一份可正常運作的設定，再複製到測試用設定中修改。若有獨立的 mihomo 執行檔，可使用 mihomo -t -f config.yaml 測試設定；請使用與用戶端相同的核心，並確認相對路徑所依據的目錄。測試成功後仍須重新載入，並從日誌確認目前設定已成功套用。訂閱回傳內容異常時，可接著閱讀訂閱解析失敗自我檢查清單。

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

通用欄位決定核心如何接收本機連線，以及連線進入後是否依規則選擇輸出。這些設定不能取代 Windows 系統代理設定：核心開始監聽，只代表應用程式可以連到該連接埠；是否有應用程式將請求送過來，還取決於用戶端的系統代理開關、應用程式自身的代理設定，或 TUN 接管。瀏覽器設定後沒有變化時，應先檢查流量入口，不要立刻更換節點協定。

port、socks-port 與 mixed-port

不必為了「完整」而同時開啟三種代理連接埠。一般桌面使用情境，一個混合連接埠通常就夠了。連接埠號可以調整，只要在有效範圍內、未被占用，且與應用程式填入的值一致即可。本文使用的 7897 僅為範例，不代表每個用戶端都採用這個預設值。修改後，先前手動填入舊連接埠的瀏覽器擴充功能、命令列工具和下載器也要一併更新。

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

這組設定適合作為僅供本機應用程式存取的起點。allow-lan: false 表示不提供區域網路裝置連線；明確指定回送位址，也能進一步表明僅供本機使用。若要讓手機連線使用電腦的代理，需調整相關限制、使用電腦的區域網路位址，並在可信任的網路範圍內設定 Windows 防火牆。不要為了排錯而直接關閉整個防火牆，也不要將本機代理連接埠轉送到公網。

規則模式與策略組是兩層設定

mode: rule 會讓連線依序比對規則；global 使用全域輸出選擇；direct 則讓連線直接連線。切換全域模式不會修改原有規則文字，只會改變目前的路由方式。在規則模式下，某條規則可能指向選擇組，而選擇組又指向直連，因此「處於規則模式」不代表請求一定經過遠端代理。驗證時應查看實際命中的規則與最後的輸出路徑。

用戶端介面上的模式按鈕可能會在執行時覆蓋檔案中的值，也可能在重新產生設定時寫回檔案。若每次重新啟動都切回另一種模式，應檢查用戶端的持久設定，而不是反覆修改訂閱。排錯時可暫時將 log-level 提高至 debug，結束後再恢復為 info；除錯日誌可能記錄網域與連線細節，分享前請清除訂閱網址、驗證資訊與個人連線紀錄。

頂層 IPv6 與控制介面

頂層的 ipv6 控制核心對 IPv6 的相關支援，與後文 DNS 中同名欄位所處的層級不同。關閉它不等於關閉 Windows 網路卡的 IPv6，也無法單憑此設定證明所有應用程式都已被接管。若網路需要 IPv6，應一併檢查流量入口、路由、解析與節點能力，而不是長期依賴關閉開關來掩蓋路徑不一致。

external-controller 是管理介面，不是瀏覽器使用的 HTTP 代理連接埠。用戶端通常會管理其位址與存取驗證，不建議在訂閱中任意修改。若連線面板突然無法顯示，但代理仍可使用，應區分管理介面連線中斷與代理監聽失效。可在 PowerShell 執行 Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue 檢查連接埠占用狀況，並搭配程序資訊確認占用者；不要直接結束不明的系統程序。

三、代理節點與訂閱提供器

節點定義描述如何連線至遠端代理服務。頂層的 proxies 通常是節點清單，每個項目包含名稱、協定類型、伺服器位址、連接埠及該協定專用的驗證資訊。名稱是供策略組引用的本機識別名稱，不會自動變成伺服器位址。重新命名節點可以讓介面更容易辨識，但必須同步修改明確引用該節點的組；若訂閱更新會重新產生名稱，透過提供器或穩定的組織架構管理會更合適。

共用欄位與協定專用欄位

server 可以是網域或 IP 位址；port 是服務端實際監聽的連接埠，不能把分享連結中的任意數字當成它。不同協定的驗證方式各異：Shadowsocks 通常使用加密方式與密碼，Trojan 使用密碼並涉及 TLS，VLESS 則有自己的識別資訊與傳輸參數。只修改 type 並不能將節點轉換成另一種協定，服務端必須提供相符的服務。

proxies:
  - name: "本機 SOCKS 入口"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: "出口選擇"
    type: select
    proxies:
      - "本機 SOCKS 入口"
      - DIRECT

這段範例使用實際的 SOCKS5 欄位，但只有在本機確實有 SOCKS 服務監聽連接埠 1080 時才能轉送流量。它不提供遠端節點，也不應指向 mihomo 自己的混合連接埠，否則可能形成迴圈。範例選用本機位址，是為了說明資料結構，避免使用虛構的驗證資訊。實際節點參數應向服務提供者取得並逐項核對，不要用網頁範例取代自己的驗證資訊。

udp: true 表示允許該節點處理相應的 UDP 流量，不會讓原本不支援 UDP 的服務自動具備這項能力。協定實作、伺服器設定、中間網路與流量入口接管方式都可能影響結果。若網頁正常，但語音或遊戲異常，應先確認應用程式使用的傳輸方式，再檢查節點是否支援，而不要只因網頁能開啟就認定整條連線正常。

proxy-providers 是代理集合的來源

設定需要獨立更新節點集合時，可以使用 proxy-providers。提供器內容通常是包含 proxies 清單的代理集合，不應將任意完整設定檔網址都當成相同格式使用。HTTP 提供器會取得遠端內容，檔案提供器則讀取本機檔案；提供器本身不等同於策略組，必須由組透過 use 引用。以下用本機檔案說明兩者的關係，路徑應位於核心允許讀取的設定目錄範圍內。

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

proxy-groups:
  - name: "訂閱出口"
    type: select
    use:
      - local-pool
    proxies:
      - DIRECT

對應的 local-pool.yaml 應包含節點清單，而不是再包一層 proxy-providers。相對路徑通常依據執行目錄或核心工作目錄，不一定是目前在編輯器中開啟的資料夾。遇到找不到檔案時，應查看用戶端顯示的設定目錄與核心日誌；不要隨意將檔案移入系統目錄，也不要為了繞過路徑限制而擴大整個磁碟的存取權限。

依層次檢查連線失敗

先檢查服務端網域能否解析，再確認目標連接埠是否可連線，接著核對驗證資訊、TLS 名稱與傳輸參數。用於 TLS 憑證驗證的名稱不一定等於連線位址，必須依服務端要求填寫。遇到憑證錯誤，應優先檢查系統時間、憑證鏈與名稱，不要把略過憑證驗證當成日常修復方式。連線逾時和驗證遭拒是不同階段的問題，日誌中的錯誤類型比反覆更換連接埠更有參考價值。

訂閱網址通常包含存取憑據，在截圖、日誌與公開提問中都應隱藏完整連結。更換用戶端前先保留訂閱來源，再從用戶端頁面選擇對應平台；本站優先推薦 Clash Plus，也提供 Clash Verge Rev 等選擇。不同圖形介面用戶端對擴充欄位的處理方式不盡相同，遷移時需確認核心支援範圍，可參考mihomo 與原版核心的差異了解欄位來源。

四、策略組：選擇、測速與回退

策略組介於規則與實際節點之間。規則可以指向組，由組決定使用哪個節點；組也可以指向另一個組，形成分層的輸出架構。如此一來，更新節點集合時，不必同步修改所有網域規則。組名應簡短且穩定，盡量表達用途，例如「工作出口」、「媒體出口」；名稱本身不會帶來特殊行為，真正決定演算法的是 type 與相關欄位。

select 適合需要明確控制的情境

select 是手動選擇組，由使用者在用戶端介面中決定目前的候選項目。候選項目可以是節點、其他組，以及 DIRECT 等內建輸出。首次載入時的選擇結果取決於用戶端是否保存先前的選擇紀錄，不能只根據清單第一項推斷目前的輸出。修改設定後，應到代理頁面實際確認一次，尤其是該組曾選過直連、舊節點或已刪除的候選項目時。

proxy-groups:
  - name: "自動回退"
    type: fallback
    proxies:
      - "本機 SOCKS 入口"
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: "出口選擇"
    type: select
    proxies:
      - "本機 SOCKS 入口"
      - "自動回退"
      - DIRECT

此片段引用上一章定義的本機節點，不能單獨取代整份設定。fallback 會依候選順序選擇可用的輸出，範例刻意將直連放在最後，方便說明回退行為。如果業務需求是在遠端代理中斷時停止連線，就不應將 DIRECT 放進回退組。設定可用與隱私目標是兩回事；回退成功只代表選到可用的候選項目，不代表仍走原本的網路路徑。

url-test 與 fallback 的判斷方式不同

url-test 會依據探測結果選擇候選項目，通常用來自動挑選回應較快的輸出；fallback 則更著重候選順序與可用狀態。interval 的單位是秒，表示探測間隔，不是每個業務連線的逾時時間。tolerance 可用來減少因細微差異而頻繁切換，但不能保證業務延遲。切換組內候選項目通常會影響新連線，既有連線未必會立即切換。

測速網址應選擇能穩定回傳預期回應的 HTTPS 網址。範例中的網址僅作為探測目標，不是網站外部資源的依賴。某個探測目標可連線，不代表所有網站都能連線；反過來說，探測網址遭封鎖，也可能讓正常節點顯示異常。不要根據單次探測結果判斷方案頻寬，更不要把探測耗時當成下載速度。排錯時可手動開啟相同網址，並對照日誌確認測試經過哪個節點。

巢狀關係須保持單向

組可以引用其他組，但不能形成迴圈。例如「出口選擇」引用「自動選擇」，而「自動選擇」又引用「出口選擇」，不會讓決策更智慧，只會造成無效依賴。提供器透過 use 加入，明確指定的節點則透過 proxies 加入，兩者可視需求搭配使用。若候選清單突然變空，請檢查篩選條件是否過於嚴格、提供器是否更新成功，以及組名是否在覆寫中遭到取代。

負載平衡不會把單一下載連線拆成多條線路來疊加速度。不同的分配演算法可能讓同一業務的不同連線使用不同輸出，進而觸發登入驗證或工作階段異常。工作帳號登入、付款及需要固定來源位址的服務，較適合明確選擇單一輸出。一般桌面設定先保留一個手動組和少量清楚的巢狀層級，比堆疊大量名稱相近的組更容易維護，也更容易從連線紀錄追查實際路徑。

五、規則語法與由上而下比對

在規則模式下，mihomo 通常會由上而下比對 rules 清單，命中後使用該規則指定的輸出。因此，規則的位置與內容同樣重要。若將範圍寬泛的直連規則放在前面，後面的精確網域規則可能永遠沒有機會生效。設定自訂規則前，先確認要比對的是網域、目標 IP、程序或其他屬性，再選擇規則類型，不要只複製看起來相似的文字。

網域規則不填寫完整網址

DOMAIN 用於精確比對網域；DOMAIN-SUFFIX 用於比對網域及其子網域；DOMAIN-KEYWORD 則依關鍵字比對，涵蓋範圍通常較廣。欄位中不包含 https://、路徑或查詢參數。一般網域規則無法依網頁網址中的路徑區分內容；同一網站的登入頁、圖片與 API 也可能使用不同網域，因此應從實際連線紀錄觀察，不要只處理網址列中的主網域。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選擇
  - 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,出口選擇

範例使用文件保留網域，不對應任何實際服務。「出口選擇」必須已存在於策略組中。最後的 MATCH 是兜底規則，會接收先前未命中的連線，通常放在清單末尾。它前面的私有位址規則用來說明區域網路直連，但仍須依實際網路環境檢視：某些企業網段可能必須透過指定通道存取，不能一概認為「私有位址」就一定能在本機直連。

了解 no-resolve 的限制

IP 類規則可能需要先取得目標位址。如果請求帶有網域名稱，解析動作可能改變後續的比對路徑。加入 no-resolve 表示比對這條規則時不主動觸發網域解析；已取得目標 IP 的連線仍可參與比對。這不代表「這條連線永遠不會使用 DNS」，也不會讓網域自動對應到某個位址。若要穩定依網域分流，通常應優先設定網域規則，再視需要補上 IP 規則。

程序規則適合依 Windows 應用程式分流，但前提是核心能辨識連線所屬的程序。流量入口、權限與系統環境都可能影響辨識結果。瀏覽器連線可能涉及多個子程序，應用程式更新也可能改變執行檔路徑；設定規則前，應先在連線詳細資料中確認實際程序資訊。程序規則能夠比對，不代表具備防火牆等級的隔離效果；若需要嚴格限制網路存取，還應使用作業系統提供的控制功能。

規則提供器須同時確認格式與行為

rule-providers 用於整理可重複使用的規則集合，與代理提供器的內容不同。behavior 表示如何解讀集合中的項目，常見值包括 domain、ipcidr 和 classical；format 則描述檔案格式。兩者分別回答「裡面是哪種規則」與「檔案如何編碼」，不能互相取代。以下使用本機的傳統規則集合，方便查看各項設定的對應關係。

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

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,出口選擇

# ./rules/local-domains.yaml 的內容：
# payload:
#   - DOMAIN-SUFFIX,example.com
#   - DOMAIN,intranet.example.org

規則集合中的項目不會附帶輸出，因為引用位置的 RULE-SET 已指定目標。規則集載入失敗時，應先檢查路徑、回傳內容與格式，不要直接刪除整份規則清單。遠端網址若回傳登入頁面或錯誤訊息，即使 HTTP 請求成功，也不是有效的規則檔案。更新週期只控制重新取得內容的間隔，不保證遠端檔案一定能正確解析。

驗證規則時，先在用戶端連線頁面查看目標網域、命中項目與最後的輸出，再決定是否調整順序。既有連線可能繼續沿用原路徑；測試前可關閉相關應用程式的連線或重新開啟應用程式，但不要把重新整理一次視為所有連線都已重建。詳細操作可接著查看連線驗證步驟；若訂閱會定期更新，應將自訂規則放入持久覆寫。合併細節請參閱覆寫與合併。

六、DNS：解析路徑與 fake-ip

DNS 設定處理網域如何取得位址，以及解析請求經由什麼路徑送出。它與代理節點選擇有關，但並非同一套開關。瀏覽器透過代理開啟網頁，不代表系統所有 DNS 請求都經過核心；反過來說，核心啟用 DNS 服務，也不代表 Windows 或應用程式已將查詢交給它。討論 Clash DNS 洩漏時，應先確認請求來源、解析器與網路出口，不能只根據單一欄位下結論。

監聽位址不等於接管系統解析

dns.enable 會啟用核心的 DNS 功能，listen 用來指定本機監聽位址。為避免與系統服務衝突，以下使用回送位址與非標準連接埠。只加入這段設定後，Windows 預設仍可能使用網路卡的 DNS，除非另有 TUN 劫持或明確的轉送設定。不要將帶有連接埠的位址直接填入只接受 IP 的網路卡設定欄位；不同入口對位址格式的要求不一樣。

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:
    - 1.1.1.1
  nameserver:
    - https://dns.cloudflare.com/dns-query

這是一段解析設定範例，不代表這個上游適用於所有網路。default-nameserver 主要用來引導解析 DNS 上游本身的網域，避免「連上解析器前，還得先解析解析器」的依賴問題；nameserver 則是一般查詢使用的上游。使用加密 DNS 可以改變查詢的傳輸方式，但不會自動改變其輸出路徑，也無法解決本機網路無法連線到上游的問題。

fake-ip 需要讓連線流量回到核心

fake-ip 會為網域指派合成位址，核心則保存位址與網域之間的對應關係，之後連線進入核心時再依此處理。範例位址區段用於這類對應，不應當成網站的真實公網位址。若應用程式取得合成位址後繞過核心直接連線，就可能失敗，因此 DNS 入口必須與流量入口搭配。看到合成位址不代表解析錯誤，關鍵在於後續連線是否經過同一個核心執行個體。

fake-ip-filter 可讓部分網域不使用合成位址，常用於本機裝置探索或確實不相容的服務，但不應將所有異常都加進篩選清單。先確認應用程式是否依賴真實 IP、是否使用自有 DNS，以及區域網路網域應由哪台解析器回覆。redir-host 採用另一種處理方式，也有相應的比對與解析限制；切換模式後應考慮舊 DNS 快取，避免用舊結果判斷新設定。

依網域選擇上游與代理節點解析

nameserver-policy 可依網域選擇解析上游，適用於企業內網網域需交由內部 DNS 解析的情境。代理伺服器本身的網域解析可透過 proxy-server-nameserver 獨立設定，降低它與一般業務解析互相依賴的情形。若啟用 respect-rules，讓 DNS 上游連線遵循路由規則，應先確認代理節點網域如何解析，否則可能形成「解析需要代理，建立代理又需要解析」的迴圈。

DNS 欄位的優先順序會影響實際行為，初次設定時不建議同時加入大量備用上游、網域策略與多層規則依賴。先建立一條清楚可解釋的解析路徑，再加入必要的例外。尤其要留意瀏覽器的安全 DNS、其他 VPN 的解析設定、企業安全軟體與路由器轉送；這些都可能讓測試請求沒有經過預期入口。備用上游也不是越多越好，每一項都需要確認可連線性與適用範圍。

修改後可視需要執行 ipconfig /flushdns 清除 Windows DNS 快取，並重新啟動使用獨立快取的應用程式。清除系統快取不一定會一併清除瀏覽器、核心與遠端解析器的快取。若區域網路印表機或企業網域無法使用，應優先恢復正確的內網解析，不要直接停用整套分流。確認新方案可用後，再儲存為持久設定，並記錄哪些網域需要本機解析，方便後續維護。

七、TUN、系統代理與 Windows 路由

系統代理與 TUN 是兩種常見的流量入口。系統代理供遵循 Windows 代理設定的應用程式使用，通常適合先用來驗證瀏覽器連線；TUN 則透過虛擬網路裝置與路由處理更多流量，適合不讀取系統代理設定的應用程式。啟用 TUN 不會改變節點驗證方式，也不會自動補上 UDP 支援。應先以可用節點和基本規則確認輸出，再接入 TUN，避免同時排查入口與遠端連線兩個問題。

設定欄位與用戶端權限共同決定結果

在 Windows 上建立虛擬網路卡、調整路由與安裝服務可能需要權限。用戶端的服務模式、以系統管理員身分啟動，以及核心設定各有不同用途，不能把一個 YAML 開關當成已完成所有系統操作。優先使用用戶端提供的服務安裝與 TUN 設定功能；若介面負責管理這些欄位，手動編輯訂閱可能在下次產生設定時被覆蓋。排錯時先確認介面狀態與執行設定一致。

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

這段使用 mihomo 的 TUN 欄位：auto-route 用來要求自動設定路由，auto-detect-interface 用來識別輸出介面，dns-hijack 則描述要交由核心 DNS 處理的請求。這些欄位需要搭配有效的 dns 設定。劫持傳統 DNS 連接埠不等於接管所有加密 DNS；應用程式透過 HTTPS 自行解析時，流量形式已不同，必須另外了解其行為。

網路堆疊不是通用的效能開關

stack 可選擇核心支援的網路堆疊方式，實際相容性會受作業系統、核心實作與應用程式影響。mixed 是一種混合處理方式，不代表在所有裝置上都比其他選項好。特定應用程式發生異常時，可在保留基準設定的前提下逐項比較，不要同時修改網路堆疊、MTU、DNS 和節點。每次只變更一項條件，才能找出問題是否因此改善。

MTU 會影響網路封包大小，某些路徑確實可能受分片或通道封裝影響，但不是所有卡頓的原因。先觀察問題是否只出現在特定網站、傳輸方式或大型封包，再考慮調整。太早套用網路上的固定數值，可能讓原本正常的連線變得更難判斷。若只有 TUN 異常、系統代理正常，檢查重點應放在路由、入口、DNS 與網路堆疊，而不是立刻更換訂閱。

多網路卡與其他 VPN 的排查順序

電腦同時連接有線、無線、虛擬機網路或企業 VPN 時，預設路由與 DNS 可能分別來自不同介面。在複雜的網路拓樸中，自動識別輸出介面不一定會得到使用者預期的結果。可使用 Get-NetRoute -AddressFamily IPv4 查看路由，並搭配 Get-NetIPConfiguration 確認介面設定。先記錄目前狀態，再於允許的環境中逐一停用衝突軟體；不要直接刪除不認識的虛擬網路卡。

系統代理與 TUN 同時開啟，不一定會造成雙重代理，但會增加判斷流量入口的複雜度。排錯時可先只保留一種方式，並關閉應用程式內額外的代理擴充功能，建立明確的測試條件。公司裝置可能受管理員政策限制，請遵守所屬網路的管理規範，不要透過刪除服務或修改系統安全政策強行繞過限制。需要長期使用時，再決定是否啟用用戶端自動啟動與服務模式。

結束用戶端前，建議先關閉 TUN 與系統代理，確認系統網路已恢復。若程式異常結束後網頁無法開啟，先檢查 Windows 代理設定是否仍指向已停止的本機連接埠，再檢查殘留路由與其他 VPN 狀態，不要立刻重設整個網路。白畫面、服務無法啟動等問題，可依照Windows 用戶端啟動問題排查繼續確認；驗證連線則回到教學的驗證章節。

八、覆寫、合併與可復原的修改流程

訂閱通常由遠端維護，直接修改匯入後的內容容易在更新時遺失。覆寫的目的，是將本機偏好與訂閱來源分開：遠端持續更新節點，本機則保留必要的規則與設定。不過，「覆寫」並非 mihomo 核心統一規定的編輯器功能，而是用戶端產生設定時採用的處理機制。Clash Plus、Clash Verge Rev 等用戶端的入口、語法與執行順序，應以各自介面的說明為準。

純量、映射與清單不能用同一種方式合併

連接埠、模式這類純量通常會用後一個值取代前一個值；DNS 這類映射可能依子欄位合併，也可能整體取代；規則與策略組這類清單則可能被取代、附加或插到前面。若用戶端沒有明確說明，就不能假設它會自動理解「把這條規則放在所有規則前面」。以下只是預期中的最終規則片段，不是適用於所有用戶端的覆寫指令。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選擇
  - MATCH,出口選擇

如果訂閱原本已有一套規則，直接用上面的清單取代，就會遺失訂閱中的其他規則。若選擇附加到清單末尾，而原有清單已包含 MATCH，新增規則可能沒有機會命中。正確做法是使用用戶端支援的規則前置功能，或在指令碼中明確指定插入位置，再檢查產生的結果。需要修改組時，也要確認是修改同名組，還是意外新增了重複名稱。

先釐清產生順序，再決定覆寫位置

產生設定時，可能依序涉及遠端訂閱、訂閱專用擴充功能、全域擴充功能、圖形介面設定與執行時選擇。實際順序由用戶端決定，本頁不會將單一用戶端的處理順序套用到整個生態系。若儲存覆寫後沒有作用，先查看最終執行檔案中是否存在該欄位：若不存在，通常是覆寫未套用或被後續階段覆蓋；若欄位存在但行為不符，再檢查引用關係、規則位置與流量入口。

全域覆寫適合所有訂閱共用的偏好，例如明確限制本機監聽；訂閱專用覆寫則適合依賴特定提供器或組名的規則。若將只存在於一份訂閱中的組名寫入全域規則，切換到其他訂閱時可能找不到目標。遷移前應將舊用戶端專用的解析指令碼與核心 YAML 分開，不要將整份指令碼貼進設定檔。相關對照請參閱Clash for Windows 遷移筆記。

依儲存、測試、載入、驗證四個步驟修改

儲存階段先備份目前可正常運作的來源與覆寫；備份若包含訂閱憑據，應妥善保管。測試階段檢查 YAML 語法、節點引用與規則目標；若能執行獨立核心測試，還應驗證最終設定，而不只是零散片段。載入階段確認用戶端沒有退回舊設定，並查看日誌是否出現解析或提供器錯誤。驗證階段則針對修改目標建立新連線，確認命中規則與最後的輸出符合預期。

# 在已安裝對應核心的終端機中測試指定檔案
mihomo -t -f config.yaml

# PowerShell：檢查範例代理連接埠的監聽狀態
Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue

# 清除 Windows 系統 DNS 快取
ipconfig /flushdns

這些命令各自用來確認不同問題：設定測試不會驗證遠端驗證資訊，連接埠正在監聽不代表目標網站可連線，清除 DNS 快取也無法修復錯誤規則。不要把這三個命令當成固定的萬用修復流程。若找不到命令，先確認執行檔路徑或終端機環境，不要下載來源不明的工具。若用戶端內建設定檢查功能，也可優先使用，避免獨立核心與用戶端核心版本不同。

更新後重新檢查相依項目，不只確認能否啟動

訂閱更新可能重新命名或移除節點，也可能調整規則組；用戶端更新則可能改變擴充功能的處理方式。更新完成後，應重新確認本機規則引用的組是否仍存在、規則提供器是否正常載入，以及 TUN 與 DNS 是否維持預期。能夠啟動只代表設定已被接受，不代表業務規則仍符合原本目標。請為重要應用程式建立新連線測試，再確認常用內網資源與一般網頁都能依設計存取。

需要查詢欄位術語時，可前往術語手冊；尚未完成訂閱匯入的話，返回訂閱匯入步驟即可，不必一次設定所有進階功能。維護設定的重點，是讓每個欄位都有明確用途、每項例外都說得清楚，並確保每次更新都能復原。精簡且可驗證的本機覆寫，通常比長期複製整份訂閱更容易維持穩定。