本文速覽

本文適合已在 Shadowrocket(小火箭)中匯入自有服務商設定,且連線成功但網頁回應或檔案傳輸速度偏慢的使用者。排查時固定測試對象與時間,依序檢查節點狀態、傳輸線路、協定參數與本地網路,再透過 Global Routing、Connectivity Test 與重複測試結果判斷問題所在。

先定義「速度慢」,再固定測試條件

「連線成功」只代表系統通道已建立,不表示從裝置到目標網站的整條路徑都處於理想狀態。一次請求通常會經過本地 Wi-Fi 或行動網路、系統 VPN 通道、Shadowrocket 規則比對、使用者既有伺服器,以及目標網站。任何環節出現排隊、封包遺失或解析等待,最後都可能呈現為頁面持續載入。

先區分三種現象。第一種是啟動慢:網頁長時間空白,之後載入速度恢復正常,通常與 DNS、建立連線或等待首個位元組有關。第二種是持續慢:大檔案從開始到結束都維持低速,應優先檢查線路吞吐量、伺服器負載與本地網路。第三種是抖動:速度時快時慢,影片頻繁切換畫質,通常需要留意封包遺失、無線干擾與尖峰時段負載。

應用程式發起請求本地網路接入系統 VPN 通道規則比對分流伺服器對外連線目標網站回應
  1. 固定測試網站

    選擇同一個可穩定存取的網頁,以及同一個大小明確的測試檔案。不要直接比較不同網站,因為目標網站本身的頻寬與快取策略各不相同。

  2. 固定設定

    在 Home 維持相同節點、相同 Global Routing 狀態與相同網路接入方式,先連續測試 3 次,並記錄首次回應時間與持續傳輸速度。

  3. 停止背景工作

    暫停照片同步、應用程式更新、雲端備份與其他大量傳輸工作,否則系統頻寬競爭會使測試結果失去可比性。

  4. 逐項變更變數

    每輪只調整一個因素,例如只更換節點,或只從 Wi-Fi 切換至行動網路。一次變更多個參數,便無法判斷是哪一項產生效果。

第一層:檢查節點負載與伺服器回應

節點層排查關注的是使用者既有伺服器能否及時接受連線並處理資料。延遲低不代表吞吐量一定高:Connectivity Test 顯示的毫秒數主要反映一次連線或請求往返所需的時間,而持續下載速度還會受到伺服器出口頻寬、並行負載與目標網站限制影響。

在 Home 的節點清單對目前節點執行 Connectivity Test,記錄測試成功、逾時,以及延遲是否大幅波動。在不同介面配置下,測試入口可能位於節點操作選單中,請以應用程式內目前顯示為準。若 3 次結果分別為 85 ms、92 ms、410 ms,第三次明顯偏離前兩次,表示鏈路或伺服器可能存在抖動;若每次都能快速完成,但大檔案持續低速,則繼續檢查線路吞吐量。

  1. 確認目前節點

    返回 Home,查看實際選取的伺服器項目,避免將訂閱群組名稱誤認為目前的對外連線節點。

  2. 執行連線測試

    對同一節點連續執行 3 次 Connectivity Test,每次間隔約 5 秒,記錄是否成功以及延遲波動範圍。

  3. 同組交叉驗證

    在自己的服務商設定中選擇另一個已知可用的節點,只更換節點並重複相同測試。若新節點恢復正常,問題更可能位於原節點或其上游路徑。

  4. 確認訂閱狀態

    在 Home 下拉更新既有訂閱,確認伺服器位址與連接埠仍是服務商目前提供的值。訂閱網址範例只能使用類似 https://example.com/sub?token=xxxx 的格式說明,實際資訊應向自己的服務商確認。

錯誤:The request timed out

原因與解法:連線在規定時間內沒有收到回應,可能是節點暫時壅塞、線路封包遺失或伺服器無法連線。維持其他條件不變並重複測試,再切換至自己設定中的另一個可用節點交叉驗證。

錯誤:Connection reset by peer

原因與解法:遠端或中間網路主動重設了連線。先核對伺服器位址、連接埠、密碼、UUID 與傳輸參數;若設定無誤但持續發生,應請對應服務商檢查伺服器端狀態。

錯誤:Failed to load subscription

原因與解法:訂閱連結可能已失效、回應逾時或存取條件發生變化。確認連結來自自己的服務商,在 Home 下拉重新整理;仍然失敗時,向服務商核對連結有效性。

不要只根據節點名稱中的地區文字判斷快慢。名稱只是設定標籤,不能直接代表實際路由、負載與出口品質。有效的判斷依據應包括重複測試是否成功、延遲波動、首次回應時間,以及固定檔案的持續傳輸表現。

第二層:判斷線路延遲、封包遺失與尖峰壅塞

線路是裝置到伺服器之間經過的網路路徑。即使伺服器本身負載正常,不同接入網路、電信業者路徑與時段也可能產生明顯差異。典型線路問題包括延遲穩定但偏高、延遲突然升高、間歇性逾時,以及小型網頁可用但長連線傳輸持續降速。

