Clash 第一次連線：選節點、測延遲到驗證代理是否生效

連線前先確認設定已進入運作狀態

訂閱匯入成功，只代表用戶端已取得設定檔，不表示代理連線已建立。第一次操作時，應先確認設定、核心、策略模式與系統接管方式處於一致狀態。不同用戶端的選單文字略有差異，常見路徑是「設定」→「訂閱」選擇剛匯入的設定，再到「設定」→「參數設定」確認核心已啟動。

使用 mihomo 核心的用戶端通常會顯示執行狀態、核心版本與控制連接埠。若主介面仍提示「未啟動」或日誌沒有任何新紀錄，應先啟動核心，不要直接反覆測試節點。節點延遲按鈕呼叫的是核心功能；核心未執行時，所有節點可能同時顯示逾時。

第一次連線的四項檢查

1. 已選取設定：設定清單中只有設為目前設定的檔案會參與規則比對。剛更新訂閱後，還要確認用戶端沒有繼續使用舊的本機設定。
2. 執行模式明確：初次使用建議選擇「規則」模式。此模式會依照設定中的規則決定直連或代理，方便在連線頁查看實際命中過程。
3. 已啟用代理接管：桌面瀏覽器通常需要開啟「系統代理」。需要接管不讀取系統代理的應用程式時，再使用 TUN 模式。
4. 連接埠沒有衝突：常見設定使用 HTTP 或 mixed-port 7890，SOCKS 連接埠常見為 7891。最終數值以目前設定與用戶端設定頁為準。

如果同時開啟系統代理與 TUN，測試結果可能混入兩種接管路徑。初次排查建議只開啟一種：先用系統代理驗證瀏覽器，再視需要測試 TUN。如此可避免把 TUN 路由正常誤認為系統代理正常，或把瀏覽器自身的代理設定問題誤判為節點故障。

第一步：在策略組中選對節點

Clash 設定通常不會讓規則直接引用某個具體節點，而是先引用策略組，再由策略組決定使用哪個節點或下一層策略組。常見名稱包括「節點選擇」「代理」「手動選擇」「自動選擇」和「故障轉移」。名稱由訂閱提供者定義，並非所有設定都相同。

先找出規則最終引用的策略組

開啟「代理」頁面後，可以看到多個群組。標記為 select 的群組需要手動選擇；url-test 會依測試結果自動挑選；fallback 優先使用可用節點；load-balance 則會依策略將連線分配給多個節點。第一次連線最適合從手動選擇群組開始，因為結果更容易控制。

不要只在某個地區群組中點選節點，還要檢查上層群組是否真的引用了這個地區群組。例如「節點選擇」目前選取「自動選擇」，而使用者只在「香港節點」中切換了具體線路，那麼最終出口仍可能由「自動選擇」決定。策略組可以巢狀，頁面上的選取標記要從頂層一路向下核對。

第一次應該選什麼樣的節點

• 先選擇地理距離較近、延遲結果穩定的節點，不必只追求清單中的最小數字。
• 連續測試三次。如果結果分別為 68 ms、71 ms、74 ms，通常會比 42 ms、190 ms、逾時這種大幅波動更穩定。
• 暫時避開名稱中明確標示倍率、實驗或限速的線路，先建立可重複的基準結果。
• 若同一地區有多個協議節點，先選擇訂閱預設推薦的常規線路，再依實際吞吐量與穩定性比較。

節點名稱只是設定提供者寫入的標籤，無法單獨證明實體位置或鏈路品質。最終仍要結合延遲、連線日誌、出口位址與實際存取表現判斷。對於需要固定工作階段的登入服務，短時間內頻繁切換節點還可能改變出口位址，因此每次切換後都應重新建立連線再驗證。

第二步：測試延遲並正確解讀結果

用戶端中的延遲測試並不是傳統意義上的 ICMP Ping。Clash 或 mihomo 通常會讓指定節點請求一個測試 URL，並記錄建立代理連線及取得回應所需的時間。常見測試位址會回傳 HTTP 204，例如 https://www.gstatic.com/generate_204 或 https://cp.cloudflare.com/generate_204。具體位址由設定或用戶端設定決定。

