Clash 節點怎麼選：看懂延遲、倍率、地區與協定四大指標

先釐清選擇節點要解決的問題

將訂閱匯入 Clash 後，「代理」頁面通常會列出幾十到上百個節點。節點名稱可能同時包含國家或地區、線路縮寫、倍率、協定與序號，例如「日本 IEPL 01｜0.8x」或「新加坡 Hysteria2｜1.0x」。這些資訊不只是單純的速度排名：延遲反映互動回應，倍率影響流量扣除，地區決定連線路徑與內容可用範圍，協定則會改變建立連線的方式與傳輸負擔。

挑選前應先確定用途。網頁瀏覽和遠端終端機更重視低延遲與穩定性；下載大型檔案、同步雲端硬碟更重視持續吞吐量與倍率；觀看地區限定內容時，應先選對地區，再比較線路；行動網路頻繁切換時，還要留意協定對封包遺失與漫遊的適應能力。只看節點名稱中的「高速」，或只做一次延遲測試，通常無法得到可靠結論。

訂閱節點、策略群組與實際出口的關係

訂閱提供節點清單及可能附帶的規則，策略群組決定目前從哪些節點中選擇，代理規則則決定特定請求是否進入該策略群組。例如規則將影音服務交給「串流媒體」策略群組，網頁流量交給「節點選擇」策略群組，那麼在「節點選擇」中切換節點，不一定會改變影音應用程式的出口。

• 節點：包含伺服器位址、連接埠、協定與驗證參數的單一代理入口。
• 策略群組：供手動選擇、自動測速、故障轉移或負載平衡使用的節點集合。
• 規則：依網域、IP、程序或規則集合，將連線交給指定策略群組或直接連線。
• 出口：請求最後經過的伺服器，可透過 IP 查詢頁面或應用程式記錄核對。

開始測試前，先進入「代理」→目標策略群組，確認選取的是具體節點，而不是另一個巢狀策略群組。若用戶端會顯示目前鏈路，也要檢查鏈路末端是否確實位於預期地區。排查期間建議暫時固定單一節點，避免自動策略群組在測試過程中切換出口。

指標一：正確解讀延遲、抖動與封包遺失

Clash 圖形化用戶端中的延遲測試通常不是 ICMP Ping。用戶端會透過節點向測試 URL 發起 HTTP 請求，並記錄連線與回應所需時間。常見測試網址是回傳 204 狀態的輕量頁面。這個數值綜合了本地網路、前往代理伺服器的線路、代理交握與測試站台回應時間，不等同於節點能達到的下載速度。

單次低延遲不代表長期穩定

假設同一時間測得三個節點分別為 68 ms、92 ms 和 145 ms，68 ms 的節點看似最快。但連續測試五次後，如果結果是 68、310、75、逾時、240 ms，而 92 ms 的節點穩定在 88 至 105 ms，後者更適合影音、會議與遠端操作。前者的平均值與峰值都偏高，表示可能存在壅塞、封包遺失或路由波動。

同地區節點可依下列方式比較。先關閉正在進行的大型檔案下載，在相同網路下連續測試 5 次，每次間隔約 10 秒；刪除一次明顯由本地斷線造成的異常結果；記錄中位數、最高值與逾時次數。延遲中位數較低、最高值接近中位數且沒有逾時的節點，應優先考慮。

這些區間只適合在相同網路環境中進行初步篩選。中國大陸連線日本節點，與歐洲使用者連線日本節點的基準不同；家用寬頻、校園網路、公司網路與行動網路也不能直接橫向比較。測試應以自身的實際連線為準，而不是追求脫離環境的固定數值。

延遲低但下載速度慢的常見原因

• 測試請求很小，無法反映伺服器的頻寬上限與長連線吞吐量。
• 節點入口距離近，但中轉線路或前往目標網站的方向發生壅塞。
• 伺服器端同時連線過多，短請求尚可，大流量傳輸卻受到限制。
• 本地 Wi-Fi 訊號不佳、路由器負載過高，或電信商在尖峰時段發生壅塞。
• 規則將測速請求與下載請求分配到不同的策略群組。

初步篩選後，可選擇一個 50 MB 至 200 MB 的固定測試檔案，分別下載 30 至 60 秒，觀察速度是否穩定。測試檔案應來自同一部伺服器，避免目標站台差異干擾結果。測速會產生實際流量，倍率節點還會依倍率扣除，因此不必對上百個節點全部進行大型檔案測試。

指標二：倍率決定流量如何扣除

