Clash 節點怎麼選：延遲、倍率、地區與協定判斷標準

先確認需求，再看測速數值

選擇 Clash 節點時，最低延遲不一定代表最佳體驗。網頁開啟速度、影片緩衝、遠端會議、檔案下載和遊戲連線，對線路的要求各不相同。開始測試前，先確認目前任務更重視回應速度、持續頻寬、地區出口，還是流量消耗。

例如，同一個訂閱中有一個 48 ms 的香港節點，以及一個 82 ms 的日本節點。前者開啟網頁通常回應較快，但如果尖峰時段有明顯丟包，影片播放反而可能不如後者穩定。另一個標示 160 ms 的美國節點雖然不適合低延遲互動，卻可能是存取限定美國地區內容時的正確選擇。

常見用途對應的優先指標

• 日常瀏覽：優先查看延遲、連線成功率和尖峰時段穩定性，通常選擇地理距離較近的地區。
• 高畫質影片：優先查看持續下載速度和抖動，瞬間測速很高但頻繁降速的線路並不理想。
• 語音會議：優先查看雙向延遲、抖動和丟包。延遲穩定在 80 ms，通常比在 35 ms 到 180 ms 之間跳動更容易使用。
• 大型下載：留意持續吞吐量、倍率和方案剩餘流量，沒有必要一味追求最低延遲。
• 地區內容：先確認出口國家或地區，再從符合地區條件的節點中比較穩定性。
• 弱網行動連線：重點比較協定表現、重新連線速度，以及 UDP 是否可用。

延遲測試數值應該怎麼看

Clash 圖形化客戶端中的延遲測試，通常會請求一個容量很小的測試網址，並記錄從發起連線到收到回應所需的時間。不同客戶端、設定檔和代理服務商可能使用不同測試網址，因此兩個軟體顯示的結果不能直接比較。

延遲結果還會受到 DNS 解析、TLS 握手、測試伺服器位置、本地 Wi-Fi 和節點目前負載影響。測出一次 42 ms，只能表示當下的小型請求完成得很快，不能證明該節點能持續提供高下載速度。

一組數值的實用分級

這些區間不是固定標準。中國大陸到香港、日本或新加坡節點，常見結果可能落在 35–120 ms；到歐洲或北美節點，常見結果可能落在 140–260 ms。電信業者、所在地城市、入口線路和跨境路由都會改變結果。

至少連續測試三次

1. 關閉正在進行的大型下載、雲端硬碟同步和系統更新。
2. 對候選節點連續測試 3 到 5 次，每次間隔約 5 秒。
3. 記錄最低值、最高值和逾時次數，不要只保留表現最好的一次。
4. 白天和 20:00–23:00 各測試一輪，比較尖峰時段的差異。
5. 選出兩到三個候選節點，再實際播放 1080p 影片或下載約 200 MB 的測試檔案。

假設節點 A 的五次結果為 46、49、51、48、50 ms，節點 B 為 32、37、145、逾時、41 ms。雖然節點 B 的最低值較低，但節點 A 的波動只有 5 ms，實際瀏覽和會議通常更穩定。此時應優先選擇節點 A。

延遲、抖動、丟包與速度的差異

延遲決定請求需要等待多久

延遲主要影響短連線和頻繁互動。開啟包含大量小型資源的網頁時，每次連線和請求都要等待網路往返。遠端終端機、線上文件和語音通話也對延遲相當敏感。延遲從 50 ms 增加到 180 ms，即使下載頻寬相同，操作時的等待感也會更明顯。

抖動代表延遲是否穩定

抖動可以理解為多次延遲之間的變化幅度。連續結果為 70、73、76 ms，通常比 40、160、55 ms 更穩定。語音和即時影片需要依時間順序持續接收資料，抖動過大時容易出現斷續、畫面停頓或短暫無聲。

丟包會觸發重傳或造成品質下降

TCP 流量遇到丟包後通常需要重傳，下載速度會下降；UDP 業務可能直接遺失部分資料，即時語音與遊戲對這種情況更敏感。家用 Wi-Fi 干擾、本地電信業者壅塞、節點入口過載和遠端線路都可能造成丟包。

頻寬決定持續傳輸上限

一個延遲 95 ms、可持續下載 80 Mbps 的節點，播放高位元率影片可能優於延遲 45 ms、尖峰時段只能維持 6 Mbps 的節點。測速時應觀察至少 30–60 秒，區分短暫峰值與持續速度。8 Mbps 約相當於每秒 1 MB 的理論傳輸量，實際還會扣除協定開銷。

