如何選擇 Clash 節點：延遲、倍率、地區與協定判斷方法

SELECTION BASELINE

先確定節點篩選目標

選擇 Clash 節點時，延遲最低不代表實際體驗最好。一個節點是否適合目前的任務，至少取決於連線穩定性、可用頻寬、網路路徑、目標地區、流量倍率與用戶端支援情況。網頁瀏覽、影片播放、大型檔案下載、即時通話與遠端開發對線路的要求各不相同，只看一次延遲數值很容易得出錯誤結論。

一般網頁存取更重視建立連線的速度與穩定性。影片播放需要持續頻寬，偶爾出現較高延遲通常不會影響緩衝後的播放，但短時間丟包與明顯抖動會造成畫質下降。語音、會議與遊戲更依賴低抖動、低丟包率以及穩定的往返時間。大型檔案下載則主要觀察持續吞吐量，同時要考慮節點倍率帶來的流量消耗。

開始篩選前，先將用途分成三類：日常預設節點、特定地區節點與高頻寬臨時節點。日常節點應優先考量穩定性，適合作為規則模式下大部分代理流量的出口；特定地區節點用於存取具有區域差異的服務；高頻寬節點用於更新、同步或下載，但不一定適合長時間維持連線。這樣分類，比試圖找到一個涵蓋所有情境的「最快節點」更可靠。

LATENCY TEST

正確理解 Clash 延遲測試

Clash 用戶端中的延遲測試通常不是系統指令中的 ICMP Ping。常見實作會透過該代理節點請求測試網址，記錄建立連線並取得回應所需的時間。這個結果更接近代理鏈路上的 HTTP 或 HTTPS 連通性，但仍只是一次小流量測試，不能直接代表持續下載速度。

同一個節點連續測試可能出現不同結果。原因包括本地 Wi-Fi 波動、電信商網路壅塞、代理伺服器負載、跨境路由變化、DNS 解析時間與測試目標的回應速度。第一次測試還可能包含網域解析、TCP 建立連線或 TLS 交握成本，後續測試則可能重用快取，因此數值通常較低。判斷時應觀察多次結果的範圍，而不是只保留最小值。

延遲數值應如何解讀

• 數值穩定：多次結果接近，即使不是清單中的最低值，通常也適合作為日常節點。
• 數值明顯跳動：例如相鄰測試相差數百毫秒，表示路徑或負載不穩定，需要繼續觀察。
• 顯示逾時：可能是節點無法使用，也可能是測試網址無法透過該節點存取，不能只因一次逾時就立即刪除設定。
• 延遲低但下載慢：小型請求回應快，不代表伺服器有足夠的出口頻寬，也不代表尖峰時段能維持吞吐量。
• 延遲高但播放穩定：只要持續頻寬充足且丟包率低，已完成緩衝的影片仍可穩定播放。

更實用的做法是連續測試三到五次，記錄中位數與波動範圍。例如兩個節點的中位延遲分別為 80 毫秒與 110 毫秒，但前者經常跳到 600 毫秒，後者始終維持在 100 至 130 毫秒，那麼後者通常更適合會議、遠端終端機與持續瀏覽。

如果所有節點同時逾時，應先檢查訂閱是否已更新、設定是否成功載入、裝置網路是否正常，以及 Clash 核心是否正在執行。若只有某個策略組逾時，還要確認組內節點是否有效。啟用 TUN 模式不會自動降低節點延遲；TUN 只會改變流量進入代理核心的方式，實際鏈路品質仍由本地網路、節點伺服器與目標網路共同決定。

REGION AND ROUTE

依地區與實際網路路徑選擇

地區標籤表示節點伺服器或入口所在區域，但地理距離只是影響延遲的其中一項因素。封包經過哪些電信商、是否繞路、入口與出口是否分離，都會改變實際結果。位置較近的節點可能因互連品質較差而延遲更高；位置較遠的節點也可能透過穩定線路獲得更低的抖動。

篩選日常節點時，可以先從地理位置較近的地區開始測試，再保留一到兩個不同地區作為備用。不要把所有候選節點都放在同一個地區，因為區域性網路故障、伺服器維護或晚間尖峰壅塞可能同時影響一批節點。備用節點的用途不是長期閒置，而是在主要節點連續逾時或速度下降時快速切換。

地區選擇的常見判斷

節點名稱中的地區不一定能完整描述網路路徑。有些服務使用中轉入口，節點名稱標示的是出口地區，但本地首先連線到的是另一個入口；也有些名稱包含線路代號或電信商縮寫。無法確認時，應以實際測試結果與服務提供者提供的節點說明為準。

