Clash 設定檔
YAML 結構與欄位

YAML 結構總覽

設定檔首先是一份具有層級的文字，不是隨意堆疊設定名稱的清單。YAML 以縮排表示從屬關係，用冒號連接欄位與內容，用短橫線表示清單項目。閱讀陌生設定時，先找最左側的頂層欄位，再查看各欄位下方縮排的內容。如此便能分辨哪些是全域設定、哪些只屬於特定節點，避免把正確參數寫在錯誤位置。

從縮排看懂物件與清單

建議統一使用兩個空格縮排，避免混用定位字元。同一層級的欄位左側應對齊，子欄位則比父欄位多縮排一層。冒號後通常要加一個空格；清單項目的短橫線後也要加空格。可在編輯器開啟「顯示空白字元」，讓縮排一目瞭然。遇到錯誤行時，也要檢查前幾行，因為漏加引號或縮排錯誤，往往到後面才會顯現。

# 可由支援這些欄位的 mihomo 核心載入
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

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

rules:
  - MATCH,手動選擇

這份範例僅示範層級，所有連線最終都會直連，不含可用的遠端代理。頂層的 proxy-groups 是一份清單，其中每個項目都是策略群組物件。物件內的 proxies 又是一份清單，列出候選出口名稱。頂層的 proxies 則用來定義代理節點。兩個欄位雖然同名，所在層級不同，作用也完全不同。

把設定看成一條引用鏈會更容易理解：代理節點宣告連線方式，策略群組引用節點名稱，規則再引用策略群組名稱。DIRECT 是內建直連出口，不必在代理清單中另建同名節點。引用名稱必須完全相符，包括大小寫、空格與標點。將「手動選擇」改成「日常選擇」時，規則中的目標也要一併修改，否則語法可能通過，載入時仍會提示找不到目標。

字串、布林值與空內容

含有特殊符號的值最好加上引號，尤其是密碼、含井字號的名稱，以及看起來像日期的內容。井字號在特定位置會開始註解，未加引號時可能截斷原值。布林值使用 true 和 false，連接埠使用數字；不要為了格式一致，把所有內容都寫成字串。[] 代表空清單，與只有欄位名稱卻沒有內容不同。敏感欄位須保留原始字元，不要自行刪除中間的空格。

同一個物件內不要重複宣告相同鍵名。兩個頂層 rules 並不代表規則會接在一起；不同解析器可能拒絕載入，也可能只保留其中一段。收到他人提供的片段時，先確認它是完整檔案，還是某個父欄位底下的內容，再決定貼上位置。若只有 nameserver 的子項，不能直接放到檔案最左側。

修改前先複製一份原始檔，並在副本名稱中註明用途。先用上方的最小結構練習縮排，再閱讀實際訂閱內容，不要直接用練習檔取代正式設定。每新增一個部分就載入一次，比一次貼上數百行後才找錯誤省事。想逐段對照完整檔案，可接著閱讀config.yaml 閱讀順序；本頁後續章節則用來查詢欄位含義與適用範圍。

連接埠與執行模式

通用欄位決定用戶端從何處接收流量，以及接收後如何處理。先區分「本機入口」與「遠端出口」：本機連接埠供瀏覽器或系統代理連線，遠端節點連接埠則用來連接伺服器。即使兩者剛好使用相同數字，也毫無關聯。只有應用程式確實將要求送到本機入口，後續規則才有機會參與判斷。因此，設定正確不代表所有程式都會自動接入。

選擇入口並控制監聽範圍

port 提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 則讓同一個連接埠接受這兩類代理連線。一般選用一個混合入口就能滿足桌面應用的常見需求，不必為了「設定完整」而同時開啟所有連接埠。範例中的數字僅供本機設定使用；若已被其他程式占用，請改用未占用的連接埠，並同步調整系統代理與應用程式設定。

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

allow-lan: false 適合僅供本機使用；bind-address 用來指定監聽位址。回送位址 127.0.0.1 只指向目前裝置。即使修改為允許區域網路連線，也仍須檢查監聽位址、防火牆與用戶端覆寫設定。不要將代理入口直接暴露於公網。確實需要讓同一區域網路中的裝置使用時，應先限制可連線的範圍，再確認核心支援的入口驗證方式。

