Clash 使用手冊
訂閱與規則分流設定

01 核心觀念：一次連線會經過哪些環節

用戶端、核心與服務並非同一回事

在 Clash 生態系中，用戶端通常是具備視窗和選單的應用程式，用來管理訂閱、切換模式及查看連線。核心則是負責網路轉送與規則比對的程式；Mihomo 是這個生態系中常見的核心。介面能開啟，只代表應用程式已啟動，不代表核心已載入設定，更不代表網路請求已進入代理。排查時將這幾件事分開確認，通常比反覆重新安裝更有效。

代理服務提供遠端連線所需的位址、通訊協定與驗證資訊；訂閱則是散布這些設定的方式。安裝用戶端不會自動提供可用服務。請向有權使用的服務提供者取得相容設定，並遵守當地法規、服務條款及所在網路的管理規範。訂閱連結可能含有存取憑證，切勿貼到公開討論區，也不要交給來路不明的轉換網站。

先了解請求如何進入，再看流量從哪裡出去

一個請求通常會經過四個步驟：應用程式發出請求，系統代理或虛擬網卡將請求送進核心，規則決定採用哪項策略，策略再選擇直連或遠端代理。系統代理是作業系統提供給應用程式的代理設定，應用程式是否遵循取決於自身設計。TUN 是虛擬網路介面，可以接管更多網路流量，但同樣會受到路由、權限及排除項目影響；啟用後不代表所有程式都會如預期運作。

節點是一組具體的遠端連線參數；代理組則是管理節點或其他策略的集合。規則中的 PROXY 通常是代理組名稱，不是任何設定都自帶的內建關鍵字。DIRECT 代表直連，REJECT 代表拒絕。看到規則指向某個名稱時，請回到設定確認該名稱是否存在，再檢查該組最後選用了什麼。

DNS 與連接埠為何會影響結果

DNS 是將網域名稱解析為位址的機制。用戶端可能使用系統解析，也可能啟用核心自己的 DNS。解析發生在哪一層，會影響網域規則是否生效、位址規則比對的結果，以及請求是否需要等待解析。遇到連線失敗，不能直接認定是節點故障；網域無法解析、解析出的位址無法連線，以及代理交握失敗，是三種不同問題。

連接埠則是本機服務的入口編號。混合連接埠通常同時接受 HTTP 代理與 SOCKS 代理請求，但不同用戶端的預設值並不一致。本文以 7897 為範例，實際操作請以目前用戶端顯示的數值為準。連接埠號碼相同，不代表流量已進入核心；還要確認監聽位址、應用程式設定，以及該連接埠是否被其他程式占用。

02 選擇用戶端：先確認平台與維護需求

優先選擇適合目前裝置的圖形介面

首次使用可以優先考慮 Clash Plus，再依平台和操作習慣比較其他用戶端。不要只看視窗外觀，也不必為了和某張教學截圖完全相同而安裝舊軟體。真正需要確認的是是否支援目前的作業系統、處理器架構是否相符、訂閱格式是否相容，以及是否具備所需的系統代理、記錄檔和 TUN 管理入口。安裝檔統一放在Clash 下載頁。

Windows 可依序了解 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu。macOS 可選擇 Clash Plus、Clash Verge Rev 或 FlClash。Linux 的圖形介面方案包括 Clash Verge Rev 和 FlClash。各用戶端可能採用相近的核心功能，但服務安裝方式、覆寫機制與權限管理各有不同，因此本文以功能名稱說明步驟，不將特定按鈕的位置視為所有用戶端的通用標準。

行動裝置與桌上型裝置的差異

Android 可依需求選擇 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard。Surfboard 的設定架構與 Clash YAML 並不完全相同，不能將所有 Clash 設定原封不動匯入後，就期待每個欄位都能一一對應。請先查看服務提供者支援的訂閱格式，再選擇用戶端。行動作業系統通常透過 VPN 介面接管流量；應用程式首次連線時要求的系統授權，是網路接管流程的一部分。

