本文適用於已在 Shadowrocket（小火箭）中匯入自有服務提供者設定的使用者。先釐清延遲、吞吐量與穩定性的差異，再固定網路、測試方式與路由模式，最後比較現有連線設定的地區與協定。選擇時應以實際目標 App 是否可用及多次測試結果為依據，而不是只看列表中最低的數字；本文不提供、不販售，也不推薦任何節點或訂閱。
一、延遲數字測量的是哪一段連線
延遲通常以毫秒（ms）顯示，代表完成某種探測所需的時間。它描述的是一次短暫互動，並非每秒可傳輸多少資料。解讀 Shadowrocket 的測試結果時，必須考量採用的測試方式：同一筆連線設定，在不同測試方式、測試目標或目前網路環境下，可能得到不同數字，不能把所有結果直接放進同一份排名。
例如，TCP 探測主要反映與指定伺服器連接埠建立 TCP 連線所需的時間。連接埠能建立連線，不代表協定驗證成功，更不代表遠端能正常存取目標網站。透過代理發出的 HTTP 探測涵蓋範圍較廣，但耗時也會受到測試網址、DNS、TLS 交握及回應方式影響。不要只看測試項目名稱，就假設它涵蓋實際服務的完整連線路徑。
| 觀察方式 | 主要能說明什麼 | 無法直接證明什麼 |
|---|---|---|
| ICMP 探測 | 目標主機是否可透過 ICMP 連線，以及往返時間 | 代理連接埠、驗證與目標網站都正常；伺服器也可能限制 ICMP |
| TCP 探測 | 與指定主機及連接埠建立 TCP 連線的情況 | 代理協定可用、持續傳輸速度夠快，或 UDP 路徑正常 |
| 透過代理進行 HTTP 探測 | 能否完成對指定測試網址的一次請求，以及所需時間 | 其他網域、其他地區的內容及長時間連線都能正常使用 |
| 實際 App 操作 | 目標頁面、影片或通話在目前設定下的表現 | 不同時間、不同網路下也能維持相同表現 |
逾時也不等於「伺服器一定離線」。測試目標無法連線、連接埠填錯、目前網路限制某種傳輸方式，或測試方式不適用該協定，都可能造成逾時。反過來說，延遲數字很低，也只代表這次探測很快完成，不能取代連線後對實際 App 的確認。
二、先固定測試條件，再比較現有設定
先確認現有訂閱已成功匯入 Home，並檢查伺服器位址、連接埠與協定欄位是否完整。更新訂閱只會同步設定資料，不會增加伺服器頻寬，也不會自動解除目標網站的限制。如果服務提供者調整了位址或驗證資訊，請先更新再進行比較；每輪測試之間，不要同時更新訂閱、切換網路又修改規則。
-
固定網路
選定同一個 Wi-Fi 或行動網路，暫停會占用頻寬的同步工作。測試期間不要在兩種網路間切換，並記下測試時段。
-
確認設定
在 Home 選取一筆現有設定，進入編輯資訊確認 Type、位址與連接埠。例如服務端要求 TCP 443，就不能自行猜測並改成 8443；連接埠必須以自己的服務端參數為準。
-
固定路由
前往 Home → Global Routing，記下目前使用的是 Config 還是 Proxy。若要排除規則影響，可暫時切換至 Proxy 進行對照，完成後再恢復原設定；也要檢查 Settings → On Demand，避免自動連線條件改變測試狀態。
-
重複探測
在 Home 使用 Connectivity Test，對每個候選設定採用相同的測試方式與目標，重複測試三至五次。記錄逾時次數、典型耗時與最高耗時，不要只抄下最低的一次。
-
驗證實際使用情境
連線後，開啟同一個實際目標，依序檢查首次開啟、持續載入，以及短暫閒置後能否恢復。每個候選設定都採用相同的觀察時間，例如持續五分鐘，再切換下一筆。
以下是假設資料，僅示範記錄格式，並非產品實測，也不對應任何可取得的服務。五次測試中若有逾時，應另外計數，不能當成 0 ms 納入平均值。成功樣本的中位數可降低單次異常值的影響，但仍須保留失敗記錄。
候選 A：假設記錄
- 測試網路
- 相同 Wi-Fi、相同位置
- 五次測試結果
- 38、41、逾時、210、43 ms
- 成功樣本中位數
- 42 ms，另記 1 次逾時
- 實際使用情境觀察
- 五分鐘內出現兩次載入停頓
38 ms 是最低值，但不能因此忽略逾時和明顯波動。
候選 B：假設記錄
- 測試網路
- 與候選 A 條件一致
- 五次測試結果
- 72、75、73、74、76 ms
- 成功樣本中位數
- 74 ms，未逾時
- 實際使用情境觀察
- 五分鐘內持續載入正常
對於需要持續互動的工作，穩定的結果可能比單次低延遲更有參考價值。
三、地區標籤不等於實際路徑與出口能力
連線名稱中的地區通常由設定提供者填寫，可能指入口、出口或服務分組，並非用戶端獨立確認的實際位置。存取路徑可能包括本地網路、網路服務業者、入口伺服器、中繼、出口及目標網站。地理位置較近，不代表路徑一定較短；路由繞行與跨網路壅塞也可能抵銷距離優勢。
如果目標 App 依出口 IP 判斷地區，應以該 App 實際看到的出口及其服務規則為準，而非只看 Home 列表中的名稱。網站也可能參考帳號地區、定位權限或過往工作階段等資訊來判斷。切換設定後仍顯示舊地區，也不能立刻認定延遲測試失準，因為這兩項觀察根本不是同一回事。
- 互動操作：優先觀察首頁載入、搜尋、送出及連續點按的回應，不要只依地理名稱判斷。
- 持續傳輸：觀察傳輸能否維持，以及是否頻繁停頓。短暫探測回應快速，不代表長連線的吞吐量足夠。
- 即時服務：除了往返時間，也要檢查抖動、封包遺失及 UDP 是否可連線；UDP 不通時，即使 TCP 探測成功，也不足以證明服務可用。
- 特定地區服務：確認目標服務的可用地區與帳號條件，並確認請求確實經由預期的出口。
四、協定類型會影響連線條件，但不代表速度排名
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 和 WireGuard 的連線機制各不相同，但不能只憑協定名稱判斷哪筆設定比較快。伺服器位置、負載、傳輸參數、本地網路及目標路徑通常都會影響結果。先確認匯入欄位與服務端設定一致，再比較實際表現；不要只修改 Type，就想把現有伺服器變成另一種協定。
| 協定 | 需優先確認的條件 | 測試時的限制 |
|---|---|---|
| Shadowsocks | 服務端支援的加密方式、密碼、連接埠與 UDP 設定 | TCP 正常不代表 UDP 轉送也正常 |
| VMess / VLESS | 身分欄位、傳輸方式，以及相應的 TLS、Host、路徑等參數 | 連接埠可連線，不代表驗證和應用層傳輸參數正確 |
| Trojan | 密碼、服務端連接埠、TLS 與伺服器名稱等參數 | TCP 建立連線後，仍可能因 TLS 或驗證失敗而無法使用 |
| Hysteria2 | UDP 連線狀態、驗證、TLS 及服務端約定的參數 | 以 QUIC 為基礎；只測 TCP 連接埠，無法據此判斷完整連線狀態 |
| WireGuard | 金鑰、Endpoint、隧道位址及 AllowedIPs 等設定 | 以 UDP 為基礎；需搭配交握與隧道內的實際通訊狀況判斷 |
連接埠號碼也不代表協定能力。TCP 443 與 UDP 443 使用不同的傳輸協定，即使號碼相同，也不是相同的連線條件。網路允許 TCP 443，不代表 UDP 443 也能連線。若某筆設定在 Wi-Fi 可用、行動網路卻無法使用，請保留原有參數，分別檢查網路與傳輸條件，而不要隨意更換連接埠或停用 TLS 驗證。
五、先排除 Global Routing 與規則造成的誤判
選取一筆設定，不代表每個請求都會使用它。Global Routing 決定整體路由模式；使用 Config 時，還要確認目前啟用的設定檔、規則比對結果及規則指定的策略。如果某個網域命中 DIRECT，一直更換代理設定通常也不會改變該網域的實際路徑。
Config
建議依照目前設定中的規則決定策略。適合規則設定正確、希望維持日常分流的情境；但不保證所有目標都會經過目前選取的代理。
適用情境：日常使用，以及確認規則比對結果後進行實際服務測試
Proxy
以代理作為整體路由方向，可用來對照 Config 的規則影響。仍須另外考量系統設定、路由排除項目或未納入接管的流量，不能因此斷定整台裝置的所有通訊都會經過代理。
適用情境：暫時排除規則因素，完成後恢復原本模式
Direct
以直接連線作為整體路由方向，用來觀察本地網路存取目標的情況。此時實際頁面表現不能作為所選代理設定的效能結論。
適用情境：建立本地網路基準，區分問題出在目標本身還是代理路徑
Scene
依照已設定的場景條件採用相應的路由安排。測試前應確認目前場景實際使用的設定，避免環境變化後兩輪比較走了不同路徑。
適用情境：已明確設定場景條件的使用環境
例如，在以下教學片段中，example.com 及其子網域會先命中 DIRECT；其他請求才會套用 FINAL 指定的 PROXY。範例網域僅用於說明語法，不是測試服務，也不是可用的連線設定。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY在 Config 中確認目前啟用的檔案，並查看請求記錄以確認策略。規則會依序比對；除了 DOMAIN-SUFFIX，GEOIP、IP-CIDR 等條件也可能影響路徑；若前面的規則都未命中，則由 FINAL 作為兜底。也要檢查策略是否引用其他指定設定或策略群組，以免誤以為請求一定使用 Home 目前選取的項目。
六、常見狀況與後續檢查
延遲只有幾十毫秒，為什麼影片還是一直轉圈？
先在 Home → Global Routing 確認測試模式，再檢查目標請求採用的策略。接著連續觀察同一部影片五分鐘，分辨是首次等待還是播放途中停頓。首次等待可能與 DNS、交握或目標回應有關；播放中停頓則更需要檢查持續吞吐量、封包遺失及網路壅塞。單次短暫探測無法涵蓋這些條件。
列表測試逾時，但實際網頁可以開啟，需要刪除設定嗎？
先不要刪除。在 Home 確認 Connectivity Test 採用的測試方式與目標，再確認網頁確實透過該設定存取。如果使用 UDP 協定，卻只測試 TCP 連接埠，或測試網址本身無法連線，逾時可能不代表實際服務失敗。請在相同條件下重複探測，並保留實際請求的結果。
換了地區，網站顯示的位置為什麼沒有改變？
先確認 Global Routing 不是 Direct，再檢查 Config 中該網域是否命中 DIRECT，或是否指定其他策略。實際出口可能與列表中的地區標籤不同；即使出口已改變，網站仍可能依帳號地區和過往工作階段判斷。應依目標服務的規則檢查，不要只是不斷切換連線。
每次切換網路，結果都不一樣，如何準備備用設定？
在常用的 Wi-Fi 和行動網路下，分別重複同一套測試，記錄成功率、波動及實際 App 的表現。檢查 Settings → On Demand 的條件是否改變了連線狀態。從自己的現有設定中，保留一筆已在備用網路上確認可用的設定，並在使用時確認切換成功；不必為了追求最低數字而頻繁修改協定參數。
最後可依「目標服務正常使用 → 常用網路下穩定 → 常用時段可重複 → 延遲與吞吐量符合需求」的順序篩選。發生問題時，記下網路類型、時間、協定、路由模式、測試方式與錯誤情況，再向自己的服務提供者確認服務端狀態。記錄時請隱去密碼、金鑰、身分欄位及完整訂閱網址，避免在排查截圖中公開驗證資訊。