Clash 首次連線如何選節點：測試延遲、切換節點並確認代理生效

先完成連線流程，再比較節點

第一次使用 Clash 或採用 Mihomo 核心的客戶端時，先別急著盯著節點清單中的延遲數字。一條完整的連線至少包含四個環節：載入設定、在策略組中選定節點、將系統流量交給客戶端，以及節點能夠存取目標網站。任何一個環節未完成，都可能出現「節點有延遲，但網頁打不開」的情況。

建議依固定順序操作：匯入訂閱、更新設定、選擇代理模式、開啟系統代理或 TUN 模式，最後進入策略組選擇節點。各圖形化客戶端的名稱略有不同，常見路徑是「訂閱」→「更新」，接著進入「代理」→目標策略組。如果只開啟客戶端，卻沒有啟用系統代理，瀏覽器通常仍會沿用原本的網路直接連線。

1. 在「訂閱」或「設定」頁面確認目前的 Profile 已啟用，並手動執行一次更新。
2. 進入「代理」頁面，將執行模式設為「規則」；首次測試不建議直接使用「直連」。
3. 開啟「設定」→「系統代理」，確認開關已處於啟用狀態。
4. 回到「代理」→主策略組，選擇一個能完成延遲測試的節點。
5. 查詢啟用代理前後的出口 IP，確認地址已改變，再測試實際網站。

手動選擇、自動測速與故障轉移的差異

Clash 設定中的「節點選擇」實際上是在策略組內進行。策略組是由多個代理節點與選擇邏輯組成的集合。最常見的類型包括 select、url-test、fallback 與 load-balance。訂閱服務可能將它們顯示為「節點選擇」、「自動選擇」、「故障轉移」或「負載平衡」。

首次連線優先使用手動策略組

手動選擇更適合第一次測試，因為變數最少。先在 select 類型的策略組中固定一個節點，完成出口 IP、網頁存取與命令列測試。連線正常後，再切換到自動測速組。如此一來，若自動選擇結果不理想，就能明確判斷問題來自測速邏輯，而非系統代理或訂閱匯入。

節點名稱中的地區、倍率與線路標籤只提供分類資訊，不能取代實際測試。例如「香港 01」不一定比「日本 02」快，「專線」也無法直接代表本地網路到入口伺服器的品質。距離較近通常有助於降低往返時間，但電信業者互聯、尖峰時段壅塞與節點負載同樣會影響結果。

自動測速測的是測試目標

url-test 會定期請求設定中指定的測試網址，再比較候選節點的回應時間。以下是一段常見的 Mihomo 設定：

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 香港 01
      - 日本 02
      - 新加坡 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval: 300 表示大約每 300 秒重新測試一次；tolerance: 50 表示候選結果差距較小時允許保留目前節點，以減少頻繁切換。測試網址回應快速，只能表示該節點目前存取這個測試目標的表現較好，不能保證存取影片、程式碼儲存庫或辦公服務時同樣最快。

該如何解讀延遲數字

客戶端顯示的延遲通常不是傳統的 ICMP Ping。多數 Clash 圖形化客戶端會透過代理發出 HTTP 請求，記錄建立連線並取得回應所需的時間。結果會同時受到本地網路、代理入口、節點出口、DNS、TLS 交握與測試伺服器狀態影響。因此，延遲是篩選工具，不是頻寬測試。

不要因為一次測得 65 ms，就認定節點穩定。較可靠的方法是間隔 10 秒測試三至五次。例如同一節點依序為 72、75、79、74 ms，波動較小；另一個節點為 48、210、93、逾時，雖然最低值更漂亮，實際使用時往往更不穩定。對於影片與下載，還要觀察持續傳輸速度；對於遠端終端機與網頁互動，則應更重視延遲與抖動。

測速全部逾時時，先檢查哪些項目

• 確認電腦本身可以直接存取一般網站，排除 Wi-Fi 中斷或閘道故障。
• 在「訂閱」→「更新」重新取得設定，避免使用已過期的節點資訊。
• 檢查系統時間與時區。時間偏差過大可能導致 TLS 憑證驗證失敗。
• 暫時關閉 TUN，只啟用系統代理進行測試，避免多種接管方式互相影響。
• 確認本地混合連接埠沒有被其他程式佔用，常見值為 7890。
• 查看客戶端日誌，重點尋找 timeout、connection refused 與 network unreachable。

