Shadowrocket（小火箭）顯示已連線，不代表每個請求都已成功送達目標。本文適合已備有自己的服務商與訂閱、能建立連線但網頁或影片載入緩慢的使用者：先固定測試條件，再逐步區分本機網路、協定參數、跨網線路與節點負載，最後透過 Ping 和 Log 留下可供查證的紀錄。
一、先固定測試條件，區分延遲與傳輸量
「慢」至少有三種情況：點擊後久久沒有回應、頁面開始載入後一直很慢、連線速度時快時慢。第一種可能與 DNS 解析或交握有關；第二種較需要檢查可用頻寬與壅塞；第三種則要搭配網路切換、封包遺失和伺服器負載來判斷。只看狀態列的 VPN 標記，無法分辨這些情況。
測試前，先在 Home（首頁）記下目前選取的節點，以及 Global Routing（全域路由）的目前設定。不要同時更新訂閱、切換協定又修改 DNS；否則即使速度恢復，也無從判斷是哪個步驟奏效。以下測試次數僅供排查參考，並非應用程式的預設值。
- 選定一個原本就能存取的網頁和一段固定的影片，分別觀察首次回應與持續載入；整個排查過程都使用相同的測試目標。
- 暫停照片同步、系統更新及其他大量傳輸作業，並保持裝置位置與網路連線方式不變。
- 每組條件重複觀察 3 次，記下網路類型、節點備註、測試時間及失敗情況，不要只記錄最快的一次。
- 每次只變更一項條件；比較結束後，先還原原本的路由與設定，再進行下一組測試。
二、本機網路：先比較 Wi-Fi 與行動網路
第一層先檢查 iPhone 或 iPad 到本機網路出口的連線。Wi-Fi 訊號強，只能表示無線接收狀況良好，不能證明路由器出口沒有壅塞。同一節點在行動網路正常、在某個 Wi-Fi 網路下緩慢，是接入網路或該網路至節點的路徑可能不同的線索，不能因此直接判定伺服器故障。
- 先透過目前的 Wi-Fi 網路瀏覽一個原本就能直接開啟的常用網頁，確認本機網路是否也明顯延遲。若暫時中斷 Shadowrocket 進行測試，請只瀏覽適合直接存取的內容。
- 前往 Settings → On Demand（隨選連線），記下目前的條件。預設值請以應用程式目前顯示為準；若此設定會干擾手動中斷連線的比較，可只在本輪測試中暫時關閉，結束後再還原。
- 使用相同節點與相同設定，關閉 Wi-Fi，改用裝置可用的行動網路重複測試；請留意行動數據用量。
- 若只有 Wi-Fi 異常，請靠近路由器再次測試，並檢查同一網路是否正在大量傳輸資料；先不要一次修改所有協定參數。
連接埠號碼是排查路徑的線索，不是調整速度的參數。任意將服務商提供的 Proxy 連接埠改成 443，或把所有 DNS 請求都視為使用連接埠 53 的流量，都可能造成新的連線問題。
三、協定參數：核對原始設定，不要只憑名稱判斷速度
第二層檢查用戶端記錄是否符合伺服器要求。Shadowrocket 中的 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 使用不同的協定與設定欄位，不能只改名稱就當成不同的速度檔位。若已有訂閱，應先比對自己的服務商提供的有效參數。
| 協定或欄位 | 應核對的內容 | 不可據此推斷 |
|---|---|---|
| Shadowsocks | 確認伺服器位址、連接埠、密碼與加密方式是否一致。 | 連接埠可連線，不代表驗證及後續轉送都成功。 |
| VMess / VLESS | 身分驗證參數、傳輸方式，以及設定中實際啟用的 TLS 和傳輸相關欄位。 | 不能只保留位址和連接埠，而忽略其他必要參數。 |
| Trojan | 密碼、TLS 相關要求，以及伺服器名稱是否符合伺服器設定。 | 不要把關閉憑證驗證當成一般的加速方法。 |
| Hysteria2 | 驗證資訊、TLS 要求，以及目前網路路徑是否支援 UDP。 | 使用 QUIC 不代表在所有接入網路下都會更快。 |
| WireGuard | 確認金鑰、端點、位址與路由範圍是否符合現有設定。 | 看得到交握，不代表 DNS 與目標路由都正確。 |
以上欄位沒有適用於所有伺服器的通用建議值；預設值請以應用程式目前顯示為準，連線參數則依現有伺服器設定為準。若問題剛好發生在訂閱更新後，先記下更新前後位址、連接埠或傳輸欄位的變化，再向自己的服務商確認。不要刪除原有記錄後反覆重新匯入，以免失去比較依據。
結論：先確認參數一致，再比較協定表現
若某組設定反覆在交握階段失敗，先處理驗證、TLS 或傳輸參數；只有兩組設定都能穩定完成同一項請求時，速度比較才有意義。
四、線路品質：分開看 Ping 與實際請求
第三層觀察本機網路至節點，以及節點至目標之間的路徑。應依目前的測試方式解讀應用程式內的 Ping（延遲測試）結果：ICMP 回應、TCP 建立連線，以及透過 Proxy 完成網頁請求，測量的並不是同一件事。節點沒有回應 ICMP，也不能直接證明 Proxy 服務無法使用。
延遲低只表示某次探測的往返時間較短，不代表持續傳輸時有足夠頻寬；若探測正常但影片持續緩衝，應繼續比較實際傳輸情況與不同時段的差異。不要只憑一次逾時，就推算整條線路的封包遺失率。
- Ping 很快，網頁首次回應卻很慢：檢查 Log 是否有 DNS 等待、連線重試或 TLS 錯誤，同時確認請求實際使用的路由。
- 首次回應很快，持續載入卻很慢：使用固定目標重測，並檢查本機頻寬使用情況、線路壅塞與伺服器限速條件。
- 同一節點只在某個網路下變慢：優先保存 Wi-Fi 與行動網路的比較結果，找出接入路徑的差異。
- 只有單一網站很慢：改用另一個正常的目標進行比較；目標網站、其內容傳遞路徑及節點出口都可能造成影響。
不要只因為「距離比較近」就認定線路比較快。地理距離、電信網路互連、壅塞情況，以及目標網站選擇的內容傳遞位置，都是不同因素，必須在相同條件下比較請求結果。
五、節點負載：先確認請求確實經過所選節點
第四層才比較現有節點的伺服器表現。前往 Home → Global Routing，先記下目前設定。Config（依設定分流）、Proxy（代理）、Direct（直連）、Scene（情境）的作用各不相同；目前預設值請以應用程式顯示為準。日常使用時依現有設定選擇；排查期間若要暫時使用 Proxy 進行比較，測試結束後請還原原值。
使用 Config 時，選取某個節點不代表每個請求都會經過該節點。DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依 IP 位址網段比對，GEOIP 依 IP 位址的地理位置比對，FINAL 則是最後套用的兜底規則；實際結果還會受到規則順序與策略影響。Scene 必須配合現有情境定義核對，不能視為固定的代理策略。
- 對同一個目標送出新的請求，並在 Log 中確認其策略、輸出節點或相關連線記錄；欄位名稱請以應用程式目前顯示為準。
- 若請求使用 Direct，先排查路由原因，不要把這次速度歸因於所選的 Proxy 節點。
- 若有多個可用節點，請保持目標、接入網路與路由設定不變，只切換節點進行比較。
- 在不同時段重複相同測試。若只有尖峰時段變慢，可能與壅塞或負載有關，但不能只憑用戶端結果確認伺服器 CPU、線上人數或限速狀態。
六、Log 錯誤：依發生階段處理，不要憑關鍵字猜測速度
開啟應用程式內的 Log（記錄；入口與可記錄內容請以應用程式目前顯示為準），重現一次載入緩慢或失敗的請求，再檢查該時間附近的記錄。以下英文是網路記錄中常見的錯誤文字；實際前綴、大小寫與完整上下文可能不同，不能把這些文字視為每次故障都會出現的固定提示。
錯誤：i/o timeout
原因：某項網路操作未能在指定時間內完成；只看這行文字，無法分辨問題出在 DNS、建立連線，還是後續讀取或寫入階段。
處理方式：查看前後記錄中的目標與操作階段，保持同一節點並切換網路重新測試，再判斷是否需要向服務商確認伺服器狀況。
錯誤：connection refused
原因：連線收到明確拒絕，可能是目標連接埠沒有監聽，或網路設備主動拒絕連線。
處理方式：確認伺服器位址與連接埠是否仍符合現有設定，並向自己的服務商確認該連接埠的服務狀態。
錯誤：certificate has expired or is not yet valid
原因：憑證有效期限驗證失敗，可能與憑證狀態或裝置時間錯誤有關。
處理方式：先檢查裝置日期與時間；若時間正確，再確認伺服器憑證，不要關閉驗證來掩蓋問題。
- 若 Log 錯誤指向訂閱更新位址，只能表示更新操作異常，不能直接證明已匯入節點的轉送速度有問題。
- 提供 Log 給他人前，請隱藏訂閱憑證、密碼、金鑰與不必要的瀏覽記錄；保留時間、錯誤階段與比較條件。
- 不要長時間反覆重新連線來取代蒐集證據。連續重試可能改變連線狀態，卻無法說明最初是哪個環節發生等待。
七、常見問題與還原檢查
Ping 只有幾十毫秒，為什麼影片還是不斷緩衝？
Ping 不是傳輸量測試。先固定一段影片，使用同一節點分別在 Wi-Fi 與行動網路觀察持續載入情況；再確認 Log 中該請求是否確實使用所選的輸出節點。
切換成 Proxy 後正常，切回 Config 又變慢，該怎麼查？
先在 Config 下重現相同目標，確認套用的規則與策略，再到 Config（設定）檢查相關規則順序。重點查看 DOMAIN-SUFFIX、IP-CIDR、GEOIP 與 FINAL 如何處理該請求，不要直接將整份設定長期改成全域代理。
只要更換協定就一定能加速嗎？
不一定。只有自己的伺服器支援該協定、參數完整，且網路路徑允許所需的傳輸方式時，才有比較的基礎。先確認連線與請求都穩定，再以相同目標和相同接入網路進行比較。
檢查完成後，哪些設定需要還原？
還原測試前記錄的 Global Routing、Settings → On Demand 條件及暫時修改的設定，再重新開啟原本的目標驗證。保留有效的單項修正，不要把測試時的臨時設定當成日常預設值。
完成一輪檢查後，應能寫下「使用哪個網路、哪個節點、哪種路由設定、哪個目標，以及在哪個階段發生等待」。若這些條件尚未固定，繼續修改 DNS、連接埠或協定只會增加變數；先補齊比較紀錄，再處理已找出的環節。