如果客戶端的延遲測試正常，但瀏覽器仍然很慢，可以先切換到另一個測試網址，再檢查 DNS、規則命中和系統代理。啟用 TUN 模式後，還需要確認流量確實進入 Clash，而不是由未接管的應用程式透過其他網路介面直接連線。

節點倍率如何影響方案流量

倍率通常是代理服務商的計費屬性，不是 Clash 協定本身的功能。標示「0.5×」表示使用 1 GB 實際流量時，方案可能扣除約 0.5 GB；「2×」則可能扣除約 2 GB。具體統計方式以訂閱服務的面板說明為準，上行、下行和協定開銷是否一併計算也可能不同。

低倍率節點不一定速度較慢，高倍率節點也不代表延遲一定更低。倍率可能與線路成本、入口品質、地區資源或營運策略有關。選擇時應將它視為「每單位使用量的方案成本」，而不是效能等級。

依每月流量回推可接受的倍率

假設方案每月有 200 GB，日常影片和下載預計實際使用 120 GB。若全部使用 1.5× 節點，理論計費量約為 180 GB，剩餘空間只有 20 GB；如果其中 80 GB 改用 0.5× 節點，另外 40 GB 使用 1.5× 節點，範例計費量約為 100 GB。對大流量任務單獨選擇低倍率策略組，通常比頻繁手動切換更清楚。

可以在設定中建立「日常」、「下載」和「地區服務」三個策略組。日常組使用穩定的 1× 節點，下載組加入低倍率節點，地區服務組只放符合出口要求的節點。由規則將不同網域或應用程式流量交給對應策略組，節點選擇會更容易維護。

地區選擇取決於出口與路由

節點名稱中的香港、日本、新加坡或美國，通常描述代理伺服器的出口位置，但名稱不一定完整反映入口和中轉路徑。兩個同為日本的節點，可能分別經過不同電信業者和中轉線路，延遲與尖峰時段表現可以相差很大。

距離近，通常只是起點

• 香港：地理距離較近，常用於日常網頁和低等待情境，但尖峰時段表現取決於入口線路。
• 日本：常見延遲適中，適合需要日本出口的內容，也可作為東亞地區的日常候選。
• 新加坡：適合東南亞地區服務，部分南部網路的連線表現較好。
• 美國：適合要求美國出口的服務，但實際距離決定基礎延遲通常高於東亞節點。
• 歐洲：主要用於特定地區存取，日常互動延遲通常較高，應優先檢查路由穩定性。

存取有地區限制的內容時，出口 IP 所屬地區比節點名稱更重要。連線後可以透過常用 IP 查詢頁面確認國家、地區和網路業者。若出口顯示正確但內容仍不可用，原因還可能是帳號註冊地區、付款資料、瀏覽器定位、DNS 結果或服務商的 IP 資料庫尚未更新。

自動選擇組要限制候選範圍

Clash 的 url-test 策略組可以定期測試候選節點並選取延遲較低者，但如果把所有地區混在同一個組裡，自動選擇可能從美國節點切換到香港節點，導致地區出口變更。需要固定地區時，應分別建立「日本自動選擇」、「美國自動選擇」等策略組。

proxy-groups:
  - name: 日本自動選擇
    type: url-test
    include-all: true
    filter: "(?i)日本|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日常手動選擇
    type: select
    proxies:
      - 日本自動選擇
      - DIRECT

這段範例每 300 秒測試一次名稱符合日本的節點，tolerance: 50 用來減少小幅延遲變化造成的頻繁切換。不同 Clash Meta（mihomo）版本和客戶端對設定欄位的支援範圍可能不同，匯入前應以目前核心文件和訂閱產生結果為準。

協定差異在弱網環境下更明顯

訂閱節點可能使用 Shadowsocks、Trojan、VLESS、VMess、WireGuard、Hysteria2 或 TUIC 等協定。Clash Meta（mihomo）支援的具體協定和傳輸組合取決於核心版本。協定不是單獨決定速度的因素，伺服器效能、入口頻寬、路由品質和參數設定通常同樣重要。

TCP 類傳輸：相容性較穩定，丟包時可能降速

Trojan、部分 VLESS 或 VMess 節點通常運作在 TCP 與 TLS 之上。TCP 在多數網路中容易通過，連線行為也較穩定，但線路發生丟包時，底層 TCP 會重傳並降低傳送速率。若代理通道中的業務本身也是 TCP，嚴重丟包下可能出現速度下降和延遲累積。

Shadowsocks：實作成熟，表現取決於線路

