Clash 首次連線如何確認成功：選擇節點、測試延遲並驗證出口 IP的完整流程

一、先確認設定已載入，別只看訂閱是否存在

訂閱出現在清單中，不代表它正在運作。首次連線時，請分別確認三件事：目前使用的設定確實已選取、代理核心成功啟動，以及設定中的策略群組已載入。Clash 是設定與核心所構成生態系的統稱，Clash Verge Rev 等用戶端提供圖形介面，mihomo 則負責解析設定、建立代理連線及套用規則。各用戶端的按鈕位置可能不同，但這三項檢查都一樣。

1. 前往用戶端的「訂閱」或「設定檔」頁面，選取剛匯入的設定，確認它標示為目前使用中。
2. 開啟「代理」頁面，確認看得到策略群組及其中的候選節點，而不只是訂閱名稱。
3. 前往「日誌」頁面，確認沒有持續出現設定解析失敗、不支援代理類型或監聽連接埠被占用等錯誤。

如果訂閱顯示更新成功，但代理頁面沒有節點，請先確認回傳內容是否為用戶端支援的設定。完整的 Clash YAML 設定與一串 Base64 節點連結是不同格式；可下載的網址也可能回傳登入頁面或錯誤訊息。設定尚未載入前，請勿反覆切換系統代理。

二、選取實際用於連線的節點

進入「代理」頁面後，先找到規則會使用的主要策略群組。它可能叫做「代理選擇」、「PROXY」或其他名稱，名稱由設定作者決定，並非軟體統一提供的選單。只在某個巢狀群組中選取節點，不代表最終流量一定會經過該節點：上層群組可能仍指向另一個自動選擇群組，目標網站也可能符合專用策略群組。

首次測試先手動選擇，減少變因

• 在可手動選擇的策略群組中，選取一個明確的實際節點；如果候選項目是另一個群組，請繼續查看它最後指向哪個節點。
• 先避開 DIRECT 與 REJECT。前者代表直接連線，後者代表拒絕連線，兩者都不是遠端代理節點。
• 優先選擇服務商標示仍可使用、地理位置也合適的線路。節點名稱中的地區僅供參考，實際出口仍須在後續步驟驗證。
• 首次測試時，只保留一個代理用戶端執行，暫時退出其他 VPN 或代理工具，避免系統代理設定互相覆蓋。

對於 url-test 自動群組，點選某個節點可能只是暫時覆寫選擇，也可能受用戶端行為及設定影響。要確認最後使用哪個節點，請查看連線面板中的實際代理鏈，不要只看節點旁的選取圖示。

三、延遲數值代表什麼

節點清單中的延遲，通常是透過該節點存取指定測試 URL 所需的時間，不應直接視為到伺服器的 ICMP ping。測試結果會受本地網路、代理交握、測試網址、伺服器負載及快取狀態影響。不同用戶端或測試網址所得的數值，不一定適合直接比較。

表中的數值僅為讀數示例，不代表線路實測排名。可連續測試 3 次，每次間隔約 5 秒，優先選擇能持續完成測試且數值波動較小的節點。某節點測得一次 45 ms、接著兩次逾時，不一定比三次都約 100 ms 的節點更適合日常使用。

測速成功，還要測試實際網站

測試 URL 可能只回傳很小的回應，例如 HTTP 204。這可以驗證基本請求路徑，卻不能取代影片傳輸速度測試、帳號地區判定或目標網站連線測試。反過來說，測試網址遭到限制，也可能導致延遲測試失敗，但部分實際網站仍可正常開啟。遇到這種情況，請搭配日誌中的目標網址與錯誤類型判斷，不要只看顏色。

四、啟用系統代理，建立最精簡的驗證路徑

首次驗證建議先使用系統代理，讓遵循系統代理設定的瀏覽器透過 Clash 連線；暫時不要同時啟用 TUN。TUN 透過虛擬網路介面接管流量，涉及路由、DNS 與權限，建議確認基本連線正常後再視需求設定。行動裝置通常透過系統 VPN 介面接管流量，無法照搬桌面版的系統代理開關步驟。

1. 在桌面版用戶端主畫面找到「系統代理」開關並啟用，同時確認核心仍在執行。
2. 開啟用戶端的連接埠設定，記下 HTTP 或混合連接埠。本文以 7890 為例，實際連接埠請以目前介面顯示為準。
3. macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理」確認；Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」確認。
4. 如果瀏覽器擴充功能另有代理設定，請先停用，或明確設為沿用系統設定，然後開啟新分頁進行測試。

規則模式適合日常使用：只有符合代理規則的請求才會經過代理。若要排除規則造成的影響，可暫時切換到全域模式，並在全域策略群組中明確選取測試節點；驗證後再切回規則模式。全域模式只會改變進入核心後的路由選擇，不會自動接管所有應用程式，也不會讓原本未經過 Clash 的連線進入核心。

