Clash 首次連線怎麼做:選節點、測延遲到驗證代理生效

把訂閱匯入 Clash 之後,很多人會在節點列表前停下來:一長串名字,後面跟著數字,不知道該點哪一個。這篇文章按照一次完整的「首連」流程來講,從打開節點列表開始,到最後確認流量確實走了代理,每一步都給出可以照做的具體動作,不假設你已經懂術語。

先認清用戶端介面的幾個區域

不同平台的 Clash 用戶端(Clash Verge、ClashX、Clash for Windows 等)在細節上略有差異,但核心結構基本一致,通常分為四塊:

• 代理(Proxies):節點列表所在的頁面,按訂閱裡的分組展示,是本文的重點。
• 規則(Rules):顯示目前生效的分流規則,決定哪些流量走代理、哪些直連。
• 連線(Connections):即時展示目前建立的網路連線,是判斷代理是否生效的重要入口。
• 設定(Settings/General):系統代理開關、TUN 模式開關、混合埠等基礎設定都在這裡。

首次使用,建議先確認「系統代理」或「TUN 模式」其中一項已經開啟——節點選好但沒有開啟接管流量的方式,瀏覽器依然不會走代理。系統代理是透過設定作業系統的 HTTP/HTTPS 代理來生效,設定簡單,對大多數網頁瀏覽和應用程式已經足夠;TUN 模式則在網路層接管全部流量,相容性更好,尤其適合不支援讀取系統代理設定的應用程式,但通常需要額外的權限確認。

看懂策略群組,再決定點哪個節點

節點列表並不是一份平鋪的清單,而是按「策略群組」組織的。常見的分組邏輯包括:

• Proxy / 手動選擇群組:你可以在這裡手動點選任意一個具體節點,選中後這個策略群組就固定使用該節點,不會自動切換。
• Auto / 自動選優群組:用戶端會按延遲測試結果自動挑選目前最優的節點,並按訂閱設定的週期重新測試和切換。
• Fallback / 故障轉移群組:優先使用主節點,主節點不可用時自動切到備用節點。
• Select 分類群組(例如「海外串流媒體」「本地服務」等,取決於訂閱規則檔案的分組設計):把不同用途的流量分別指向不同的策略,你可以為每一類單獨選節點。

對第一次使用的人來說,最簡單的做法是:找到主策略群組(通常命名為 Proxy 或訂閱商自訂的名字),點開下拉列表,手動選中一個顯示為綠色或延遲數值較低的節點,先確保這一組能正常連通,再考慮要不要切換成自動選優。如果訂閱檔案按用途拆了多個分組,建議每個分組都檢查一遍目前選中的節點是否可用,避免某個分類始終指向一個已經失效的節點。

發起延遲測試,讀懂回傳的數字

節點名稱右側通常會顯示一個延遲數值,單位是毫秒(ms)。點擊節點列表頁面的「測速」或單個節點右側的重新整理圖示,可以手動觸發一次延遲測試。理解這個數字需要注意幾點:

1. 測試對象是延遲探測位址,不是你要造訪的具體網站。用戶端會向一個預設的測試位址(常見的是某個穩定可達的網域)發起請求,統計往返耗時,這個耗時能大致反映節點到測試位址的網路狀況,但不完全等同於造訪某個特定網站的實際速度。
2. 數值範圍的大致參考:200ms 以內通常體驗流暢;200~500ms 依然可用,但網頁載入、影片緩衝會有輕微延遲感;超過800ms 或顯示逾時,建議更換節點。
3. 顯示「逾時」或紅色標記不代表節點一定不可用,可能是探測請求本身被中間網路丟棄,但也可能是節點確實已經失效,建議直接切換到延遲正常的節點,不必糾結原因。
4. 延遲會隨時間波動,尤其是使用高峰時段。如果某個節點平時延遲穩定,某次測試突然升高,可以隔幾分鐘再測一次,排除偶發波動。

切換節點後要做的確認動作

點選了一個新節點之後,不要立刻假設它已經生效,按下面的順序做一次確認:

1. 確認節點列表裡該節點確實顯示為「已選中」狀態(通常有高亮或勾選標記)。
2. 回到設定頁,確認系統代理開關處於開啟狀態,或者 TUN 模式已啟用。二者選其一即可,沒必要同時開啟。
3. 打開「連線」頁面,觀察是否有新的連線記錄出現,記錄裡的目標網域和使用的節點名稱是否符合預期。