規則模式不是連線開關

mode: rule 表示依照規則清單進行比對；global 通常會將接入流量交由全域策略選擇；direct 則以直連方式處理。切換至全域模式可協助判斷規則是否影響特定要求，但不應把它當成解決所有問題的按鈕。若應用程式沒有進入代理入口，或節點本身無法連線，切換模式也無法排除這些前置問題。

系統代理與 TUN 模式也屬於不同層面。系統代理是向系統登錄代理位址，應用程式可自行決定是否遵循；TUN 則是虛擬網路介面，由路由將符合條件的封包交給核心處理。TUN 通常涉及管理員權限、路由與 DNS 接管，相關欄位也會因平台而異。初次排查建議先使用系統代理確認單一明確要求可正常運作，再依照使用說明啟用 TUN，避免同時排查兩種入口。

用戶端介面中的連接埠與模式可能優先於檔案內容。若檔案設定為規則模式，介面卻顯示全域模式，應檢查目前實際生效的設定，而不是反覆修改原始檔。部分用戶端會將連接埠設為應用程式層級設定，重新載入訂閱也不會改變。確認目前實際監聽的連接埠後，再檢查瀏覽器或命令使用的位址，才能避免要求誤送到另一個正在執行的代理程式。

記錄層級平時使用 info 即可，排查問題時再暫時切換為 debug。詳細記錄會增加輸出，也可能記下目標網域、位址與連線路徑，分享前請檢查是否含有敏感資訊。結束除錯後應恢復常用層級，避免長期累積不必要的記錄。控制介面用於管理核心，不是上網入口；不要將系統代理指向控制介面的連接埠，也不要為了方便管理而任意擴大監聽範圍。

最後再檢查 IPv6。頂層的 ipv6 與 DNS 區段中的同名選項，分別影響連線與解析行為，實際效果須視核心實作而定。範例將其關閉是為了縮小入門排查範圍，並不代表所有網路都應長期關閉。若網路與代理出口支援 IPv6，可在基本連線穩定後單獨啟用測試，同時查看 AAAA 解析結果與實際出口位址，確認不只是介面上的開關狀態改變。

DNS 與網域解析

DNS 是將網域名稱轉換為網路位址的過程。規則中使用網域名稱，不代表整條連線都不需要解析：連線至代理伺服器、目標網站或判斷位址所屬區域，都可能觸發 DNS 查詢。排查時先確認「由誰解析、向哪裡解析、得到什麼結果」，不要直接把逾時歸咎於節點失效。瀏覽器內建的加密 DNS 也可能繞過系統解析路徑，讓同一裝置上的不同應用出現不同結果。

一般解析與 Fake IP

enhanced-mode 用來選擇增強解析模式。fake-ip 會回傳一個對應用程式使用的映射位址，再由核心根據映射找回原始網域；這並不是網站的實際位址。此方式較容易保留網域資訊供規則使用，但前提是後續要求確實進入同一個核心。redir-host 主要回傳實際解析位址，行為較接近傳統解析。不要只因某個網站推薦，就在尚未了解入口的情況下反覆切換。

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

這段設定提供本機 DNS 監聽入口，但單靠 listen 不會自動修改系統 DNS，也不會自動完成 TUN 接管。若系統仍將要求送至路由器，核心中的設定可能尚未參與處理。確認入口時，須一併檢查用戶端 DNS 接管設定、系統網路設定與記錄。若監聽使用非標準連接埠，一般系統 DNS 設定通常無法直接指定該連接埠，應改用支援此入口的程式或接管機制。

default-nameserver 常用來引導解析加密 DNS 服務本身的網域，因此範例使用 IP 位址，避免必須先解析網域才能找到解析器的循環。nameserver 是一般上游解析服務；範例使用 HTTPS 傳輸，也就是常說的 DoH。加密解析仍須確保網路可連線，不保證所有環境都能直接使用，也不能取代代理節點。更換上游服務時，應先確認目前網路能否連到該服務。

