Shadowrocket（小火箭）連線後的速度取決於整段請求路徑；連線測試的延遲低，不代表下載速度快。本文適合已有自己的服務商與訂閱、可以連線但瀏覽變慢的使用者，依序檢查本地網路、路由與協定、線路品質及節點負載。每次只調整一項條件並記錄結果，再決定保留設定或還原；本站不提供、不販售、不推薦節點或訂閱。
一、先分辨延遲、吞吐量與連線失敗
「網速慢」至少有三種情況：開啟網頁後等很久、檔案下載速度持續偏低、連線時好時壞。第一種可能與 DNS 查詢、建立連線或遠端回應有關；第二種較可能是持續吞吐量問題；第三種則要留意封包遺失、網路切換及連線中斷。先描述具體情況，比直接更換協定有效。
這是診斷用的邏輯分層，並非固定的封包處理順序。DNS 查詢可能發生在不同環節。Home 中的 Connectivity Test 用來確認測試目標是否可連線，並參考相應測試方式所需時間；它不能取代檔案下載測試，也無法證明所有網站及傳輸方式都正常。
- 首頁載入很久：記錄首次與再次造訪是否有明顯差異，同時檢查網域解析與連線建立情況。
- 下載速度持續偏慢：固定同一個檔案與目標網站，觀察至少 30 秒，避免只看剛開始的瞬間速度。
- 頻繁卡住：記錄卡住時是否剛從 Wi-Fi 切換到行動網路，或螢幕剛從鎖定狀態喚醒。
- 只有一個網站很慢：優先檢查該網站的路由、資源伺服器及帳戶限速，不要直接歸因於用戶端。
注意單位：8 Mbps 約等於 1 MB/s，這是位元與位元組的換算，尚未扣除協定額外負荷。直接比較測速頁面的 Mbps 和下載介面的 MB/s，可能會把正常差異誤認為速度下降。
二、建立本地 Wi-Fi 與行動網路基準
先確認裝置連上網際網路的基本連線正常，再檢查代理路徑。選擇目前網路可直接存取的網站作為基準目標，不要用原本就必須透過代理才能存取的目標測試直連。測試期間暫停其他裝置傳輸大型檔案，也避免同時執行多項測速。
-
記錄原始設定
在 Home 記下目前選取的節點與 Global Routing 模式，在 Config 記下目前使用的設定檔。後續每次只調整一項條件，測試後才能回到同一基準。
-
暫停自動連線
檢查 Settings → On Demand。若已啟用自動觸發條件，先記下設定並暫時關閉相關開關，再回到 Home 關閉連線開關，確認測試期間沒有重新建立連線。
-
測試直連
使用 Wi-Fi 存取基準目標，記錄開啟所需時間、持續下載速度及是否中斷。連續測試三次，保留三次結果，不要只挑最快的一次。
-
切換網路
關閉 Wi-Fi，確認裝置已改用行動網路，再以相同目標及相同操作重測。留意行動數據用量；不要在切換網路時同時計時。
-
恢復連線
回到 Home，選取原本的節點並開啟連線。先執行 Connectivity Test，再測試存取同一目標；完成所有對照後，還原原本的 On Demand 設定。
若關閉連線後 Wi-Fi 仍慢、行動網路正常，優先檢查無線訊號、路由器上行頻寬占用及本地網路品質。若兩種網路直連都正常，但連上同一節點後只有一種網路變慢，表示裝置接入網路至該節點之間的路徑差異值得進一步檢查，但還不能據此判定是節點負載。
三、確認 Global Routing 與實際套用的規則
連線後變慢，不一定代表流量確實經過所選節點。Home → Global Routing 決定路由模式；Config 中的規則只有在相應模式下才會參與分流。先確認模式，再檢視規則，避免修改目前未生效的設定。
| 模式 | 排查用途 | 注意事項 |
|---|---|---|
| Proxy | 用來對照代理路徑，減少分流規則帶來的變因。 | 僅供短時間測試，完成後請還原原本模式。 |
| Direct | 用來觀察直接連線的存取結果。 | 不等於關閉系統中的 VPN 連線，不能取代中斷連線後的基準測試。 |
| Config | 依目前設定中的規則決定處理方式。 | 檢查目前設定、規則比對順序及最後採用的策略。 |
| Scene | 依已設定的情境決定相關路由行為。 | 先確認實際觸發的情境，避免測試條件隨網路變動。 |
以下僅示範規則語法，並非建議覆蓋現有設定。DOMAIN-SUFFIX 比對網域及其子網域；IP-CIDR 比對 IPv4 網段；GEOIP 依 IP 位址歸屬資料庫判斷；FINAL 處理前面未比對到的請求。規則會依序比對，範圍較廣的規則若放在前面，後續較細的規則可能就不會生效。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY- 範例中的
example.com是說明用網域，並非測速目標；192.168.0.0/16是私有 IP 位址範圍，不涵蓋所有私有網段。 GEOIP,CN,DIRECT不代表「所有中文網站都直連」；網域使用的語言與伺服器 IP 位址的歸屬地是不同概念。- 在請求記錄中確認目標網域及實際採用的策略。若改為 Proxy 後正常、還原 Config 後又出現問題，應優先檢查規則及策略指向。
- 同一個網頁可能會向多個網域請求圖片、影片及指令碼。主要網域正常，不代表所有資源都經過相同路徑。
四、先核對協定參數，不要猜測數值來提速
在 Home 開啟既有節點的編輯頁面，核對 Type、伺服器位址、連接埠及驗證資訊。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的參數不能互換；協定必須與遠端設定一致，不能只修改 Type 來比較協定速度。
例如，既有設定指定連接埠 443 時，應先確認遠端實際監聽的傳輸方式。TCP 443 可連線，不代表 UDP 443 也可連線；連接埠號碼相同，也不表示使用相同協定。Hysteria2 以 QUIC 為基礎，依賴 UDP；WireGuard 也使用 UDP，網路對 UDP 的限制可能影響連線及持續傳輸。
- TLS 與伺服器名稱：使用 TLS 的設定，應核對遠端要求的伺服器名稱及憑證條件。不要用關閉憑證驗證的方式掩蓋參數錯誤。
- 傳輸路徑：既有設定若使用 WebSocket 等傳輸方式，路徑與 Host 必須符合遠端設定。一般網頁能開啟，不代表代理的傳輸入口可用。
- Hysteria2 頻寬參數：若設定中包含上行及下行頻寬，應依目前網路狀況和遠端說明填寫。盲目調高數值不保證更快；設定過高的傳送預期，可能加劇排隊或封包遺失。
- WireGuard MTU：先保留已知可用的數值。只有在小型請求正常、大型請求停滯時，才考慮路徑 MTU 問題；例如將原本的 1420 暫時改為 1380 作為一次對照，但這不代表 1380 是通用最佳值。
- DNS：若網域無法存取，但既有 IP 連線可用，請檢查 Config 中實際使用的 DNS 設定。不要同時修改 DNS、規則及協定，否則無法判斷是哪項調整造成變化。
五、透過對照結果區分線路品質與節點負載
線路品質與節點負載都可能造成「晚上變慢」，不能單憑時段下結論。固定目標網站，先固定節點、切換接入網路；再固定接入網路，切換至自己已有的另一個節點。每組至少重複測試三次，並留出間隔，避免同時測速而互相占用頻寬。
| 觀察結果 | 優先懷疑 | 下一步驗證 |
|---|---|---|
| 同一節點只有在 Wi-Fi 下變慢 | 本地無線環境，或該接入網路至遠端的路徑。 | 靠近路由器重新測試，再與行動網路結果對照。 |
| 同一節點在兩種網路下都慢，其他既有節點正常 | 該節點的入口、出口或資源限制。 | 改測兩個目標網站，並比較不同時段的結果。 |
| 所有節點存取同一網站都慢 | 目標網站、資源伺服器，或各路徑共用的區段。 | 固定節點不變，改測另一個獨立目標。 |
| Connectivity Test 正常，但持續下載很慢 | 吞吐量受限、封包遺失、遠端限速或目標回應能力不足。 | 記錄持續下載速度，不要只比較測試所需時間。 |
| 頻繁逾時，結果波動明顯 | 無線干擾、網路壅塞、封包遺失或遠端不穩定。 | 先完成本地直連對照，再檢查節點路徑。 |
延遲低只表示短請求的往返或建立連線所需時間較短；頻寬、封包遺失率及並行連線限制仍可能拖慢大型檔案。反過來說，遠距離節點的延遲較高，也不一定代表持續下載速度較慢。若兩張測速截圖沒有控制目標、時間及網路條件，就無法證明某種協定一定較快。
若只有尖峰時段明顯變慢，且本地直連基準正常，可將現象、時段、接入網路及已遮蔽敏感資訊的測試結果提供給自己的服務商確認。節點 CPU、出口頻寬及連線數都是遠端指標，不能只憑用戶端顯示的延遲直接推算。
- 保留每組測試的最低、最高及中間結果，留意波動範圍，不要只記下單次最佳成績。
- 影片應用可能會快取內容或自動降低畫質，短時間播放流暢不代表持續吞吐量已恢復。
- 測速目標與日常使用目標可能走不同路徑，最後應回到實際發生問題的應用程式重新測試。
六、出現錯誤時，先依錯誤類型處理
以下是網路連線診斷中可能出現的標準錯誤訊息；實際顯示內容以請求記錄為準，不保證每種測試都會出現相同文字。錯誤訊息描述的是失敗階段，並非遠端根本原因的最終判定。記下原始訊息及發生時間，比反覆開關連線更有助於診斷。
錯誤：i/o timeout
原因與處理方式：未能在指定時間內完成相關網路讀寫，可能與路徑不通、封包遺失或遠端沒有回應有關。先固定節點並切換 Wi-Fi／行動網路，再核對遠端位址、連接埠及相應的傳輸方式；不要直接將逾時判定為頻寬不足。
錯誤：connection refused
原因與處理方式：連線請求遭到明確拒絕，常見原因是目標連接埠沒有相應服務正在監聽，或中間設備主動拒絕連線。核對既有設定中的位址及連接埠，並向自己的服務商確認監聽狀態；通常調整 MTU 無法修復這類錯誤。
錯誤：no such host
原因與處理方式：目前的解析程序未能取得所需的網域記錄，可能是網域填寫錯誤或解析環境異常。核對伺服器網域拼寫，切換接入網路後重新測試，再檢查目前設定使用的 DNS；不要未經確認就長期固定使用某個 IP 位址。
若沒有錯誤訊息，只是速度偏低，應繼續比較持續吞吐量，而不是尋找不存在的錯誤。提交記錄前，請遮蔽密碼、Private Key、驗證 token 及訂閱網址；通常保留協定類型、已去識別化的目標、連接埠、網路類型及時間，就足以描述問題。
七、常見問題與排查收尾
延遲只有幾十毫秒，為什麼下載還是很慢？
Connectivity Test 與持續下載測量的項目不同。回到 Home 並維持同一節點，固定目標檔案觀察至少 30 秒，並確認是否混用了 Mbps 和 MB/s；再換另一個目標重測，以區分單一網站限速與路徑吞吐量問題。
切換成 Proxy 就正常，Config 為什麼會卡？
先在 Home → Global Routing 確認兩次測試使用的模式，再到 Config 檢查目前設定中的 DOMAIN-SUFFIX、IP-CIDR、GEOIP 及 FINAL 順序。搭配請求記錄確認實際採用的策略，不要直接刪除所有規則。
切換網路後卡住，需要一直重新啟動裝置嗎？
先等新網路穩定，再於 Home 關閉並重新開啟連線，讓連線透過新路徑建立；檢查 Settings → On Demand 是否觸發了預期之外的自動連線。確認能重現的條件後，再判斷問題是否與網路切換有關。
換成 Hysteria2 就一定能加速嗎？
無法保證。先確認自己的遠端支援此協定且參數完整，再確認目前網路能傳輸相應的 UDP 流量。不同入口與出口會帶來額外變因，應盡量固定目標、接入網路及測試時段，不能只憑協定名稱判斷。
排查結束後要還原哪些設定？
還原原本的 Global Routing、目前使用的設定及 On Demand 設定，撤銷未改善問題的 MTU 或 DNS 調整。最後使用日常應用程式重新測試一次，並記下有效的變更及對應結果，避免保留臨時測試模式。
排查的目標應是得出可重現、可驗證的結論，例如「本地直連正常，同一節點只有在某種接入網路下持續下載變慢」，而不是籠統地說「用戶端很慢」。保留這項結論，再處理對應層面，才能減少無效調整。