代理節點怎麼選？從延遲、流量倍率、地區與傳輸協定判斷

先確認是否可用，再比較延遲與成本

挑選節點時，依序確認目標服務能否連線、連線是否穩定、流量費用是否可接受，最後才比較延遲。Clash 節點清單中的毫秒數只代表某次測試結果，不能直接反映下載速度、出口地區或服務可用性。日常瀏覽、播放影片與遠端終端連線，對網路的需求也各不相同。

開始比較前，先確認用戶端使用的核心。原版 Clash 與 Clash Meta（現名 mihomo）支援的協定不盡相同；訂閱中若有 Hysteria2 或使用 REALITY 參數的 VLESS 節點，須搭配支援相應協定的核心。節點匯入失敗可能是相容性或設定問題，不宜直接判定為線路品質不佳。

1. 確認用途：瀏覽網頁要看首屏載入與請求回應；播放影片要看持續傳輸量；SSH 等互動連線則要留意延遲波動與斷線情形。
2. 固定測試條件：使用同一台裝置及同一個 Wi-Fi 或有線網路進行比較，並暫停雲端硬碟同步與背景更新。
3. 確認路由：確認目標請求確實經過正在比較的節點，而非被 DIRECT 規則直連，或改由其他策略組處理。
4. 保留備用節點：除了主要使用的節點，也要準備一個不同線路或不同伺服器的備用節點，避免兩個名稱不同的節點實際上共用同一個故障點。

一、延遲測試：確認測試網址、重複結果與實際請求

毫秒數不等於下載速度，也不等於 ICMP ping

mihomo 的 URL 測試會透過指定代理連線至測試網址，並取得一次 HTTP 探測所需的時間。結果會受到用戶端至節點的連線、代理交握、節點至測試站的連線，以及測試端點回應速度影響。新建連線與重複使用連線的結果也可能不同，因此不能把節點清單中的數值直接視為純粹的網路往返延遲。

例如，測試網址使用 https://www.gstatic.com/generate_204，反映的是該節點連線至這個端點的狀況。測試成功不代表其他網站、影音服務或 API 也能正常使用。測試逾時也不一定表示節點完全離線；測試站受到限制、解析異常或短暫壅塞，都可能造成失敗。

• 比較節點時，請使用相同的測試網址，並維持一致的逾時設定。
• 每個節點連續測試 5 次，記錄成功次數、常見耗時與最長耗時，不要只看最低值。
• 平日白天與晚間各測一輪；只在低負載時表現良好的節點，不一定適合晚上播放影片。
• 如果介面顯示 timeout，先透過該節點連線至實際使用的目標，再判斷是測試端點問題還是線路問題。

例如，某節點測試 5 次的結果為 80、82、85、83、900 毫秒，另一個節點則為 110、112、109、115、111 毫秒。前者的最低值較低，但有一次明顯的延遲尖峰。互動式連線應繼續觀察尖峰是否反覆發生，而不是立刻依照 80 毫秒的結果排序。

使用 curl 確認請求經過哪個本機連接埠

以下指令會明確連線至本機 HTTP 代理 127.0.0.1:7890。使用前，請確認用戶端確實在該位址提供 HTTP 或 mixed-port 服務；若連接埠不是 7890，請依目前設定修改。在 Rule 模式下，明確使用本機代理仍會套用規則，必須到用戶端的連線清單確認最後使用的出口策略。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

以下是 macOS、Linux 的指令寫法。Windows 請使用 curl.exe，並將 /dev/null 改為 NUL，其餘參數不變。測試網址正常回應時通常會傳回 HTTP 204；time_starttransfer 是收到第一個位元組前的總時間，time_total 則是整個請求耗時，兩者都不是單獨的「節點 ping」。

HTTP 204 回應內容很少，適合確認請求能否完成，不適合測量傳輸速度。測試下載速度時，請使用來源可信、檔案大小已知且允許測試的檔案，並固定檔案與測試時間。也要統一單位：1 MB/s 約等於 8 Mbps，不能直接比較不同單位的數值。

