Clash 節點怎麼選？延遲、流量倍率、地區與協定取捨指南

先確認流量出口：節點選擇是否確實生效

挑選節點前，先確認目標連線確實經過正在調整的策略組。Clash 的規則模式會由上而下比對 rules；如果瀏覽器請求符合 DIRECT，更換代理節點也不會改變這條連線的路徑。串流影音規則也可能指向獨立的策略組，與首頁顯示的預設代理組無關。

1. 在用戶端的「設定檔」或「Profiles」中，確認目前啟用的訂閱設定檔，而不只是更新了另一份設定檔。
2. 在「代理」或「Proxies」中，找出規則實際使用的策略組，先手動選定一個節點。
3. 前往目標網站，再開啟「連線」或「Connections」，查看目標網域、符合的規則與流量出口。各用戶端的選單名稱可能不同，重點是確認這三個欄位。
4. 切換節點後，建立新的連線再測試。既有的 TCP 長連線通常不會自動切換，必要時先停止原本的工作，再重新連線。

評估延遲要看穩定度，別只挑最低的一次

用戶端顯示的延遲通常是透過節點連線至測試 URL 的探測結果，不等於裝置到節點伺服器的單純 ICMP 延遲，也不代表下載速度。測試網址、DNS、連線建立、協定交握、連線重用與核心實作都會影響結果。只有在相同網路、使用相同測試網址比較，兩個節點的數值才較有參考價值。

記錄五輪測試，篩選候選節點

先選出 3 個候選節點，每隔約 30 秒測試一輪，共測 5 輪。測試期間避免同時進行大型下載，並保留逾時結果，不要只記錄成功時的最低數值。以下是判斷方式的範例，並非本站對任何服務進行的實測。

以上例來說，日常瀏覽應優先測試 A，而不是只因為 B 曾出現 25 ms 就選擇 B。如果 C 符合目標服務的地區需求，也可能比不穩定的 B 更合適。探測逾時本身無法直接證明封包遺失率；若要判斷封包遺失，還需搭配網路診斷與實際連線狀況。

晚間尖峰時段再測一次實際工作

• 瀏覽：連續開啟 5 個常用網頁，觀察首次載入、圖片與指令碼是否一再等待。
• 影片：固定播放同一部影片與畫質，觀察 3 分鐘內的緩衝情況，別只看影片能否快速開始播放。
• 下載：使用同一個合法測試檔案，分別記錄開始後的短時間速度，以及持續 60 秒的表現；避免多項工作同時占用頻寬。

白天速度正常、晚間明顯下降，常見原因是線路或伺服器負載改變。更換協定未必能解決這類問題，建議先比較其他線路，並在平常使用的時段重新測試。

流量倍率：先估算用量，再比較速度

節點名稱中的「0.5 倍」、「1 倍」或「2 倍」，通常是訂閱服務的計費標示，並非 Clash 核心通用的限速參數。節點名稱標示「2 倍」，不代表用戶端會讓下載速度加倍。實際扣除流量的方式，請以服務商說明和帳戶用量紀錄為準；部分服務也會分別計算上傳、下載或特定時段的用量。

使用相同單位估算帳戶用量

假設服務以「計費流量 × 倍率」扣除用量，且單次工作計入 2 GiB：0.5 倍約扣 1 GiB，1 倍約扣 2 GiB，2 倍約扣 4 GiB。這只是計算範例；協定額外負載、上下載雙向計費，以及 GB 與 GiB 的單位差異，都可能讓帳戶紀錄與本機檔案大小不同。

• 瀏覽網頁與即時通訊：通常先看穩定度，倍率列為次要考量。
• 串流影音與大型檔案：先估算每月用量，再選擇能長時間滿足需求的低倍率節點。
• 臨時的重要工作：可使用倍率較高但更穩定的候選節點；工作結束後再切回日常使用的節點。

選擇地區：考量出口與目標服務，不只看地理距離

節點名稱中的地區可能代表出口位置，也可能只是服務商標示線路的名稱。入口伺服器、轉送線路與最終出口可能位於不同地點。裝置離某個地區較近，不代表連線至當地節點一定最快；電信業者互連、繞道與尖峰壅塞都可能影響結果。

日常網站與串流影音的判斷方式不同

