Clash 用戶端的節點清單中，經常同時出現地區、線路、倍率、協定與專線等標記。若只按照延遲數字由低到高選擇，通常只能得到單次測試中的最快回應，無法直接判斷網頁載入、影片緩衝、檔案傳輸或長連線是否穩定。選擇節點應拆分成多項指標：先確認節點能夠連線，再判斷前往目標服務的路徑是否合適，最後結合流量計費與持續穩定性作出選擇。

本文所說的「節點」，是設定檔中提供代理群組使用的代理伺服器項目。Clash、Clash Meta 或 mihomo 會依照規則將連線交給相應節點，但用戶端無法改變節點上游線路的壅塞程度，也不能從單一延遲數字推導出完整的網路品質。正確做法是建立一套可重複的篩選順序，而不是在數十個節點之間頻繁隨機切換。

LATENCY TEST

延遲數字代表什麼

用戶端顯示的延遲通常來自一次 HTTP 探測。Clash 會向測試網址發起連線，請求成功後記錄耗時。常見測試網址會回傳很小的空回應，因此這個結果主要反映 DNS 解析、與節點建立連線、代理握手，以及存取測試網址所需的時間。不同用戶端可能使用不同的測試 URL、逾時值與測試方法，因此兩個用戶端顯示的數字不一定完全一致。

延遲 80 毫秒，不代表節點能以固定速度下載資料。吞吐量還會受到節點出口頻寬、跨境鏈路壅塞、伺服器負載、電信商路由、TCP 壅塞控制與目標網站限速影響。一個延遲 120 毫秒但線路穩定的節點，實際體驗可能優於延遲在 50 至 300 毫秒間持續波動的節點。

看中位表現，不看單次最低值

連續測試三至五次，比單次測試更具參考價值。如果結果分別為 72、75、78、74 毫秒，表示路徑相對穩定；若結果為 65、230、逾時、91、410 毫秒，即使最低值較小，也應先將該節點標記為不穩定。實際使用時的卡頓通常與延遲抖動和封包遺失有關，而不是最低延遲不夠低。

  • 低延遲且波動小：適合互動頻繁的網頁、遠端終端機、即時通訊與即時應用程式。
  • 延遲中等但吞吐穩定：適合影片、系統更新與較大的檔案傳輸。
  • 延遲忽高忽低：可能存在壅塞、封包遺失、節點過載或本地無線網路干擾。
  • 測試逾時：可能是節點離線，也可能是測試網址無法連線、協定不相容或連線逾時設定過短。

先排除本地網路波動

如果所有節點同時出現高延遲，應先關閉代理測試本地網路。可以檢查路由器負載、Wi-Fi 訊號、行動網路切換與 DNS 回應。多個節點同時惡化時，通常不應先歸因於某一個遠端節點。使用有線網路或穩定的 5 GHz、6 GHz 無線連線重新測試，可以減少本地鏈路對判斷造成的干擾。

REGION ROUTING

節點地區應與目標服務相符

節點名稱中的香港、日本、新加坡、美國等地區，通常代表伺服器出口位置，但名稱本身無法描述完整線路。用戶端到節點是一段路徑，節點到目標服務又是另一段路徑。選擇地區時需要同時考量這兩段連線，而不是單純選擇地理距離最近的國家或地區。

存取部署在亞洲的服務時，香港、日本、新加坡等節點往往具有較短路徑；存取主要部署於北美的服務時，美國西部節點可能在目標網站一側更直接。實際結果仍取決於服務使用的 CDN、節點營運商互聯，以及本地網路出口。同一地區的兩個節點也可能經由完全不同的骨幹網路，因此應以測試結果為準。

地區選擇的實用順序

  1. 先確認目標服務是否有地區限制、帳號地區要求或內容區域差異。
  2. 在符合目標地區要求的節點中，篩選能夠穩定連線的項目。
  3. 比較連續延遲、頁面首屏時間、影片開始播放時間或下載速度。
  4. 保留一個不同地區的備用節點，避免單一區域發生線路故障。

需要維持登入狀態的服務，不宜頻繁跨地區切換。出口位址在短時間內從亞洲切換到歐洲或北美，可能觸發服務本身的安全驗證。此時應在同一地區內選擇主要節點與備用節點，既保留故障切換能力，也能減少出口區域大幅變動。

節點名稱中的「家用寬頻」「資料中心」「專線」「中轉」等標籤由設定提供者定義，並不是 Clash 對線路類型的驗證結果。標籤可作為初步分類依據，但最終仍應觀察出口屬性、目標網站可達性，以及一段時間內的穩定表現。

