Shadowrocket 連線後網速變慢怎麼排查：節點、線路、協定與本機網路分層檢查

一、先固定測試條件，確認慢在哪裡

連線開關已開啟，只能表示系統通道已建立，不能證明目標請求已成功經過所選節點。網頁首頁載入緩慢、持續下載速度慢與影片頻繁緩衝也不是同一種問題：前者可能與 DNS 和連線建立有關，後兩者則更需要觀察持續傳輸速度與穩定性。

先在 Home 記下目前使用的節點、Global Routing 狀態與本機網路，再確認 Config 中正在使用的設定檔。測試期間不要同時更新訂閱、更換 DNS、切換協定及修改規則，否則即使速度恢復，也無法判斷是哪項變更發揮作用。

1. 選擇一個你有權存取、可以重複載入的固定網頁或檔案，並記下目標名稱。不要直接比較兩個不同網站的下載速度。
2. 暫停系統更新、照片同步及其他大量傳輸工作。連續測試 3 次，每次約 30 秒，記錄首頁載入等待時間、持續速度及是否中斷。
3. 統一速度單位。1 MB/s 約等於 8 Mbps；檔案下載顯示的 MB/s 與寬頻方案標示的 Mbps 並非相同數值。
4. 每輪只變更一項條件，並在相近時段進行對照。使用行動網路測試會消耗數據，開始前請確認資費方案的剩餘流量。

二、節點層：先分辨可連線與有持續傳輸速度

在 Home 對現有節點執行 Connectivity Test，先排除明顯無法連線的項目。延遲測試反映的是特定測試方式下的回應狀況，不等於下載頻寬；測試目標、交握流程及是否經過代理都會影響數值，因此不能只憑最低毫秒數判斷使用體驗。

從現有訂閱中選取兩個節點，盡量使用相同協定，並以同一個目標、同一個本機網路進行比較。若只有其中一個節點持續偏慢，問題範圍可縮小到該節點或其連線路徑，但仍不能直接判定是伺服器負載所致。

三、線路層：交叉比對時段與網路

線路並不是節點清單中的獨立開關。一次連線至少包含本機網路至伺服器，以及伺服器至目標網站兩段路徑；即使節點名稱與地區相同，實際路由、壅塞情況和目標內容傳遞方式仍可能改變。地理位置接近，不代表網路路徑較短，也不保證尖峰時段穩定。

1. 同一節點更換網路：在 iPhone 上關閉 Wi-Fi，改用行動網路存取相同目標；接著切回 Wi-Fi 重測。其他條件維持不變。
2. 同一網路更換時段：分別在問題發生時段與較不繁忙的時段測試，記錄時間與持續速度，不要只寫「晚上很卡」。
3. 同一節點更換目標：測試兩個不同網站。若只有一個目標速度慢，應優先檢查出口至該目標的路徑，而非繼續修改本機 DNS。
4. 整理交叉測試結果：記錄「Wi-Fi 慢、行動網路正常」或「兩種網路在相同時段都慢」。前者優先檢查 Wi-Fi 接入及其上游路徑；後者則搭配節點與目標測試結果判斷。

同一節點在兩種網路下的差異，無法完全區分「電信業者線路」與「本機無線環境」。若 Wi-Fi 下所有連線都慢，請先完成後文的本機網路檢查；若只有特定代理路徑速度慢，再繼續縮小線路範圍。不同節點也可能共用上游線路，因此多個節點同時變慢，不一定代表有多個獨立故障。

四、協定層：確認傳輸條件，不要盲目更改連接埠

協定名稱不代表速度等級。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 的傳輸條件和設定欄位各不相同，能否使用取決於伺服器的實際部署。不能只把現有節點的協定下拉選項換成另一個名稱，就視為完成協定比較。

連接埠為 443，不代表一定使用 TCP，也不表示流量一定能通過。Hysteria2 可以使用 UDP 443，但實際連接埠仍由伺服器決定。若網路限制 UDP，依賴 UDP 的連線可能失敗或不穩定；反之，UDP 可用也不代表壅塞時能有較高的持續傳輸速度。

• 核對服務商提供的伺服器位址、連接埠與驗證資訊；若涉及 TLS，也要確認對應的伺服器名稱與憑證驗證設定，不要以關閉驗證取代問題排查。
• 只有在現有設定提供可比較的不同協定入口時，才進行協定比較。若伺服器與線路也同時改變，請標記為「多變數比較」，不能將所有差異都歸因於協定。
• 若小型請求正常，但大型檔案傳輸反覆停頓，請先完成更換網路的測試；MTU 或路徑 MTU 只是可能原因之一，未留下測試記錄前，不要連續修改多個數值。

以上是連線記錄中可能出現的底層錯誤訊息，並非每次故障都一定會顯示。保留完整的前後文，比只留下最後一行更有助於排查。

五、本機網路與規則：確認請求實際經過的路徑

返回 Home 檢查 Global Routing。Proxy、Direct、Config、Scene 分別代表不同的路由方式：Proxy 與 Direct 分別偏向全域代理或直連；Config 依目前設定檔處理；Scene 則會套用所選場景的設定。進行對照測試前，先記下原有狀態；暫時切換後記得還原，避免診斷結束後仍使用錯誤的路由設定。

1. 檢查本機網路接入：移至路由器附近重測，並確認 Wi-Fi 沒有等待網頁驗證；若裝置網路允許，且目標可直接連線，可暫時關閉連線進行基準測試。若直連也很慢，應先處理網路接入問題。
2. 檢查規則命中策略：在 Config 確認目前使用的設定檔，再透過連線記錄確認測試目標命中了哪條規則、使用了哪個策略與節點。選取某個節點，不代表所有請求都會經過該節點。
3. 檢查規則順序：DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對 IP 位址範圍，GEOIP 根據 IP 地理資料比對，FINAL 用於最終兜底。先確認前面的規則是否已命中，不要只修改最後一條。
4. 檢查自動重新連線：若測試期間連線狀態自行變更，請查看 Settings → On Demand。先記下現有條件，再暫時關閉相關的自動連線行為，手動測試完成後恢復設定。

只有在測試現象指向 DNS 時，才需要排查 DNS：例如首次開啟時等待明顯，但連線建立後持續下載正常。先確認是否有解析逾時、解析失敗或目標位址異常，再核對目前設定檔中的 DNS 設定。不要把「換一個 DNS」當成所有網速慢問題的通用解法，也不要任意關閉憑證驗證或擴大直連範圍。

六、常見問題與停止排查的時機

一份有效的問題回報應包含：發生時間、Wi-Fi 或行動網路、節點識別資訊、協定、Global Routing 狀態、目標、速度單位及對照結果。排查的目的不是找出一組「最快設定」，而是確認故障影響哪個環節，以及接下來應由哪一方檢查。若客戶端以外的網路接入或遠端路徑已呈現一致異常，繼續修改本機設定通常無法解決問題。