日常瀏覽可先測試鄰近地區的穩定線路，再比較實際網頁載入狀況。串流影音則應先確認目標內容對帳戶地區、出口 IP、內容授權與服務條款的要求。出口 IP 被判定位於某個國家或地區，不代表當地所有內容都能播放。

1. 手動固定候選節點，確認目標網域符合預期的策略組。
2. 透過該出口檢查 IP 位址與所在地區，再前往服務本身的播放頁面進行驗證。
3. 固定畫質播放至少 3 分鐘，確認是否反覆緩衝、降低畫質或出現地區提示。
4. 如果網頁與播放結果不一致，請檢查媒體網域是否被其他規則分流，而不是立刻認定節點失效。

開發工作也要依目標服務進行驗證。程式碼代管平台、套件儲存庫與容器映像檔可能使用不同的 CDN；測試首頁載入很快，不代表下載相依套件也很快。對於需要穩定登入狀態的服務，盡量維持出口地區一致，避免自動選擇組頻繁切換不同地區。

協定取捨：先確認相容性，再檢查 UDP 與網路環境

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUIC 是不同的代理協定或方案名稱，並非速度等級。相同協定部署在不同線路上，使用體驗也可能差異很大。選擇前先確認用戶端搭載的核心支援該協定與相關參數；舊版 Clash 和 Clash Meta（mihomo）的支援範圍並不相同。

Hysteria2、TUIC 採用 QUIC，仰賴可用的 UDP 網路路徑；部分網路可能會限制 UDP，導致無法連線或連線不穩。常見採用 TCP 的代理傳輸方式也會受到壅塞與線路品質影響。協定名稱不能取代實際測試，也不適合直接用來排出一份通用的「最快協定」排行榜。

網頁正常，但語音或遊戲無法使用時，應檢查 UDP、TUN 接入方式與分流規則。如果用戶端提示不支援該代理類型，請先處理核心相容性問題，不要把關閉憑證驗證當成通用解法。訂閱中的驗證資訊、伺服器位址與傳輸參數都必須與伺服器端一致。

策略組設定：日常自動選擇，重要工作手動指定

url-test 適合根據測試結果從候選節點中自動選擇，但不會檢查流量倍率、影片授權或開發工作是否成功。把所有地區、所有倍率的節點混在同一個自動選擇組中，可能會選到探測延遲較低，卻不符合實際需求的節點。

mihomo 設定片段

以下僅展示 proxy-groups 片段。假設目前設定中的 proxies 已有名稱完全相符的 JP-A 與 SG-A 兩個節點；請替換成實際名稱後合併至現有設定，不要在同一份 YAML 中重複新增頂層 proxy-groups 欄位。

proxy-groups:
  - name: Daily
    type: select
    proxies:
      - Auto
      - JP-A
      - SG-A

  - name: Auto
    type: url-test
    proxies:
      - JP-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• type: select：手動選擇。日常使用可選擇 Auto；長時間下載或登入狀態敏感的工作，則可固定使用單一節點。
• interval: 300：自動探測間隔為 300 秒，不是訂閱更新間隔。
• tolerance: 50：切換容許差值，單位為毫秒，用於減少因小幅延遲差異而頻繁切換；並非限速值或逾時門檻。
• url：請選擇能穩定連線的輕量 HTTPS 測試網址。更換網址後，不宜直接比較更換前後的數值。

以上欄位依據 mihomo 常見設定說明，其他核心請參照各自的文件。規則也必須引用 Daily，才能影響目標流量；只有建立策略組並不會自動改變分流。可在策略組欄位說明確認設定結構，並在規則欄位說明檢查引用關係。

依使用情境收尾：保留主要與備用節點

最後保留一個主要節點，以及一個使用不同線路的備用節點即可。記錄測試日期、使用的網路、目標工作、倍率與結果；遇到問題時，先用相同工作切換備用線路重新測試。如果所有節點同時變慢，應優先檢查本機網路、接入模式、DNS 與目前的設定，而不是繼續增加候選節點。

選擇原則可簡化為以下步驟：先確認連線經過正確的策略組，再篩選穩定的節點；有地區需求時先確認服務是否可用，沒有地區限制再比較延遲；大量傳輸工作先計算倍率，最後才比較相容協定的差異。