iOS 可透過下載頁前往 Clash Plus 的 App Store 頁面，也可查看其官方網站 clashplus.io。手機的背景執行限制、依應用程式接管流量的能力，與桌面的系統代理開關並非同一套機制。跨裝置學習時，應沿用規則思路與設定關係，而不是照搬選單名稱。訂閱可以共用，不代表每台裝置都能使用完全相同的執行參數。

封存用戶端與獨立使用核心

Clash for Windows 和 ClashX Meta 已停止維護，下載頁將它們列為封存選項。既有設定可供遷移時參考，但新環境較適合優先選擇仍持續維護的方案。遷移時請保留訂閱來源、規則用途與代理組選擇，不要直接覆蓋新用戶端的整個資料目錄。舊版的資料庫、快取與服務註冊資訊，可能與新用戶端不相容。

Mihomo 核心套件主要提供給願意自行維護設定、程序與權限的使用者。它並非具備完整視窗介面的安裝程式，也不會自動替使用者完成所有系統整合。如果目前只想讓瀏覽器依規則存取網路，先用圖形介面完成主要流程會更省事。若要遷移舊環境，可搭配閱讀Clash for Windows 停止維護後的替代方案與遷移方式，逐項確認連接埠和代理設定。

這個階段不必同時安裝多個用戶端來「比較運作狀況」。先選一個作為主要用戶端，並關閉其他工具，避免它們同時修改系統代理、路由與 DNS。保留單一清楚的網路路徑，後續驗證結果才有意義。

03 安裝檢查：系統架構、權限與本機連接埠

下載前確認作業系統與處理器架構

先開啟系統資訊，確認作業系統、處理器架構及可用儲存空間。Windows 常見安裝檔適用於 x64；macOS 須區分 Intel 與 Apple Silicon；Linux 則要確認發行版的套件格式。檔名中有 ARM，不代表所有 ARM 裝置都能使用同一個檔案。請以下載頁提供的架構及用戶端需求為準，不要靠更改副檔名或強行解壓縮來解決平台不相容。

安裝前請退出舊的代理用戶端，以及其他可能接管網路的工具。若舊應用程式啟用了開機啟動或常駐服務，只關閉視窗可能仍會留下背景程序，請從系統匣選單完整退出。記下舊環境的混合連接埠與訂閱來源，方便遷移後核對。此時先不要刪除舊設定；等新用戶端完成連線並通過驗證後，再決定是否清理舊環境。

依平台完成首次啟動

Windows 執行安裝程式後，先以一般應用程式方式啟動。只有安裝服務或使用 TUN 權限時，才依用戶端說明核准提升權限。不要把長期以系統管理員身分執行整個應用程式當成通用解法。macOS 將應用程式移至「應用程式」資料夾後，透過系統認可的方式開啟；遇到安全性提示時，先確認來源與提示內容，不要照抄來路不明的終端機指令，大量關閉系統防護。

Linux 請使用符合發行版的套件管理方式安裝，並確認相依性錯誤已排除。圖形視窗出現後，檢查核心狀態及記錄檔入口是否可用。涉及桌面環境的系統代理設定時，各桌面環境的行為可能不同；未自動寫入代理設定，不一定代表核心無法執行。請先區分應用程式啟動失敗、核心啟動失敗與系統整合失敗，再針對相應層級處理。

建立乾淨的首次啟動基準

首次啟動後，先查看設定中的混合連接埠、監聽位址及允許區域網路連線的狀態。若只供目前這台電腦使用，通常維持僅限本機存取即可。本文以 127.0.0.1:7897 作為示範入口；若實際顯示其他連接埠，後續的應用程式設定與指令也要一併替換。儲存設定後，確認用戶端沒有回報監聽失敗或連接埠遭占用。

# Windows PowerShell：查看範例連接埠的監聽狀態
Get-NetTCPConnection -LocalPort 7897 -State Listen

