Shadowrocket 速度慢怎麼排查？節點、線路、協定與本機網路逐層檢查

一、先確認「慢」發生在哪個階段

Shadowrocket（小火箭）顯示已連線，只能代表連線狀態，無法證明前往目標網站的整條路徑都暢通。開啟網頁通常會經過 DNS 解析、建立連線、TLS 交握與傳輸內容；任何環節變慢，都可能讓頁面遲遲無法顯示。先記下發生的情況，再調整設定，避免把解析等待誤認為頻寬不足。

延遲數值不等於下載速度。單次延遲測試反映特定探測過程所花的時間，不代表實際服務的持續傳輸量；測試一次失敗，也不能直接判定伺服器無法使用。影片開始播放、網頁首次顯示與檔案傳輸應分別觀察，不要用單一數值代表所有使用體驗。

二、建立固定基準：先檢查 Global Routing

在 Home 檢查目前使用的伺服器與 Global Routing。Proxy、Direct、Config、Scene 代表不同的路由模式，不是速度檔位。若要排查規則影響，可暫時比較 Proxy 與 Config：若 Proxy 下目標恢復正常，但 Config 下仍然緩慢，應優先核對規則與策略指向；這不代表需要長期使用 Proxy。

1. 記錄原有設定

   在 Home 記下選用的伺服器與 Global Routing；前往 Config 確認目前選用的設定檔。保留原有值，測試完成後還原。

2. 固定測試目標

   在 Safari 選擇一個可重複瀏覽的網頁，以及一個允許測試的檔案資源。每輪使用相同目標，並暫停其他大量傳輸工作。

3. 比較路由模式

   在 Home → Global Routing 暫時選擇 Proxy，伺服器維持不變；接著切回 Config 再測一次。記錄目標是否套用預期的策略。

4. 檢查隨選連線

   前往 Settings → On Demand 檢查隨選連線條件。若要以中斷連線的狀態進行基準測試，請先暫時停用相關條件，避免測試期間自動重新連線。

5. 還原並再次確認

   完成比較後，還原原本的 Global Routing 與 On Demand。再次瀏覽相同目標，確認重現的是同一個問題，而非不同的連線狀態。

Direct 適合用來確認目前網路能否直接連線至目標，但不能拿原本就無法直接連線的目標，當成本機網路故障的證據。Scene 的結果也取決於對應的場景設定，不能只看模式名稱就判斷實際路由。若涉及規則，請查看 Config 中的順序與實際請求命中結果；DOMAIN-SUFFIX、IP-CIDR、GEOIP 與 FINAL 各有用途，變更 DNS 不會自動修正錯誤的策略選擇。

三、節點層：在相同網路下只更換伺服器

此處所說的節點，是服務商提供的個別伺服器項目。先保持 Wi-Fi、測試目標與路由模式不變，只在自己已有的伺服器項目中切換兩個。盡量選擇協定及相關參數相同的項目，否則結果也會受到協定差異影響，無法單獨歸因於伺服器負載。

• 只有一個項目一直很慢：記下該項目的位址、連接埠與發生時段，再向自己的服務商確認負載、維護或限速情況。
• 所有項目都同時很慢：接著檢查共用線路、本機網路與目標服務；不要立刻一次修改所有參數。
• 同一項目時快時慢：在相近條件下，分不同時段重測。晚間變慢只能作為壅塞線索，無法據此判定壅塞發生在哪一段。
• 更換項目後恢復正常：仍應切回原項目再測一次，排除目標快取、暫時恢復或背景工作結束造成的誤判。

訂閱項目可能會由服務商調整。若懷疑位址或連接埠已變更，可在 Home 更新自己的訂閱，再檢查伺服器欄位是否同步；訂閱連結請向自己的服務商取得。更新訂閱只會同步設定，不會直接增加伺服器頻寬，也不能以「更新成功」證明線路正常。

四、線路層：交叉測試 Wi-Fi 與行動網路

線路涵蓋裝置至伺服器，以及伺服器至目標服務之間的傳輸路徑。切換本機連線網路只能改變其中一部分，因此「行動網路恢復正常」表示問題可能與連線網路或相關路徑有關，但不能只憑這一點就認定路由器故障。沒有行動網路功能的 iPad，可改用自己能控制的其他 Wi-Fi 或個人熱點進行比較。

以上是測試規劃，並非實測結果。建議每種組合重複三輪，記下時間與失敗次數；測試大型檔案會消耗流量，使用行動網路前請先確認自己的方案。若兩台伺服器都只有在原本的 Wi-Fi 下變慢，應優先檢查無線環境、路由器與該連線線路；若其中一台在兩種網路下都很慢，則繼續檢查該伺服器及其通往目標的路徑。