TRAFFIC RATE

倍率影響流量消耗，不代表速度等級

倍率通常由訂閱服務的計費規則定義。例如使用 1 GB 的實際傳輸流量，1 倍率節點可能扣除 1 GB 配額，2 倍率節點可能扣除 2 GB，0.5 倍率節點可能扣除 0.5 GB。具體統計方式應以訂閱提供者的說明為準。倍率欄位不屬於 Clash 的統一效能指標，用戶端也不會因為倍率較高而自動提供更多頻寬。

高倍率節點有時對應成本較高的線路，但不能直接推導出「倍率越高越快」。尖峰時段的負載、節點總頻寬與本地電信商路由仍會改變結果。選擇時應將倍率視為成本條件，將延遲、抖動、吞吐量與可達性視為品質條件，分開判斷。

依任務分配倍率

  • 網頁與文字通訊：流量較小，可優先考量低延遲與穩定連線。
  • 高畫質影片與大型檔案：流量消耗明顯，應比較低倍率節點的持續速度。
  • 遠端控制與終端機連線：更依賴抖動與封包遺失，高頻寬並非首要條件。
  • 臨時緊急連線：可保留品質較高的備用線路，主要節點故障時再手動切換。

若方案流量有限，可以建立兩層策略：日常規則群組使用低倍率的穩定節點，關鍵服務則單獨使用經過驗證的節點。這樣比將所有連線長期放在高倍率線路上，更容易控制流量消耗。策略群組只負責選擇代理項目，流量扣除仍由遠端服務端統計。

PROTOCOL COMPATIBILITY

選擇協定前，先看核心相容性與網路環境

訂閱中可能出現 Shadowsocks、Trojan、VMess、VLESS、Hysteria2、TUIC 等協定。協定名稱描述連線與傳輸方式，但不能脫離伺服器設定、核心實作與目前網路環境單獨比較。傳統 Clash 與 Clash Meta、mihomo 支援的協定和欄位範圍並不完全相同，匯入前應確認用戶端實際使用的核心版本。

如果設定包含目前核心不認識的協定類型或參數，常見結果是設定解析失敗、節點不顯示，或連線時直接報錯。這類問題不是切換策略群組可以解決的，應先升級至相容核心，或使用訂閱提供者提供的相容設定。同一協定也可能使用不同的傳輸層、TLS、SNI、指紋或 UDP 參數，不能只憑節點名稱判斷設定是否等價。

TCP、UDP 與網路限制

部分協定主要基於 TCP，部分協定會使用 UDP 或 QUIC。UDP 型傳輸在合適線路上可以有較好的抗封包遺失表現，但企業網路、校園網路、公共 Wi-Fi 或部分電信商鏈路可能限制 UDP。若某類節點在家用網路正常、在辦公網路持續逾時，應檢查目前網路是否允許對應傳輸，而不是直接判定伺服器離線。

即時語音、線上遊戲與部分 DNS 處理需要 UDP 轉發。節點項目、協定實作、策略群組與運作模式都需要支援相應流量。啟用 TUN 模式後，更多系統流量會進入核心處理，但 TUN 本身不會補足節點缺少的 UDP 能力，也不會提高遠端線路頻寬。

協定不是速度排名

無法建立固定的「某種協定一定最快」排名。協定開銷、握手方式與壅塞控制確實會影響表現，但伺服器負載與線路品質通常同樣重要。更可靠的判斷方式是：先確認目前用戶端能正確解析並連線，再在相同網路、相近地區與相近時段比較實際任務表現。

STABILITY CHECK

透過持續測試確認實際可用性

完成延遲、地區、倍率與協定的初步篩選後，應將候選節點放入實際使用情境中驗證。建議每個候選節點至少觀察十至三十分鐘，並涵蓋網頁、多媒體或工作連線中的主要任務。只執行一次測速，很容易將短時間的閒置狀態誤判為長期穩定。

四項穩定性檢查

  1. 建立連線：連續開啟多個新頁面，觀察是否頻繁停留在連線階段。
  2. 持續傳輸：播放一段較高位元率的影片或下載一個大小適中的檔案，觀察速度是否週期性歸零。
  3. 長連線：讓即時通訊、遠端終端機或網頁應用程式保持上線，檢查是否反覆斷線。
  4. 尖峰時段複測：在平時最常使用的晚間或工作時段重新測試，避免只記錄低負載時段的結果。