# macOS / 常見 Linux 環境：查看範例連接埠
lsof -nP -iTCP:7897 -sTCP:LISTEN

這些指令是依作業系統選用的排查工具，不需要在所有平台上執行。查不到監聽狀態時，先確認核心是否已啟動、是否已載入設定，以及實際連接埠是否為此數值。找到程序後，請核對程序名稱，不能只因連接埠存在就判定正常。若出現找不到指令的訊息，可使用系統內建的資源監視器或用戶端記錄檔確認，不必為了一次檢查額外安裝工具。

安裝階段不必立即啟用 TUN、開機連線及所有自動更新選項。先確保用戶端能正常啟動、記錄檔可讀取且連接埠沒有衝突，再進入訂閱章節。遇到故障時，保留完整錯誤訊息與觸發步驟，比只記下「打不開」更有用。至此應建立一套精簡且可重現的本機執行環境，而不是堆疊許多尚未驗證的功能。

04 匯入訂閱：從連結到實際執行設定

取得相容設定後，再執行更新

訂閱是可更新的設定來源，常見形式是遠端連結，也可能是本機 YAML 檔案。請先向服務提供者確認它適用於哪個用戶端或核心，再開啟用戶端的訂閱、設定或 Profiles 頁面，新增遠端設定。輸入容易辨識的名稱，貼上完整連結，儲存後執行更新。避免漏掉連結末端的參數，也不要把網頁顯示的標題當成實際訂閱網址。

更新成功後，通常還要選取並啟用該設定。下載完成與設定生效是兩個步驟：訂閱清單中的更新時間改變，不代表執行中的核心已切換設定。請查看目前設定名稱、核心記錄檔及代理組是否出現；如果仍看到舊的組名，先確認是否已啟用。部分用戶端支援同時管理多個訂閱，但實際執行設定如何合併，仍須依其設定機制判斷。

釐清訂閱檔、覆寫層與執行結果

訂閱原始內容是服務提供者傳送的資料；覆寫是用戶端載入時額外補上或修改的內容；執行設定則是核心最後接收的結果。手動編輯下載快取，下次更新時可能會被覆蓋。要長期保留的規則、連接埠或 DNS 設定，應優先放在用戶端提供的持續性覆寫入口，並確認它是在訂閱前、訂閱後，還是依欄位合併執行。

並非所有遠端設定都包含完整規則。有些只提供節點，需要用戶端的範本補上代理組和規則；有些則已包含 DNS、規則提供器及完整策略。匯入後請先檢查結構，不要為了套用某段教學就直接刪除原始設定。尤其代理組名稱與規則目標之間存在引用關係，改了組名卻未同步更新規則，可能導致核心拒絕載入或部分策略失效。

# 結構範例：用來認識欄位，並非代理服務設定
mixed-port: 7897
allow-lan: false
mode: rule

proxies: []

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

以上 YAML 可用來說明設定之間的關係，但沒有遠端節點，所有請求最後都會直連。它適合閱讀與檢查欄位，不適合用來驗證代理服務是否可用。實際訂閱中的伺服器位址、密碼、通訊協定與憑證參數，應由有權限的來源提供，不要拼湊教學片段使用。YAML 使用空格縮排，同一層級應保持一致；定位字元、全形冒號和未成對引號都可能造成解析錯誤。

依錯誤類型處理更新失敗

若顯示網路逾時，先確認目前網路能否連線至訂閱服務，再檢查是否必須透過既有代理更新。若回報驗證失敗，請確認連結是否過期、服務是否有效。若收到的內容是網頁而非設定，可能開啟了登入頁、錯誤頁或轉址頁，請向服務提供者確認正確入口。若下載成功但解析失敗，應著重檢查欄位相容性及錯誤行，而不是一再更換節點。