節點名稱中的 0.5x、1x、1.5x 或 2x，通常表示訂閱服務的流量計費倍率。實際傳輸 1 GB 資料時，0.5x 節點可能從方案中扣除 0.5 GB，2x 節點可能扣除 2 GB。倍率由訂閱提供者定義，不是 Clash 或 Mihomo 自動計算的效能評分，也不能直接代表節點速度。

用具體用量判斷倍率是否合適

假設每月方案為 100 GB，每天觀看影片實際消耗 3 GB。持續使用 1x 節點，30 天約使用 90 GB；使用 1.5x 節點約使用 135 GB，會超出方案；使用 0.5x 節點則約使用 45 GB。若只是偶爾瀏覽網頁，倍率差異可能不明顯；若需要系統更新、雲端備份或高畫質影片，應先考慮倍率，再比較速度。

1. 查看訂閱面板對倍率的定義，確認上傳與下載是否都會計入。
2. 估算一天的實際傳輸量，而不是只看應用程式的播放時間。
3. 將實際用量乘以節點倍率，再與方案剩餘流量比較。
4. 高倍率節點只在確實具備線路優勢時使用，不要把倍率視為品質保證。

低倍率節點在尖峰時段也可能較為壅塞，高倍率節點也可能只是成本較高的線路。實際選擇可分成兩組：將 0.5x 或 1x 的穩定節點用於日常流量，把確實具備低抖動或特定地區能力的高倍率節點保留給會議、直播或臨時任務。這比長期固定使用高倍率節點更容易控制用量。

指標三：地區影響路由、出口與內容範圍

節點地區至少包含兩層意義：伺服器入口所在的地區，以及網站看到的出口 IP 所屬地區。兩者多數時候一致，但中轉線路、跨區出口或節點命名不準確時也可能不同。需要特定地區出口時，應以實際 IP 定位與目標服務結果為準，不能只看節點名稱中的旗幟或縮寫。

日常瀏覽優先選擇地理位置接近的地區

在其他條件相近時，距離較近通常意味著較短的實體路徑與較低的往返時間。東亞網路環境下，日本、新加坡、韓國等節點常用於低延遲瀏覽；存取歐洲境內服務時，法蘭克福、阿姆斯特丹或倫敦出口可能具備更合適的目標路由。真正決定體驗的是電信商之間的路由與壅塞情況，地理距離只是第一輪篩選條件。

可以先從目標地區選出 3 至 5 個節點，再進行連續延遲測試。不要把東京、洛杉磯、倫敦的延遲放在同一份清單中，只選數值最低的節點，因為任務可能需要不同出口。存取地區限定內容時，順序應改為「地區是否正確 → 服務是否可用 → 延遲與速度是否合格」。

解鎖結果為什麼會變化

• 出口 IP 的資料庫歸屬與節點標示的地區不一致。
• 同一地區的不同 IP 網段被目標服務採用不同策略。
• DNS 請求經由本地解析，但業務連線經由代理，導致地區判斷衝突。
• 瀏覽器保留了舊的 Cookie、帳號地區或定位權限資訊。
• 策略規則只代理部分網域，登入、媒體與 API 請求沒有經由同一出口。

遇到地區辨識錯誤時，先在「代理」中固定節點，再查看「連線」頁面，確認目標網域命中的規則與策略群組。接著清除目標站台的網站資料並重新登入。若已啟用 TUN 模式，請檢查 DNS 與路由是否同時由目前設定接管；若只啟用系統代理，則要確認應用程式確實遵循系統代理設定。

指標四：協定影響連線方式，但不能單獨決定速度

訂閱中常見的協定包括 Shadowsocks、Trojan、VMess，以及 Mihomo 支援的 VLESS、Hysteria2、TUIC 等。不同協定在交握、加密、傳輸層與 UDP 支援方面有所差異，但節點速度仍取決於伺服器效能、線路品質、頻寬限制、本地網路與用戶端核心。看到某個協定名稱時，不應直接推論「一定更快」。

常見協定的觀察重點

Hysteria2 和 TUIC 主要以 UDP 傳輸。在允許 UDP 且線路適合時，它們可能在高延遲、輕微封包遺失的環境中維持良好吞吐量；但公司網路、校園網路或部分行動網路可能限制 UDP，此時會出現無法連線、交握逾時或速度不穩定。遇到這種情況，應先切換到同地區的 TCP 類節點比較，而不是立即修改所有 DNS 與規則。

協定相容性也取決於核心。Clash Nyanpasu 可搭配 Mihomo 核心使用，但訂閱中的具體欄位必須能被目前的核心版本識別。更新核心後若某類節點仍全部失敗，應開啟記錄查看「unsupported」、「authentication failed」、「TLS handshake」或「timeout」等訊息。協定不受支援、驗證錯誤與線路逾時是三種不同問題，處理方式也各不相同。