Shadowsocks 的額外開銷通常可控，客戶端和伺服器端實作廣泛。它在一般寬頻上的體驗更多取決於加密方式、伺服器負載和網路路徑。看到 SS、Trojan 或 VLESS 標籤時，不應直接依協定名稱排出絕對效能順序。

Hysteria2 與 TUIC：採用 UDP/QUIC 傳輸

Hysteria2 和 TUIC 以 UDP/QUIC 為基礎，在部分高延遲且存在一定丟包的線路上，可以透過壅塞控制和連線遷移取得更平順的吞吐表現。不過，某些校園網路、公司網路、公共 Wi-Fi 或行動網路會限制 UDP，表現可能是無法連線、握手逾時或速度突然下降。

WireGuard：適合穩定通道情境

WireGuard 使用 UDP，協定結構精簡，常用於整段網路通道。它對系統時間、MTU 和 UDP 可達性較敏感。網頁可以開啟但部分網站卡住時，可以檢查 MTU；常見排查值包括 1280、1380、1420，但最終值應根據實際鏈路測試，而不是固定照抄。

弱網測試要包含網路切換

1. 分別在家用 Wi-Fi、手機熱點和行動網路下測試同一個節點。
2. 播放 10 分鐘影片，觀察是否頻繁重新緩衝。
3. 鎖定螢幕 2 分鐘後恢復，檢查連線是否能快速重建。
4. 從 Wi-Fi 切換到行動網路，記錄恢復存取所需的時間。
5. 若 UDP 協定持續逾時，改測 TCP 類節點，確認是否為網路限制。

在 Android 上使用 VpnService，或在桌面端開啟 TUN 模式時，網路切換後可能需要等待系統重新建立預設路由。此時短暫斷線不一定是節點故障。可以先等待 5–10 秒，再檢查客戶端記錄中的逾時、DNS 錯誤或介面重建記錄。

用策略組減少手動選節點

當訂閱包含幾十個節點時，逐一點擊測試的效率很低。更實用的方法是依用途建立策略組：地區組限定出口，自動組比較延遲，手動組保留最終控制權，故障轉移組則在主要節點不可用時切換到備用節點。

四類策略組的適用範圍

• select：手動選擇節點或其他策略組，適合地區內容和需要固定出口的帳號。
• url-test：定期測試並傾向選擇低延遲節點，適合日常瀏覽。
• fallback：依序使用可用節點，主要線路失敗時切換到備用線路。
• load-balance：依設定策略在多個節點間分配連線，不適合要求固定出口 IP 的登入工作階段。

自動測試的間隔也需要控制。設定為 10 秒會頻繁產生探測請求，並可能造成節點反覆變更；300–600 秒更適合一般使用。tolerance 可以避免兩個節點只相差 5–20 ms 時不斷切換。登入、購物車和風控敏感服務應使用固定節點或固定地區策略組。

訂閱更新後，節點名稱可能變更。使用正規表示式篩選地區時，應同時涵蓋中文、英文縮寫和服務商常用命名，例如日本節點可匹配「日本」、「JP」、「Japan」。篩選結果為空時，先查看實際節點名稱，再修改運算式，不要直接將空策略組用作規則出口。

一套可重複的節點選擇流程

1. 確認任務：明確是日常瀏覽、下載、會議、地區內容，還是行動弱網使用。
2. 篩選地區：保留符合出口需求的節點，並透過出口 IP 核對實際地區。
3. 檢查倍率：根據方案剩餘量排除不適合長期使用的高倍率節點。
4. 連續測試延遲：進行 3–5 次測試，記錄波動、逾時和尖峰時段結果。
5. 實際執行業務：至少測試網頁、影片或下載其中一種，不要只依賴 URL Test。
6. 比較協定：在目前網路下分別測試 TCP 類和 UDP/QUIC 類節點。
7. 建立策略組：將最終候選節點放入手動、自動或故障轉移組。
8. 保留備用節點：除了主要節點之外，至少準備一個不同入口或不同協定的備用節點。

最終選擇可以概括為：地區正確、連線穩定、倍率可接受，接著才是延遲盡可能低。對日常網頁而言，穩定在 60–100 ms 的近距離節點通常已足夠；對高畫質影片，應優先確認持續頻寬；對特定地區內容，應保持出口不變；對弱網環境，則應透過實際網路切換，檢驗協定的重新連線與抗抖動能力。

節點品質會隨時間變化。線路調整、尖峰時段負載、電信業者路由和伺服器維護，都可能讓上週的最佳節點變成今天的普通節點。每隔一到兩週重新測試候選組，並在明顯變慢時先切換備用節點，再檢查本地網路、DNS、規則和 TUN 接管狀態，可以減少無效排查。