五、交叉比對出口 IP 與連線面板

檢查出口 IP 時需要有對照條件。只看到陌生位址，不能證明這次請求經過所選節點；看到原本的位址，也不一定表示代理失效，因為該檢測網域可能被規則設為直連。可靠的做法是同時記錄模式、目標網域、命中規則及代理鏈。

依照以下順序進行比對

1. 在允許直接連線測試的網路環境中，關閉系統代理，並確認沒有 TUN 或其他 VPN 接管流量，再使用同一個 IP 查詢服務記錄基準位址。若已有基準資料，可略過此步驟。
2. 啟用系統代理，暫時使用全域模式並選定節點，再查詢一次。可在瀏覽器網址列開啟 https://api.ipify.org 查看公網 IPv4 位址。
3. 立刻前往用戶端的「連線」頁面，搜尋 api.ipify.org，查看記錄中的目標、規則、代理鏈及流量計數。短請求可能很快結束，請先開啟面板，並查看已關閉的連線記錄。
4. 切回規則模式後再查詢一次；若結果有所不同，請確認該網域是否命中 DIRECT，或進入另一個策略群組。

確認連線生效的關鍵證據是：查詢請求出現在連線面板中、代理鏈包含預期節點，而且服務回傳的位址符合這條路徑。位址與基準不同是有用的訊號，但不是唯一條件；不同節點也可能共用同一個出口 IP。IP 資料庫標示的國家、城市及電信業者可能有延遲，不宜只憑城市標籤判定線路有誤。

也要區分 IPv4 與 IPv6。查詢 IPv4 不代表已確認 IPv6 的路由；若兩個查詢網站使用不同的 IP 位址類型，顯示不同位址是可能的。若要驗證 IPv6，請另外測試支援 IPv6 的目標，再對照連線記錄、用戶端接管範圍及 DNS 設定判斷。

六、使用命令列排查本機連接埠問題

若瀏覽器測試結果不明確，可讓 curl 明確連線到本機 HTTP 或混合代理連接埠，避開瀏覽器擴充功能及系統代理設定。以下的 127.0.0.1:7890 僅為範例；若用戶端顯示混合連接埠為 7897，請將命令中的連接埠改為 7897。請勿將純 SOCKS 連接埠當作 HTTP 代理使用。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

在 Windows PowerShell 中可使用 curl.exe 執行相同參數，避免部分舊版環境的命令別名差異。此命令會明確指定代理入口，但請求進入核心後仍受目前的規則模式影響；若要排除規則造成的直連，請搭配前述的暫時全域模式測試，並檢查連線面板。

• Failed to connect：先確認核心已啟動、本機監聽連接埠及位址正確，優先排查請求是否抵達本機代理。
• 約 20 秒後逾時：表示本次未能在時限內完成，請進一步查看核心日誌中的遠端連線、DNS 或 TLS 錯誤。
• 有回傳 IP，但瀏覽器無法連線：優先檢查瀏覽器獨立代理、擴充功能及舊連線；此時本機代理連接埠至少已能處理這次命令列請求。

不要把關閉憑證驗證當作一般修復方式。若出現憑證時間錯誤，請先檢查作業系統日期、時區及自動校時；若只有某個網站失敗，再檢查該網站的憑證與線路，不要直接降低整個瀏覽器的安全設定。

七、常見結果與排查順序

每一輪只調整一個變因。例如先固定節點，只在規則模式與全域模式之間切換；再固定模式，改用另一個節點。同時變更 DNS、TUN、連接埠及節點，即使連線恢復，也很難找出問題所在。

八、完成首次連線後的記錄項目

驗證成功後，切回預計長期使用的規則模式，再分別造訪一個應直接連線的網站及一個應透過代理連線的網站，檢查兩者的連線記錄。直連請求顯示 DIRECT、代理請求顯示預期的策略鏈，才能確認分流行為符合設定意圖；兩個網站都能開啟，本身不足以證明規則正確。

• 記錄用戶端名稱、核心名稱、目前使用的設定名稱及本機監聽連接埠。
• 記下測試網域、模式、最後使用的節點、出口 IP 及測試時間，方便日後比對。
• 需要使用 TUN 時再單獨啟用，重新測試目標網站及出口 IP，並檢查是否與既有 VPN 或虛擬網卡衝突。
• 日後遇到異常時，先重現這條最精簡的驗證路徑，再處理應用程式專屬設定。

首次連線的驗收重點不是測出最低延遲，而是建立可重複驗證的證據鏈：設定已載入、節點可連線、請求已進入核心、規則指向正確，且目標服務有回應。逐項確認後，日後更換訂閱或用戶端時，也能沿用同一套判斷方式。