Clash 設定欄位參考

YAML 結構總覽

Clash 設定不是一組互不相關的開關，而是一份彼此引用的運作設定。通用欄位決定核心如何監聽連線，DNS 決定網域如何解析，節點提供實際出口，策略群組負責組織出口，規則則將請求交給特定策略。理解這個流程，比背熟所有鍵名更實用。排查時也沿著流程逐步檢查：先確認請求進入核心，再查看規則指向的目標，最後檢查選取的節點。

先看結構，再看欄位

YAML 以縮排表示從屬關係。頂層的 dns、proxies、proxy-groups 與 rules 位於同一層；nameserver 屬於 DNS，因此必須縮排。清單項目前的短橫線代表新項目，不是裝飾符號。建議統一使用兩個半形空格，不要使用定位字元。編輯器中看起來對齊，不代表實際字元相同；尤其是從網頁複製內容後，請檢查行首是否混入全形空格。

以下是僅含直連出口的結構範例，可用來確認設定載入、監聽連接埠與策略引用。這份範例不會自動提供代理服務，也不能取代服務提供者提供的連線參數。先讓這份精簡設定通過檢查，再逐段加入自己的節點與規則，比一次拼湊大量不同來源的片段更容易找出問題。

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

dns:
  enable: false

proxies: []

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

rules:
  - MATCH,PROXY

字串、清單與引用

節點名稱與策略群組名稱都會以字串方式引用。規則指定 PROXY，設定中就必須有這個策略群組，或同名出口；名稱相近不代表相同，大小寫、空格與標點都會影響比對。建議使用簡短且穩定的名稱，不要將可能變動的流量提示或日期設為主要引用名稱。節點改名後，也要一併檢查策略群組清單及直接引用該節點的規則；否則即使語法正確，語意檢查仍可能失敗。

布林值通常寫成 true 或 false，連接埠與時間間隔使用數字，密碼等文字則建議加上引號。字串若含有冒號加空格、井字號、方括號或其他特殊字元，更應明確加上引號。引號本身不會隱藏敏感資訊，只是用來標示資料型別。請勿使用全形冒號作為鍵值分隔符；中文輸入法產生的引號也不能取代 YAML 所需的半形引號。

同一層級不要重複宣告相同的鍵。例如先寫一段 DNS，檔案末尾又貼上一個 dns:，不代表兩段內容會自動合併。不同解析器可能拒絕重複鍵，也可能只保留後面的值，結果都不可靠。要新增解析伺服器，請編輯原有清單；要讓用戶端合併設定，則應使用明確的覆寫機制，並查看最後產生的內容。

完整設定與節點清單的差異

完整設定包含監聽、策略群組與規則等執行資訊；節點清單則主要描述連線參數。兩者都可能使用 YAML，但用途不同。proxy-providers 通常引用的是提供器格式，不能只看副檔名就當成完整訂閱使用。匯入失敗時，先確認收到的內容是否其實是登入頁面、錯誤訊息或一串編碼文字；格式差異可參考訂閱連結與 YAML 格式說明。

閱讀後續範例時，請將程式碼視為個別欄位的寫法，而不是每段都能獨立執行的檔案。尤其是包含策略群組名稱或提供器名稱的片段，必須與自己的實際定義相符。每次儲存前，確認片段應位於頂層還是某個清單項目內。層級放錯時，最棘手的情況不是立即報錯，而是欄位遭到忽略，程式仍沿用舊設定執行。

連接埠與執行模式

連接埠設定決定「應用程式將連線送到哪裡」，不會決定「最後由哪個節點連線」。系統代理通常會將應用程式指向本機的 HTTP 或混合連接埠；應用程式內的 SOCKS 設定則需要對應的 SOCKS 入口。請先確認入口類型，再填入位址與連接埠。將代理伺服器的遠端連接埠填成本機監聽連接埠，或反過來填寫，都可能導致連線失敗，但兩者位於完全不同的連線環節。

port、socks-port 與 mixed-port

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
profile:
  store-selected: true

允許區域網路存取所需條件

allow-lan: false 適合只供本機使用的情況。若要讓另一台裝置連線，除了允許區域網路存取，還必須使用可供存取的監聽位址，並在對方裝置填入執行用戶端那台電腦的區域網路位址，而不是對方自己的迴路位址。接著檢查作業系統防火牆與 Wi-Fi 網路的裝置隔離設定。允許區域網路存取不代表自動具備驗證機制，也不代表可以將監聽連接埠直接暴露於公網。