如果只有特定網站速度慢，其他目標正常，也要考慮目標的 CDN 分配、出口位址限制或應用程式本身的限速。不要以「地理位置較近」取代實際測試：路由路徑、互連品質與負載都會影響結果。

五、協定層：先核對參數，再檢查傳輸條件

協定名稱不代表速度保證。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 採用不同的連線機制；實際效果仍取決於伺服器部署與網路條件。只比較服務商已提供且參數完整的設定，不要把項目的 Type 改成另一種協定來測試，伺服器端不會因此自動支援該協定。

• 位址與連接埠：以服務商提供的資訊為準。HTTPS 常見的 443 連接埠並非所有代理服務通用，不能因連線緩慢就一律改成 443。
• TLS 與 SNI：Trojan 等設定應核對憑證對應的名稱及 SNI。憑證驗證失敗屬於連線問題，不應以啟用 Allow Insecure 作為加速方法。
• 傳輸參數：服務商使用 WebSocket 等傳輸方式時，路徑、Host 等參數必須與伺服器端設定相符；能解析伺服器位址，不代表這些參數正確。
• UDP 條件：Hysteria2 以 QUIC 為基礎，WireGuard 使用 UDP。部分連線網路可能限制 UDP，造成連線失敗或不穩定；請與服務商提供的其他可用設定比較。

若出現日誌錯誤，請先處理錯誤，再進行傳輸量測試。以下列出網路診斷中常見的錯誤片段；實際前綴與完整內容請以日誌為準，並非每種速度慢的情況都會出現這些訊息。

六、本機網路層：檢查 Wi-Fi、DNS 與背景流量

若交叉測試顯示問題可能出在本機，先採取可還原的操作。靠近路由器重測、暫停其他裝置的大量傳輸，比直接重置所有網路設定更能保留排查線索。無線訊號強不代表干擾少，也不代表寬頻出口沒有排隊；同一 Wi-Fi 下其他裝置大量上傳，也可能增加網頁載入時間。

1. 檢查連線品質：伺服器維持不變，靠近路由器重新測試；若路由器提供不同頻段，可在可控條件下分別測試，並記下連線的網路。
2. 暫停競爭流量：暫時停止照片同步、系統更新及其他裝置的大型檔案傳輸，再瀏覽相同目標；測試完成後恢復原有工作。
3. 確認直接連線的基準：確認 On Demand 不會自動重新連線後，中斷連線並瀏覽目前網路可正常存取的網頁；若仍然緩慢，請先處理本機連線問題。
4. 分辨 DNS 與傳輸量：只有首次連線明顯等待時，才優先檢查解析設定。不要直接以網站 IP 取代網域名稱測試 HTTPS，因為憑證、SNI 與虛擬主機可能都需要網域名稱。
5. 觀察重新連線：切換 Wi-Fi 與行動網路後，等待目前連線穩定，再重新開始測試。舊連線中斷不代表伺服器在新網路上無法使用。

不建議優先調整 MTU。若小型請求正常，但較大的傳輸反覆停頓，可將 MTU 列入後續排查方向；不過類似情況也可能是封包遺失或目標限速所致。只有在設定確實提供相關選項，且服務商有明確參數依據時才進行調整；每次保留原值，不要直接套用網路上所謂的通用數值。

七、整理排查結果並確認恢復

排查的目標不是某次測速變快，而是在原本的使用環境中穩定完成相同工作。還原原本的 Config 與 On Demand 後，再檢查常用網頁及實際使用的 App；若還原 Config 後又變慢，應回頭檢查規則命中與策略選擇，而非繼續更換伺服器。

• 環境：記錄使用的 iPhone 或 iPad、連線網路類型、發生時段，以及是否只有單一目標異常。
• 設定：記錄 Global Routing、使用的協定、伺服器連接埠及選用的設定檔；請勿公開密碼、金鑰或訂閱驗證資訊。
• 比較結果：說明「原伺服器在兩種網路下都很慢」或「同一伺服器只有在原本的 Wi-Fi 下很慢」，比只寫「速度不理想」更容易找出問題。
• 證據：保留實際錯誤片段與測試次數。分享日誌前，請先檢查並遮蔽驗證參數、完整訂閱連結及個人瀏覽紀錄。
• 還原：撤銷暫時變更並重新測試原目標；若問題仍可重現，請回報自己的服務商，不要繼續疊加未經驗證的設定。

若需進一步檢查規則與 DNS，可參閱Global Routing 與規則分流教學及DNS 排查說明。這些檢查針對不同環節，應依據證據逐項進行，不必在同一次測試中全部變更。