二、流量倍率：先計算扣除流量，再決定用途

流量倍率是服務商的計費規則，不是協定參數，也不代表速度倍增。標示為 2 倍的節點，不代表速度是一般節點的兩倍。常見計算方式是「計費流量 × 倍率」，但上傳是否計費、GB 與 GiB 的定義，以及是否按時段調整，都應以服務商說明為準。

將剩餘額度換算為可用流量

假設剩餘方案額度為 60 GB，使用 2 倍節點時，依照上述計費方式，約可傳輸 30 GB 的計費流量。若改用 0.5 倍節點，則約可傳輸 120 GB。這項換算可用來估算成本，但不會影響方案到期日、速度限制或其他服務條款。

• 瀏覽網頁與傳訊：通常更重視回應速度與穩定性，可靠的線路即使倍率較高也可能值得使用。
• 播放影片與下載大型檔案：先確認倍率，再進行長時間傳輸測試；測速本身也可能消耗流量額度。
• 背景備份：確認是否需要經過代理，避免規則將大量上傳流量導向高倍率線路。

三、選擇地區：分清節點入口、出口 IP 與目標服務

應依目標服務的需求選擇地區，而非只挑地圖上最近的位置。訂閱名稱中的「日本」可能代表出口地區，不表示用戶端直接連線的伺服器也位於日本；中轉線路可能先連至本地入口，再轉往海外出口。地理距離較近的節點，也可能因電信業者路由繞道而比更遠的節點慢。

先確認目標服務實際看到的出口

1. 在目前的策略組中選擇待測節點，開啟目標網站並建立新連線。
2. 在用戶端的連線清單中查看該請求套用的規則與代理鏈，確認沒有改走其他策略。
3. 透過可信任的 IP 查詢網站核對出口 IP 位址與地區，再確認目標服務是否如預期提供內容。
4. 如果既有的長連線仍使用舊出口，請關閉相關應用程式後重新開啟；部分用戶端也提供關閉既有連線的功能。

IP 資料庫與目標服務判定地區的方式可能不同。查詢網站顯示日本，不代表所有影音串流、付款或帳戶系統都會將出口判定為日本。服務可能同時參考帳戶地區、付款資訊、裝置位置、過往登入紀錄與 IP 風險紀錄。單純更換國家，無法保證解除存取限制。

依用途保留不同地區的節點

• 遠端工作：優先遵守組織的連線政策，盡量維持出口穩定，避免頻繁切換地區登入而觸發驗證。
• 地區限定內容：直接測試目標服務所需的內容，不要只確認首頁能否開啟。
• 一般瀏覽：在可用節點中比較尖峰時段的表現，地區名稱僅供輔助判斷。
• 遊戲：先確認遊戲流量是否確實經過代理，以及節點與規則是否支援所需的 UDP；瀏覽器能開啟網頁，不代表遊戲連線也能正常使用。

如果瀏覽器與命令列顯示不同的出口，請先檢查瀏覽器代理擴充功能、系統代理、TUN 路由，以及應用程式本身的代理設定。確認路由前不要反覆更換節點，否則比較到的是不同的流量路徑，而非節點本身。

四、傳輸協定：如何選擇 Trojan、VLESS 與 Hysteria2

協定會影響連線的建立與傳輸方式，但無法取代線路品質。相同協定可能部署於完全不同的伺服器與網路；同一台伺服器也可能提供多種協定入口。應先確認用戶端相容性，再於自己的網路環境測試連線成功率、持續傳輸量與斷線後的恢復情形。

Trojan 與 VLESS：別只看協定名稱

Trojan 節點常見的組合是 TCP 與 TLS。VLESS 則還需確認安全層和傳輸設定；REALITY 是安全層方案，不是「傳輸速度等級」。WebSocket、gRPC 等傳輸方式也會改變連線特性。只憑「VLESS 比 Trojan 新」，無法判斷它在目前的網路環境下會比較快。