延遲數字分別代表什麼

這些區間只用於初步篩選。一個 55 ms 的節點可能因頻寬壅塞而下載緩慢，一個 180 ms 的節點也可能在持續傳輸時保持穩定。延遲主要反映短連線回應，無法直接等同於下載速度、封包遺失率或尖峰時段容量。

批次測試時不宜連續快速點擊。一次同時測試數十個節點，會瞬間建立大量連線，路由器、DNS 服務或遠端伺服器都可能限制流量。建議等待本輪結果完整回傳，間隔 10 至 20 秒再進行第二輪。三輪資料比單次最小值更具參考意義。

所有節點都逾時時先檢查測試鏈路

1. 開啟「日誌」，確認點擊測速後是否出現連線嘗試。完全沒有日誌，通常是核心未執行或介面沒有連線到控制連接埠。
2. 檢查本機是否能直接解析測試位址。DNS 失敗會讓一批正常節點同時顯示逾時。
3. 將測試 URL 換成另一個穩定的 204 位址，再測試一次。某個測試站點無法連線，不代表所有節點同時失效。
4. 確認本機時間準確。涉及 TLS 的連線在系統時間偏差較大時可能握手失敗。
5. 查看日誌中的 timeout、connection refused、network is unreachable 等資訊，分別處理逾時、連接埠遭拒與路由無法連線的問題。

第三步：驗證流量確實經過代理

驗證代理不能只看系統代理開關變色，也不能只看節點旁出現延遲數字。可靠的方法是同時觀察出口位址、Clash 連線紀錄與規則命中結果。三者能夠相互對應，才能確認請求經過預期節點。

方法一：比較直連與代理的出口位址

1. 關閉系統代理與 TUN，存取一個顯示公用 IP 的服務，記錄直連出口。
2. 重新開啟系統代理，固定選擇剛測試過的節點。
3. 使用新的無痕視窗再次查詢公用 IP，避免頁面快取影響結果。
4. 比較兩次位址，並在 Clash「連線」頁面找到對應網域的請求。

如果使用的是負載平衡策略組，不同連線可能出現不同出口，不能要求每次查詢都完全一致。若使用手動選擇的單一節點，出口通常應保持相對穩定。公用 IP 沒有變化時，也不要立刻判定失敗：目前規則可能把查詢服務設為 DIRECT，應先查看連線紀錄中的出站策略。

方法二：在終端機中明確指定代理連接埠

終端機程式通常不會自動讀取桌面系統代理。可以使用 curl 明確指定本機代理，將「終端機是否繼承系統設定」與「Clash 連接埠是否正常」分開測試。以下指令假設 HTTP 或 mixed-port 為 7890：

curl --proxy http://127.0.0.1:7890 https://api.ipify.org

Windows PowerShell 中建議呼叫 curl.exe，避免舊版環境將 curl 解析為其他指令：

curl.exe --proxy http://127.0.0.1:7890 https://api.ipify.org

若設定單獨開放 SOCKS5 連接埠 7891，可以讓網域解析也透過代理端完成：

curl --proxy socks5h://127.0.0.1:7891 https://api.ipify.org

socks5h 中的字母 h 表示將主機名稱交由 SOCKS 代理解析。若指令回傳連線被拒，應先核對實際監聽連接埠，而不是直接更換節點。部分新設定只啟用 mixed-port，此時未必存在獨立的 socks-port。

方法三：查看連線詳細資訊與規則鏈

開啟用戶端的「連線」頁面，再重新整理目標網頁。請求詳細資訊通常會顯示目標主機、來源位址、上傳下載流量、命中的規則與最終策略鏈。例如一筆紀錄可能顯示：

example.com
規則：DomainSuffix
策略鏈：節點選擇 → 香港節點 → HK-01
網路：TCP
狀態：Active

看到 DIRECT 表示該請求依規則直連；看到具體節點名稱表示代理出站；看到 REJECT 表示規則主動拒絕。若連線清單沒有出現目標請求，流量可能沒有進入 Clash，排查重點應轉向瀏覽器代理、應用程式內代理、TUN 路由或本機防火牆。