切換節點後，為什麼沒有立即變化

在策略組中點選新節點後，新建立的連線通常會使用新的選擇，但已建立的連線可能繼續沿用舊通道。瀏覽器的 HTTP/2、HTTP/3 長連線、下載工具的分段任務，以及即時通訊程式的常駐連線，都可能讓舊出口短暫保留。因此，切換後立即重新整理同一個頁面，不一定能看到出口變化。

依照以下順序重新建立連線

1. 進入「代理」→主策略組，確認選取標記已移至新節點。
2. 關閉正在測試的網頁分頁，並等待 5 至 10 秒。
3. 重新開啟無痕視窗，避免頁面快取與既有連線影響結果。
4. 再次查詢出口 IP，並與切換前的地址比較。
5. 仍未變化時，重新啟動瀏覽器；必要時在客戶端的連線頁面關閉舊連線。

還要檢查規則模式是否將測試網站分配至預期的策略組。規則模式會由上而下比對網域、IP、程序或規則集合。如果出口 IP 查詢網站的網域命中 DIRECT，頁面顯示的仍會是本地公網地址，即使主策略組已選取代理。排查時可在客戶端日誌或連線清單中找到該網域，核對顯示的規則、策略組與實際節點。

也可以短暫切換至全域模式進行對照測試。全域模式下，流量通常會統一交給指定的代理節點；如果全域模式能改變出口，而規則模式不能，問題多半出在規則比對或策略組引用。測試完成後切回規則模式，避免原本應直連的區域網路或中國大陸服務也經過代理。

透過出口 IP 頁面確認代理是否生效

最直觀的方法是先關閉系統代理，存取一個公網 IP 查詢服務，記錄目前的出口地址；再開啟系統代理並重新整理查詢。兩次結果不同，且啟用代理後的地區與所選節點大致一致，就表示瀏覽器流量已經經過代理。不要只看頁面顯示的國家或城市，IP 地址本身更適合作為比對依據。

1. 關閉 Clash 的「系統代理」開關，開啟 IP 查詢頁面，記錄一組 IPv4 或 IPv6 地址。
2. 重新開啟「系統代理」，並在策略組中固定一個節點。
3. 建立新的瀏覽器無痕視窗，再次查詢出口 IP。
4. 切換至另一個地區的節點，關閉查詢分頁後重新開啟，確認地址再次改變。
5. 回到客戶端的「連線」頁面，查看查詢網域是否經過目標策略組。

如果 IPv4 已改變，但 IPv6 仍顯示本地電信業者地址，就需要檢查客戶端是否接管 IPv6，以及瀏覽器存取的查詢服務是否優先回傳 IPv6。不同作業系統、TUN 設定與網路環境對 IPv6 的處理方式各不相同。只測試 IPv4，不能推斷所有 IPv6 流量也經過相同路徑。

使用命令列分別測試直連與代理

命令列測試可以避開瀏覽器擴充功能、快取與長連線，更容易確認本地代理連接埠是否正常運作。以下範例假設 Mihomo 的混合連接埠為 127.0.0.1:7890。混合連接埠同時接受 HTTP 與 SOCKS 連線；如果客戶端使用其他連接埠，應以「設定」→「連接埠設定」中顯示的數值為準。

Windows PowerShell

Windows 10 或 Windows 11 可先確認 curl.exe 的實際程式，避免 PowerShell 舊版本將 curl 解讀為其他命令。直連與代理請求分別執行：

curl.exe --noproxy "*" https://api.ipify.org
curl.exe -x http://127.0.0.1:7890 https://api.ipify.org

macOS 與 Linux

curl --noproxy "*" https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