匯入後若出現 TLS 或交握錯誤，請檢查系統時間、伺服器位址、連接埠、SNI、驗證資訊，以及訂閱內容是否完整。使用 REALITY 時，相關參數也須符合伺服器要求。不要為了消除錯誤而直接關閉憑證驗證；應先排除位址、憑證或參數不符的問題。

Hysteria2：先確認 UDP 可連線，再測試傳輸量

Hysteria2 在某些高延遲或容易遺失封包的網路中，可能有較好的傳輸表現，但實際結果取決於網路與伺服器設定。如果校園網路、企業網路或公共 Wi-Fi 限制 UDP，可能發生 TCP 類型的節點可用、Hysteria2 卻無法連線的情況。此時可換個網路重新測試，並保留可用的 TCP 類型節點。

頻寬參數並非越大越好。設定頻寬時，應依實際連線能力與伺服器限制調整；數值過高可能加劇網路壅塞。請先保留服務商提供的有效設定，只有在了解相關壅塞控制參數後才進行調整，不要套用與自身線路無關的「高速參數」。

將四項條件化為可重複的篩選流程

第一次篩選不必讓訂閱中的所有節點逐一跑滿頻寬。先用少數候選節點完成基本檢查，再針對常用服務測試。以下流程適用於手動挑選節點，也適合用來確認自動選擇策略組是否符合需求。

1. 挑出 3 個候選節點：符合目標地區需求、倍率可接受，且核心能辨識；盡量涵蓋不同線路。
2. 確認規則：查看目標請求套用的規則與出口。若要暫時使用 Global 模式進行比較，測試結束後請切回原本的 Rule 模式。
3. 重複測試小型請求：使用同一個測試網址，讓每個節點測試 5 次，並記錄失敗次數與波動情形。
4. 測試實際用途：開啟常用網頁、播放同一段影片，或維持一段遠端終端連線，觀察實際中斷與重新連線的情況。
5. 補測尖峰時段：至少在平常最常使用的時段重測一輪，不要把白天的結果當成全天的結論。
6. 保留主要與備用節點：主要節點須符合穩定性與成本需求；備用節點則須能在主要節點故障時完成相同任務。

自動選擇組不等於最適合目標服務

mihomo 的 url-test 群組會依設定的測試網址、測試間隔與容差等條件選擇節點。它只會依探測結果進行選擇，不會自動判斷影音串流的地區需求、流量倍率或帳戶登入習慣。若將不同倍率、不同地區的節點放進同一群組，出口與費用可能隨自動切換而改變。

較穩妥的做法是先依用途篩選候選節點，再讓自動選擇組在候選節點中比較。例如，為特定地區的服務保留同一地區的節點，為大量傳輸任務保留計費方式可接受的節點。設定欄位說明請參閱站內進階設定；首次匯入與代理模式的操作方式請參閱使用教學。

最後不必建立複雜的評分表，只要記錄網路環境、測試時間、目標服務、成功次數、波動情況與倍率即可。能在常用時段穩定完成任務，且費用容易預估的節點，比偶爾測出最低延遲的節點更適合日常使用。

技術文件與查證連結

不同用戶端的按鈕名稱可能不同，協定支援與測試行為應優先查閱所用核心的文件。以下資料可用來確認 URL 測試欄位、代理協定設定及 Hysteria2 頻寬設定，不代表任何節點品質獲得背書。

• mihomo 文件：自動選擇群組 url-test，可查閱測試網址、間隔與容差設定。
• mihomo 文件：出站代理，可查閱 Trojan、VLESS、Hysteria2 的欄位與支援情況。
• Hysteria 2 文件：完整用戶端設定，了解 QUIC 與頻寬相關設定；原生用戶端的設定格式不能直接貼入 mihomo YAML。