辨識「能測速但沒有代理」的假連線

假連線最常見的表現是節點延遲正常、用戶端顯示正在執行，但目標應用程式仍使用直連網路。原因通常不在節點本身，而在策略組選擇、規則命中或應用程式接管範圍。依照下列順序檢查，比重複更新訂閱更有效。

頂層策略組沒有選取剛測試的節點

使用者可能在「香港節點」群組中選了 HK-01，但規則實際引用的是「節點選擇」，而「節點選擇」仍指向「自動選擇」。此時 HK-01 可以正常測速，卻沒有承擔業務流量。回到頂層群組，沿著目前選項逐層查看，直到最終節點名稱與預期一致。

目標網域被規則設為直連

規則模式會依順序比對。諸如 DOMAIN-SUFFIX、GEOSITE、GEOIP 與兜底 MATCH 都可能改變出口。連線紀錄若顯示 DIRECT，表示系統代理本身可能已正常運作，只是規則決定直連。可以短暫切換至全域模式進行對照，完成驗證後再回到規則模式檢查規則順序。

瀏覽器或應用程式繞過系統代理

部分瀏覽器允許擴充功能或企業原則單獨設定代理，開發工具、遊戲啟動器、容器與終端機程式也可能直接建立連線。系統代理通常只會影響主動讀取作業系統代理設定的程式。這類應用程式可以設定本機 HTTP/SOCKS 位址，或確認系統相容後啟用 TUN 模式。

TUN 已開啟，但路由或權限尚未就緒

TUN 模式透過虛擬網路介面接管更廣泛的流量。Windows、macOS 與 Linux 都可能要求系統管理員權限或安裝系統擴充功能。開啟後應檢查 TUN 狀態、虛擬介面與日誌；只看到開關處於開啟位置，不代表路由已成功寫入。若日誌提示介面建立失敗或權限不足，先修復權限，再測試節點。

舊連線沒有隨節點切換而重建

切換節點不會強制所有既有 TCP、QUIC 或長連線立即遷移。瀏覽器分頁、影片用戶端與即時通訊程式可能繼續使用舊連線。切換後可關閉對應連線、重新載入頁面，必要時結束並重新開啟應用程式。測試網頁時使用新的無痕視窗，能減少快取、Service Worker 與持久連線造成的干擾。

IPv4 與 IPv6 採用了不同路徑

目標網域可能同時回傳 A 與 AAAA 記錄。應用程式選擇 IPv6，而目前代理或 TUN 路由只涵蓋 IPv4 時，就會出現部分請求直連、部分請求代理的混合結果。連線頁面與日誌可以確認請求使用的位址族。不要只憑一個公用 IP 頁面推斷全部流量路徑。

建立可重複的第一次連線檢查流程

完成一次成功連線後，可以將排查步驟固定下來。日後更新訂閱、更換網路或切換用戶端時，依相同順序檢查，能快速區分設定問題、節點問題與應用程式接管問題。

1. 選擇目前的訂閱設定，確認 mihomo 或其他相容核心正在執行。
2. 保持規則模式，先只開啟系統代理，不要同時啟用 TUN。
3. 在頂層手動策略組中選擇一個具體節點。
4. 間隔 10 至 20 秒測試三次，記錄延遲與是否出現逾時。
5. 存取目標頁面，同時觀察「連線」與「日誌」是否出現對應請求。
6. 核對規則命中、策略鏈與最終節點名稱。
7. 比較直連與代理的出口位址，再使用終端機明確指定 127.0.0.1:7890 進行獨立驗證。
8. 確認基礎鏈路正常後，再啟用自動選擇、故障轉移或 TUN。

選節點、測延遲與驗證代理是三個獨立環節。選取節點解決「準備使用誰」，延遲測試解決「探測請求能否通過」，出口與連線紀錄則解決「實際流量去了哪裡」。將三個步驟分開判斷，才能避免把一個綠色延遲數字當成完整的連線結論。