為什麼要在客戶端裡完成測速與挑節點
多數人第一次接觸 Clash／Mihomo 類軟體時，直覺會以為「節點越多越好」，但實務上痛點往往是：不知道當下哪一個出口真的好用、切了節點卻看不出差別、或是規則命中與自己想像的不一致。Mihomo Party 這類 GUI 的價值，就是把「批次延遲量測」與「策略組切換」收斂到同一個視窗，讓你不用先讀完整份 YAML 也能完成 80% 的日常操作。
本文刻意不談重新安裝系統、也不談進階覆寫腳本；你要的是在既有訂閱前提下，用介面完成測速、排序、手動選擇與簡單驗證。當你之後想讓某個策略組在背景自動挑最快節點，再把視線轉到設定檔裡的 url-test 與間隔參數，閱讀路徑會順很多。
proxy-groups；「節點」「Proxies」對應 proxies。UI 用詞會隨版本微調，但資料來源仍是同一份合成後的設定。
前置檢查：訂閱、設定檔與模式別搞錯
在按任何測速鍵之前，先確認三件事。第一，訂閱已成功下載，節點清單不是一片空白；若你剛匯入連結，記得執行重新整理或更新，並留意代理商是否限制短時間內重複抓取。第二，目前啟用中的 Profile／設定檔確實是你想測的那份；有些介面把「訂閱原料」與「套用中的合成設定」分成兩層，只下載而不選用會讓所有測速按鈕看起來像沒反應。第三，系統代理或規則模式的開關狀態要心裡有數——測速本身通常仍能對單一節點發起連線，但後續「驗證瀏覽器是否走代理」時，模式若關著會誤判成節點壞掉。
若你經常遇到訂閱更新失敗，可對照本站《訂閱自動更新與 UA》裡關於時間戳、HTTPS 與 User-Agent 的代表情境；網路沒壞卻一直拉不下設定時，十之八九是連結、頻率或標頭問題，而不是 Party 本身「測速壞了」。
最後，延遲數字只是量測方法與測試目標下的一個參考。相同數字在不同時段、不同測試 URL、不同節點負載下都會漂移；習慣把它當「篩選候選」而不是「唯一真理」。
一鍵測速在哪裡、實際在做什麼
Mihomo Party 不同版本把按鈕放在「代理」「節點」「Proxies」或工具列裡，但行為邏輯類似：對清單內的一批節點並行或排隊發起延遲量測，把結果寫回每一列。你可以把它理解成「用同一套規則，對多個出口各做一次很短的連線探測」。因此測速鍵按下後，請給它一點時間讓逾時列穩定；馬上重新整理畫面或連續狂按，有時只會讓結果更難解讀。
測試目標若可由進階設定調整，請優先選地理與線路性質接近你日常用途的位址；有些預設 URL 對某些地區特別友善，會讓延遲看起來「全都很好」或「全都逾時」，這不是神秘 bug，而是探測目標與你的網路路徑不匹配。若你完全不確定，維持供應商預設通常是最省事的第一步，先把「相對排序」做出來，再談微調。
一個常見誤會是：看到某節點延遲極低就以為「頻寬也最大」。延遲與吞吐量是兩件事；下載大檔、4K 串流或冷門 CDN 仍可能在低延遲節點上撞到頻寬天花板。實務上仍要回到實際應用測試與日誌命中。
延遲排序：如何把「候選節點」縮小到可手動選的範圍
當清單出現一整排數字後，建議你用表頭排序或介面內建的「依延遲排序」把最低延遲在上、逾時在下。接著不要只看第一名：若你鎖定的是特定國家或城市出口，請先用地區標籤篩選，再在子集合裡比較延遲；否則你可能挑到「很快但地理不合」的節點，反而讓目標服務以為你在別區。
排序後請刻意留一行備註：哪些節點屬於同一機房批次。它們的延遲往往在相近區間一起起伏；若你發現全系統只有這一組特別慢，問題可能在供應商側或該線路擁塞，而不是你電腦設定突壞。
對於標示為 REJECT、DIRECT、或顯然不是一般出口的項目，請不要把它們当成「延遲很高的爛節點」，它們在規則裡扮演的角色不同。手動選擇時若誤點，症狀會變成「該開的出口沒開」，排查方向要回到策略組語意而非單純重測。
在策略組裡手動切換：Selector 與子群組怎麼點
設定檔裡的 proxy-groups 在 GUI 中通常呈現為一張張可展開的卡片或樹狀清單。Selector／手動類型代表由你指定當下要使用哪一個成員：可能是單一節點，也可能是多輪巢狀的子策略組。操作順序建議是——先在葉節點層（實際伺服器）用上一節的排序挑出兩三個候選，再回到上層策略組決定「對外顯示的那條出口鍊」要連到誰。
當你在 GUI 點選某節點後，留意是否有「套用」「儲存」「寫入執行中設定」之類的第二步。部分版本會把實驗性編輯與執行中設定分開；若你只改了檢視畫面而沒有套用到核心，瀏覽器當然還是舊行為。若你不確定目前生效的是哪一層，請以日誌或連線測試頁為準。
有些使用場景會同時存在「全域策略組」與「規則分流後才命中的區域策略組」。換節點時若僅改了全域，實際造訪網站卻仍走另一條規則，並不矛盾；此時要到日誌確認匹配規則與最終策略組是哪一個。想從語意上理解規則順序，可延伸閱讀《Clash YAML 規則與策略組入門》。
連線驗證：用日誌與測試頁確認「真的走這顆節點」
手動切換完成後，請立刻做最小可行的驗證。打開 Mihomo Party 的連線或日誌面板，造訪一個你熟悉的測試網域，檢查是否出現預期的規則命中、策略組決策與實際出口名稱。若日誌顯示命中 DIRECT 或與你點選的不一致，代表問題在規則優先順序或模式，而不是節點本身延遲。
接著可用瀏覽器開啟你信任的 IP 或地理位置查詢頁，粗略核對出口位置與節點標籤是否一致。請避免一次性開啟十來個分頁狂刷新，那不僅無助判讀，也容易撞上速率限制。若你公司有強制 Proxy，瀏覽器額外的擴充套件也可能繞過系統設定；驗證時盡量關掉干擾因素。
Windows 上若只有 Microsoft Store 內應用異常，請記得一般瀏覽器與 UWP 的行為路徑不同；這種症狀回到 Party 裡重測延遲常常看起來正常，要搭配《Windows 11 UWP 與回環代理》那類主題才對症。若你打算啟用 TUN 做更完整接管，先讀《TUN 與系統代理排查》確認權限與衝突來源，再決定是否開啟。
和 url-test 自動挑節點有什麼不同？該什麼時候看 YAML
你在 Party 裡手動測速、排序、點選，本质是「人類做一次決策」。若在設定檔把某個策略組宣告成 url-test，核心會依排程對成員做健康檢查並自動選擇當下延遲較佳者，那是「儀表自動決策」。兩者不是互相取代，而是日常與維運場景的分工：前者適合你在追劇前快速挑線路、在遊戲前試兩顆節點；後者適合長時間掛機、不想一直盯著清單的人。
本站《Clash url-test 策略組：測速 URL、間隔與健康檢查》把 interval、lazy、測試 URL 取捨與常見陷阱拆開寫；當你已熟悉 Party 裡的按鈕行為，再讀那篇會非常快對上號。畢竟 GUI 只是把同一套核心能力包裝得比較好點，底層語意仍是 Mihomo。
若你發現自動策略組與手動認知老是打架，九成是測試 URL 與實際業務網域不在同一條路徑上。此時不要急著調整整份規則，先把測試目標改得更貼近真實流量，再觀察一兩次完整日誌週期。
常見問題
測速按下去整片逾時，但瀏覽器還能上網？
可能目前並未走代理，或探測目標被擋；請先確認模式與規則命中，再換測試 URL 或網路環境比對。
同一顆節點前後兩次延遲差很多？
批次量測遇上瞬間壅塞或無線訊號波動是正常的；請以一段時間內的趨勢為準，必要時固定位置與網路。
手動選了節點，日誌卻顯示走了別名稱？
可能是別名、Provider 批次命名或巢狀子群組顯示層級不同；對照完整鏈路名稱比對單一段字串更可靠。
想記錄哪顆節點最適合打某款遊戲？
延遲排序只能當粗篩；請在實際遊戲時段測試延遲與掉包，並接受 UDP／RTC 類流量與一般 TCP 探測可能不一致。
寫在最後：為什麼需要獨立一篇「Party 介面測速與手動挑節點」
不少整理文把「隱藏選單」「一鍵優化」寫得很像萬靈丹，卻沒說清楚測試探針與真實業務流量可能不是同一條路，讀者照做後覺得「客戶端騙人」。另一些過度簡化的懶人包則乾脆把策略組塞在雲端黑箱，短期好用，長期一出事就無法對照日誌與 YAML。Mihomo Party 走社群開源路線，至少讓你能回到訂閱來源、版本更新與本機工作目錄核對；缺的往往是一篇把「按鈕」與「核心語意」對起來的操作型說明，而不是再堆一張含糊截圖。
相較之下，ClashNote 把同一主題拆成平台安裝、GUI 操作與YAML 自動策略多條閱讀路徑，讓你可以先在不改系統的前提下把日常節點挑順；真的要寫 url-test 或調整 DNS 細節時，再回到對應專文逐步加參數。許多封閉或來路不明的二次打包「魔改版」介面看似更省事，卻常伴隨不可稽核的預設規則、過度寬鬆的權限申請或過時的核心版本，長期維護成本往往轉嫁到你身上。若你希望路線透明、又能銜接本站下載索引與規則教學，建議維持官方建置＋自己能看懂的基本操作這條主軸。
接下來若要系統化撰寫或閱讀整份設定，建議延伸閱讀《Clash YAML 規則分流完全指南 2026》；若你從 Win11 安裝開始接上來，歡迎回頭複習《Win11 安裝 Mihomo Party》中的訂閱與模式開關段落，確保測速前的地基穩固。