共用入口時，請確認使用者與網路範圍，並視需要設定入口驗證及用戶端支援的存取限制。管理介面與代理入口也要分清楚：external-controller 是控制核心的介面，不是要填入瀏覽器的代理位址。如果不需要遠端控制，請將介面限制為僅本機可存取；不要直接照抄公開監聽的控制介面範例，也不要把控制憑證放進可公開下載的設定檔。

模式與流量接管是兩回事

rule 代表依規則選擇出口，global 代表使用全域策略，direct 則代表直連。全域模式不會強制所有軟體都經過代理，它只會改變已進入核心的請求如何選擇路由。應用程式若未使用系統代理，即使介面顯示全域模式，也可能仍然直連。因此請先確認連線是否出現在用戶端的連線清單中，再判斷模式設定是否有問題。

系統代理通常適用於遵循系統代理設定的應用程式；TUN 則透過虛擬網路介面接管流量，兩者並不是同一欄位的不同名稱。TUN 還涉及權限、路由、DNS 劫持與其他虛擬網卡，不能只打開開關就認定一切設定完成。初次驗證時，建議先用明確支援代理的應用程式測試混合連接埠，再另外啟用 TUN，避免入口與路由問題同時發生。

設定中的模式與策略選擇可能受到用戶端保存狀態的影響。範例中的 store-selected 用於保存策略群組選擇，可避免重啟後重新選取，但也可能導致修改預設清單順序後，當前選擇仍未改變。檢查時應以介面顯示的即時模式、策略群組目前出口及核心執行設定為準，不要只查看訂閱文字中的某一行。

發生連接埠衝突時，先關閉重複執行的用戶端，確認背景核心是否仍在監聽，再決定是否更換連接埠。更換後，也要同步修改系統代理、瀏覽器擴充功能及應用程式內手動填寫的位址。只修改 YAML，卻保留應用程式中的舊連接埠，便會出現「核心正常、網頁無法開啟」的情況。這類問題不必重新安裝軟體；通常只要讓入口與應用程式設定一致，就能解決。

DNS 解析設定

DNS 決定網域如何解析成位址，也會影響依據網域或位址進行的分流判斷。網頁無法開啟不一定是節點失效：也可能在連線到遠端之前，網域解析就已經失敗。排查時先分清楚目標網站網域、代理伺服器網域與 DNS 上游伺服器網域，三者不一定使用相同的解析路徑。用同一台解析伺服器處理所有用途，看似簡單，卻容易在網路環境改變時形成依賴循環。

啟用內建解析與 fake-ip

dns.enable 控制內建 DNS 功能。listen 用來指定監聽位址，但設定監聽不代表作業系統會自動將查詢送過來；還需要透過系統 DNS 設定、用戶端接管或 TUN 劫持，將請求送進核心。enhanced-mode: fake-ip 會為網域配置虛擬位址，由核心保存網域對應關係，再於實際連線時處理出口。虛擬位址不是網站的真實伺服器位址，不能當作節點位址使用。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost"

上述位址用來示範欄位之間的關係，是否適合目前的網路環境仍須實際測試。default-nameserver 通常用於解析 DNS 上游伺服器本身的網域，因此應選擇目前網路可直接連線的引導解析入口。proxy-server-nameserver 可為代理伺服器網域指定解析路徑，避免「連線代理前必須先解析節點，但解析節點又需要代理已連線」的循環。它不是所有網站查詢共用的出口。

分別檢查解析策略與連線策略

nameserver 是主要上游清單，nameserver-policy 可依網域或支援的規則條件指定上游。若需要更細緻的控制，先設定範圍小且結果可驗證的策略，再逐步擴大。DNS 請求使用某條路徑，不代表接下來的網站連線也一定使用相同出口；最終連線仍須經過分流規則。混淆兩者，就容易誤以為「解析成功便代表代理正常」。

mihomo 的 respect-rules 可讓 DNS 上游連線遵循路由規則，但啟用前應先規劃代理伺服器網域的解析方式，並確認規則不會反過來依賴尚未完成的解析。對新手來說，保留清楚的引導路徑，比堆疊多個加密上游更重要。如果目前網路無法連線某個上游，在相同路徑上增加更多位址也未必能提升可用性，還可能讓日誌更難判讀。