穩定節點通常不是所有指標中的絕對第一名，而是在不同時段維持相近的表現。可以記錄三個候選節點的測試時間、延遲範圍、目標服務、倍率與異常情況。持續記錄幾天後，這些資料比節點名稱中的線路標籤更具參考價值。

區分節點問題與規則問題

切換節點後，目標網站仍然走 DIRECT，表示問題可能出在規則匹配，而不是節點品質。應查看用戶端連線記錄，確認請求命中了哪條規則、被交給哪個策略群組，以及策略群組目前實際選用了哪個節點。規則會按照設定宣告順序匹配，前面的規則可能先於後面的地區或網域規則生效。

若瀏覽器可以存取、其他應用程式卻無法連線，應檢查系統代理的涵蓋範圍。系統代理主要處理遵循代理設定的應用程式；TUN 模式可以接管更多網路流量，但需要相應的系統權限。此時更換節點可能暫時改變現象，卻無法解決流量沒有進入 Clash 的根本問題。

DNS 異常也可能偽裝成節點故障。網域無法開啟、但直接存取已知位址正常時，應查看 DNS 模式、nameserver 設定與日誌。Fake-IP 模式由核心維護網域與保留位址的映射，部分應用程式若對回傳位址有特殊檢查，可能需要加入相容規則。節點延遲正常，並不能證明 DNS 解析鏈路正常。

POLICY GROUPS

將節點篩選結果放入合適的策略群組

手動選擇適合需要固定出口或明確控制的情境；自動延遲選擇適合從一組用途相同的節點中挑選目前回應較快的項目；故障轉移適合優先使用主要節點，並在探測失敗後切換至備用節點。不同策略群組解決的問題不同，不應將所有節點放進一個自動群組後，期待它同時處理地區、倍率與服務相容性。

mihomo 設定中常見的 url-test 會依指定網址與間隔測試節點，並選擇符合條件的低延遲結果。fallback 更強調按照清單順序選取可用節點。實際支援的欄位取決於核心版本，修改設定前應保留可還原的副本。

proxy-groups:
  - name: 日常選擇
    type: select
    proxies:
      - 亞洲自動
      - 主要節點
      - 備用節點

  - name: 亞洲自動
    type: url-test
    proxies:
      - 香港-01
      - 日本-01
      - 新加坡-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

上例中的測試網址僅用於說明結構，應選擇在目前網路與節點出口下長期可達、回應穩定的輕量網址。interval 控制重新測試的間隔，過短會增加請求與日誌雜訊；tolerance 用於減少延遲接近時的頻繁切換。自動群組仍然只依據測試機制作出決定，不會理解倍率、帳號地區或某項服務的登入狀態。

建議的節點分層方法

  • 依地區建立候選群組，例如亞洲、北美與歐洲，不要將用途差異過大的節點混在一起。
  • 依流量成本區分日常群組與高品質備用群組。
  • 為要求固定地區的服務建立獨立策略群組，並透過規則指向該群組。
  • 每個關鍵群組至少保留兩個不同伺服器或不同線路的節點。
  • 定期清理持續逾時、協定失效或名稱已變更的舊項目。

如果訂閱更新後節點名稱發生變化，手動寫入策略群組中的舊名稱可能會失效。較適合長期維護的方式，是使用用戶端支援的代理集合、篩選條件或設定覆寫功能，但具體語法取決於用戶端與核心。修改後應執行設定檢查，並在日誌中確認策略群組已成功載入。

SELECTION CHECKLIST

Clash 節點選擇檢查清單

  1. 確認訂閱已正常更新，且節點協定與目前的 Clash Meta 或 mihomo 核心相容。
  2. 在穩定的本地網路下連續測試多次，排除單次最低延遲造成的誤判。
  3. 依目標服務選擇地區，維持登入狀態時避免頻繁跨區域切換。
  4. 將倍率視為流量成本，不要直接把倍率當成速度或線路等級。
  5. 檢查目標任務是否依賴 UDP、TUN 模式或特定 DNS 處理方式。
  6. 透過網頁、影片、下載或長連線驗證實際表現，並涵蓋平時常用的尖峰時段。
  7. 查看連線日誌，確認規則命中、策略群組選擇與實際節點三者一致。
  8. 保留同地區的備用節點，並透過手動選擇、自動測試或故障轉移群組進行管理。

最終選擇應服務於具體任務：互動操作關注延遲與抖動，持續傳輸關注吞吐量與穩定性，地區服務關注出口位置，流量有限時關注倍率。將這些條件分開判斷，再透過策略群組組合，能比單純選擇延遲最低的節點獲得更穩定、也更容易解釋的結果。