還要區分「目標服務地區」與「代理節點地區」。存取部署在全球 CDN 上的網站時，節點可能會被分配到靠近出口的邊緣伺服器，因此出口地區會影響內容分發路徑。對沒有地區要求的日常存取，優先選擇穩定且路徑較短的節點；只有目標服務明確依賴地區時，才將出口位置作為首要條件。

TRAFFIC RATE

判斷倍率與實際流量成本

節點倍率通常是訂閱服務採用的流量計費係數，不是 Clash 協定本身的屬性。標示為 1 倍的節點，使用 1 GB 資料通常按 1 GB 計入方案；標示為 2 倍時，相同的傳輸量可能按 2 GB 計算。具體統計範圍與計算方式應以訂閱服務說明為準，Clash 用戶端只負責使用設定中的節點，不負責統一定義倍率規則。

倍率高不一定代表速度更快。高倍率可能對應成本較高的線路、較少壅塞的入口或特定地區資源，但節點目前的負載仍會變化。相反地，低倍率節點也可能在非尖峰時段提供足夠速度。因此倍率應作為成本指標，與延遲、穩定性及吞吐量分開評估。

依任務分配倍率

1. 日常瀏覽與即時通訊優先使用穩定的一般倍率節點，減少頻繁手動切換。
2. 系統映像檔、遊戲更新與雲端同步會產生大量流量，應先檢查剩餘配額，再比較低倍率節點的持續速度。
3. 對地區或線路有明確要求的臨時任務，可以使用較高倍率節點，完成後切回預設策略。
4. 測速本身也會消耗流量，連續執行大型檔案測速會快速增加用量，不適合對所有節點反覆執行。

PROTOCOL REVIEW

比較常見代理協定與用戶端支援

訂閱中可能同時出現 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUIC 等節點。協定決定連線與傳輸方式，但協定名稱本身不能單獨證明節點更快。伺服器位置、線路頻寬、壅塞程度、傳輸層設定與用戶端核心版本往往影響更大。

Shadowsocks

Shadowsocks 設定相對直接，常見 Clash 核心通常支援多種加密方式。實際可用性取決於用戶端核心是否支援節點指定的加密方法或擴充形式。如果匯入訂閱後節點出現 cipher、plugin 或 unsupported 等相關錯誤，應先確認核心支援情況，而不是反覆測試延遲。

VMess 與 VLESS

VMess 與 VLESS 常與 TCP、WebSocket、gRPC、TLS 等傳輸設定組合使用。VLESS 本身不等於固定的線路品質，Reality、TLS 或其他安全傳輸參數也需要核心正確支援。舊版 Clash 核心與基於 Clash Meta、現稱 mihomo 的核心，在協定及擴充支援範圍上可能不同。訂閱中出現新欄位時，應使用仍支援相應設定格式的用戶端與核心。

Trojan

Trojan 通常執行於 TLS 連線上，設定中會涉及伺服器名稱、憑證驗證與傳輸層參數。裝置時間錯誤、網域解析異常或伺服器憑證問題，都可能導致交握失敗。這類故障通常表現為節點無法建立連線，不應誤判為單純的高延遲。

Hysteria2 與 TUIC

Hysteria2 與 TUIC 採用基於 UDP 的傳輸設計，在部分高延遲或存在一定丟包的網路中可能獲得較好的吞吐表現，但前提是本地網路、路由設備與電信商路徑能正常傳輸 UDP。某些公司網路、公共 Wi-Fi 或防火牆會限制 UDP，此時節點可能逾時，切換到基於 TCP 的候選節點更容易判斷問題來源。

選擇協定應以相容性優先：先確認用戶端核心能解析設定並建立連線，再比較使用體驗。如果多個協定節點使用相同入口與相近線路，實際差距可能很小。不必因為協定名稱較新就將其設為預設，也不應在沒有錯誤記錄的情況下任意修改訂閱產生的協定參數。

PROXY GROUPS

使用 Clash 策略組自動篩選

節點數量較多時，可以利用策略組減少手動切換。Clash 與 mihomo 設定中的常見策略組包括 select、url-test、fallback 與 load-balance。它們解決的問題不同，不能只看組名判斷行為。

• select：由使用者手動選擇節點或下層策略組，適合預設出口與特定地區選擇。
• url-test：定期測試候選節點，並根據測試結果選擇符合條件的低延遲節點。
• fallback：依候選順序檢查可用性，前面的節點無法使用時切換到後續節點。
• load-balance：按照設定策略將不同連線分配給多個節點，不等於將單一下載連線的頻寬簡單相加。