fake-ip-filter 適用於不應取得虛擬位址的網域，例如部分區域網路探索服務或依賴真實位址的應用程式。不過，過濾只會改變解析結果，不等於直連規則。若某個網域需要直連，還要另外確認連線規則指向 DIRECT。不要把所有遇到問題的網站都加進過濾清單；清單過長可能掩蓋真正的接管問題，也會降低網域對應關係的可觀察性。

IPv6、快取與故障範圍

頂層 ipv6 與 DNS 內的同名欄位，不應視為完全相同的開關。前者涉及核心是否使用 IPv6，後者則影響內建解析器查詢與回傳位址的方式。作業系統、應用程式與其他 DNS 服務也可能保留自己的 IPv6 路徑。部分網站時好時壞時，應檢查是否只有 IPv4 流量被接管、IPv6 仍繞過代理，而不是直接認定某個節點不穩定。

修改 DNS 後，現有連線不會自動重新解析；應用程式快取與系統快取也可能繼續保留舊結果。請先重新載入設定，再關閉相關應用程式的連線並重新送出請求；確有需要時再清除對應快取。若使用 fake-ip，請避免將舊快取長期沿用到另一套不相容的位址對應設定中。成功解析出位址只代表這個階段有結果，還要繼續檢查連線清單中的目標、規則與出口。

需要比較多種 DNS 設定時，每次只調整一個項目，例如先更換上游，再測試過濾，最後調整是否遵循規則。記下失敗網域、測試時間及日誌顯示的錯誤階段，不要只記錄「網頁很慢」。這樣才能判斷問題出在引導解析失敗、上游無法連線、網域對應異常，還是解析完成後目標連線失敗；最後一種情況應回頭檢查節點與規則，而不是繼續增加解析伺服器。

代理節點欄位

proxies 描述連線到遠端服務所需的實際資訊。節點名稱只是本機識別名稱，不能決定通訊協定；通訊協定由 type 指定，其他必要欄位也會依協定而異。節點名稱中寫了某種協定，不代表實際採用的就是該協定。排查時應查看實際欄位，並確認目前核心支援對應類型。圖形介面能匯入文字，不代表核心一定能建立連線；這兩個步驟須分開驗證。

通用資訊與協定專屬資訊

大多數節點會包含 name、type、server 與 port。伺服器可以是網域或位址，連接埠必須與遠端服務相符。驗證方式則依協定而異，有些使用密碼，有些使用使用者識別資訊或其他憑證。不要混合拼湊不同協定的欄位，也不要以為只要更改 type 的名稱就能轉換協定。伺服器端與用戶端必須使用相同的連線方式。

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

這段範例展示 Shadowsocks 節點結構；example.com 與範例密碼並不是可用的服務。實際使用時，必須替換成服務提供者提供的資訊，並將節點名稱加入策略群組引用。cipher 必須與伺服器端設定一致，不能只因為「看起來更安全」就自行換成另一種方式。伺服器位址正確但驗證資訊不符時，底層連線可能已建立，應用程式資料卻仍無法正常傳送。

TLS 與傳輸層不要混在一起修改

支援 TLS 的協定可能還會使用 servername、憑證驗證與應用層協定等參數；部分傳輸方式則另有路徑、要求標頭或傳輸選項。這些參數分屬不同層次：伺服器位址決定連線目標，服務名稱參與 TLS 交握，傳輸路徑則影響伺服器如何識別上層連線。若直接將伺服器位址改成解析出的位址，卻未保留原有服務名稱，可能導致憑證驗證失敗。

遇到憑證錯誤，應優先檢查系統時間、服務名稱是否正確、憑證鏈是否完整，以及網路中是否有其他中間設備。略過憑證驗證不應成為通用修復方式，更不能因為暫時連得上就認為問題已解決。若服務提供者有指定參數，請依其說明核對，並保留失敗日誌中出錯的階段。交握失敗、驗證失敗與目標網站逾時，需要採取不同的處理方式。

udp: true 表示該節點設定允許相關 UDP 功能，但能否實際使用，還取決於協定、遠端服務、入口方式與本機網路。它不是讓所有應用程式立即取得 UDP 代理的萬用開關。瀏覽器能開啟網頁，只能證明部分 TCP 或應用程式連線可用；遊戲、語音及其他 UDP 應用程式仍須另外測試，也要確認應用程式沒有繞過目前的代理入口。