依網域指定解析器

部分網域需要透過特定解析路徑，例如公司內部網域只存在於內網 DNS。mihomo 支援使用 nameserver-policy 依網域選擇上游解析器。以下的內部網域與解析位址僅供示範結構，實際使用時必須換成所在網路提供的值，並將這段內容放在同一個 dns 物件中，不要另建第二個頂層 DNS 欄位。

# 合併至現有 dns 物件內
nameserver-policy:
  "+.corp.example.com":
    - 192.168.1.1

Fake IP 過濾清單用來讓指定網域不使用虛擬位址映射，與規則中的直連清單不同。為網域新增過濾項目後，流量仍會繼續依照分流規則處理。區域網路探索、某些遊戲或依賴實際位址的程式發生異常時，可針對已確認有問題的網域測試過濾。不要將所有網域都加入清單，否則原本想使用的機制就失去作用。

在支援的 mihomo 設定中，也可使用 proxy-server-nameserver 指定代理伺服器網域的解析器。它與網站網域解析不同，目的是在建立代理連線前先找到伺服器位址。若使用 respect-rules 等讓 DNS 連線遵循分流規則的選項，更要檢查是否形成循環：解析器需要透過代理連線，但代理伺服器又必須先由該解析器取得位址。若沒有明確需求，先保留較簡單的解析路徑。

驗證 DNS 時分兩步檢查：先確認查詢確實到達核心，再確認查詢結果可供後續連線使用。Fake IP 模式下看到映射位址可能是正常現象，不能直接將它當作遠端伺服器位址。若只有一個應用程式異常，優先檢查其內建 DNS、快取與接入方式；若所有應用程式同時異常，再檢查上游連線與接管路徑。一次只更動一項解析設定，才能從結果判斷真正影響的環節。

代理節點欄位

代理節點描述建立遠端連線所需的參數，不是只填上名稱就能使用的標籤。通訊協定類型決定欄位組合，伺服器決定具體值，用戶端核心則決定是否支援。若訂閱已提供節點，應優先保留原始參數，只調整策略群組或規則。手動修改加密方式、傳輸方式或驗證資訊，通常不會讓連線更快，反而容易造成用戶端與伺服器設定不一致。

先核對共用欄位

name 是供策略群組引用的本機名稱；type 是通訊協定識別碼；server 是遠端伺服器網域或 IP；port 是伺服器監聽的連接埠。名稱可依用途命名，但應保持唯一，避免與策略群組及內建出口重名。網域欄位只填主機名稱，不要加上 https:// 或網頁路徑。連接埠也不能直接照抄本機混合連接埠，必須依伺服器提供的資料填寫。

proxies:
  - name: 範例出口
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - 範例出口
      - DIRECT

範例使用保留的示範網域與假密碼，僅展示 Shadowsocks 節點結構，不提供實際代理服務。若要建立連線，必須合法取得伺服器位址、連接埠、加密方式與密碼。cipher 必須與伺服器設定相符，不能將它當成可任意挑選的安全等級。複製密碼時尤其要留意引號內的空格、特殊符號與換行；介面中看起來相似，不代表字元內容完全相同。

不同通訊協定的參數不可混搭

不同通訊協定使用的驗證欄位並不通用。例如，有些通訊協定使用密碼，有些則使用 UUID；傳輸層可能採用 TCP、WebSocket 或其他方式。不要把多篇教學中的欄位拼在一起，期待核心自動判斷。先確認通訊協定，再查閱該通訊協定在目前核心中的欄位定義。某欄位在其他用戶端可用，不代表目前核心也支援相同寫法；未知欄位有時會被忽略，不一定總會收到明確錯誤。

TLS 是連線中用來加密並驗證對端身分的機制。servername 常用來指定交握時的伺服器名稱，與節點顯示名稱不同。若憑證發生錯誤，先核對伺服器資料、裝置時間與名稱是否相符。不要把停用憑證驗證當作長期解決方式，這可能掩蓋位址錯誤或信任問題。WebSocket 的要求路徑與要求標頭也必須符合伺服器設定，不能只根據網站首頁網址推測。