匯入本機檔案適合遷移與離線備份，但通常不會自動隨服務提供者更新。遠端訂閱則應配合服務有效期限與更新頻率使用，避免過於頻繁地手動重新整理。更新前先保留可還原的本機設定；更新後確認代理組、規則與連線仍正常。分享記錄檔或截圖時，請遮蔽訂閱連結、伺服器驗證資訊及個人存取紀錄；只遮住名稱並不代表已完整處理。

05 代理模式：分開設定入口開關與路由決策

規則、全域與直連各自控制什麼

代理模式決定進入核心的請求如何選擇出口，但不負責確保所有應用程式都會把請求交給核心。規則模式會依設定逐條比對，適合日常分流。全域模式會將已進入核心的請求交給全域策略，適合暫時縮小排查範圍。直連模式則讓進入核心的請求直接連線至目標，適合做對照測試。切換為全域模式，不會讓原本繞過系統代理的應用程式突然受到接管。

全域模式也不代表固定使用某個節點。切換後要確認全域策略目前指向哪個組或出口。規則模式則須檢查每條規則所引用的策略組選擇。若某個組包含 DIRECT，選擇該組就代表直連，即使介面仍顯示規則模式。要判斷請求的實際行為，應查看連線路徑與規則比對結果，不能只看首頁上的模式文字。

完成首次可判讀的連線驗證

先啟用規則模式，在代理組中選擇有權使用的出口，再開啟系統代理。開啟需要驗證的網頁，同時查看連線頁面。如果沒有新連線，優先確認瀏覽器是否使用獨立代理設定、擴充功能是否覆蓋設定，以及請求是否已被快取。可以重新開啟網頁以觸發新請求，但不要把瀏覽器原有連線誤認為切換後的結果。

若連線出現，請展開詳細資料，確認目標網域、符合的規則及最終策略。網頁能開啟只是其中一種結果：可能是直連成功，也可能是代理生效。請選擇預期路徑明確的目標進行對照，例如設定中明確指定直連的測試網域，以及明確指定代理的目標。不要只憑單一網頁是否載入，推斷整體網路環境；也不要將外部頁面顯示的地區當成唯一依據。

為不遵循系統代理的應用程式明確設定入口

有些命令列工具不會自動讀取桌面的系統代理設定。此時可以在工具本身設定代理，或為單次命令明確指定本機入口。以下請求使用範例混合連接埠；若連接埠不同，請替換相應數字。這項測試用於檢查 HTTP 代理入口，不能據此推斷 UDP 或 TUN 也正常。請求結果還會受到目標網站、目前網路與所選策略影響。

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

若指令顯示無法連線到本機連接埠，請回到安裝章節檢查監聽狀態。若已連上代理，但遠端交握失敗，接著檢查出口、驗證資訊與網路限制。需要暫時進行全域測試時，先記下原本的模式和代理組選擇，測試完成後恢復規則模式。切換模式通常只會影響新連線，既有長連線可能仍沿用原本路徑；必要時關閉相關連線，再重新發出請求觀察。

本階段要養成固定習慣：先確認「請求有沒有進來」，再確認「依哪條規則處理」，最後確認「出口是否可用」。如果入口完全沒有流量，調整規則無法解決問題；如果規則比對正確但交握失敗，繼續修改規則只會增加變數。需要更精簡的操作順序時，可返回入門指南，依照主線逐項重現。

06 規則分流：從首次比對到持續性覆寫

由上往下比對，符合後即停止

規則清單並非先計算所有條件再綜合判斷。一般而言，核心會由上而下檢查，第一條符合的規則便決定策略，後續規則不再參與這次判斷。越具體、越需要優先執行的例外，越應放在涵蓋範圍較大的規則之前。MATCH 是預設兜底規則，通常放在最後；若提早出現，後面的規則就不會有機會處理相應請求。

DOMAIN 比對完整網域名稱，DOMAIN-SUFFIX 比對特定網域及其子網域，DOMAIN-KEYWORD 則依網域中的關鍵字比對。三者的涵蓋範圍不同，不能只為了少打幾個字就任意互換。尤其關鍵字規則，涵蓋範圍可能超出預期。若只想處理特定主機，完整網域規則通常更容易驗證與維護。