節點提供器與訂閱更新

節點數量多、更新頻繁時，可以使用 proxy-providers 將節點來源與策略群組定義分開。提供器負責讀取或下載節點清單，策略群組則透過 use 引用提供器名稱。這裡引用的是提供器，不是個別節點。檔案格式、可存取路徑與更新方式，都必須符合目前核心及用戶端的支援情況；不能將完整用戶端設定直接放進只接受節點清單的入口。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - local-nodes

對應檔案應以頂層 proxies: 清單整理節點。路徑通常以核心工作目錄為基準解析，但圖形用戶端可能限制可讀取的位置或重新安排目錄，因此不能只看檔案與訂閱是否「放在一起」。找不到檔案時，先查看執行日誌記錄的實際路徑；健康檢查沒有結果時，再分別確認提供器未載入、清單為空或測試請求失敗，不要直接判定所有節點都無法使用。

訂閱更新後，節點改名或刪除會影響直接以名稱引用的策略群組。長期自訂設定較適合使用穩定的提供器引用，或透過用戶端支援的篩選方式管理節點。不要在每次更新都會被覆蓋的原始節點清單中反覆手動修改；若更新本身失敗，先依照訂閱更新失敗排查流程確認連結、網路與回傳格式，再檢查節點參數。

策略群組與健康檢查

策略群組是規則與節點之間的中介層。規則不必知道目前哪台伺服器可用，只要將請求交給穩定的群組名稱；群組再負責手動選擇、自動選擇或故障切換。如此一來，更換節點時不必逐條修改規則，也能依用途分組。例如，日常瀏覽與特定服務可以引用不同策略群組，但群組名稱本身不會產生特殊功能；實際效果仍取決於群組出口、測試方式與命中的規則。

四種常見類型如何選擇

select 用於手動指定選擇，適合希望固定出口的情況。url-test 會依測試結果自動選擇，適合讓核心從候選節點中自動調整的情況。fallback 著重依清單順序使用可用候選，而不是一味追求最低測試值。load-balance 用於依支援的策略分配連線，不代表單一下載工作會自動合併多條線路的頻寬。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自動選擇
      - DIRECT
  - name: 自動選擇
    type: url-test
    proxies:
      - SS-範例
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

這段範例必須搭配前一章定義的同名節點才能使用。外層手動群組讓使用者自行選擇，內層自動群組則負責測試候選節點。自動群組只有一個候選時仍可進行測試，但沒有其他節點可供切換。interval 是檢查間隔，tolerance 用來減少測試值略微變動所造成的頻繁切換；它不是下載速度門檻，也不保證每個網站都有相同體驗。

測試成功只能回答一個問題

健康檢查確認的是「這個候選節點能否依指定方式連線至測試目標」，不能取代實際業務測試。測試目標無法連線、目標限制目前網路存取，或該目標解析異常，都可能讓原本可用的節點顯示失敗。反過來說，測試請求成功也不代表特定帳號服務、串流平台或遊戲一定能使用。測試目標應穩定、輕量，並與自己的用途合理相關。

將檢查間隔設得太短，會增加持續請求，不一定能改善選擇結果。網路狀態頻繁變化，也可能造成測試結果波動。請先觀察失敗是否有規律，例如只在裝置從休眠恢復後發生、只在特定網路發生，或只有某個測試網址失敗。需要排查時，可暫時切換到手動群組並固定單一節點，減少自動切換對日誌與實際體驗的影響，再逐一測試候選節點。

提供器的健康檢查與策略群組的檢查屬於不同層次，設定時要確認由誰發起檢查，以及檢查哪些候選節點。不要看到提供器有測試結果，就認定所有引用它的群組都採用完全相同的選擇方式。使用 use 引用節點來源時，也要確認提供器已成功載入；若同時使用名稱清單與提供器，應檢查是否有重複候選，或意外加入直連出口。

巢狀引用與狀態保存

策略群組可以引用其他策略群組，但不能形成循環。甲群組指向乙群組，乙群組又指回甲群組，即使名稱都存在，也無法確定出口。設計時盡量減少層級：用途群組指向選擇群組，再由選擇群組指向節點即可。層級過多會讓連線紀錄難以閱讀，也使「介面上明明選了節點」與實際出口之間經過多次選擇，增加理解成本。