線路測試的關鍵是比較時間與接入方式。維持 Shadowrocket 節點與協定不變,在 Wi-Fi 下完成一輪測試,再切換至行動網路完成另一輪。如果只有一種接入方式明顯偏慢,應優先檢查該本地網路及其通往伺服器的路徑,而不是直接修改協定參數。

觀察結果 優先判斷 下一步動作
Wi-Fi 慢,行動網路正常 路由器、無線干擾或寬頻路徑 靠近路由器、切換頻段並重新啟動網路設備後再測試
兩種網路都只有一個節點慢 節點負載或節點上游線路 使用自有設定中的另一個節點交叉驗證
所有節點只在單一網站速度慢 目標網站、DNS 或規則命中結果 查看請求是否依預期使用 DIRECT 或代理策略
晚間速度普遍下降 尖峰時段壅塞 在早晚相同條件下各測試 3 次,並比較中間值

第三層:核對協定與傳輸參數開銷

Shadowrocket 支援 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等設定類型。不同協定的握手方式、加密處理、傳輸層與封包遺失復原機制各不相同,但不能脫離伺服器端設定,單獨判斷哪一種一定更快。用戶端參數必須與伺服器端逐項匹配。

協定層問題常被誤判為線路速度慢。例如傳輸方式、TLS、SNI、Path、密碼或 UUID 填寫不一致時,可能出現反覆握手、連線重設或完全無法連線;UDP 受限時,依賴 UDP 特性的設定可能出現測速不穩定。此時反覆切換 Global Routing 不會修正參數錯誤。

設定類型 排查重點 常見判斷現象
Shadowsocks 伺服器位址、連接埠、密碼與加密方式 任何一項不一致,通常會導致連線失敗或立即中斷
VMess / VLESS UUID、TLS、SNI、Transport 與 Path 握手逾時或重設時,先核對完整參數組合
Trojan 密碼、TLS、SNI 與憑證相關設定 TLS 階段異常可能表現為無法建立連線
Hysteria2 UDP 可達性、驗證資訊與伺服器參數 在受限網路中可能出現抖動或無法完成連線
WireGuard 金鑰、Endpoint、Allowed IPs 與 MTU 部分網站卡住但小型請求正常時,可檢查 MTU
  1. 儲存原始設定

    修改前記錄目前的伺服器位址、連接埠與協定參數。不要憑猜測批次調整 TLS、MTU、Transport 或 UDP 相關選項。

  2. 核對伺服器端資訊

    將 Home 中的節點詳細資料與自己的服務商目前設定逐項比較,尤其檢查大小寫、Path 開頭的斜線、SNI 與連接埠。

  3. 只修改一個參數

    每次只修正一個明確不一致的欄位,儲存後重新連線並重複相同測試,避免之後無法追溯。

  4. 恢復原值

    如果調整後沒有改善或出現新錯誤,立即恢復已記錄的原始設定,再繼續排查其他層面。

MTU 只應在有明確分片或特定網站卡頓證據時調整。數值過大可能造成部分資料封包無法通過,數值過小則會增加封包標頭比例與處理次數。不要將某個網路環境下有效的 MTU 數值直接套用到所有設定。

第四層:排除本地 Wi-Fi、行動網路與背景流量

本地網路是最容易被忽略的一層。裝置距離路由器過遠、同頻干擾、路由器長時間高負載、寬頻上傳頻寬被占用,都會讓 Shadowrocket 表現為延遲升高。此時即使關閉連線後存取本地網站也可能變慢,因此應先比較未啟用與啟用連線時的結果。

Wi-Fi 訊號圖示滿格,只代表裝置收到的無線訊號較強,並不直接表示網際網路出口沒有壅塞。2.4 GHz 通常覆蓋範圍較大,但更容易受到同頻裝置影響;5 GHz 在近距離下通常有較高可用頻寬,但穿牆衰減更明顯。具體頻段名稱與切換方式由路由器決定。

  1. 關閉背景傳輸

    暫停雲端照片同步、系統備份、應用程式更新與區域網路檔案傳輸,等待約 30 秒後重新測試。

  2. 靠近路由器

    在沒有遮蔽物的近距離位置測試同一節點。如果延遲波動明顯下降,應優先處理無線覆蓋或干擾問題。

  3. 切換接入網路

    維持節點、協定與 Global Routing 不變,從 Wi-Fi 切換至行動網路,重複相同的網頁與檔案測試。

  4. 重新建立網路連線

    關閉 Shadowrocket 連線開關,重新連線目前網路,再重新開啟連線。若仍然異常,可依照裝置與路由器的正常操作流程重新啟動後再測試。

  5. 檢查 On Demand

    進入 Settings → On Demand,確認規則沒有在 Wi-Fi 與行動網路切換時反覆連線或中斷。排查期間可先記錄原始設定,再暫時停用並手動連線測試。

