為什麼要先搞懂「策略組」？
對大多數使用者來說，Clash 系列客戶端最容易誤解的一點，是把「有節點」等同於「所有程式都會自動走對的那條線」。實務上，流量會先被規則與策略組層層轉送：可能先問要不要走廣告阻擋、再問要走哪一組負載平衡，最後才落到你看到的單一伺服器名稱。Clash Verge Rev 在 Windows 上把這一整套攤平成清楚的清單介面，但你若不知道點的是哪一層，就很容易發生「明明延遲測速很漂亮，可是某個軟體還是連不上」的狀況。
這篇文章刻意和一般入門設定做出區隔：我們不再重複下載安裝，而是假設你已能成功匯入訂閱並啟動核心，專心處理「策略組怎麼切」「延遲測速按下去背後在做什麼」「怎麼判讀結果」。若你剛接觸 Verge Rev，也可以先讀站上較早的入門文取得基礎流程，再回來對照本文的視角，會更有感覺。
你在設定裡會看到的幾個關鍵詞
以下名詞在設定檔（YAML）與介面上會交替出現，先對齊語彙後面比較不會迷路。
- 策略組（Proxy Group）：一個可再放多個「上游」的容器；上游可能是單一節點，也可能是另一個子策略組，形成樹狀結構。
- Selector（手動選擇）：由你點選要使用哪個上游；適合你想固定連某國線路、或排除自動選線不穩的時候。
- URL-Test / 自動測速選線：核心會依設定對候選節點輪詢延遲，挑選符合條件的一個當前生效節點；介面上常顯示為可展開的群組，並帶有週期性更新。
- 延遲測速：客戶端對設定的測試目標（多在設定檔的
url或 UI 提供的預設）發 request，量到的數字是「到該目標的往返延遲」參考值，不是頻寬，也不保證等於你開 YouTube 或遊戲伺服器的路徑品質。 - GLOBAL / RULE / DIRECT：屬於模式層級的概念，決定規則表如何套用；與「同一模式底下要挑哪一個策略組出口」是兩件事，但常一起影響你觀察到的測速結果。
不同機場產出的設定檔命名習慣差異很大：你可能會看到「手動選擇」「自動選擇」「🔰 選擇節點」等中文別名，本質上仍落在 Selector 或 URL-Test 這類型之一。
在 Windows 版介面要從哪裡進去？
請先完成兩個前置檢查：第一，左側「設定檔」分頁已經選定要使用的訂閱，且狀態顯示為已啟用；第二，主畫面上的系統代理或 TUN 開關是否符合你當下的需求（僅測延遲時通常不強制開 TUN，但若你實際上網靠 TUN，測試情境請盡量接近真實）。接著切換到「代理」（Proxies）分頁，這裡就是大多數策略組與節點的總覽。
畫面通常會以樹狀或分組清單呈現：最上層可能是 PROXY 或機場自訂的入口名稱，點開後才看到實際的區域節點或下一層子組。若你找不到預期組名，八成是訂閱裡把它折疊在不同別名下，可在頂部搜尋框輸入關鍵字快速過濾。對懶得翻 YAML 的人，這個搜尋框往往比改檔更快。
手動節點切換（Selector）實際怎麼點？
當策略組型別為手動選擇時，你點了哪一個子項目，核心就把該組目前的出口鎖定在那一項，直到你再次更改。實務步驟很直覺：在代理分頁展開目標策略組，直接點選節點名稱，使其呈現高亮或勾選狀態。部分面板會把「當前選中的上游」放在列的最上方，修改後若網頁沒立刻恢復，請先確認不是快取或長連線應用卡著舊連線。
若同一組底下除了節點還看到另一個組名，代表那是巢狀策略：你選了子組後，真正的伺服器還要看子組內部的 Selector 或 URL-Test 結果。這也是新手常覺得「我明明換了節點，怎麼規則還是走舊線」的原因——實際上你只換了外層標籤，內層仍由自動選線決定。遇到這種結構，建議從最靠近規則引用的那一層開始調，或在設定檔裡暫時改成較扁平的組合以便除錯。
手動切換後若應用程式仍走舊連線，可嘗試關閉並重開該程式，或在瀏覽器使用全新無痕視窗；某些遊戲與通訊軟體會長時間佔用既有 UDP session，不會立即跟著策略組切換。
URL-Test 自動選線背後在做什麼？
URL-Test 類型的策略組會讀取設定裡的測試網址、間隔、容忍值與節點容錯策略。核心在一次週期內對候選清單做延遲量測，挑出當下符合條件者作為預設出口。介面上你看到的主節點名稱可能會自動跳來跳去，這不是 bug，而是自動選線在汰換表中較佳節點。
也因為這個機制，你「手動點選」有時會被下一輪自動測試洗回去——除非設定檔允許固定或 UI 提供覆寫選項。若你希望長期固定某節點，應優先找機場是否提供純手動組，或自己在 Selector 上指定，而不是硬槓 URL-Test 的自動邏輯。
進階使用者若需要理解參數語意，可直接在 Verge Rev 的設定檔編輯器查看對應片段：留意 type: url-test 區塊內的 url、interval 與節點列表。把測試網址換成更接近你日常目標的 HTTPS 位址，有時比猛測一個完全不同的 CDN 節點更能反映實際體驗，但要與服務商政策與節點權限相容，避免違規濫測。
延遲測速按鈕：單點、群組與批次
介面中的閃電圖示或「延遲測試」文案，本質上是請核心對指定節點向測試 URL 發出探測。你可以先對單一節點點一次，確認線路沒有全滅，再對整個展開後的清單做批次測試（實際按鈕位置會隨版本微調，通常在群組標題列或頂部工具列）。批次測速省時間，但會一次產生大量請求，若機場節點本身不允許高頻探測，數字可能短暫失真或觸發節流。
建議把測速當「相對比較」而非絕對真理：同一次批次內排名高低的參考價值，通常大過跨日跨網路環境的絕對毫秒數。若你今天測到全部節點忽然比平常高一個數量級，先檢查是不是家裡 Wi-Fi 塞車、背景正在下載大檔，或 Windows 防火牆剛剛更新規則。
實測小技巧：先固定在同一個 Wi-Fi、關掉其他 VPN，保留 Verge Rev 的「規則模式」做兩輪測速；若第二輪結果顯著穩定，才代表節點本身大致可用，而非你的測試動作撞到暫時性尖峰。
測速數字怎麼讀才不會誤會？
常見的顯示包含毫秒數、timeout 或代表失敗的符號。毫秒越低通常代表到測試 URL 的握手越敏捷，但不代表串流不卡。若節點在晚間尖峰掉速，你可能看到延遲僅小幅上升，實際影片卻頻繁緩衝——那是頻寬與出口的排隊問題，而不是單純 ping 能揭露的。
當你看到少數節點極低延遲、多數節點 timeout，很可能代表測試目標對部分出口不可達，或該批節點被區域路由繞太遠。此時可改用手動挑選一個「體感穩定」的節點，不要被單一數字誤導。對長時間連線需求（會議、遠端桌面），延遲略高一點但抖動小的節點，往往比極低延遲卻頻繁切換的路線更適合。
若測速結果與實際訪問某個網站差距過大，請回頭檢查規則是否把該網站域名導到不同策略組；有些設定會把大型站点的不同 CDN 路徑拆開，導致你在節點榜上看到的第一名，根本不是服務該域名時會走的那條出口。
與規則、入口策略組的關係（進階速查）
在「規則」（Rules）分頁或外部完整的規則表裡，最後常常會看到諸如 MATCH 指向 PROXY 或機場自訂名稱。實際路徑是：規則命中某個策略組後，該組再決定節點或進一步的子組。手動切換節點時要找對的那個組，便是你必須理解這條鏈的原因。
另一個典型情境是「你在 GLOBAL 手動選了 A 節點，但規則仍是 Rule 模式」。在 Rule 模式下，GLOBAL 全域組未必會覆寫每一條規則；若你預期所有流量跟著你在 GLOBAL 的選擇走，需要確認客戶端的模式切換是否真的在 Global，而不是只是展開了錯誤的組閱讀。這點和 macOS 上部分 GUI 把模式與節點分區呈現的體驗不同，Windows 使用者有時會忽略模式列的狀態。
常見問題（精簡版）
測速漂亮但上網不順？
如前文所述，測試 URL 與真實業務域名不同、DNS 走向不同、或節點頻寬被佔滿，都會造成體感落差。優先換一個你常用的網站實際打開試試，並觀察 CPU 是否被 TLS 解密拖垮；在純系統代理情境下，少數不支援系統 Proxy 的程式會讓你誤以為「節點壞了」，其實是流量根本沒進代理。
整排 timeout 怎麼辦？
先更新訂閱並重啟核心；再檢查系統時間、臨時關閉第三方防火牆實驗；若只在某個網路環境發生，可能是對外針對測試域名的攔截。仍無法排除時，把問題縮小到單一節點與最小規則集，會比同時改多個參數容易找到因果。
和 ClashX Pro 的「模式切換」差在哪？
macOS 上的 ClashX 系列常把模式與狀態列操作綁在一起，而 Verge Rev 在 Windows 更偏向完整儀表板；兩者核心概念相似，但路徑所依賴的 UI 不同。本文刻意聚焦 Verge Rev 的代理分頁與策略組操作，避免把選單名稱直接套用到另一套客戶端。
建議的實測流程總整理
- 確認訂閱生效、模式落在 Rule 或你日常使用的狀態。
- 開啟代理分頁，搜尋機場給的主出口策略組名稱。
- 先看清該組是 Selector 還是 URL-Test，避免在自動組上強行當手動用。
- 執行一輪批次延遲測速，記錄相對排序而非純看絕對值。
- 挑两支節點做 A／B 真實上網交叉驗證，必要時改手動固定。
- 若仍有異常，回到規則鏈檢查命中路徑，而不是一直重複測速。
最後，把視角拉回工具選擇：不少使用者會嘗試只靠改系統 Proxy、或找功能半套的老舊客戶端硬撐，結果在策略組與測速資訊不足的情況下，只能「猜節點」排查問題，浪費大量時間。相較之下，Clash Verge Rev 搭配 Mihomo 核心，能把多層策略組、url-test 與規則鏈攤在單一介面裡逐步核對；當你需要在 Windows 上手動節點切換、理解自動選線邏輯，或使用批次延遲測速找出相對穩定的出口時，這套組合能顯著降低試錯成本。若你也希望用現代化、可驗證來源的方式管理代理，不妨 立即免費下載 Clash，開啟流暢上網新體驗，從乾淨的官方用戶端與完整策略視圖開始建立自己的使用節奏。