代理節點怎麼選：延遲、倍率、地區與協定的評估指南

先確認用途，再看節點數據

Clash 節點清單中的延遲只是單次測試結果，並非綜合評分。節點是否適合目前的用途，還得看目標網站、持續傳輸速度、穩定度、出口地區與計費倍率。挑選時先排除無法連上目標服務的節點，再比較穩定性與成本，最後才用延遲區分條件相近的候選節點。

建議先留下三個候選節點：日常主用、不同線路的備用，以及確有需要時使用的特定地區出口。節點名稱中的「專線」、「原生」、「高速」等字眼是服務商的命名，不能取代實際測試，也不能單憑名稱確認線路架構。

• 瀏覽網頁與遠端操作：留意首次回應時間、連續操作是否卡頓，以及晚間尖峰時段的波動。
• 串流影片與大型檔案：留意持續下載速度、緩衝狀況與倍率；單次低延遲不足以證明傳輸效能。
• 地區限制服務：先確認服務如何判定出口 IP，再看速度。節點名稱標示的地區不一定等於服務實際判定的地區。
• 遊戲與即時語音：先確認應用程式流量確實經過代理，且節點支援所需的 UDP 轉送；一般網頁延遲不能取代遊戲內的測試數據。

延遲測試：確認測量目標、重複結果與實際連線

Clash 顯示的毫秒數代表什麼

常見的節點延遲測試，是透過指定代理存取測試 URL，測量核心實作所記錄的請求耗時，並非單純對節點伺服器執行 ICMP ping。測試網址、連線重用方式與核心實作各有差異，因此結果也可能不同。不同用戶端或測試網址的數值，不宜直接互相比較。

一次測出 80 ms，另一次測出 130 ms，只能表示前者在該次測試中較快。實際網站可能使用不同的出口路由，還會受到網域解析、TLS 握手與伺服器處理時間影響。測試 URL 能連線，也不代表所有目標網站都能存取。

固定測試條件重複測量，不要只挑最低值

1. 使用同一台裝置、同一個網路與同一個測試網址。暫停大型檔案下載，避免占滿本地頻寬。
2. 每個候選節點測 5 次，間隔約 10 秒，記錄中位數、最大值與逾時次數。
3. 分別在平常使用時段與晚間尖峰時段重測，例如 10:00 和 21:00。時間只是測試紀錄條件，不代表效能保證。
4. 開啟實際要使用的網站，連續重新整理或執行相同操作，確認頁面資源也能順利載入。

例如，節點 A 五次測試結果為 65、70、68、900 ms、逾時；節點 B 則為 115、120、118、125、122 ms。B 的中位數較高，但這組測試結果更穩定。以上數字僅為判讀範例，並非本站實測線路結果；少量樣本也無法用來推估長期可用率。

流量倍率：依帳單規則換算，倍率不等於速度

倍率通常表示服務商如何扣除方案流量，不是 Clash 核心的加速參數。以服務商按上下行總流量計費為例，實際傳輸總量為 5 GB，使用 2 倍率節點會扣除約 10 GB；使用 0.5 倍率節點則約扣除 2.5 GB。實際計費方式請以服務商帳單為準，不能只憑用戶端的連線統計判定扣費異常。

高倍率不保證低延遲，低倍率也不一定比較慢。若每天實際傳輸 4 GB，連續 30 天就是 120 GB；若全程使用 2 倍率節點，依上述規則會扣除約 240 GB。選擇前先估算每月用量，再確認方案額度是否足夠，別等到月中下載時才發現流量不夠。

測速本身也會消耗流量。以平均 80 Mbps 下載 30 秒，約會傳輸 300 MB，還不包含其他流量。沒必要把數十個節點逐一跑滿速測試；先用低流量的延遲測試縮小範圍，再挑兩三個候選節點短時間測試傳輸速度即可。

選擇地區：分清入口、出口與網站的判定結果

裝置連線的伺服器位址可視為入口的一部分，目標網站通常看到的則是出口 IP。中轉線路的入口與出口可能位於不同地區。節點名稱標示「日本」，不代表裝置與日本伺服器之間只有一段直連路徑，也不能只看連線位址就推斷最終出口。

地理距離近，不代表路由較短

地理距離會影響傳播延遲，但電信業者互連、繞道路由與網路壅塞也會左右連線表現。同一節點在家用寬頻、公司網路與手機熱點上，測試結果可能不同。更換網路後應重新確認主用節點，不要直接套用另一條寬頻的測試結果。

地區限制服務要直接在目標服務中確認