TUN 模式不會讓節點自動變快

TUN 模式透過虛擬網路介面接管更多應用程式流量，適合不遵循系統代理設定的終端程式、遊戲啟動器或部分桌面應用程式。它改變的是流量進入 Clash 的方式，不會提升代理伺服器的頻寬。若啟用 TUN 後測速下降，應檢查是否出現重複代理、MTU 不合適、DNS 繞行或安全軟體攔截。

在桌面版常見配置中，可進入「設定」→「Clash 設定」→「TUN 模式」查看狀態；切換節點則位於「代理」→策略群組→節點名稱。不同版本的文字可能略有差異。進行比較測試時應保持模式一致：不要在測試節點 A 時使用系統代理，測試節點 B 時又改用 TUN，否則結果同時包含接管方式的變化。

一套可重複執行的節點挑選流程

面對大量節點時，不需要逐一完成完整測速。先透過用途、地區與倍率減少候選，再用短時間測試排除明顯異常，最後讓真實應用程式完成驗證。以下流程通常能在約十分鐘內，從幾十個節點中挑出日常主節點與備用節點。

1. 確認用途：說明是網頁瀏覽、影片、下載、遠端連線，還是特定地區服務。
2. 限定地區：從符合出口需求的地區中保留 5 至 10 個節點。
3. 核對倍率：依方案剩餘流量排除不適合長期使用的高倍率節點。
4. 連續測試延遲：每個候選節點測試 5 次，記錄中位數、峰值與逾時次數。
5. 短時間吞吐測試：對剩餘 2 至 3 個節點使用同一檔案測試 30 至 60 秒。
6. 以真實應用驗證：實際開啟目標網頁、播放影片或建立遠端連線。
7. 保留備用節點：主節點與備用節點最好來自不同伺服器或不同線路。

如何設定自動策略群組

如果訂閱允許在本地覆寫設定，可以使用 url-test 在一組候選節點中定期選擇延遲較低的節點。以下範例每 300 秒測試一次，容差為 50 ms；當多個節點的差距很小時，容差可以減少頻繁切換。節點名稱需要替換為設定中實際存在的名稱。

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

url-test 主要依據測試 URL 的回應時間自動選擇節點，不會考慮倍率、地區解鎖或大型檔案吞吐量。候選清單應預先篩選，不能把所有地區與所有倍率混在一起。需要優先確保可用性時，可以考慮 fallback，但同樣不能取代實際業務驗證。

常見誤區與故障判斷

延遲顯示逾時，網頁卻能開啟

測試 URL 可能暫時無法連線、受到目標網路限制，或用戶端測試逾時時間過短，但節點本身仍能代理其他網站。先將測試網址換成穩定的輕量頁面，再透過實際連線與記錄判斷。若所有節點同時逾時，應優先檢查本地網路、訂閱狀態、核心程序與防火牆，而不是逐一刪除節點。

選取節點後出口沒有變化

最常見的原因是切換了錯誤的策略群組。進入「連線」查看目標請求命中的規則、策略群組與節點鏈路。如果規則將請求交給「串流媒體」，而使用者只修改了「節點選擇」，出口自然不會改變。也應檢查瀏覽器是否啟用了獨立代理擴充功能，以及終端機是否設定了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 環境變數。

自動選擇總是在幾個節點之間跳動

當節點延遲差距只有 10 至 30 ms 時，網路輕微波動就可能改變排名。可將測試間隔設為 300 至 600 秒，並設定約 50 ms 的容差，減少沒有明顯收益的切換。對遠端終端機、會議或長連線任務而言，手動固定穩定節點通常比頻繁追求最低延遲更合適。

同名地區節點的表現差距很大

同樣位於日本或新加坡，不代表使用相同的電信商、入口、跨境線路與伺服器負載。節點序號也不等於品質等級。將表現穩定的節點記錄在獨立策略群組中，同時保留一條不同線路作為備用；在尖峰時段再測試一次，會比白天單次測試更準確地反映長期體驗。

最後以四項記錄做決定

節點選擇可以整理成一份簡單記錄：延遲填寫中位數與最高值，倍率填寫實際扣除規則，地區填寫實際出口與目標服務結果，協定填寫目前網路下的連線穩定性。例如「日本-02：延遲中位數 86 ms、最高 112 ms、1x、日本出口、Trojan，連續下載 60 秒穩定」，比「日本節點很快」更方便日後比較。

日常主節點不必在每項指標都排名第一。穩定、倍率可接受、出口符合用途，並且在真實應用中持續可用，就是更實用的選擇。網路狀況會隨電信商路由、伺服器負載與時段變化，建議在出現明顯卡頓時重新進行短測試，而不是每天反覆切換節點。