udp: true 表示允許使用節點的 UDP 能力，並不會讓原本不支援 UDP 的伺服器突然具備此能力。瀏覽網頁正常，但遊戲或語音異常時，應分別檢查本機入口是否接入 UDP、通訊協定與伺服器是否支援，以及規則是否將這些要求送往預期出口。只有 HTTP 連線測試正常，不足以證明整條 UDP 路徑運作正常；這也是「節點顯示可用，但應用程式無法使用」的常見原因。

節點數量較多時，可使用 proxy-providers 管理代理集合，再由策略群組透過 use 引用。這與會回傳完整設定檔的訂閱不同：代理提供器預期收到相容的節點清單結構，不能直接填入任意訂閱網址。遠端網址也可能包含存取憑證，分享設定時請先移除。新手建議先使用用戶端現有的訂閱管理功能，確認需要獨立管理節點池後再導入提供器。

更換用戶端時，請先保留設定副本，再確認所用核心與支援的通訊協定。可先從下載頁面的 Clash Plus開始選擇，其他用戶端也應依裝置需求挑選。若節點參數由服務提供者提供，連線失敗時應先對照原始資料，不要一次重新命名所有節點。清楚的名稱有助於閱讀記錄，但不會改變連線效能；穩定的欄位引用比複雜的命名更重要。

策略群組與選擇

策略群組是在多個連線選項之間做選擇的中介層。規則不必直接指定某個遠端節點，而是將要求交給一個群組，再由群組決定出口。如此一來，更換節點時通常只需調整群組選擇，不必重寫每條規則。了解策略群組時，先看候選成員，再看選擇方式，最後確認哪些規則引用了該群組；只看群組名稱，無法判斷流量最終會送往何處。

手動選擇、自動測試與故障切換

select 是手動選擇，適合需要明確控制出口的情境。url-test 會依指定測試網址的連線測試結果選擇，但測試結果只代表該目標與測試方式，不能代表所有應用程式的實際體驗。fallback 偏向依候選順序尋找可用成員，適合有明確主備需求的情境。這三者解決的問題各不相同，不應只因為名稱有「自動」，就把所有流量交給同一種群組處理。

proxy-groups:
  - name: 自動候選
    type: url-test
    proxies:
      - 範例出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日常出口
    type: select
    proxies:
      - 自動候選
      - 範例出口
      - DIRECT

此片段需要先在 proxies 中定義「範例出口」，不能單獨當作完整檔案載入。測試間隔的單位是秒；tolerance 是以毫秒計算的容差，用來減少結果小幅波動造成的頻繁切換。測試網址應穩定、可連線並適合目前網路，範例網址並非必選。若測試目標本身受到限制，群組內所有候選都失敗，也不能直接證明所有節點都無法連線至其他目標。

當「日常出口」選擇「自動候選」時，要求會繼續交由內層群組選擇節點；選擇「範例出口」則直接使用該節點；選擇 DIRECT 就會直連。群組中出現直連，並不只是備用說明，而是真正可以選擇的出口。若某類流量必須經由代理，就不要在其依賴路徑中不小心保留可選的直連出口；至少要確認目前選取的成員。

引用關係與穩定性

群組可以引用其他群組，但不能形成循環。例如「日常出口」包含「媒體出口」，「媒體出口」又包含「日常出口」，就沒有可結束選擇的路徑。規劃時可畫出簡單的單向鏈：用途群組指向選擇群組，選擇群組再指向節點或內建出口。每增加一層都應有明確理由，不要只為了讓介面分類更美觀而過度巢狀，否則發生問題時就得逐層確認實際選項。

自動切換主要影響之後建立的連線，不保證現有連線會立即轉移。網頁可能重複使用連線，影片也可能維持長連線，因此切換後仍可能沿用原出口。涉及登入、付款或對出口位址敏感的服務時，穩定選擇通常比頻繁追逐測試結果更合適。要驗證切換效果，請關閉舊連線後重新發出要求，並在連線詳細資訊中檢查策略鏈，不要只看策略群組按鈕是否變色。

