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

開始前：固定測試條件，區分延遲與傳輸速率

先說結論：Connectivity Test 的結果不等於下載速度。延遲代表完成一次測試請求所需的時間；持續傳輸則還會受到可用頻寬、封包遺失、壅塞及目標伺服器限速等因素影響。測試回應很快的節點，大檔案傳輸仍可能很慢；某個網頁開啟緩慢，也不能直接證明整體連線都很慢。

在 Home 記下目前選取的節點與 Global Routing。若原本使用 Config，先保留目前設定作為基準；需要排除規則影響時，再短暫切換至 Proxy，並確認待測請求確實經過選取的節點。Scene 涉及情境選擇，本輪比對時不要一併更動；Direct 也不能代表代理線路的速度。

1. 選定同一個日常使用的目標，分別觀察首次開啟、再次開啟與持續傳輸；不要拿不同網站互相比較。
2. 暫停其他裝置的大量資料傳輸，記下測試時間、網路類型、節點名稱、Global Routing，以及是否發生逾時。
3. 每種條件重複測試 3 次，記錄各次結果或中位數，不要只保留最快的一次。
4. 每次只變更一個變數，變更後重新建立連線；測試結束後還原原本的 Global Routing。

第一層：節點是否可用，還是只有測試回應正常

在 Home 對目前節點執行 Connectivity Test，再以實際請求驗證。測試成功只能表示在該測試條件下可以連線；測試失敗時，則要分辨是伺服器無法連線、驗證錯誤，還是測試目標無法連線。不要反覆重新整理訂閱來代替節點診斷；更新清單本身無法解決遠端負載或線路壅塞。

1. 確認節點位址、連接埠、協定及驗證欄位，是否與使用者現有資訊相符。連接埠必須使用服務商實際提供的值；即使看到常見的 443，也不能自行把其他連接埠改成這個值。
2. 在相同網路與 Global Routing 下，選取現有清單中的另一個節點，重複相同請求。盡量先選擇協定相同的項目，以減少變數。
3. 若只有一個節點反覆失敗，記下測試時間與錯誤訊息；若所有節點都很慢，接著檢查共用線路、本地網路與測試目標。
4. 若懷疑節點資訊已變更，依照原本的 Subscribe 更新方式重新整理一次，並確認目前選取的項目。不要把訂閱更新成功誤認為節點已成功連線。

以下是連線記錄中常見的錯誤片段，完整措辭會因協定及底層連線而異。這些訊息只能作為排查線索，不能單獨用來判定原因；還要確認錯誤發生在網域解析、建立連線或傳輸階段。

第二層：如何分辨線路壅塞與規則分流

節點是連線的遠端入口；線路則包括本地接取、電信業者路徑、節點出口，以及從出口到目標網站的路徑。名稱不同的兩個節點也可能共用部分線路。因此，「換了節點還是很慢」不能單獨排除線路問題；同樣地，某個測試目標正常，也不代表所有目標都正常。

Config 會依照目前設定中的規則決定請求的路徑；Proxy 可用來比對代理模式，但仍須確認實際請求記錄。規則會依序比對，前面的規則可能使後面的規則無法生效。以下僅用來說明語法關係，不是可直接取代現有設定的完整檔案，也不代表這些策略適用於所有目標。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX 依網域後綴比對；IP-CIDR 依 IP 網段比對；GEOIP 依據 IP 地理資料比對；FINAL 用來處理先前未匹配的請求。若某個請求實際走的是 DIRECT，繼續測試代理節點的延遲，無法解釋該請求為何緩慢；應先確認命中的規則。

第三層：確認協定參數正確，比直接更換協定更重要

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的傳輸與驗證機制各不相同，不能只更改節點的協定名稱就算完成切換。每種連線都需要相應的伺服器支援及完整參數。只在使用者現有且已確認可用的設定之間進行比對；若兩筆設定使用不同伺服器，測得的差異不能全歸因於協定。

