本文適合已在 Shadowrocket（小火箭）中加入自有節點，且連線可以建立但網頁載入或檔案傳輸明顯變慢的使用者。排查時先建立本地網路基準，再依序檢查節點延遲、線路時段、Global Routing、協定參數與 Log；每次只變更一個條件，最後判斷瓶頸位於裝置網路、遠端線路、規則設定或傳輸參數。
先固定測試條件，避免測速結果互相干擾
速度排查最常見的問題，是同時更換 Wi‑Fi、節點、協定與測速目標。即使結果變快，也無法判斷究竟是哪一項發揮作用。正確做法是固定裝置、網路、測試目標與測試時段，每輪只變更一個變數，並至少重複三次。
先記錄未啟用 Shadowrocket 連線時的本地網路表現，包括網頁首次開啟時間、下載速率與基本延遲。接著開啟 Shadowrocket，維持相同 Wi‑Fi 與測試目標，再記錄一組結果。若本地基準本身已明顯波動，應先處理路由器、訊號或接入網路，而不是立即修改用戶端設定。
記錄本地基準
關閉 Shadowrocket 的連線開關，在同一個 Wi‑Fi 下連續測試三次。記錄延遲、下載速率與網頁首次開啟時間，不要只保留最高值。
固定一個節點
返回 Home，選取使用者現有服務中的一個節點。測試期間不要重新整理訂閱或自動切換節點，以免測試對象發生變化。
使用 Config
在 Home → Global Routing 選擇 Config，讓請求依照目前設定檔中的規則處理。排查過程中也記錄設定名稱，避免把規則變化誤判為線路變化。
重複三輪測試
開啟連線後，對同一個目標連續測試三輪，每輪間隔約 30 秒。若結果分別為 18 Mbps、76 Mbps、24 Mbps，應優先判斷為波動，而不是穩定限速。
一次變更一項
更換節點後重新測試；確認節點差異後，再比較協定或傳輸參數。不要在同一輪中同時修改 DNS、MTU、Global Routing 與節點。
第一層：檢查本地網路與裝置接入
請求從應用程式送出後，必須先經過裝置目前使用的網路，再進入系統建立的 VPN 通道。Wi‑Fi 訊號弱、路由器繁忙、接入網路切換或區域網路封包遺失，都可能在流量抵達遠端節點前造成延遲。此時更換協定通常無法解決根本原因。
在 iPhone 或 iPad 上，可以先靠近無線路由器測試，再切換到另一個已知穩定的 Wi‑Fi 重新測試。條件允許時，也可以比較行動網路，但兩組測試必須使用相同節點與相同目標。若某個 Wi‑Fi 下所有節點都變慢，而另一個網路恢復正常，問題更可能位於本地接入層。
也要留意「剛連線時很快，幾分鐘後逐漸變慢」的現象。這可能來自無線訊號干擾、路由器負載變化，或裝置在不同接入點之間切換。可以先保持螢幕開啟完成一輪短測試，再進行五至十分鐘的持續傳輸，比較短連線與長連線的差異。
- 所有節點同時變慢：優先檢查 Wi‑Fi 訊號、路由器負載與目前接入網路。
- 只有一個節點變慢：本地網路通常不是首要嫌疑，應繼續檢查節點與線路。
- 網頁首次開啟很慢、開啟後正常：重點檢查 DNS、連線建立與 TLS 交握階段。
- 小檔案正常、大檔案持續變慢：重點觀察線路吞吐量、封包遺失、MTU 與壅塞控制。
- 切換網路後立即恢復：保留原有 Shadowrocket 設定，先處理原本的網路環境。
第二層：用 Ping 與分時測試定位節點和線路
在 Home 的節點清單中執行可用的延遲或 Ping 測試時，不要只看一次結果。單次 60 ms 不能證明線路穩定；連續結果為 58 ms、62 ms、61 ms，通常比 35 ms、240 ms、90 ms 更可預測。後者雖然最低值較好，但抖動明顯，網頁與影片仍可能出現停頓。
Ping 也可能受到遠端回應策略影響，因此只能作為初步指標。若延遲測試正常但實際存取很慢，應繼續進行真實傳輸測試，並查看 Log 中連線建立、逾時與重試的時間分布。遠端沒有回應 Ping，也不代表對應服務一定無法使用。
線路時段同樣重要。可以在早上、晚上及問題出現的固定時段，對同一個節點執行相同測試。如果只有晚上吞吐量下降，而本地基準與其他節點正常，現象更符合特定線路或遠端資源在該時段壅塞。
錯誤：timeout
原因與解法：連線未能在限定時間內完成，可能是本地封包遺失、遠端節點繁忙或中間線路不穩定。先在同一網路測試另一個自有節點，再更換網路重新測試，透過兩次對照確認範圍。
錯誤：connection refused
原因與解法：目標位址可以到達，但指定連接埠拒絕連線。核對節點位址、連接埠與協定是否與使用者自己的服務商資料一致；連接埠 443 只是常見範例，不代表所有設定都應改成 443。
錯誤：Network is unreachable
原因與解法：目前網路沒有可用路徑，或網路在 Wi‑Fi 與行動網路切換時短暫中斷。等待系統網路穩定後重新連線，再檢查這個錯誤是否持續出現。
第三層：核對 Global Routing、規則與 DNS
節點本身正常，但部分網站很慢或只有某些應用程式變慢時，應檢查 Global Routing。Proxy 表示請求統一使用目前的代理策略，Direct 表示直接連線，Config 依設定檔規則處理，Scene 則依已設定的場景選擇行為。排查日常設定時，通常先確認目前是否處於預期的 Config，而不是誤停留在 Direct 或 Proxy。
在 Config 模式下，一個請求會由上到下比對規則。DOMAIN-SUFFIX 依網域後綴比對，GEOIP 依目標 IP 的地理資料庫結果比對，IP-CIDR 依位址範圍比對，FINAL 處理前面規則都未命中的請求。順序錯誤可能讓原本應 Direct 的請求進入代理，也可能讓需要代理的請求提前命中 Direct。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY以上語法僅用於說明比對順序，不代表適合所有設定。第一條將指定範例網域交給 PROXY，第二條讓區域網路位址 Direct，第三條依 GEOIP 結果 Direct，最後由 FINAL 接收其餘請求。實際策略名稱必須與目前 Config 中存在的策略一致。
如果現象是「Ping 正常但網頁長時間空白」，也應檢查 DNS。網域解析發生在建立目標連線之前；解析逾時、回傳無法到達的位址，或不同網路下快取結果不一致，都可能表現為首屏載入緩慢。不要同時替換多項 DNS 設定，先恢復到已知可用的設定，再逐項比較。
- 先在 Home 確認目前節點與 Config 名稱。
- 確認 Global Routing 沒有意外停留在 Direct 或全域 Proxy。
- 在 Config 中檢查目標網域最先命中的規則，而不是只查看 FINAL。
- 對於「網域無法開啟但 IP 可以連線」的現象，優先查看 DNS 解析過程。
- 修改規則後重新建立連線，避免把既有連線的快取結果當成新規則的結果。
第四層：比較協定與傳輸參數
Shadowrocket 支援 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等協定。協定名稱本身不能直接決定速度；實際表現還取決於伺服器設定、加密方式、傳輸層、線路封包遺失、CPU 負載，以及參數是否相符。只有在相同網路、路徑條件接近時，協定比較才有意義。
修改前應保存使用者自己的服務商提供的原始參數。位址、連接埠、密碼、UUID、公鑰、SNI、Transport、TLS 與路徑需要成組相符。只複製位址與連接埠、遺漏其他欄位，可能出現可以建立連線但不斷重試、交握失敗或傳輸效率異常的情況。
- Shadowsocks：核對加密方式、密碼與連接埠。用戶端與伺服器參數不一致時，通常無法正常完成資料交換。
- VMess 與 VLESS：核對 UUID、Transport、TLS、Host、Path 與 SNI。WebSocket 路徑或 Host 錯誤會影響交握。
- Trojan：重點核對密碼、TLS 與 SNI。憑證名稱與目標名稱不相符時，可以在 Log 中看到 TLS 相關錯誤。
- Hysteria2：在高封包遺失網路中的表現，與頻寬、壅塞控制及伺服器限制有關。不要脫離伺服器設定單獨填寫頻寬參數。
- WireGuard：核對公鑰、私鑰、Address、Endpoint 與 Allowed IPs。若小型請求正常而較大傳輸停滯，可在服務商說明允許的範圍內比較 MTU，例如依序測試 1280、1380 與 1420，每次只修改一個數值。
MTU 不是越小越好。過大時，部分路徑可能發生分片或封包丟棄；過小時，每個資料封包承載的有效資料減少，額外負擔上升。測試 MTU 時應使用同一節點與同一傳輸工作，並在每輪修改後重新連線。若服務商明確指定數值，應優先維持指定值。
On Demand 主要用於依網路條件自動建立連線，不是測速加速開關。若排查期間出現連線自動中斷或切換，可進入 Settings → On Demand，暫時檢查現有規則是否依 SSID、網域或網路狀態觸發。記錄原本設定後再調整，測試結束後依實際使用需求恢復。
第五層：從 Log 判斷連線在哪個階段變慢
Log 的價值不是顯示籠統的「快」或「慢」，而是展開請求經過的各個階段。進入 Settings → Log，在清除既有記錄後重現一次問題，再依時間查看 DNS、連線、TLS、規則命中與重試資訊。只保留一次重現過程，通常比在大量歷史記錄中搜尋更容易定位。
如果同一個網域在短時間內反覆解析，之後才建立連線，應檢查 DNS。若 TCP 建立後長時間停在 TLS handshake，重點核對系統時間、SNI、TLS 參數與遠端回應。若連線迅速建立，但傳輸過程中連續出現 timeout 或 retry，則更接近封包遺失、壅塞或遠端負載問題。
錯誤：TLS handshake failed
原因與解法：TLS 協商未完成。核對節點中的 SNI、Host、TLS 開關與使用者自己的服務資料，確認裝置時間已自動同步，再重新連線測試。
錯誤：DNS lookup failed
原因與解法：網域解析沒有取得可用結果。先比較其他網域是否正常，再檢查 Settings 中的 DNS 設定，以及目前網路能否存取所設定的解析服務。
錯誤：connection reset by peer
原因與解法：遠端主動重設了已建立的連線，可能與參數不相符、遠端策略或線路中斷有關。保持本地網路不變，使用另一個自有節點進行對照，再向自己的服務商核對原節點狀態。
閱讀 Log 時應關注時間關係，而不是只截取最後一行。例如 DNS 用時 20 ms、建立連線用時 70 ms，但 TLS 階段等待數秒，瓶頸就不在網域解析。相反地，如果連線前已反覆出現 DNS timeout，更換節點未必能解決問題。
清除舊記錄
開啟 Settings → Log，先清除與本輪測試無關的歷史內容。
重現一次問題
返回目標應用程式或網頁，只執行一次能穩定觸發變慢的操作。
找到第一筆請求
依網域、目標位址或時間定位請求起點，確認它命中了哪條規則與哪個策略。
查看等待階段
比較 DNS、建立連線、TLS 與資料傳輸之間的時間間隔，找出最長的停頓。
進行單變數重新測試
只更換網路、節點或一個參數，再重現一次。若對應錯誤消失，即可縮小故障範圍。
常見速度問題的直接判斷
完成以上分層後，可以依現象組合快速分類。分類的目的不是立即給出統一參數，而是決定下一步應該修改哪裡。使用者現有服務的具體節點狀態、連接埠與傳輸設定，應以自己的服務商資料為準。
為什麼 Ping 很低，下載仍然很慢？
Ping 測量的是回應延遲，不是持續吞吐量。固定同一個節點執行至少三次真實下載測試，同時觀察 Log 是否出現 timeout、retry 或連線重設。若延遲穩定但吞吐量持續偏低，應檢查線路容量、遠端負載與傳輸參數。
為什麼只有晚上明顯變慢？
先分別在早晚記錄本地基準與同一節點的結果。若本地網路正常，而該節點只在固定時段下降，再對照另一個自有節點；只有特定節點下降時，更接近線路的時段性壅塞。
為什麼網頁很慢，但應用程式中的小型請求正常？
網頁通常包含多個網域、TLS 連線與較大的靜態資源。檢查 Config 中各網域的規則命中情況，再從 Settings → Log 查看 DNS 與 TLS 階段是否反覆等待。
切換到 Proxy 後變快，Config 就一定有問題嗎？
這表示兩種模式產生了不同路徑，但還不能直接確定具體規則錯誤。返回 Config，查看目標網域最先命中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL，並核對其策略是否符合預期。
需要把所有協定參數都調整一遍嗎？
不需要。先保留服務資料中的原始值，只有在確認本地網路、節點狀態與規則都正常後，才針對 Log 中的現象修改一項參數。每次修改後重新連線並記錄結果。