# 假設現有設定中有一個名為 PROXY 的代理組
rules:
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

在這段規則順序中，docs.example.com 會先依完整網域規則設為直連，其他符合後綴條件的網域則交由代理組處理。私有位址規則會處理指定的位址區段；no-resolve 表示不會為這條位址規則主動觸發網域解析，但請求已有目標 IP 時仍可比對。不要將它理解成整份設定都停用 DNS，也不要對所有位址規則一律加上這個選項。

位址規則與規則集的適用範圍

IP-CIDR 用於 IPv4 位址區段，IPv6 位址區段通常使用 IP-CIDR6。GEOIP 依據位址資料庫判斷，IP 歸屬地並不等同於公司所在地或訪客所在區域。資料庫內容也可能變動。是否需要解析網域、是否沿用現有位址，都會影響實際結果；因此當位址規則排在網域規則前面時，尤其要留意 DNS 行為與比對記錄。

RULE-SET 用來引用設定中已宣告的規則提供器，適合將某一類規則獨立維護。它不是可直接把遠端連結寫進規則清單的簡寫；提供器名稱、來源、格式與行為類型必須彼此相符。純文字網域清單和傳統規則清單的格式不同，混用可能導致載入失敗或規則無效。新手應先理解幾條本機規則，再加入外部規則集。

修改執行結果，不只修改下載快取

新增規則前，先確認用戶端提供的是前置規則、後置規則，還是整份設定覆寫。如果把自訂規則加在既有 MATCH 後面，即使語法正確，也可能永遠不會生效。儲存後請檢查最終執行規則，而不只是編輯框中的文字。若代理組名稱含有空格、標點或非英文字元，必須照原樣引用，不能憑印象縮寫；若目標名稱不存在，應先修正引用關係。

每次只新增一條容易驗證的規則，重新載入設定，再建立新連線，確認連線詳細資料是否顯示新規則。若仍有舊連線，先關閉相應連線或重新啟動發出請求的應用程式。若依然未比對到，請確認看到的是網域還是 IP、前方是否有涵蓋範圍更廣的規則、應用程式是否繞過核心，以及覆寫是否確實納入執行設定。如此才能逐步找出問題，而不是一次加入整份規則後無從判斷。

07 TUN 模式：擴大接管範圍並搭配 DNS

什麼情況需要 TUN

如果瀏覽器已能依規則連線，但某個應用程式仍不遵循系統代理，可以先確認該應用程式是否支援單獨設定 HTTP 或 SOCKS 代理。若沒有合適入口，而且確實需要接管更多網路請求，再考慮使用 TUN。TUN 透過虛擬網路介面與路由將流量送進核心，比修改系統代理涉及更多系統層面的行為，因此應先確保基本連線正常再啟用。

啟用前先記錄系統代理狀態、目前的 DNS 與其他 VPN 工具狀態，並確認停用後有辦法還原。關閉可能與預設路由衝突的其他流量接管工具，再依用戶端要求安裝服務或核准權限。不要同時啟用多張虛擬網卡接管，再試著判斷是哪一套發生問題。行動裝置的 VPN 介面與桌面版 TUN 設定入口不同，不能照搬桌面 YAML 來覆寫手機上的所有設定。

一併理解介面、路由與解析

TUN 能接收流量，不代表解析路徑自然就正確。應用程式可能透過系統 DNS、加密 DNS 或自己的解析器取得位址；核心也可能接管部分 DNS 請求。如果網域資訊沒有進入預期路徑，部分網域規則的表現就可能與系統代理模式不同。遇到「直接輸入位址可用，輸入網域卻無法使用」時，應優先檢查 DNS，而不是立刻更換所有出口或修改所有規則。

# Mihomo 欄位範例；是否需要填寫，請依用戶端的 TUN 管理方式判斷
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