第一個命令會強制略過代理，回傳本地網路的公網出口；第二個命令則明確將請求送至 Clash 混合連接埠。如果兩個命令回傳不同地址，且第二個請求同時出現在客戶端連線記錄中，就表示 HTTP 代理連線已生效。若第二個命令提示無法連線至 127.0.0.1:7890，應檢查客戶端是否正在執行、連接埠是否填寫正確，以及監聽地址是否允許本機存取。

也可以測試 SOCKS5，讓網域解析透過代理端完成：

curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org

--socks5-hostname 與單純的 --socks5 有一項重要差異：前者會將網域交由 SOCKS 代理解析，適合用來排除本地 DNS 解析結果對測試造成的影響。如果 HTTP 代理可用，但 SOCKS 請求失敗，應檢查目前的連接埠究竟是混合連接埠、HTTP 連接埠，還是獨立的 SOCKS 連接埠。

檢查本地連接埠是否正在監聽

Windows 可以執行：

netstat -ano | findstr :7890

macOS 可以執行：

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux 可以執行：

ss -lntp | grep 7890

看到 127.0.0.1:7890 或 0.0.0.0:7890 處於監聽狀態，表示有程式正在接收該連接埠的連線，但這本身還不能證明節點可用。仍需結合代理請求結果與客戶端日誌判斷。如果監聽程序不是目前的 Clash 客戶端，可能存在連接埠衝突，應關閉衝突程式，或同步修改客戶端連接埠與系統代理設定。

瀏覽器可用，但其他應用程式無法連線時的處理方式

瀏覽器能夠存取網站，不代表所有程式都會讀取系統代理設定。部分遊戲、命令列工具、商店應用程式與採用自有網路堆疊的軟體會忽略 HTTP 代理設定。此時先查看應用程式本身是否提供代理選項；如果支援，可填寫 HTTP 代理 127.0.0.1:7890，或使用同一個混合連接埠作為 SOCKS5 代理。

應用程式沒有代理設定時，可以考慮使用 TUN 模式。常見操作路徑是「設定」→「Mihomo」或「核心設定」→「TUN 模式」。首次啟用可能需要管理員權限，並建立虛擬網路介面卡。開啟後應重新測試出口 IP 與目標應用程式，同時檢查區域網路裝置、印表機與公司內網是否仍能依規則直連。

TUN 模式的驗證重點

• 客戶端日誌中能看到目標應用程式建立的新連線。
• 連線記錄顯示正確的規則與策略組，而不是意外命中 DIRECT。
• DNS 請求能正常完成，沒有連續出現解析逾時。
• 關閉系統代理後，目標應用程式在 TUN 模式下仍能依規則連線。
• 結束客戶端後網路可以恢復，預設路由與 DNS 沒有殘留異常。

不要同時反覆切換系統代理、TUN、全域模式與多個節點。一次只改變一個變數，並記錄結果。例如先固定「日本 02」，只開啟系統代理；確認命令列代理可用後，再啟用 TUN；最後恢復規則模式。這樣的排查順序能快速定位問題是在節點、連接埠、規則，還是流量接管層。

首次連線的穩定性檢查清單

選定一個延遲較低的節點後，再進行一輪連續測試。開啟三個不同類型的網站並維持 5 分鐘；下載一個約 50 MB 的公開測試檔案，觀察速度是否持續；切換兩次頁面並查看客戶端連線記錄。短暫測速成功，但幾分鐘後大量逾時，通常表示節點負載、線路抖動或本地網路不穩定。

• Profile 已更新，客戶端顯示的設定更新時間符合預期。
• 主策略組明確選取一個節點，而不是誤選 DIRECT。
• 連續三次延遲測試沒有大幅波動或頻繁逾時。
• 系統代理或 TUN 至少啟用一種，並與測試目標相符。
• 代理前後的出口 IP 不同，連線日誌顯示目標節點名稱。
• 在規則模式下，常用網站命中預期的策略組。
• 關閉客戶端後，系統網路能正常恢復。

最後選擇不必追求清單中的最低數字。一個穩定維持在 110 ms、連續使用正常的節點，通常比在 45 ms 到 400 ms 之間跳動的節點更適合日常工作。先確保可用且穩定，再根據影片速度、網頁回應或特定地區需求調整策略組。