Shadowrocket 延遲測試怎麼看？依地區與協定挑選現有節點

一、延遲數值測量的是什麼

延遲通常以 ms（毫秒）顯示，但數值代表什麼，取決於測試方式。對伺服器進行 TCP 連線測試，主要反映連上該位址與連接埠所需的時間；透過代理存取 HTTP 或 HTTPS 測試目標，則還包含代理交涉、連線至目標及等待回應的時間。兩種測量涵蓋的路徑不同，不能把結果當成同一種指標排序。

比較節點前，先確認 App 中目前使用的測試方式與測試目標。若測試只涵蓋伺服器連接埠，數值較低只能表示這一段回應較快，不能證明目標網站已可正常存取。即使測試是透過代理存取指定目標，也只反映該目標當下的表現，不能代表所有網站或所有時段。

測試逾時也不代表節點一定失效。測試目標無法連線、解析失敗、伺服器連接埠受限或協定交握失敗，都可能導致測試無法完成。應分別確認「連接埠是否可連線」、「代理是否能建立」及「目標是否能傳回內容」，避免用一個紅色結果概括所有故障。

二、先固定條件，再測試現有訂閱

比較前先更新一次訂閱，並記錄目前的網路環境。更新可能變更位址、連接埠或節點清單；若部分結果來自更新前、部分來自更新後，就不是在比較同一組設定。訂閱連結屬於存取憑證，不應放進截圖、公開筆記或求助內容。

1. 確認訂閱

   在 Home（首頁）找到自己的訂閱群組。首次匯入時，可依序選擇 Home →「+」→ Type（類型）→ Subscribe（訂閱），填入自己已有的連結並儲存；已匯入的內容不必重複新增。

2. 完成更新

   在 Home 更新現有訂閱，並確認清單已重新整理。若更新失敗，先處理連結存取或憑證問題，不要把舊清單的測試結果當成最新狀態。

3. 固定測試環境

   選定同一個 Wi-Fi 或行動網路，並暫停進行中的大量資料傳輸。前往 Settings（設定）→ On Demand（隨選連線）確認自動連線條件，避免測試期間因網路切換而改變連線狀態。

4. 重複測量

   在 Home 對候選節點執行延遲測試，並保持測試方式與目標一致。每個項目間隔片刻測試三次，同時記錄逾時情形；批次結果用於初步篩選，少數候選節點再個別複測。

5. 實際驗證

   選取候選節點並連線，確認 Global Routing（全域路由）採用的模式，再開啟相同的目標頁面。分別觀察首次顯示、連續瀏覽及較長請求是否正常。

測試三次並非統計上的保證，只是比單次讀數更容易看出偶發波動。例如某項結果為 48 / 51 / 49 ms，另一項為 25 / 逾時 / 180 ms，前者較值得進一步驗證。這些數字僅供說明如何判讀，不是任何節點的實測資料，也不是合格門檻。

三、依地區篩選：名稱只能作為線索

地區篩選應以實際需求為依據。若目標內容要求特定地區的出口，先確認出口地區，再比較同一組候選節點；若沒有地區限制，則優先比較穩定性與實際存取情形。節點名稱中的地區、旗幟或縮寫由訂閱內容提供，不能單憑這些資訊證明伺服器位置或最終出口位置。

同一地區的兩個節點也可能使用不同入口、中繼路徑或出口。反過來，名稱標示不同地區的節點也可能共用部分路徑。因此，「距離近就一定快」和「地區相同就有相同表現」都不適合作為操作依據。應記錄具體節點、使用的網路與測試時間，而不只是地區名稱。

四、依協定類型篩選：先確認連線條件

Shadowrocket 中的現有節點可能使用 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard。協定名稱說明連線機制，不代表延遲或頻寬排名。同一種協定在不同伺服器、連接埠與網路路徑上的表現可能差異很大；不要為了追求某個協定名稱而修改現有訂閱參數。

以 Hysteria2 為例，它以 QUIC 為基礎運作；若目前網路限制 UDP，改用同一地區、名稱不同的同類節點未必能解決問題。WireGuard 同樣依賴 UDP，但其交握與通道機制不同，也不能用 TCP 建立連線所需時間來解讀連線狀態。至於 VMess 或 VLESS，只比較 Type 仍不夠，還需考量傳輸方式與伺服器設定。

• 比較同一地區的不同協定時，盡量選擇測試時段相近、目標相同的候選節點，以減少環境變化。
• 協定連線失敗時，先確認訂閱更新、位址、連接埠與驗證參數；不要為了讓連線成功而降低驗證要求。
• 若某類連線只在一個 Wi-Fi 網路下失敗、在行動網路下正常，優先檢查該網路的傳輸限制。
• 不要批次手動修改訂閱節點的連接埠、TLS 或傳輸參數；這些設定需要伺服器端配合。

五、延遲低卻無法開啟網頁：檢查 Global Routing 與規則

延遲測試通過，不代表瀏覽請求一定使用剛才測試的節點。Home → Global Routing 中的 Proxy（代理）、Direct（直連）、Config（設定檔）與 Scene（情境）會決定路由方式。日常使用可依現有 Config 分流；排查問題時，則應確認請求實際經過哪條路徑。

Scene 用於情境化路由，實際行為取決於現有情境設定，不能只看名稱判斷目前使用哪條路徑。若測試前已啟用 Scene，應先確認對應設定，或清楚記錄原設定後，再切換至適合排查的模式。

• 在 Config（設定檔）確認目前啟用的設定檔，而不是只查看未啟用的檔案。
• DOMAIN-SUFFIX 依網域後綴比對；GEOIP 依 IP 地理資料比對；IP-CIDR 依 IP 網段比對。
• FINAL 是前面的規則都未符合時的最終去向；規則順序及其引用的策略都會影響結果。
• 搭配連線記錄確認目標、命中的規則及流向。若目標被分流至 DIRECT，就不能用這次的頁面表現評估代理節點。

六、透過實際請求區分「回應快」與「傳輸穩」

低延遲主要有利於頻繁的小型請求，但持續傳輸還會受到可用頻寬、封包遺失、壅塞及目標伺服器負載影響。某個節點可能很快完成交握，傳輸內容時卻反覆等待；另一個節點初始回應稍慢，後續請求卻能穩定完成。應依實際用途分別觀察，不要把兩種表現合併成單一數值。

瀏覽器快取與連線重複使用也會影響實際體感。第二次開啟同一頁面時變快，可能是命中快取，不代表節點有所改善。比較時盡量使用相同內容與相近的請求條件；不要一邊播放影片或同步大量檔案，一邊根據延遲變化判斷節點優劣。測試本身會產生網路流量，也應將現有服務的流量限制納入考量。

七、保留可重現的挑選結果

最後保留的應是「在特定網路與用途下驗證過的選項」，而非永久排名。訂閱更新、伺服器調整及本地網路變化，都可能使舊結論失效。不必頻繁測試整份清單；發生異常、切換網路或訂閱變更後，只要重新確認少數常用候選節點即可。

1. 記錄條件：記下 Wi-Fi 或行動網路、測試方式、目標及測試時間，不要公開訂閱憑證。
2. 記錄候選項目：保留節點名稱、地區標籤、Type 與更新狀態，避免混淆名稱相近的項目。
3. 記錄結果：分別記下延遲、逾時次數及實際請求表現，不要只截取最低數值。
4. 記錄路由：註明 Global Routing 模式及實際命中的策略，確保下次可以重複驗證。
5. 保留備用選項：從自己現有的內容中保留一個測試過的替代選項，切換後重新確認存取結果。