這段設定展示自動路由、出口介面偵測與 DNS 接管欄位，並非可獨立執行的完整設定。圖形介面用戶端可能會自行產生這些欄位，優先透過其設定介面管理，以免重複覆寫。any:53 不代表會自動處理所有形式的加密 DNS；應用程式透過 HTTPS 發出的解析請求，不能直接等同於傳統的 53 埠查詢。實際行為也會受到 DNS 設定與路由範圍影響。

了解 Fake-IP 與真實位址解析

Fake-IP 是一種為網域指派內部對應位址，再由核心將位址與網域連結的運作方式，並非真的把目標伺服器移到這個位址。使用時，系統工具顯示的位址可能不是網站的真實公網位址，因此不能只憑一次解析結果就認定遭到錯誤攔截。部分應用程式依賴真實位址或特殊探索機制，可能需要排除特定網域；排除範圍應盡量精確，不要直接關閉整套 DNS 功能。

切換 DNS 運作方式後，系統或應用程式快取可能仍保留舊結果。先結束相關連線、重新進行解析，再查看記錄檔；必要時依系統文件清除 DNS 快取。區域網路印表機、共享資料夾或裝置探索異常時，請檢查私有網段路由、區域網路網域解析及排除規則。不要將所有區域網路問題都歸咎於節點故障，也不應透過開放整個監聽範圍來解決解析問題。

驗證時分別測試瀏覽器、目標應用程式與區域網路資源，並在連線頁面確認它們是否進入核心。若只有一個應用程式失敗，請檢查它本身支援的通訊協定與代理功能；若所有應用程式都失敗，優先檢查流量接管路徑。退出用戶端後，也要確認系統網路已恢復正常。完成這些對照後，才適合啟用自動啟動與自動接管；不能只憑某個網頁短暫開啟，就認定設定穩定。

08 日常維護：更新、備份與分層排查

分開處理三種更新

用戶端更新、核心更新與訂閱更新各自會改變不同內容。用戶端更新會影響介面與系統整合；核心更新可能影響通訊協定、規則與 DNS 行為；訂閱更新主要影響服務提供者下發的節點與規則。不要等三項都更新後才開始驗證，否則很難找出變化來源。請依需求逐項更新，每次都記錄操作前後的模式、設定名稱及重要開關。

更新前先儲存可還原的設定，並閱讀與目前使用方式相關的變更說明。訂閱新增的欄位可能需要較新版核心支援，舊用戶端也可能無法正確管理新核心的功能。遇到相容性錯誤時，先確認用戶端與核心的組合，再考慮是否回退；不要從多個來源混裝來路不明的檔案。還原備份時，同樣要確認用戶端能辨識設定格式，不要直接覆蓋所有內部資料。

備份應保留哪些內容

一份實用備份至少要包含訂閱來源、持續性覆寫、自訂規則、代理組選擇，以及連接埠、TUN 和 DNS 的重要設定。訂閱快取可以作為暫時的還原材料，但不能取代訂閱來源與自訂內容。截圖方便記住開關狀態，卻不適合還原長篇規則。將設定匯出為文字，再附上簡短操作說明，通常比只備份應用程式資料夾更容易遷移。

備份可能包含可存取服務的憑證，應存放在有存取控制的位置，跨裝置傳輸時避免公開分享。電腦與手機可以使用相同訂閱連結，但連接埠、介面、快取路徑及 TUN 參數未必通用。多裝置同步時，建議先同步「服務與規則用途」，再分別設定系統層級參數。具體做法可參考電腦與手機共用訂閱的幾種同步方式。

每次只變更一個條件來排查

先確認不經代理時基本網路是否可用，再確認核心是否啟動、連接埠是否正在監聽，接著查看目標請求符合哪條規則，最後檢查遠端連線。每個步驟都要留下結論。暫時切換全域模式是為了比較規則因素，並非所有日常故障的通用解法；暫時停用 TUN 是為了判斷是否為流量接管問題，也不代表 TUN 必須永久停用。排查結束後，請還原原有設定並重新驗證。