• Shadowsocks：確認加密方式與密碼；若使用外掛程式，也要確認伺服器要求的外掛程式及其參數。
• VMess／VLESS：確認身分欄位、傳輸方式及 TLS 等參數。使用 WebSocket 或 gRPC 時，對應的路徑或服務名稱也必須與伺服器一致。
• Trojan：確認密碼與 TLS 伺服器名稱。若連線因憑證驗證失敗，應檢查時間、網域與憑證鏈，不應以關閉驗證來加速。
• Hysteria2：以 QUIC 為基礎，並仰賴可用的 UDP 路徑；若目前網路限制 UDP，可能發生交握失敗或連線不穩，不能預設它在所有網路環境下都比較快。
• WireGuard：使用 UDP，須確認金鑰、端點及路由相關參數。小型請求正常、較大的傳輸卻停滯時，可將 MTU 列入檢查項目，但應先排除封包遺失與伺服器問題。

這個流程說明「連線開關已開啟」與「目標內容能穩定傳輸」並非同一種狀態。交握異常時，通常應優先檢查驗證、TLS 或底層傳輸；交握完成後才開始持續變慢，則進一步檢查封包遺失、壅塞、遠端負載與目標回應。不要同時修改 MTU、DNS、協定與節點，否則即使恢復正常，也無法判斷是哪項變更造成的。

第四層：檢查 Wi‑Fi、行動網路與 DNS

保持相同節點與目標，依序測試 Wi‑Fi 和行動網路，是區分本地連線差異的直接方法。切換前請留意行動數據用量；切換後等網路穩定，再重新建立連線。兩種網路的結果不同，表示接取環境或路徑有差異，但還不能據此判定問題一定出在路由器、電信業者或節點。

1. 確認基本連線：暫時中斷 Shadowrocket，開啟一個原本可直接存取的常用網頁。如果基本連線也很慢，先處理本地網路；不要用原本就無法直接存取的目標來驗證。
2. 檢查 Wi‑Fi 狀況：靠近路由器重新測試，暫停區域網路中的大量資料傳輸，並確認已完成公共 Wi‑Fi 的登入驗證。訊號格數無法完整反映可用頻寬。
3. 分辨解析與傳輸：如果首次開啟要等很久，之後內容傳輸卻正常，請檢查 DNS 請求是否逾時或反覆重試。不要只因為這個現象就更換所有 DNS 設定。
4. 檢查自動連線的影響：在 Settings → On Demand 中確認現有條件，觀察切換網路時是否觸發重新連線。若要建立手動測試基準，可先記下原有設定，暫時關閉 On Demand，測試後再還原。
5. 保留 IPv6 相關資訊：如果問題只在特定網路發生，記錄解析結果是否包含 IPv6 位址，以及相關連線是否失敗。沒有比對結果時，不要把關閉 IPv6 當成通用解決方案。

DNS 變更會影響名稱解析方式及後續可能使用的位址，不會直接增加線路頻寬。若下載已開始且持續緩慢，反覆更換 DNS 通常無法找出頻寬瓶頸。反之，若請求卡在解析階段，就應先檢查解析結果與請求路徑，而不是繼續調整協定參數。

常見問題：延遲很低、更新訂閱與夜間變慢

整理測試結果：以可重現的紀錄完成排查

四層排查的目的在於縮小問題範圍，而不是重新設定所有選項。完成比對後，還原原本的 Global Routing 和 On Demand；沒有證據支持的變更也應還原。若需要自己的服務商協助，只提供必要的現象與連線資訊，不要公開完整訂閱連結、密碼、私鑰或驗證權杖。

• 環境：iPhone 或 iPad、Wi‑Fi 或行動網路、發生時間與持續時間。
• 連線：已選節點的辨識名稱、協定、Global Routing，以及是否使用相同目標重新測試。
• 結果：3 次測試的原始紀錄、實際存取狀況、錯誤片段，以及切換另一種網路或另一個現有節點後的比對結果。
• 已執行的操作：逐項列出曾變更的設定及是否已還原，讓下次檢查能從已知狀態開始。