登入、付款或長時間工作階段可能對出口變動較敏感。自動切換或連線分配讓不同請求使用不同出口時，伺服器可能要求重新驗證；這不一定代表節點失效。這類用途可使用獨立的手動選擇群組，維持策略穩定。修改群組類型後，請建立新連線再測試；既有的長連線不一定會立即切換，介面上的新選擇與舊工作階段可能會短暫並存。

切換訂閱後，如果策略群組選擇與預期不同，請檢查用戶端是否還原先前的選擇、原節點是否已刪除，以及群組名稱是否沿用舊設定。穩定的群組名稱有利於保留使用習慣，但也會一併沿用狀態。排查時請記錄目前選取的實際節點，不要只寫「使用自動選擇」；這樣在重新載入或自動切換後，仍能準確重現當時連線的條件。

規則語法與比對順序

規則清單會由上而下檢查，通常由第一條符合的規則決定出口。範圍較小的例外應放在前面，範圍較大的分類則放在後面，最後以 MATCH 處理其餘請求。沒有任何單一關鍵字能取代順序設計：即使規則內容相同，只要前後順序互換，結果就可能不同。撰寫自訂規則前，先用一句話說明要涵蓋哪類請求，再選擇能精確表達需求的規則類型。

網域規則與位址規則

DOMAIN 比對指定網域，DOMAIN-SUFFIX 比對網域及其子網域，DOMAIN-KEYWORD 則依關鍵字擴大比對範圍。關鍵字太短容易涵蓋無關網站，因此一般例外規則通常優先使用完整網域或網域後綴。規則中的網域不要包含通訊協定、路徑或查詢參數；網頁位址是完整 URL，而網域規則只處理其中的主機名稱。

rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.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

範例中的 router.example.com 會先符合精確直連規則，不會再被後面的後綴規則改為代理。位址範圍規則適合區域網路或明確的網路區段；GEOIP 則依賴地理資料進行分類。地理位置不等於網站用途，內容傳遞網路也可能讓同一服務對應多個地區的位址，因此不能把某次位址分類結果視為永久不變的服務標籤。

no-resolve 的適用範圍

no-resolve 常用於位址類規則，表示不必只為了比對這條規則而主動解析網域。它不是「整個請求禁止 DNS」，也不代表這條規則一定會略過所有網域請求。如果核心已掌握目標位址，仍可能進行位址比對。使用這個參數的目的是減少不必要的解析或控制比對流程，不是用來避開所有解析問題。

網域規則必須讓核心取得網域資訊。如果請求直接使用位址、應用程式自行進行加密解析，或入口沒有提供可用的主機名稱，網域規則可能缺少比對條件。部分情況可透過 DNS 對應或嗅探補充資訊，但嗅探也有協定、加密方式與設定上的限制。請先查看連線詳細資訊中是否有網域，再判斷是規則寫錯，還是根本沒有足夠資訊可供網域規則比對。

GEOSITE 與 RULE-SET

GEOSITE 透過網域分類資料表示一組服務範圍，RULE-SET 則引用規則提供器。兩者都需要可用的資料來源，分類名稱也必須確實存在。只把網路上看到的分類名稱寫進規則，並不會自動取得對應資料。匯入大型規則方案前，請先確認資料格式、更新路徑與核心支援情況，避免設定本身能載入，執行時卻缺少引用的資源。

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

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,PROXY

上述提供器檔案可使用頂層 payload:，並在清單中放入網域比對內容，例如加上引號的 "+.example.com"。behavior: domain 用於網域集合，ipcidr 用於位址區段集合，classical 用於支援的完整規則項目；三者不能未經轉換就互換。完整規則項目也不能誤放進只接受網域的清單，否則會出現格式錯誤或比對結果不符預期。

規則提供器負責提供比對條件，再由 RULE-SET 這一行決定將符合條件的請求交給哪個策略。如此一來，同一份網域集合可套用在不同設定中，不必在集合內寫死所有出口。多個集合若有重疊，仍依外層規則順序處理；不能因為某個集合名稱較具體，就認為它會自動取得較高優先順序。要調整優先順序，請直接變更引用規則的位置。