load-balance 會依設定策略將連線分配到候選成員，不代表單一下載連線的頻寬會直接相加。不同連線可能使用不同出口，網站也可能因此要求重新驗證。若沒有明確的負載分配需求，先使用手動選擇或較簡單的自動候選群組。複雜群組除了需要核心支援，也要求了解候選可用性、連線維持方式，以及服務對出口一致性的需求。

透過提供器匯入節點時，策略群組可以使用 use 引用提供器名稱，不要誤將提供器寫成一般節點名稱。過濾選項會影響實際候選集合，正規表示式寫錯可能使群組變成空群組。更新訂閱後若群組中的節點消失，請依序檢查提供器是否更新成功、過濾條件是否相符，以及名稱是否變更。不要先刪除規則，因為規則只負責將要求交給群組，不會建立群組成員。

用戶端可能會保存手動選擇結果，重新載入設定後不一定會回到清單第一項。排查時先記下目前選項，必要時明確重新選擇，再發出新要求。策略群組名稱應保持穩定，尤其是被規則、覆寫檔或用戶端選擇紀錄引用時。若要重整群組結構，先保留原名稱並確認新候選可用，再逐步調整引用，比一次重新命名所有群組更容易還原。

規則語法與順序

規則清單通常由上往下判斷，第一條符合的規則就會決定處理目標，不會自動比較哪一條「更精確」。因此，規則不只要內容正確，也要放在正確位置。可將它想成分流路徑上的連續岔口：要求先經過前面的規則，已被分流的流量不會再流到後面的規則。設定中最容易誤判的情況，就是精確規則被上方涵蓋範圍更大的規則提前攔截。

網域、位址與最終兜底

多數規則採用「類型、比對內容、目標」的格式，例如 DOMAIN-SUFFIX,example.com,日常出口。網域規則中的內容不是網址，不要加上通訊協定、連接埠或路徑。DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對網域本身及其子網域，DOMAIN-KEYWORD 則依關鍵字比對網域字串。關鍵字的涵蓋範圍可能超出預期；已知確切網域時，優先使用完整網域或後綴比對。

rules:
  - DOMAIN,router.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,日常出口
  - DOMAIN,ads.example.net,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,日常出口

這段設定需要先有「日常出口」策略群組。IP-CIDR 依位址網段判斷，GEOIP 依位址資料庫判斷所屬區域，MATCH 不需要比對內容，用來作為最後的兜底規則。若將 MATCH 放在前面，後續規則就不會再有比對機會。私有網段範例只列出兩段，不代表涵蓋所有本機位址；實際網路可能還需要其他網段、IPv6 或內部網域規則。

解析行為與規則提供器

no-resolve 常用於支援此選項的位址類規則之後，表示不要只為了判斷這條規則而主動觸發網域解析。它不代表「這條連線永遠不需要 DNS」。若要求已帶有實際位址，仍可能參與位址比對；若只有網域且沒有可用位址，規則就可能無法命中。將它加到所有位址規則上會改變比對機會，應搭配前面的網域規則與最終兜底一併分析。

GEOIP,CN 判斷的是位址資料庫中的區域，不是網站使用哪種語言，也不等同於網域註冊地。使用內容傳遞網路的網站可能回傳不同區域的位址，資料庫也可能更新延遲。若特定服務需要穩定出口，可考慮明確指定網域規則，不要完全依賴區域判斷。更新 Clash GeoIP 時，請先確認目前核心實際使用的資料格式與路徑，再透過用戶端提供的更新入口操作。

規則數量較多時，可使用 rule-providers 獨立管理規則集合，再透過 RULE-SET 引用。提供器的行為類型必須符合內容格式，例如網域清單與經典規則清單不能任意混用。遠端規則更新也涉及下載路徑與網路連線，不能假設內容會像本機文字一樣永遠存在。初次設定時，先用幾條本機規則確認分流方向與順序，再加入規則集合，較容易區分內容錯誤與更新問題。