如果切換節點後打開網頁明顯卡頓或者無法載入,先回到延遲測試確認這個節點目前是否正常,再考慮是不是規則把這類流量分到了別的分組、走的是另一個節點。

用瀏覽器驗證代理是否生效

最直接的方式是造訪一個能顯示目前出口 IP 和地理位置的頁面。具體步驟:

1. 在開啟代理之前,先造訪一次 IP 查詢頁面,記下顯示的位址和地區,這是你的直連出口資訊。
2. 確認 Clash 裡節點已選中、系統代理或 TUN 模式已開啟。
3. 重新整理同一個 IP 查詢頁面(建議強制重新整理,避免讀取瀏覽器快取),對比新顯示的位址和地區是否發生了變化。

如果地區資訊變成了節點所在地區,說明代理已經生效;如果顯示的還是本地網路的位址,大概率是系統代理沒有開啟,或者瀏覽器本身設定了獨立的代理設定(部分瀏覽器允許在系統代理之外單獨設定,需要檢查一下是否被覆蓋)。

另外可以打開用戶端的「連線」頁面,造訪網頁的同時觀察是否即時出現對應網域的連線記錄,並且這條記錄標註的節點是你剛才選中的那一個。這一步能確認具體是哪個節點在處理這次請求,比單看 IP 更精確。

用命令列驗證代理是否生效

命令列方式適合習慣用終端排查問題的使用者,尤其在瀏覽器快取、擴充功能干擾導致結果不直觀時更可靠。以 macOS 和 Linux 常見的 curl 命令為例:

curl -x http://127.0.0.1:7890 https://ifconfig.me

這條命令透過本機的 HTTP 代理連接埠發起請求,回傳值是出口 IP 位址。連接埠號需要對照用戶端設定頁裡顯示的混合連接埠或 HTTP 連接埠,不同用戶端預設值可能不同,不要直接照抄範例裡的數字,以實際介面顯示為準。

如果啟用的是 TUN 模式而不是系統代理連接埠,可以不加 -x 參數直接發起請求,因為 TUN 模式在網路層已經接管了流量:

curl https://ifconfig.me

對比這兩次(開啟代理前後)回傳的 IP,如果位址發生變化且與所選節點的地區吻合,說明代理鏈路是通的。如果命令回傳逾時或連線被拒絕,先檢查連接埠號是否填對,再檢查用戶端的代理監聽服務是否處於運行狀態。

驗證不通過時的排查順序

如果按上面的步驟操作後,代理仍然顯示未生效,建議按下面的順序逐項排除,而不是同時改動多個設定:

• 先看節點本身:延遲測試是否正常,是不是恰好選中了一個失效節點。換一個延遲正常的節點重新測試一次。
• 再看接管方式:系統代理開關和 TUN 模式的狀態,確認至少有一項處於開啟狀態,並且沒有被系統設定裡的「忽略代理的例外清單」覆蓋掉你要測試的網域。
• 然後看規則命中:打開規則頁面,確認你測試用的網域被分流到了代理策略群組,而不是被規則比對成了直連(DIRECT)。部分訂閱預設把本地網路或特定地區的網域設為直連,這種情況下即使代理正常也不會看到 IP 變化。
• 最後看用戶端行程:確認 Clash 核心行程處於運行狀態而不是已經退出或崩潰,部分用戶端在核心異常退出時介面仍會保留舊的選中狀態,容易造成「看起來已經開著」的錯覺。

逐項排查完成後,再重複一次前面瀏覽器或命令列的驗證步驟,確認問題已經解決,而不是憑感覺認為「應該好了」。

建立一個簡單的日常驗證習慣

首次設定成功之後,後續每次切換節點或者重新啟動用戶端,建議保留一個簡短的確認動作,而不用每次都走完整流程:打開「連線」頁面看是否有新連線產生,或者用之前記錄的命令列命令快速跑一次,幾秒鐘就能確認鏈路是通的。這個習慣在排查「為什麼突然連不上了」時特別有用——因為你已經清楚正常狀態下應該看到什麼,異常狀態一眼就能分辨出來。