本篇要解決什麼：在 CFW 裡「換節點」與「看延遲」
如果你已經能在 Windows 上開啟 Clash for Windows（常簡稱 CFW），也讓設定檔／訂閱成功載入，下一個最常卡住的問題往往是：Clash for Windows 要怎麼換節點？測速數字怎麼看？能不能依延遲排序挑一條比較順的線？
本篇刻意不談下載、安裝與匯入訂閱，而是聚焦在 Proxies（代理／節點）相關操作：先認識策略組與你的流量怎麼被送出去，再在介面裡完成節點切換、一鍵測速（延遲測試），並學會用延遲排序當成選線的捷徑。這些動作正是多數使用者在搜尋「CFW 換節點」「Clash for Windows 節點切換」「一鍵測速」時真正想完成的目標。
不同版本、不同作者打包的圖形介面，按鈕名稱可能略有出入；本文明確指出邏輯與觀念，讓你即使按鈕文字不完全一致，也能在畫面上找到對應功能。若你手邊的 CFW 衍生版本已更名，建議以「Proxies／代理」或「節點清單」所在分頁為中心去找。
操作前兩項確認：有節點、代理已開
在講策略組與延遲排序之前，先用最短的時間確認環境沒有擋在更前面的問題，否則你再怎麼測速，讀到的也可能是「錯誤狀態」。
- 設定檔已載入且節點清單不是空的：到 Profiles（設定檔）或等價位置，確認作用中的設定檔確實是你預期的那份；必要時先更新訂閱，再回到節點頁。若清單一片空白，問題多半在訂閱或 YAML，而不是「不會按測速」。
- 已開啟會讓瀏覽器走代理的開關：多數情境要先把 System Proxy（系統代理）或你慣用的等同選項打開，才能在瀏覽器裡感受到換節點的差異。若你改用 TUN 或其他全域方式，也請確保該模式確實生效，再進行延遲測試與排序比較。
接下來，把專注力放在 Proxies：這裡才是「策略組」與「節點切換」的主戰場。
先搞懂策略組：你的流量不是「直接點節點」而已
在 Clash 系模型裡，對外連線通常不是單一節點一路用到底，而是由規則決定「這一包流量要丟進哪一個策略組」，策略組再決定真正走哪一個節點或下一層策略。
你在介面上看到的一排排可展開項目，很多就是Proxy Group（策略／代理群組）。常見類型包括（實際以你的設定檔為準）：
- Selector（選擇器）：偏「人為決策」。你點選哪一個子項目，該群組在一段時間內就以那條線當出口（直到你改選或設定檔更新）。這也是新手最容易理解的「手動切換」。
- URL-Test：偏「自動決策」。核心會對候選節點做探測，依結果挑一條當前「看起來最快」的線；介面上可能仍顯示列表，但切換時機由測試規則與間隔掌控。
- Fallback：偏「備援」。當前節點不可用時往後跳；與「你手動想選一條追剧線」的體感不同。
- Load-balance：分散到多條線，目的常是連線品質或負載管理，而不是單純挑延遲最低的單點。
因此，搜尋「Clash for Windows 節點切換」時，請先在腦中分兩件事：（1）規則把某類網站導到哪個策略組；（2）該策略組目前是 Selector 還是自動型。只有前者對了、後者也對了，你在介面上選的節點才會真的反映到你想測的那條連線上。
Proxies 分頁怎麼切換節點（CFW 日常路徑）
在大多數 CFW 版面裡，切換節點就是到 Proxies，依序處理兩個層級：先看外層策略組，再點內層實際節點或子策略。
手動策略組：點名稱就是換節點
當某策略組屬於可手動選擇型，列表裡會列出數個候選：可能是單一直連節點，也可能是另一組下游策略。操作上通常是：
- 展開你要控制的策略組（例如常見的「GLOBAL」「Proxy」「♻ 自動選擇」等命名，實際以你的 YAML 為準）。
- 在子清單裡單擊你要使用的節點名稱；被選中的項目多數 GUI 會以顏色、勾選或高亮呈現。
- 回到瀏覽器或應用程式重新載入頁面，觀察連線是否符合預期；若沒有，優先懷疑「規則並沒有把流量導到這個策略組」，而不是節點本身。
為什麼我換了節點但感覺沒變？
三個最常见原因，都很值得你一一排驗：
- 命中規則走的是另一個群組：例如影片流量落在「媒體」策略組，而你只在「預設 Proxy」裡換節點。
- 同一策略組內還有可再往下選的子群組：你改的是上層顯示，實際出口仍由下游 Selector 決定。
- 應用程式不吃系統代理：此時你可能要以 TUN 或針對應用程式設定 Proxy，才能讓「換節點」外顯成體感差異。
一鍵測速與延遲測試：數字怎麼來、怎麼用
在 Proxies 相關畫面，幾乎都找得到與延遲有關的按鈕：有的寫「減速／測試延遲」，有的是閃電圖示或「Test」字樣。這類功能常被口語叫做一鍵測速，但技術上它更接近「對探測目標量 RTT」而不是家用寬頻的上傳下傳測頻寬。
延遲（ms）代表的意義與限制
一般情況下，介面展示的是毫秒級延遲；數字低通常代表路徑較短或較順，但不保證：
- 該節點對「你要上的那個網站」同一時間也最快；
- 串流或下載就一定流暢（頻寬與 QoS 也可能成為瓶頸）；
- ICMP 被禁時，探測方式改為 HTTP／TCP 類時，與你心算的 ping 不完全相同。
所以延遲排序適合作為第一輪篩選：把明顯 timeout、數字異常大的候選先排除，再挑幾個較低延遲的節點做實際使用驗證。
全系統或分組測試的實務習慣
操作上可以遵循「先粗後細」：
- 先使用會批次測試一大片節點的按鈕，讓清單上的延遲欄位刷新（實際名稱依版本而定）。
- 再對仍在猶豫的少數節點，配合手動切換後實際開啟網頁或使用目標服務確認。
- 若你所在網路對探測頻率敏感，避免在極短時間內狂按測試造成節點或服務商側的干擾；養成「有需要再測」的節奏。
延遲排序：快速挑出當下比較香的候選線
當節點數量多時，依延遲排序是最省時間的操作之一。多數 CFW 介面會在表頭提供排序方式：當你點「延遲」欄位或使用內建排序工具時，清單會把由低到高（或反向）排列，讓你一眼看到哪些節點在目前網路環境下相對較佳。
建議把排序當成「輔助」，而不是「唯一真理」：
- 同時看穩定度：某節點這次 40ms、下次 280ms，可能比長期維持 80ms 的節點更難長時間使用。
- 注意逾時項：顯示 timeout、叉號或異常大數字時，不要硬選；先改測其他節點或更新訂閱。
- 自動群組與手動群組分工：若你想「這一類站永遠手動選某策略」，優先把規則導向你可控制的 Selector；把全自動交給 URL-Test 的群組，就偏重讓核心自己跑排程測試。
設定檔層級：與介面切換互相補位
圖形介面能做到的事，很多都對應到 config.yaml 裡的 proxy-groups 與 rules。當你發現「怎麼換節點都改不了某一類網站」，往往不是 Proxies 分頁壞了，而是規則寫成固定出口或走向另一個群組。
這裡給初階使用者一個務實結論：先把介面上的 Selector 與延遲排序用熟，確定體感與規則一致，再考慮進階改寫 YAML。逆過來很容易造成「介面顯示一組、實際命中另一組」的挫折感。
進階情境與簡短排查
玩遊戲或語音仍然卡：延遲低也不夠
即時互動場景常牽涉 UDP、NAT 類型與路由策略；它們不一定會在你熟悉的 HTTP 延遲測試裡完整反映。若主訴是遊戲或語音，請仍以實際連線為主，必要時向服務商確認節點對 UDP 的支援敘述，並避免同時開多個會搶路由的軟體。
從 CFW 換到別款 GUI，概念能不能沿用？
可以。只要是 Clash／Mihomo 生態的圖形介面，大多仍會提供「策略／群組—節點—延遲測試」這條主軸。差異多半在按鈕位置與命名；你把本篇的策略組類型與規則命中搞懂之後，遷移成本會顯著降低。
為什麼仍建議理解 Clash 的「策略組＋規則」而不是只靠一鍵測速
市場上不少代理工具把體驗做得很「一鍵」，但常見取捨是：你看不到流量怎麼分流、出問題只能猜。也有一些過度精簡的客戶端，遇到規則衝突或 DNS 異常時，很難對症調整。
相對之下，Clash 系工具把 規則、策略組、節點拆成可理解的層次；當你在 CFW 裡學會 節點切換、看懂 一鍵測速／延遲排序 的意義，其實已經掌握了多數場景的選線方法。接下來無論你留在舊版 CFW 介面，或遷移到仍持續維護的圖形客戶端，都能沿用同一套觀念，減少每次換軟體就從零開始的時間成本。
如果你也希望在桌面與行動裝置之間，挑到清楚標示更新節奏、下載來源透明的 Clash 系用戶端，不妨到本站下載頁一次瀏覽適用於 Windows、macOS、Linux 與行動平台的版本，選擇最符合你操作習慣的一款。