程序規則可依程式名稱或路徑比對，但支援情況會受作業系統、核心權限與流量接入方式影響。若看不到程序資訊，增加更多程序規則也未必有效。行動裝置與桌面系統不能直接套用同一組程序辨識規則。若要確認某個應用程式是否進入核心，先查看連線記錄中是否確實有程序欄位，再決定是否使用這類規則。

驗證規則時，記下目標網域、命中的規則、策略群組與最終出口。網站可能同時連線至主站、圖片、登入與 API 網域，只比對主網域未必涵蓋整個頁面。遇到「頁面能開但圖片載入失敗」時，先查看失敗資源的實際要求，不要把規則擴大到不相關的關鍵字。常見比對問題也可參閱FAQ 故障排除分類，先依現象縮小範圍再修改清單。

覆寫與設定合併

覆寫是在保留原始設定的前提下，透過另一層設定改變最終結果；合併則是將多個來源整理成核心實際讀取的一份設定。這些並非 YAML 格式內建的統一功能，不同用戶端可能採用不同規則。檔案本身可以描述物件與清單，但「清單前置插入」「保留節點」「腳本處理」通常由用戶端實作。看到他人的覆寫片段時，先確認適用的用戶端與執行階段，不要假設所有軟體都以相同方式處理。

原始設定不等於生效設定

一份訂閱設定可能依序經過下載、用戶端基本設定覆寫、使用者覆寫、腳本處理，最後才交給核心。實際順序應以用戶端說明為準。若修改後介面與檔案內容不一致，請尋找「查看執行設定」、「匯出最終設定」或類似功能。若只是不斷開啟下載的原始檔，可能永遠看不到用戶端最後加上的連接埠、DNS 或規則變更。

直接編輯訂閱下載檔案的風險，在於下次更新時會重新取得內容，覆蓋本機修改。較穩妥的做法是讓訂閱管理遠端節點，並以覆寫管理個人規則與本機設定，兩者分開維護。若用戶端目前不支援符合需求的覆寫功能，可以複製為本機設定，但必須接受它不會自動取得原訂閱後續的變更。該選哪種方式，應視是否需要持續更新而定，而不是看哪種介面按鈕比較少。

# 原始片段
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5

# 預期的最終結果：保留其他鍵，只替換上游清單
# 此處展示結果，並非通用覆寫指令

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

上方的重點是「保留物件中的其他鍵」。若用戶端採用淺層替換，提交只含 nameserver 的新 dns 物件，可能會一併移除原有的 enable 與增強模式；若採用遞迴合併，則可能予以保留。不要因為片段看起來合理，就自行推斷合併結果。實際操作後請展開最終 DNS 物件，確認未修改的必要欄位仍然存在。

清單替換與插入位置

清單尤其需要小心。rules、proxies 及策略群組中的候選項目都屬於清單，合併工具可能整份替換、直接串接，或依名稱處理各項目。若規則清單整份被替換，原訂閱中的分流內容就會消失；若只是追加，自訂規則又可能排在原有 MATCH 之後，永遠不會命中。因此，真正需要的通常不是「加進去」，而是「插入明確位置並保留兜底」。

例如，若要讓 docs.example.com 直連，應在所有可能提前命中的廣泛規則之前插入 DOMAIN,docs.example.com,DIRECT。插入機制的名稱因用戶端而異，不要把「prepend」之類的工具設定直接寫進核心的 rules 清單。完成後查看最終清單的頂端與底端，確認目標規則位置正確、只保留預期的兜底規則，且引用的策略群組仍然存在。

策略群組清單也不能只依陣列位置覆蓋。訂閱更新可能調整成員順序，原本的第二個群組可能不再是相同用途。支援依名稱比對的覆寫方式通常較容易維護，但仍須留意群組名稱可能被上游更改。每次更新後，至少檢查重要群組是否有候選項目，以及個人規則的引用是否仍有效。若將固定節點名稱加入候選項目，上游刪除或重新命名節點時，也須更新候選清單中的對應名稱。

本機維護建議分成三份：原始訂閱副本、個人覆寫檔，以及確認可正常使用的最終設定快照。出錯時先停用最新覆寫，還原上一份已驗證結果，再逐項重新加入。不要在同一輪同時更換節點、DNS 與規則清單，否則無法判斷是哪一層造成差異。修改說明應寫清楚目的，例如「內部網域直連」，比只寫日期更有助於日後理解。