錯誤:Network is unreachable

原因與解法:裝置目前沒有可用的網路路徑,或網路切換期間路由尚未恢復。先確認 Wi-Fi 或行動網路本身可以存取網際網路,再關閉並重新開啟 Shadowrocket 連線。

錯誤:The Internet connection appears to be offline

原因與解法:系統偵測不到可用的網際網路連線。先在關閉 Shadowrocket 的情況下驗證本地網路,恢復接入後再重新建立系統 VPN 通道。

檢查 Global Routing、規則命中結果與 DNS 等待

速度問題也可能來自流量走錯路徑。Shadowrocket 的 Global Routing 常見狀態包括 Proxy、Direct、Config 與 Scene。Proxy 讓流量統一使用代理策略,Direct 讓流量直接連線,Config 依照 Config 中的規則由上至下比對,Scene 則依照設定的情境處理。排查時必須確認目前狀態與預期一致。

如果 Global Routing 停留在 Direct,目前節點不會承擔相應的代理流量;如果停留在 Proxy,原本應使用 DIRECT 的本地資源也可能繞行。日常使用 Config 時,規則順序尤其重要。Shadowrocket 命中第一條符合條件的規則後,通常不會繼續向下檢查,因此寬泛規則放在前面可能遮蔽後續的精確規則。

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

上例僅用於說明比對順序:example.com 先依 DOMAIN-SUFFIX 使用 PROXY;區域網路位址依 IP-CIDR 直接連線;其餘符合 GEOIP 條件的流量使用 DIRECT;未命中前述規則的請求最後落到 FINAL。實際策略名稱必須與自己的 Config 中定義的內容一致。

DNS 等待通常表現為首次開啟網域速度很慢,但重新整理同一頁面後會加快。排查時可比較存取網域與存取已知可用 IP 資源的差異,但不要隨意填入未知的 DNS 位址。還應檢查 Config 中是否存在需要解析後才能判斷的 GEOIP 或 IP-CIDR 規則,以及 `no-resolve` 是否用於不需要觸發解析的情境。

現象:Connected but no traffic

原因與解法:系統通道已建立,但規則、DNS 或伺服器對外連線沒有產生有效回應。先檢查 Global Routing 是否誤設為 Direct,再使用 Config 逐條確認目標網域的第一個命中結果。

依固定順序重新測試並記錄結論

完成單層調整後,應回到最初固定的測試對象,而不是更換網站後憑主觀感受判斷。建議記錄日期、時間、接入網路、節點標籤、協定、Global Routing、3 次延遲、首次回應表現與持續速度。只要記錄欄位一致,後續就能辨識是偶發波動還是穩定差異。

延遲很低,為什麼下載速度仍然很慢?

延遲反映單次往返時間,不代表伺服器出口與整條路徑的持續吞吐量。固定一個大小明確的檔案連續測試 3 次,同時檢查節點負載與尖峰時段的線路表現。

更換節點後立即變快,可以直接下結論嗎?

先在相同網路、相同 Global Routing 與相同測試對象下重複 3 次。若原節點持續偏慢而新節點持續正常,才能將範圍縮小至原節點或其上游線路。

Wi-Fi 慢但行動網路正常,該怎麼辦?

維持 Shadowrocket 設定不變,靠近路由器重新測試,並暫停背景同步。近距離恢復正常時,檢查無線覆蓋;仍然偏慢時,檢查路由器負載與寬頻路徑。

訂閱更新失敗會影響既有節點嗎?

既有項目可能暫時保留,但無法取得服務商後續的設定變更。先在 Home 下拉更新;出現 Failed to load subscription 時,向自己的服務商確認連結與存取條件。

應該長期使用 Proxy 進行測試嗎?

Proxy 適合在排查時驗證統一的代理路徑,但會繞過 Config 的分流結果。測試結束後應恢復原有狀態,並檢查 DOMAIN-SUFFIX、GEOIP、IP-CIDR 與 FINAL 的實際命中順序。

  1. 先在目前網路與目前節點完成基準測試,連續記錄 3 次結果。
  2. 只更換節點,判斷伺服器負載或節點上游路徑是否異常。
  3. 只切換 Wi-Fi 與行動網路,判斷本地接入與線路差異。
  4. 核對協定參數,不要憑猜測修改連接埠、TLS、Transport 或 MTU。
  5. 檢查 Global Routing、Config 規則順序與 DNS 首次回應。
  6. 恢復原始設定,使用相同對象再測試 3 次,並保留中間值作為結論。

Shadowrocket 是 Apple 平台上的付費商業應用程式,iPhone 與 iPad 是主要使用裝置,商店相容性欄也可能列出 Mac、Apple TV 與 Apple Vision;系統要求以 App Store 頁面標示為準。唯一取得入口是 App Store,產品頁上的開發者應顯示為 Shadow Launch Technology Limited,應用程式 ID 為 932747118,購買方式為一次買斷。用戶端購買與使用者自己的線路服務是兩件不同的事。