一個簡化的自動測試組可以依照以下結構組織。實際支援的欄位取決於所使用的核心版本，節點名稱必須與設定中的代理項目一致。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - HK-01
      - SG-01
      - JP-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval 控制測試間隔，過短會增加請求次數與資源消耗。tolerance 用於減少延遲差距很小時的頻繁切換。不同核心版本對切換條件與健康檢查欄位的實作可能存在差異，修改前應參考目前核心對應的設定說明。

自動選擇適合候選節點品質相近、地區用途一致的組。如果把不同地區、不同倍率與不同用途的節點全部放進同一個 url-test 組，最低延遲節點可能不符合地區要求，也可能帶來更高的流量成本。更合理的結構是先按地區或用途分組，再在組內自動測試，最上層使用 select 選擇「自動節點」、「特定地區」或「手動選擇」。

規則模式會根據網域、IP、程序或其他規則，將連線送入指定策略組。節點選擇只決定策略組最終使用哪個出口，不會改變規則由上到下比對、命中後停止的基本邏輯。發現某個網站沒有使用預期節點時，應同時檢查規則命中情況與策略組目前的選擇，而不是只更換節點。

TEST PROCESS

建立可重複的節點篩選流程

可靠的篩選應在相近的本地網路條件與相近時段完成。使用 Wi-Fi 測試時，先確認裝置訊號穩定，暫停背景大型檔案下載、雲端同步與系統更新。行動網路與固定寬頻的路由不同，在一個網路上表現最好的節點，切換網路後可能不再占優。

1. 更新訂閱：確保用戶端已載入目前設定，避免繼續測試已下線或參數已變更的節點。
2. 執行一次全組連通性測試：排除持續逾時、無法交握與不支援設定的節點。
3. 選擇少量候選：從目標地區保留三到五個延遲較低且波動較小的節點。
4. 重複測試：間隔數十秒測試多次，觀察中位延遲、最大值與逾時次數。
5. 進行實際任務驗證：開啟常用網頁、播放一段影片或進行短時間下載，觀察載入、吞吐與重新連線情況。
6. 檢查倍率與配額：體驗相近時，優先選擇流量成本合適的節點。
7. 保留備用節點：選擇不同伺服器或不同地區的候選節點，避免主要節點故障時重新從完整清單篩選。

測試結果最好按時段記錄。某個節點上午穩定、晚間明顯降速，通常表示尖峰時段負載或網路互連發生變化。只在凌晨完成一次測速，不能代表日常使用時段。對於工作用途，可以分別在上午、下午與晚間進行短測試，連續觀察一到兩天後再決定預設節點。

切換節點後，既有連線不一定會立即轉移到新節點。瀏覽器連線池、下載工作、影片工作階段與終端機長連線可能繼續使用原本的出口，直到連線關閉或逾時。驗證新節點時，應重新開啟測試頁面或重新啟動相關連線。若啟用了系統代理或 TUN，還要確認目標應用程式的流量確實進入 Clash；僅在用戶端介面選取節點，不代表所有應用程式都已使用該節點。

ERROR CHECK

常見誤判與處理方法

只選擇清單中延遲最低的節點

最低值可能來自一次偶然測試，也可能只反映測試網址的回應。應增加重複次數，並使用常用服務驗證。如果最低延遲節點經常中斷，穩定但稍慢的節點更適合作為預設出口。

測速失敗就認定訂閱失效

單一節點失敗與整份訂閱失效是兩回事。先觀察其他節點能否連線，再查看用戶端記錄中的 DNS、交握、逾時、協定不支援或網路無法連線等資訊。如果所有節點同時失敗，才需要進一步檢查訂閱更新、設定載入與本地代理狀態。

切換節點後仍無法存取

問題可能出在規則，而不是節點。檢查目前模式是規則、全域還是直連，確認目標連線命中了哪個策略組。DNS 快取、瀏覽器現有連線與目標服務本身故障，也可能造成切換後沒有立即恢復。可以先關閉原有連線，再使用另一個已確認可用的網站進行對照測試。

把 TUN 模式當成加速選項

TUN 模式用於接管更多不遵循系統代理設定的流量，對遊戲、命令列程式或特定應用程式的涵蓋可能更完整，但不會提高代理伺服器的頻寬。啟用後體驗有所變化，通常是因為流量路徑或 DNS 處理方式改變。出現異常時，應檢查 TUN 權限、路由、DNS 與應用程式相容性，而不是繼續提高測速頻率。

一次大型檔案測速消耗過多流量

大型檔案可以測試持續吞吐量，但不需要對每個節點執行。先透過小型請求篩選候選節點，再選擇兩到三個節點進行短時間實際下載。測試結束後及時停止工作，並結合用戶端流量統計與訂閱面板核對用量。