記錄檔層級以足以完成目前排查為準。需要更多資訊時，暫時提高層級，重現一次後儲存相關片段，再恢復日常設定，避免長期累積大量存取紀錄。向他人求助時，請說明系統、用戶端、目前模式、流量接管方式與完整故障現象，並提供已遮蔽敏感資訊的必要記錄檔。不要直接上傳整份訂閱，也不要連同無關的瀏覽紀錄一起打包。

延遲測試是輔助觀察工具，不代表完整使用體驗。測試位址、交握流程、目標網站與頻寬需求都會影響結果。若測試正常但實際應用程式仍卡頓，應檢查該應用程式的目標連線，而不是只反覆按測試。關於測試結果的意義，可閱讀url-test 延遲與實際體驗的差異，避免將單一數值視為整體出口品質。

09 進階學習路線：代理組、規則集與可還原設定

先完善策略架構，再增加自動化

基本連線穩定後，進階目標不是讓設定越長越好，而是讓選擇、更新與回復更清楚。先為日常使用、特定服務及直連例外建立明確的策略界線，再考慮自動選擇。名稱清楚、層級較少的代理組，比多層互相引用更容易理解。建立代理組前，先寫下它要解決的需求，以及發生問題時應切回哪個出口。

select 代理組由使用者手動選擇，適合需要固定出口的情境。url-test 會依指定位址的測試結果選擇候選項目；fallback 則依候選順序與可用狀態切換。不同代理組的選擇邏輯各不相同，不能一概視為「自動選最快」。測試請求本身也會消耗網路資源，應依實際需求設定檢查週期，不必為了介面變化而頻繁測試。

# 設定片段：proxies 中必須先有同名節點
proxy-groups:
  - name: 日常選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT

  - name: 自動選擇
    type: url-test
    proxies:
      - 出口甲
      - 出口乙
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

這裡的「出口甲」與「出口乙」是範例引用名稱，使用前必須替換成現有設定中實際存在的節點名稱。測試位址也應選擇目前環境允許存取且適合持續檢查的目標。interval 是檢查間隔，tolerance 用於降低因小幅波動而頻繁切換的可能性；這些參數不保證速度。對需要穩定工作階段的應用程式，也要考慮切換出口對登入狀態與長連線的影響。

將規則集視為獨立相依項目管理

加入規則提供器時，請記錄來源、行為類型、更新方式與引用位置。遠端規則變動後，實際分流也會改變，因此「設定檔沒有修改」不代表執行行為永遠不變。重要的自訂例外應保留為前置規則，並定期確認規則集仍可更新。遇到下載失敗時，先查看提供器狀態，不要只因代理組正常，就認定所有外部相依項目都已載入。

擴充 DNS 與流量嗅探功能前，也要先釐清要解決的問題。嗅探是從部分通訊協定流量中嘗試取得網域等資訊，能力會受到通訊協定與加密方式限制，並非所有連線都能還原網域。若目前規則已可靠運作，就不必為了讓功能清單看起來完整而啟用所有選項。每新增一項功能，都應記錄它處理哪類請求、有哪些限制，以及停用後如何恢復原有行為。

建立可重現的設定變更流程

建議將變更分成四個步驟：複製目前可用的設定、進行一項小幅修改、驗證語法與執行結果，記錄結論後再決定是否保留。若使用獨立的 Mihomo 核心，而且終端機能找到該程式，可使用下方指令檢查設定。圖形介面用戶端也可先使用內建的設定檢查功能。語法檢查通過只代表設定可被接受，仍須實際連線驗證規則與出口。

mihomo -t -f config.yaml

進階練習可依序完成：為一個網域新增直連例外、為某類服務建立獨立策略、確認一個規則集能正常更新，再設計一份可還原的備份。每項完成後，檢查執行規則與連線路徑是否符合預期。選擇出口時，可參考延遲、倍率、地區與通訊協定的比較方式，但不要用單次測試取代長期實際觀察。