從連線紀錄判讀比對結果

遇到分流錯誤時，先找出一筆具體連線，記錄網域、目標位址、命中的規則與最終出口。若命中 MATCH，代表前面的條件都未符合，不是兜底規則出了問題；若規則命中正確但出口錯誤，應檢查策略群組目前的選擇。若清單中完全沒有該請求，請回頭排查入口接管。更完整的組合方式可參考GEOIP、GEOSITE 與 RULE-SET 分流實作。

設定覆寫與合併

設定覆寫用來處理「訂閱會更新，但本機設定需要保留」的情況。直接修改訂閱原始內容，下次更新時可能會還原成服務提供者的版本；直接修改執行時產生的檔案，用戶端重啟時也可能重新建立。通常應使用用戶端提供的持久化覆寫、擴充設定或合併功能。各用戶端的實作方式不盡相同，不能將某個介面中的覆寫格式當成所有核心都支援的標準欄位。

先確認由誰產生最終設定

設定流程通常包含訂閱原始內容、本機持久化設定、用戶端處理結果與核心執行狀態等層次。用戶端可能會固定監聽連接埠、補上控制介面、替換 DNS，或在載入時插入規則。訂閱中的某一行未生效，不一定代表欄位不受支援，也可能是在後續階段遭到覆蓋。請先找到用戶端提供的執行設定預覽、匯出或日誌功能，再比較修改前後實際交給核心的內容。

Clash Plus 可優先考慮作為多平台用戶端，實際支援哪些設定入口仍須以介面為準；需要安裝時，請前往用戶端下載頁依平台選擇。Clash Verge Rev、FlClash 等用戶端的擴充設定名稱與執行順序也可能不同。請勿照著另一款用戶端的按鈕名稱操作，也不要為了保留本機規則而修改用戶端每次都會自動產生的暫存檔。

物件合併與清單合併的差異

物件欄位可能採遞迴合併，也可能整段取代；清單則可能取代、插入開頭、插入結尾或去重。例如只覆寫 DNS 的一個子鍵，有些機制會保留其他 DNS 欄位，有些則要求重新提供完整物件。規則清單尤其需要留意：若將自訂規則加在原有 MATCH 後面，檔案雖然包含規則，實際上卻永遠不會有機會命中。

# 僅供支援對應合併語意的用戶端覆寫範例
# 不是可直接交由所有核心使用的通用欄位
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
append-proxies:
  - name: 本機 SOCKS
    type: socks5
    server: 127.0.0.1
    port: 1080

prepend-rules、append-proxies 這類名稱可能代表用戶端提供的合併操作，未經確認不應放到一般 config.yaml 的頂層。核心原生執行設定最後仍應產生一般的 rules 與 proxies 清單。如果目前用戶端不支援這些鍵，請使用它提供的合併入口或擴充功能，不要一再貼上相同片段。

本機 SOCKS 片段也要求對應服務確實在指定位址與連接埠上監聽；新增節點定義不會啟動該服務。加入節點後，通常還要將它加入某個策略群組，才能在介面中選取。如果群組由提供器自動建立，也要確認是否會納入本機新增的節點。設定中存在節點，與規則能夠使用該節點，是兩件需要分別檢查的事。

小幅修改，維持設定可維護性

長期維護時，應優先覆寫少數明確欄位，而不是複製整份訂閱後長期分流維護。完整複製也會讓你必須自行處理節點變動、策略群組調整與規則資源更新。如果需求只是讓一個網域直連，就保留一條容易理解的前置規則；若只需固定連接埠，就只修改入口欄位。改動越少，訂閱結構變更後越容易發現衝突，也更方便還原。

需要以腳本處理設定時，應將它視為設定建置程式，而不是隨手貼上的文字。腳本可能因欄位不存在、清單為空或名稱變更而失敗，因此必須明確定義輸入假設與失敗處理方式。不要讓腳本將驗證資訊輸出到主控台，也不要依賴節點清單中的固定索引。可依穩定的群組名稱或明確條件進行處理，但處理後仍須檢查是否產生空群組、重複名稱或失效引用。

確認設定是否成功持久保存，必須進行兩次驗證：先重新載入本機設定，確認本次執行正確；再更新一次訂閱，確認本機修改仍存在且位置正確。最後關閉並重新開啟用戶端，檢查歷史狀態是否影響結果。編輯後立即測試一次，無法證明更新流程正常。保留原始訂閱與本機覆寫的分工記錄，日後轉換用戶端時也能更清楚地重建設定。