完成合併後，也要測試一次訂閱更新。手動載入成功，只能證明目前檔案可用，不能保證下次遠端更新後個人設定仍會保留。更新完成後再檢查目標規則、DNS 與策略群組選擇，確認覆寫確實在預期階段執行。若更新後行為改變，先比較最終設定的差異，再檢查上游內容，不必立刻重新安裝用戶端；多數合併問題在這一步就能看出哪些欄位遺失或重複。

驗證與故障排查

設定驗證可分成三個層次：文字是否能解析、引用項目是否能載入，以及實際連線是否符合預期。通過 YAML 語法檢查，只代表縮排與基本格式正確；節點名稱不存在、通訊協定欄位不受支援，仍可能導致核心載入失敗；即使載入成功，應用程式也可能沒有接入代理。按照這三個層次排查，比一遇到逾時就修改整份檔案更容易找到可靠答案。

先檢查，再載入

編輯後先儲存副本，並使用用戶端提供的設定檢查功能。若已有命令列環境且安裝 mihomo，可使用核心測試命令。命令中的路徑是範例檔名，請在實際檔案所在目錄執行；Windows 可依安裝位置使用對應的執行檔。測試時也要確認相對路徑資源、規則檔案與資料目錄是否齊全，不能只複製主檔就假設執行環境與用戶端相同。

mihomo -t -f ./config.yaml

若出現 YAML 解析錯誤，先檢查錯誤位置附近的縮排、冒號、引號與短橫線；若提示找不到代理或策略，沿著名稱引用往上確認定義；若提示欄位或通訊協定不受支援，請核對目前使用的核心，不要靠隨意刪除欄位碰運氣。測試命令通過後再載入，並查看啟動記錄，確認實際使用的是這份檔案，避免檢查的是副本，執行的卻是另一份 Profile。

用明確要求驗證入口

先選擇一個可重複存取的測試目標，確認本機連接埠，再明確指定代理發出要求。以下命令假設本機混合入口監聽在範例連接埠，且環境中已安裝 curl。命令會透過 HTTP 代理方式存取 HTTPS 網站，可用來確認要求是否進入本機入口；命令成功不代表系統中的其他應用程式也已使用代理。

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

同時查看用戶端連線記錄。若完全沒有新要求，請檢查連接埠、監聽位址、程式是否正在執行，以及命令是否連到了另一個代理。若已看到要求，接著檢查命中的規則與策略鏈。只有命中規則、群組選項與預期相符，才進一步排查節點與遠端連線。回應狀態碼也須依目標判斷，並非所有網站都會對 HEAD 要求回傳與一般頁面存取相同的回應。

記錄中的「連線遭拒」、「解析失敗」、「交握失敗」與「等待逾時」分別指向不同階段。連線遭拒可能是連接埠沒有服務監聽；解析失敗應先檢查 DNS 路徑；交握失敗須核對通訊協定、驗證與 TLS；等待逾時則要依發生位置判斷網路是否可連。不要只截取最後一行錯誤，保留前後相關記錄更有幫助；分享前務必清除訂閱網址、驗證資訊與不想公開的存取目標。

若只有 Windows 市集應用程式異常，但瀏覽器透過同一入口運作正常，可接著參閱UWP 回送限制處理步驟。若用戶端一開啟就退出，請先依照啟動閃退排查筆記檢查記錄並還原設定。不同現象不要套用同一種修復方式，尤其不要一遇到問題就重新安裝；重新安裝可能保留舊設定，也可能刪除排查所需線索。

驗證完成後，請還原暫時使用的除錯設定，儲存一份可正常運作的最終設定，並記下測試目標與修改範圍。下次遇到問題時，從最近變更的項目開始還原。想重新整理操作流程，可回到使用說明；想判斷常見現象，可查看FAQ；想更換適合裝置的用戶端，請前往下載頁面。本頁的查閱順序始終是先確認入口，再追蹤解析、規則與出口。