Shadowrocket（小火箭）連線後速度變慢，先固定測試目標、伺服器與時段，再比對 Wi-Fi 和行動網路；接著檢查路由模式、既有協定參數、線路波動及伺服器負載。本文適用於已有服務商提供的設定或訂閱的使用者，重點釐清「連線延遲低」、「網頁開啟快」與「持續下載快」之間的差異。透過單一變因測試縮小問題範圍，不要只憑一次 Ping 結果就更改所有設定。
一、先釐清「慢」是連線、首位元組還是持續傳輸
先說結論：Ping 數值低不代表頻寬大，開啟連線也不代表目標請求已依預期經過代理。排查前，先在 Home 記下目前的伺服器，在 Global Routing 記下目前模式，再到 Config 確認使用中的設定。保留設定副本，之後每次只變更一個項目。
網頁等很久才顯示內容，可能與 DNS、建立連線或目標伺服器回應有關；網頁很快開啟但大型檔案下載速度低，較像是持續傳輸量不足；影片一開始播放正常、中途卻間歇卡頓，則應觀察速度波動、封包遺失及目標端限速。這些情況可能同時發生，不能一概歸因於協定速度不夠快。
- 固定使用一個自己有權存取、可重複測試的目標頁面或檔案，每輪不要更換網站。
- 分別記錄連線耗時、頁面開始顯示前的等待時間，以及穩定傳輸後的速度。
- 記下使用 Wi-Fi 或行動網路、伺服器名稱、Global Routing 模式及測試時間。
- 每組測試重複三次並記錄失敗次數，不要只留下最快的一次結果。
二、本地網路層：比對 Wi-Fi 與行動網路
固定使用同一台伺服器、同一個目標及同一份設定，只更換網路。若 Wi-Fi 下速度慢、行動網路正常，表示差異可能與網路接入方式或該網路通往伺服器的路徑有關，但還不能據此判定路由器故障。無線干擾、上傳頻寬用盡、網路政策，以及不同電信網路的路由，都可能造成這種結果。
- 先在 Wi-Fi 下完成一組測試，記錄三次結果；再靠近無線基地台，排除訊號微弱的影響。
- 關閉 Wi-Fi，確認裝置已改用行動網路；中斷後重新建立 Shadowrocket 連線，讓新連線採用新的網路路徑。
- 保持伺服器與目標不變，再完成一組測試。下載測試會耗用行動數據，請先確認方案剩餘流量。
- 切回 Wi-Fi 再測一次。如果只有某個基地台反覆出現異常，再檢查該網路是否壅塞或受到限制。
若要確認一般網路是否正常，可選擇原本就能直接存取的目標，暫時中斷連線後進行比對；此時流量會依系統的一般網路路徑傳送。先到 Settings → On Demand 記下並暫時關閉自動連線條件，避免測試期間重新連線，結束後再還原。不要用原本就無法直接存取的目標，判斷本地網路是否故障。
| 反覆出現的情況 | 優先檢查項目 | 下一步 |
|---|---|---|
| Wi-Fi 慢，行動網路正常 | 無線連線品質、網路壅塞、通往伺服器的路徑 | 在同一個 Wi-Fi 網路更換基地台，伺服器維持不變再測 |
| 兩種網路都慢，但直接存取的比對目標正常 | 代理路徑、伺服器或目標端 | 確認路由模式，再比較已有的伺服器 |
| 直接存取與代理連線都慢 | 本地網路流量、目標端回應 | 暫停背景傳輸，並增加一個可直接存取的比對目標 |
三、路由層：確認測試使用的是同一條路徑
在 Home → Global Routing 確認目前模式。Config 依設定規則處理請求；Proxy 用於比對代理路徑；Direct 用於比對直接連線；Scene 則依所選場景處理，測試時也要確認使用的場景。不要將不同模式下的測速結果混在一起計算平均值。
使用 Config 時，規則會依順序比對。DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 與 GEOIP 處理相應的 IP 條件，FINAL 則處理前面未符合規則的請求。看似相同的目標，其頁面圖片或媒體可能使用其他網域，因此採用不同策略。比起只確認首頁能否開啟，檢查請求紀錄中的目標及命中策略更可靠。
- 短暫切換至 Proxy 比對同一目標前，先記下原本的模式；測試結束後還原設定。
- 如果 Proxy 正常、Config 卻很慢，應優先檢查命中的規則、策略組及實際選用項目，不要立刻變更協定參數。
- 切換模式或伺服器後，重新建立測試連線；既有的長連線可能影響測試結果。
- 如果只有第一次開啟很慢、後續傳輸正常，接著檢查 DNS 查詢與建立連線的階段；不要同時更改 DNS、規則和伺服器。
四、協定層：檢查參數，不要把更換協定當成萬用解法
在 Home 開啟目前伺服器的編輯頁面，逐項比對位址、連接埠及協定參數與自己已有的設定。連接埠不是速度檔位，不能任意將服務改成 443 來嘗試加速。協定、連接埠與伺服器端的監聽設定必須相符；位址能解析，也不代表驗證與加密參數正確。
| 協定 | 檢查重點 | 應避免的操作 |
|---|---|---|
| Shadowsocks | 伺服器位址、連接埠、密碼、加密方式及已設定的外掛參數 | 自行更改加密方式或密碼 |
| VMess / VLESS | 使用者識別碼、傳輸方式，以及啟用 TLS 時的伺服器名稱等參數 | 將傳輸方式或路徑改成猜測值 |
| Trojan | 密碼、連接埠及 TLS 伺服器名稱 | 不要關閉憑證驗證來掩蓋交握問題 |
| Hysteria2 | 驗證資訊、TLS 參數及網路接入環境中的 UDP 可達性 | 不要將設定中的頻寬數值視為線路保證 |
| WireGuard | 金鑰、對端位址、連接埠及隧道相關設定 | 未確認原因前不要更改 MTU 或替換金鑰 |
Hysteria2 與 WireGuard 仰賴 UDP 傳輸條件；其他協定的實際傳輸方式也須依設定判斷。如果同一份 UDP 設定只在某個 Wi-Fi 網路下持續逾時，而行動網路正常，應優先確認該網路是否限制 UDP。只有在伺服器端已提供其他相容設定時，比較不同協定才有意義；不能只更改用戶端的協定名稱。
五、線路與節點層：交叉比對 Ping、時段及持續傳輸
Ping 通常反映往返延遲，不代表持續傳輸量。部分伺服器不回應 ICMP，即使 Ping 逾時，仍可能建立應用程式連線；TCP 連線測試也只涵蓋特定連接埠的連線階段，不等於檔案下載測試。使用 Home 中的 Connectivity Test 時，先確認測試方式與目標，避免直接比較不同方式測得的數值。
線路品質與本地至伺服器、伺服器至目標的傳輸路徑有關；節點負載則涉及伺服器 CPU、可用頻寬、連線數或限速。單靠用戶端的一次測量，通常無法完全區分兩者，應連同時間、網路接入方式及目標記錄測試現象。
- 固定伺服器，比對不同時段：在問題發生時段及另一個時段重複相同測試。若只有特定時段變慢，可能與壅塞或負載有關，但不能直接證明是哪一端壅塞。
- 固定目標，更換已有伺服器：只比較自己已有且可正常使用的設定。如果某一台持續較慢、其他伺服器正常，可將問題範圍縮小至該伺服器或相關路徑。
- 固定伺服器，更換目標：若只有一個目標較慢、其他目標正常，應優先檢查目標端限速、通往目標的路徑，或是否命中不同規則。
- 觀察持續傳輸：記錄穩定傳輸階段及停頓次數。即使延遲低，仍可能有封包遺失、重傳或伺服器排隊的情況。
如果發現「晚上所有目標都慢、切換至行動網路仍慢、更換另一台已有伺服器後恢復正常」，可將測試紀錄提供給自己的服務商，請對方檢查負載與線路。這項結果仍無法區分伺服器資源不足與共用出口壅塞，需要進一步查看伺服器端監測資料。不要只以地理距離近或 Ping 最低作為選擇依據。
六、出現錯誤時：先排除連線失敗，再測速度
持續出現錯誤表示測試可能根本沒有進入穩定傳輸階段。以下列出網路記錄中常見的錯誤片段；實際訊息會因底層連線及錯誤來源而異，不是每種協定都會顯示相同文字。只有在自己的記錄確實出現相應訊息時才參考，不要根據未顯示的字詞推斷故障。
錯誤：i/o timeout
原因與處理方式：某次網路讀寫未能在期限內完成，可能與無法連線、封包遺失或對端沒有回應有關——保持伺服器不變，切換 Wi-Fi／行動網路重測，再確認逾時發生於連線階段還是傳輸階段。
錯誤：connection refused
原因與處理方式：連線請求遭對端或中間設備拒絕，這不單純是頻寬不足——確認位址、連接埠及服務是否仍有效，並向自己的服務商確認該連接埠的服務狀態。
錯誤：certificate has expired
原因與處理方式：憑證驗證結果顯示有效期限已過，也應排除裝置時間不正確的可能——先檢查系統日期與時間，再請負責維護服務的一方確認憑證；不要以關閉憑證驗證來加速。
如果自己的訂閱近期變更過位址或連接埠，可在 Home 找到對應訂閱並更新，再確認目前選用的伺服器。更新後先檢查 Config 與 Global Routing 是否仍符合原本的測試條件。更新訂閱只是同步已有設定，不能保證線路效能，也不應成為反覆測速時同時變動的因素。
七、常見問題與還原檢查
Ping 只有幾十毫秒，為什麼下載還是很慢？
延遲與傳輸量是不同指標。保持目前的伺服器與目標，進行一段穩定傳輸測試，記錄速率單位、停頓情況及測試時段，再換一個目標比對。不要只憑 Ping 排除頻寬限制或目標端限速。
Wi-Fi 慢、行動網路快，是協定選錯了嗎？
不能直接下結論。先保持協定與伺服器不變，切換網路接入方式並重新建立連線；若差異持續出現，再檢查 Wi-Fi 壅塞、UDP 限制及路徑差異。避免同時更改協定與網路。
需要直接修改 MTU 或開啟所有選項嗎？
先保留原本的數值。小型請求正常、大量傳輸卻停頓，只能當作線索，不能單獨證明是 MTU 問題。只有取得符合現有隧道的參數或明確的診斷依據後，才單獨修改一項並重新測試。
測試完成後，需要還原哪些設定？
還原原本的伺服器、Global Routing 模式與 Config；前往 Settings → On Demand 還原原有的自動連線條件，再重新連線並檢查常用目標。刪除測試紀錄前，先保留最後確認可用的設定。
向自己的服務商回報時，提供網路接入方式、伺服器識別資訊、協定、測試時段、目標類型及重複測試結果即可；分享截圖或記錄前，請遮蔽訂閱 token、密碼、使用者識別資訊及金鑰。若仍無法區分線路與負載，明確註明「用戶端比對尚無法判定」，比只寫「速度慢」更有助於進一步排查。
- 結論應優先描述可重現的現象，例如「同一台伺服器在 Wi-Fi 下三次都會停頓，行動網路下三次皆正常」，不要把推測寫成確定原因。
- 說明測試時使用 Config 或 Proxy，以及是否重新建立連線，避免雙方比對不同路徑。
- 保留原始錯誤訊息與時間，但不要公開完整訂閱連結或驗證參數。