設定驗證與故障排除

驗證應分成三個層次：檔案能否解析、核心能否啟動，以及實際請求是否經過預期出口。通過第一層不代表後兩層也成功；測試目標可連線，也不代表所有應用程式都已被接管。將這三個層次分開檢查，通常比反覆重新安裝更有效率。每次只修改一個與問題相關的欄位，並保留修改前的設定與一筆可重現的請求，才能判斷變更帶來的影響。

先做靜態檢查，再重新載入

使用獨立 mihomo 核心時，可透過設定測試參數檢查檔案；使用圖形用戶端時，則優先採用內建的檢查與重新載入功能。請在具備相關程式與檔案的目錄中執行命令；若程式不在環境變數中，請使用實際路徑。以下命令不會自動為應用程式設定系統代理，也無法證明遠端節點在線；主要用途是提早發現解析、引用及其他設定錯誤。

mihomo -t -f ./config.yaml

若使用 Windows 命令環境，程式名稱與路徑可能需要依實際情況寫成可執行檔格式。錯誤訊息指出某一行時，除了檢查該行，也要確認上一個清單項目、引號是否成對，以及上層縮排是否正確。若錯誤是引用了不存在的策略，請搜尋該名稱的定義與所有使用位置，不要只刪除報錯行；直接刪掉規則可能讓流量改走另一個兜底出口。

依照連線經過的階段閱讀日誌

重新載入後，先確認設定已成功載入，再檢查監聽是否建立。連接埠遭占用、權限不足、提供器檔案無法讀取，都可能在送出網頁請求前發生。若用戶端無法啟動，可先參考啟動時閃退的逐項處理方式。核心運作正常後，再送出新的請求，依序檢查 DNS、規則命中、策略選擇與遠端連線，不要把所有錯誤一概稱為網路問題。

解讀日誌中的逾時，必須搭配目標與發生階段。解析伺服器逾時時，先檢查 DNS 上游路徑；連線代理伺服器逾時時，先檢查節點位址、連接埠與目前網路；若代理已建立但目標網站逾時，則繼續檢查伺服器出口與目標可達性。單獨一行錯誤通常不足以判斷原因，前後數行與同一時間的連線詳細資訊更有參考價值。閱讀方式可參考執行日誌內容與排查步驟。

透過最小化測試區分問題

先固定一個手動選取的節點，關閉不必要的自動切換，再使用明確支援代理的應用程式送出請求。如果這個入口可正常使用，啟用 TUN 後卻失敗，就應檢查權限、路由、DNS 劫持與其他虛擬網卡，而不是繼續修改節點密碼。如果直連與代理都無法解析同一個網域，就先處理解析路徑。每次只改變一項條件，測試結果才有比較價值。

測試自訂規則時，先將一條精確網域規則放在前面，然後建立新連線並觀察是否命中。如果精確規則有效，但大型規則集合無效，請檢查集合格式、載入狀態與外層順序；如果精確規則也未命中，請確認請求主機名稱是否符合預期。網頁可能會連線到多個網域，首頁開啟不代表頁面中的所有資源都使用相同出口，因此應針對實際失敗的連線進行檢查。

重新載入設定後，也要考慮舊連線、DNS 快取與歷史選擇。長連線可能繼續使用原出口，瀏覽器可能重用現有連線集區，用戶端也可能還原先前保存的策略。需要進行乾淨測試時，先保存目前狀態，再結束相關連線並重新送出請求。不要保留舊工作階段，卻只憑介面上的新群組名稱，就推斷所有流量都已切換；如此很容易得到互相矛盾的觀察結果。

還原設定與分享排查資訊

修改失敗時，請還原到最近一次可用的設定，不要在錯誤基礎上不斷增加開關。可以依照連接埠、DNS、節點、策略群組、規則、覆寫的順序逐項加入變更，每次記錄成功與失敗的範圍。尋求協助時，只需說明作業系統、用戶端名稱、使用的核心、失敗階段及最小相關片段。請先移除訂閱網址、密碼、使用者識別資訊與控制憑證；公開截圖也要檢查側欄和日誌中是否含有敏感資料。