Clash for Android：怎麼用一鍵測速並手動切換節點（看懂 Proxies 延遲排序與策略組）
對多數讀者而言，Clash for Android最直覺的兩個操作就是：進 Proxies（代理）看節點，以及遇到卡頓就「換一條線」。但如果只會盲目點來點去，很容易出現「測速很漂亮、上站卻還是轉圈」的錯覺。本篇用繁體中文與台灣慣用語，帶您把一鍵測速、延遲排序、策略組切換與GLOBAL 對照串成一條可重現的連通驗證流程；若您還卡在訂閱匯入，可先對照本站Android 訂閱排查與背景與省電鎖定先把底座補齊。
為什麼「會亮綠燈」仍要學 Proxies？
手機上網的體驗問題，往往不是單一事實造成的：同一個時間點，您可能同時碰到 DNS 解析分歧、規則把流量送去意料之外的策略組、節點線路壅塞或握手逾時……而 Clash／Clash Meta for Android把工作拆成規則引擎與出站（outbound）兩個層次：前者決定該會話進哪個 proxy-group，後者才決定實際從哪一台機器離開。
也因此，許多只看「總開關是否開著」的玩家，會在主觀上把問題誤會成軟體壞掉；但更有可能的情況是：您測到哪裡不重要，重要的是「當下的那一條真實連線走到了哪個策略組與哪個節點」。學會在 Proxies裡對節點做批量測速、讀延遲排序，再配合策略組手動鎖定，才能把「感覺卡」推進到「哪一段路徑慢」。
先建立三句話心智模型
您要在腦中隨時能回答：我現在是 Rule 還是 Global？ 這個網站應該命中哪個策略組？ 該組目前鎖在哪個出站？這三問對齊之後，一鍵測速才不是「數字占卜」，而是可操作的工具。
名詞對照：Proxies、proxy-group（策略組）、GLOBAL
不同發行版本的選單名稱可能略有出入，但只要您掌握語意即可跨版本遷移。下面用「最常用的 GUI 詞彙／YAML 概念」對照說明，避免您在論壇看文章時對不上號。
- Proxies／代理頁：視覺上通常是「出站清單＋可做延遲測試的介面」，其中既可能包含原子節點（單機出口），也可能包含proxy-group（策略組／群組出站）。在您未確認命名規則前，請不要預設最上面那一列就是總出口。
- proxy-group／策略組：把多個節點或子群組收成一個可被規則引用的「手柄」。典型型態包含
select（手動挑選）、url-test（依測試 URL 自動挑延遲最佳）、fallback（線路備援）、load-balance（分載）。您日常說的策略組切換，多半是在select這類可手動指派的群組上操作。 - GLOBAL：可把它理解成「暫時不要走細緻分流，所有（或大部分）流量改由同一個全局策略握手」的診斷開關。它能幫您快速判斷問題是否出在規則誤判，但並不適合長期開著；後文會再強調如何使用才不會製造更大的困惑。
- Rule／Direct／Global 模式（依版本）：指的是「規則引擎對流量的頂層處置方式」。一般用戶日常使用應以 Rule 為主，把 Global 留給短暫對照；若您在公共 Wi-Fi 想先確認基底連線是否正常，也可用 Direct 做對照（注意：這代表不走代理出站）。
第一步：確認設定檔與 Proxies「真的載入出站」
在進任何測速之前，請先確認不是「載入設定失敗但以為成功」的空清單狀態。若您按下更新訂閱後仍長期無節點、或 Proxies 看起來殘缺，問題多半需要先回到資料面：訂閱 URL、YAML 相容性與機場端狀態。您可以先複習本站Clash Android 訂閱匯入失敗排查，把這一步當成硬門檻。
當 Proxies 已能展開多個分組，您會看到兩類常見排版：一類是「依機場習慣命名的 PROXY／自動選擇／手動」等群組；另一類是「依地區折疊＋底層才是具體節點」。無論哪一種，請記得測速按鈕常常作用在「當前展開清單」或「當前分頁」，若您沒展開到正確層級，容易誤以為節點壞光，其實只是沒測到。
疊 VPN、私人 DNS、公司憑證時要小心
Android 上可以同時存在多個會改路由的組件（系統級 VPN、其他代理、HTTPS 內容檢視／過濾類安全套件）。這些堆疊常常讓 Proxies 的延遲測試結果與瀏覽器實際體驗完全不同步。若您在排查過程換過網路或關過其他套件，請在每次測速前固定環境條件，否則很難重現結論。
第二步：Proxies「一鍵測速」怎麼用？它在測什麼？
所謂一鍵測速，在工程上多半是對出站清單批量送出連線探測（可能是 TCP、HTTP HEAD、或類似 Ping 的度量），再把結果以毫秒或狀態欄呈現。它測的不是「您能看多快的影片」，而是一個統一的測試目標下，哪個節點在目前網路條件下往返延遲較低、較穩定。
延遲排序怎麼讀才不會被數字騙？
當清單依延遲排序重新排列時，請把「排序」當成相對參考，而不是絕對承諾。舉例來說，若測試目標位於 A 區域，而您晚間要看的串流節點實際從 B 區域出發，那麼您看到的第一名節點未必是串流體感最佳解。更務實的讀法是：
- 先看是否大面積 timeout：若幾乎全紅，問題更像「當前網路對測試目標不可達」或「訂閱節點集體失效」，而不是單點挑錯。
- 再看延遲分布的「尾段」：如果多數落在合理範圍，但偶有極端高延遲，通常代表線路抖動或 QoS；可先把尾段剔除後再試實際上站。
- 最後才把第一名當預設候選：並以您真實要用的情境（HTTPS 網站、長連線聊天室、影音）做一次短暫交叉驗證。
測速與吞吐是兩件事
延遲低不代表頻寬大；影音卡頓有時來自對端 CDN 調度與 QUIC／UDP，而不是 Proxies 上顯示的那個毫秒數。若在延遲穩定的情況下仍卡，請開始懷疑「是否命中對的策略組」，以及「是否需要換一個對 UDP 友善的線路」（依機場與協定而定）。
第三步：在正確的策略組「手動切換節點」
這是最容易做錯的一步：很多人在 Proxies 最外層點了一台節點，便以為全域都會改用該出站；但真正決定規則命中的，往往是某個叫作 PROXY 或類似名字的 proxy-group／策略組。請用下面流程自我檢核：
手動換節點（精簽版）
- 先確認目前是 Rule：避免在不知情的情況下長期卡在 Global。
- 在 Proxies 內定位「規則最常引用」的出口群組（常見為 PROXY／手動／自動選擇的上層）。
- 若該群組是
select：直接點選具體節點名稱，讓群組鎖定該出站。 - 若該群組是
url-test／fallback：介面可能顯示「目前挑中誰」；若您沒有手動覆寫空間，就需要回到設定檔或機場策略理解其自動邏輯，再挑一個可手動覆寫的上層群組。 - 換完後不要立刻滑社群，先用下一節的連通驗證重現一次問題場景。
若您同時使用「分應用代理」或「旁路清單」，也要把心理預期調整好：某些 App 可能根本沒走 Clash 核心，您在 Proxies 再怎麼換都不會影響它。這類主題可延伸閱讀Android 分應用分流與代理驗證，避免把「沒進核心」誤判成「節點全壞」。
第四步：什麼時候用 GLOBAL？怎麼用才不誤事？
GLOBAL最大的價值是快速二分法：當您懷疑「規則把流量送去錯的組」或「某條域名規則順序導致意外 DIRECT／REJECT」時，短暫切換到 Global，等同把「規則分流的變因」先關掉一半。操作上通常會再於 Global 群組內挑一個您剛剛測速表現穩定的節點，然後回到瀏覽器做連通驗證。
GLOBAL 請當「診斷貼」，不要當「日常模式」
長期 Global 會讓本該直連的站台也走代理，增加延遲、耗電與被網站風控告警的機率；同理，也最難在出問題時回推「規則責任」。建議準備計時：3～5 分鐘內完成對照並回到 Rule，並隨手記錄您當時選定的節點與結果，免得晚上忘記自己又切過模式。
若 Global 對照可行、但 Rule 下不可行，您就可以把下一步縮小到「規則／策略組鏈結」而非「冤枉整包節點」。這種方法與桌面上閱讀 Connections／Logs 的精神一致；若您在 Windows 也使用 Clash for Windows，可再對照本站流量統計與核心日誌排查把「對齊真實連線」的習慣延伸到多平台。
第五步：連通驗證怎麼做才「算數」？
這裡所謂連通驗證，指的是用最少變因確認「出站路徑與協定鏈是正常的」。建議準備這三種粒度由淺入深：
- 純 HTTPS 文字站點：能快速分辨 DNS／TLS 是否正常，避免一上來就用重站點把問題複雜化。
- 會跳轉或含多國 CDN 的典型網頁：協助您在「規則命中複雜」時仍能觀察整體首屏時間。
- 您真正卡住的那個場景：例如影音、論壇圖床、線上報表；請固定同一支手機、同一個瀏覽器，並在同一個 Wi-Fi／行動數據下重做，才能比較延遲排序與換節點是否帶來改變。
驗證時也請留意「快取誤導」：剛換節點後，瀏覽器可能仍短暫沿用舊連線或 HTTP 快取。遇到怪異情況，可用無痕視窗或在站內做一次硬性重新載入，讓測試更貼近新的出口。
常見誤區：換節點之前，別急著下定論
第一種誤區是只看 Proxies，不看背景限制：Android 的省電策略、休眠斷線、或未鎖定的背景程式，會讓長連線在體感上頻繁重撥號，這與線路好不好不完全相同。
第二種誤區是混淆「自動選組」與「手動選節點」：您若以為自己手動點了一台機器，但實際上某個 url-test/fallback 仍在上層自動切換，觀察就會對不起來。此時請回頭確認群組嵌套結構。
第三種誤區是把測試 URL 結果當成所有 App 的真相：手機上任一 App 都可能使用自有 DNS、自有連線池與 QUIC，您若在 Proxies 測得極低延遲，但某 App 仍「連得上卻慢」，就要把懷疑轉向該 App 是否真正走了 Clash 核心與其 UDP／TLS 特徵。
常見問題（附實務簡答）
測速全 timeout，是否代表節點全掛？
不一定。請先切換到另一種網路（例如從公司 Wi-Fi 改 5G），再重試；若僅在特定網路下全掛，較像路徑封鎖或 DNS 被污染，而不是 Clash 單方面故障。若所有網路皆如此，再回頭查訂閱與機場狀態。
手動選了節點卻跳回自動？
常見原因是您選到的是「子層節點」，但上層 url-test 仍在挑選；或 UI 觸發了重新整理訂閱後狀態被重置。建議把操作錄成可重現序（點了哪個群組、是否更新訂閱），再對照設定檔中該群組型態。
串流解鎖與測速不一致怎麼辦？
串流站點常看「出口 IP 與地域」而不是單純延遲，請以實際播放頁作為最終裁判，而不是只看 Proxies 的名次。若您需要穩定命中某區域，通常要搭配機場提供的對應節點標籤與規則，而不是只挑延遲最低的那台。
總結：把「會用 Clash」升級成「會用手機節點面板」
Clash for Android的價值不只是能導流，而是把「出口選擇」變成可見、可測、可切換的操作面。當您學會在 Proxies裡做一鍵測速、讀懂延遲排序的相對意義，並能在正確的策略組裡完成手動切換節點，再搭配短暫的 GLOBAL 對照與可重現的連通驗證，您會發現多數「晚上卡、白天好」的現象其實都能被壓縮成可定位的敘述，而不是只靠重開機試手氣。
延伸閱讀（同一套方法的鄰居篇）
Android 側邊還有很常一起出現的情境：電視或電視盒側載後只敢用最基本功能、或是在省電強化機型上不斷掉線；可延伸閱讀本站Android TV／電視側載 Clash整理遙控操作的現實細節。若您是從電腦轉到手機，也值得把本篇與桌面上「連線對齊」類文章對照閱讀，讓多裝置之間的詞彙保持一致。
市面不少手機端工具把「自動」包裝成一鍵結果，對新手看似省事，但一旦遇到卡住就只剩下重裝或換別支 App；更麻煩的是，您很難知道流量到底走了哪個策略組，也不易用可重現的方法驗證是不是規則誤判。Clash 生態把 Proxies、策略組與模式切換攤開成可讀的面板，本質上是在用工程方式降低不確定性：您仍需要學一點點概念，但換來的是可定位、可對照、可長期維護的上網路徑。
若您也希望在 Android 上維持這種「看得懂、換得準、驗得過」的控制感，而不是每次卡頓都把原因交給運氣，不妨下載 Clash 官方提供的客戶端與更新通道，讓訂閱、核心與介面行為維持一致，搭配本文流程就能穩定落地。