Clash 第一次連線怎麼做:選節點、測延遲、確認代理生效

先看懂節點清單的三層結構

用戶端裝好、訂閱匯入完成之後,大多數人會直接卡在節點清單這一步——不是找不到節點,是不知道該點哪個。Clash 核心把節點組織成三層:最外層是「代理群組」(Proxy Group),比如「自動選擇」「手動切換」「香港」「美國」這類分類標籤;中間是具體「節點」,一份訂閱可能帶來幾十上百個;最裡層是「策略」,決定這個代理群組按什麼規則挑節點——url-test(自動測速選最快)、fallback(主備切換)、select(手動選)或 load-balance(負載平衡)。

打開用戶端的「代理」或「節點」頁面,你看到的每一個可點擊的群組卡片對應一個代理群組,展開後是一排節點條目,右側跟著一個數字加單位「ms」,這就是延遲。第一次連線不需要理解全部策略類型,只要記住兩件事:哪個群組是目前生效的出口,哪個節點在這個群組裡被選中。大多數用戶端會用顏色或勾選標記突顯目前選取的項目。

批量測速:延遲數字是怎麼測出來的

節點清單頁面通常有一個測速按鈕,圖示常見是圓形箭頭或碼表,點一下會對目前群組裡的所有節點發起測速,幾秒後每條節點後面的數字會刷新。這個數字不是「網速」,而是延遲——用戶端透過這個節點存取一個測試位址(常見是 Google 的 generate_204 或用戶端內建的測速端點),記錄從發出請求到收到回應的時間,單位毫秒。

延遲低不代表下載速度快,但延遲能反映兩件事:節點伺服器與你所在網路的路由距離,以及節點目前是否卡頓——如果延遲顯示超時或幾千毫秒,大概率是節點目前無法使用,不用管數值,直接跳過。

• 延遲 100ms 以內:回應很快,適合看影片、語音通話這類即時性要求高的情境。
• 延遲 100~300ms:正常範圍,瀏覽網頁、下載檔案沒有明顯影響。
• 延遲 300ms 以上或顯示超時:大概率線路壅塞或節點故障,優先換節點。

批量測速建議在切換網路(比如從 Wi-Fi 換成行動數據)之後都重新跑一次,因為延遲和你本地出口線路直接相關,不是訂閱商單方面決定的固定值。

手動測速與自動測速的差異

如果代理群組的策略是 url-test,用戶端會按設定的時間間隔(通常設定檔裡寫的是幾分鐘一次)自動跑一次測速,並把流量切到目前最快的節點,清單上會看到一個「自動選擇」之類的群組,裡面不需要你手動點。如果策略是 select,則完全靠手動點選,測速只是提供參考數字,選哪個節點由你自己點擊決定。

按延遲挑節點:除了數字還要看什麼

只盯著最低延遲點節點,有時候反而不是最佳解,原因有三個:

1. 延遲測的是短連線,不是持續吞吐量。個別節點延遲很低但頻寬有限,大檔案下載或高畫質影片反而卡頓,這種情況延遲數字幫不上忙,只能靠實際使用體感判斷。
2. 地區節點服務不同。如果訂閱節點按地區分組(香港、日本、美國等),選哪個地區取決於你要存取的服務本身部署在哪——延遲只在同地區節點之間比較才有意義,跨地區比較延遲沒有參考價值。
3. 付費訂閱通常有倍率標示。節點名稱裡常帶有「0.5x」「2x」這類倍率,代表流量計費係數,挑節點時低倍率能節省流量額度,但不影響延遲本身。

沒有特殊需求的情況下,最省心的做法是直接用帶「自動選擇」「Auto」字樣的代理群組——它內建了 url-test 策略,會持續在同群組節點裡挑延遲最低且可用的那個,不需要人工介入。手動模式適合你明確知道某個節點線路更穩、想固定使用的情境。

切換代理模式:規則、全域、直連怎麼選

節點選好之後,還有一層開關容易被忽略——代理模式。Clash 用戶端一般在主畫面或設定裡提供三種模式切換:

第一次連線建議先切到規則模式——這也是大多數用戶端的預設值,規則檔案(比如常見的 GEOIP、GEOSITE 規則集)會自動判斷哪些網域需要代理、哪些保持直連,不需要手動維護名單。如果懷疑某個網站沒走代理,可以暫時切到全域模式做對照測試,確認之後再切回規則模式,避免所有流量一直走代理造成不必要的額外消耗。

確認代理真的生效:三種檢查方法

節點選好、模式切好,不代表流量真的按預期在走。下面三種方法從易到難,建議按順序做完至少兩種再放心使用。

方法一:用 IP 查詢頁面看出口位址是否變化

打開瀏覽器存取任意一個顯示目前公用 IP 的查詢頁面,先在直連模式下記錄一次結果,再切到規則或全域模式存取同一個頁面。如果兩次顯示的 IP 位址、歸屬地明顯不同,說明流量確實經過了代理節點轉發;如果兩次結果一致,說明代理沒有生效,需要回頭檢查節點選擇、代理模式或用戶端的系統代理開關是否打開。

方法二:看用戶端內建的流量統計或連線紀錄

大多數 Clash 用戶端在主畫面或「日誌」頁面會即時顯示目前活躍連線,包括存取的網域、符合的規則、走的是哪個節點。打開一個網頁後回看這個清單,如果能看到網域條目並標註了具體節點名稱(不是 DIRECT),說明這次請求確實經過了代理。這個方法比 IP 查詢更細,能定位到具體是哪個網域走了代理、哪個走了直連。

方法三:核對系統層面的代理設定或 VPN 圖示

Android 系統採用 TUN 模式接管全域流量時,狀態列通常會出現一個持續顯示的金鑰或小鎖圖示,提示系統層的 VPN 服務正在執行;如果用戶端使用的是本機 HTTP/SOCKS 代理模式而不是 TUN,則需要到系統的 Wi-Fi 詳細資訊或代理設定裡確認代理位址與連接埠是否已經填入且處於啟用狀態。這一步主要用來排查「用戶端介面顯示已連線,但系統實際沒有接管流量」這種邊界情況。

常見排查順序:
1. IP 查詢頁面 IP 未變化 → 檢查代理模式是否停在「直連」
2. IP 變化但個別網站打不開 → 查連線紀錄,看該網域符合哪條規則
3. 日誌顯示走了代理但網頁仍載入失敗 → 換一個節點重試,排除單節點故障

三種方法各有側重:IP 查詢驗證的是「出口有沒有換」,連線紀錄驗證的是「具體哪條流量走了代理」,系統設定驗證的是「接管方式對不對」。日常使用只需要做一次 IP 查詢確認整體生效即可,連線紀錄和系統設定留給排查具體問題時用。

常見誤區小結

• 把延遲數字當網速看——延遲低只代表回應快,不代表頻寬大。
• 一直用全域模式圖方便——台灣本地服務會被一起代理,容易觸發異地風險警示。
• 換了網路不重新測速——延遲和本地出口線路強相關,Wi-Fi 換行動網路後數字會變。
• 只看用戶端畫面狀態就認為已生效——畫面顯示「已連線」只代表行程在執行,不代表流量真的被接管,用 IP 查詢頁面走一遍才是硬證據。

把這幾步走完一遍,基本就能確認訂閱、節點、模式三個環節都設定正確。後續使用中如果某天突然連不上,也可以按同樣的思路——先看節點延遲,再看代理模式,最後核對 IP 是否變化——逐層排查,而不用整個重灌用戶端。