• 先連上候選節點，再確認前往目標服務的請求確實經過該節點，而不是被規則設為直連。
• 查看目標服務顯示的地區提示或可用內容。IP 查詢網站使用的資料庫可能與目標服務不同。
• 帳號註冊地區、付款資料、裝置定位與過往連線紀錄也可能納入判定；更換出口不保證結果會改變。
• 需要長期登入的服務，盡量維持出口穩定。頻繁切換地區可能觸發服務的額外驗證。

若只是瀏覽一般網頁，可以先測試路由表現較好的鄰近地區；只有業務明確要求特定出口地區時，才另外保留對應節點。地區選項多，不代表可用性一定更高。

協定取捨：先確認核心支援，再看目前網路狀況

Clash 是用戶端生態中常見的名稱，不同用戶端可能採用不同核心。Clash Meta（現多稱為 mihomo）支援的協定與舊版 Clash 並不完全相同。訂閱可以匯入，只表示設定已被接受到某個階段；實際節點類型、欄位與傳輸選項仍須由目前使用的核心支援。

若目前網路限制 UDP，依賴 UDP 的傳輸可能無法建立連線；同一份訂閱中的 TCP 類候選線路則可能正常。反過來說，在部分高延遲或封包遺失的環境中，設定合適的 QUIC 類傳輸也可能表現較好。應在同一網路環境下實測後再下結論，不能只按協定名稱排序。

不要為了「加速」而隨意停用憑證驗證。遇到憑證錯誤時，應檢查裝置時間、伺服器名稱與訂閱設定，必要時向服務商確認。協定連線成功與憑證驗證正確是兩回事；略過驗證並非通用的故障排除方式。

在 Clash 中確認：實際使用的是哪個節點

選好節點後仍然很慢，常見原因是目標請求並未經過所選策略群組。規則模式會依序比對規則，命中後交由對應策略處理；某些網域可能設為 DIRECT，也可能交由另一個自動選擇群組。請在用戶端的「連線」或記錄檢視畫面中，檢查目標網域、命中的規則與實際代理鏈；實際選單名稱依用戶端而異。

先手動指定節點，再比較自動策略

mihomo 的 select 群組適合手動固定候選節點；url-test 會依測試 URL 的結果選擇節點；fallback 則依候選順序選擇可用項目。自動測試反映的是測試網址的表現，不會自動判斷影片畫質、帳號地區或流量倍率。

以下是現有 mihomo 設定中的策略群組片段，引用訂閱中已存在的 proxy-provider，並非可獨立匯入的完整設定。測試群組每 300 秒探測一次；保留手動選擇群組，方便以相同節點重複比較。

proxy-groups:
  - name: 日常手動選擇
    type: select
    use:
      - provider-main

  - name: 延遲候選
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

provider-main 必須替換成設定中實際存在的提供者名稱。測試 URL 僅用於連線探測，不能代表目標服務的實際狀況。修改前請先備份設定，避免訂閱更新覆蓋本機修改；提供者與規則的寫法請參閱YAML 手冊。

切換節點後，使用新連線重新測試

1. 固定使用一個候選節點，開啟目標網站，記錄載入或下載狀況。
2. 切換到另一個候選節點後，重新送出請求。既有的長連線可能仍沿用原本的代理鏈。
3. 必要時只關閉該應用程式的舊連線，避免中斷其他下載或會議。
4. 使用相同檔案、在相近時段進行比較，並記錄是否卡頓，不要只記下最高速度。

最後篩選：記錄主用、備用與用途

比較完成後，將結果整理成一行紀錄：網路環境、測試時間、節點名稱、實際出口地區、倍率、延遲中位數、逾時次數與實際使用表現。不必長期保存每一次測試數值，但應記下選擇原因，方便訂閱更新或網路狀況改變後重新檢查。

• 主用節點：目標服務可正常使用，常用時段穩定，倍率也符合日常用量。
• 備用節點：盡量選擇不同入口或不同線路。只有名稱不同的兩個節點，不一定能在故障時互相備援。
• 特定用途節點：確實需要對應地區或協定功能時才啟用，不必承載所有流量。
• 重新檢查時機：更換寬頻、更新用戶端核心、訂閱內容調整或持續發生逾時後，依相同條件重新測試。

實用的判斷順序是：服務能否使用 → 連線是否穩定 → 倍率能否接受 → 延遲與傳輸速度是否合適。把這四個條件分開評估，通常比反覆點選「最低延遲」更容易找到適合目前網路的節點。