適用於已有自己的服務商與訂閱，且 Shadowrocket 已能連線，但開啟網頁或傳輸檔案速度緩慢的情況。先分辨延遲、傳輸速度與初次載入等待，再固定測試條件，依序檢查本地網路、節點、線路與協定。每次只變更一項，最後整理出可重現的故障紀錄，而非反覆更動所有設定。
一、先釐清「慢」的狀況：延遲、傳輸速度與初次載入等待
Shadowrocket（小火箭）的連線開關已開啟，只代表系統通道已啟動，不表示每個目標都能正常存取。Home 中的延遲測試也不等於持續頻寬測試：一次探測成功，無法排除稍後發生的封包遺失、壅塞、遠端限速或目標網站回應緩慢。
先確認問題發生在哪個階段。點選連結後長時間沒有內容，可能是在等待 DNS 解析、建立連線或完成 TLS 交握；頁面很快顯示文字，但圖片一直載入，可能是資源請求或持續傳輸受限；影片一開始播放正常，之後卻反覆緩衝，就要觀察數分鐘內的傳輸速度變化。不要只憑單一毫秒數判斷線路品質。
| 觀察到的現象 | 優先檢查項目 | 比對方式 |
|---|---|---|
| 只有第一次開啟時較慢 | DNS、建立連線、TLS | 連續開啟同一頁面三次，分別記錄第一次與後續的狀況 |
| 一開始很快，之後持續變慢 | 傳輸速度、壅塞、伺服器限速 | 連續傳輸同一個檔案 60 秒，記錄中段的速度 |
| 只有一個網站很慢 | 目標服務、流量分流結果、節點出口 | 保持節點不變，改用兩個平常會造訪的目標測試 |
| 所有 App 都同時變慢 | 本地網路、目前節點、共用線路 | 先比較 Wi-Fi 與 Cellular，再比較已有的節點 |
注意單位：Mbps 是每秒百萬位元，MB/s 是每秒百萬位元組。理想換算下，80 Mbps 約等於 10 MB/s；實際使用時還會有協定額外負擔。不要把 App 顯示的 8 MB/s，和方案標示的 80 Mbps 直接視為相差十倍。
二、建立可重複的測試基準
開始前先儲存目前使用的設定，並記下 Home 中選取的節點、Global Routing 模式，以及測試時使用的網路。以下步驟都使用你已有的參數，不涉及取得新的連線服務。測試盡量在短時間內完成，避免把不同時段的網路負載誤認為設定差異。
-
記錄目前狀態
在 Home 記下目前的節點與 Global Routing；前往 Config 確認目前使用的設定。檢查 Settings → On Demand 是否設有自動連線條件，只記錄原本狀態，不必為了測速先修改。
-
固定測試目標
選擇一個平常能開啟的網頁，以及一個允許測試的固定檔案。每輪都使用相同目標，並暫停雲端同步、照片上傳及其他大量傳輸工作，避免占用頻寬。
-
檢查流量分流
在 Home → Global Routing 檢查目前的選擇。Config 會依設定中的規則處理請求，Proxy 代表使用代理模式，Direct 代表直連模式；若使用 Scene，也要確認場景實際採用的設定，不能只看場景名稱。
-
重複測量
每種條件測試三輪，每輪約 60 秒，記錄中位表現。不要同時切換節點、協定與網路；測試前重新建立與目標的連線，避免瀏覽器沿用舊連線或快取，掩蓋實際變化。
-
還原原本設定
完成臨時比對後，還原原本的 Global Routing 與設定。如果曾調整 On Demand，也要恢復原本條件，再用日常 App 驗證，避免診斷設定影響後續使用。
三、本地網路層：先比較 Wi-Fi 與 Cellular
同一個節點在 Wi-Fi 下速度慢，切換至 Cellular 後恢復，表示差異與網路連線方式有關，但還不能直接判定是路由器故障。兩種連線會走不同的電信業者路徑，差異也可能出現在本地網路到節點之間。先縮小故障範圍，再決定是否檢查路由器或聯絡自己的服務商。
- 靠近無線基地台重新測試：使用同一台 iPhone 或 iPad，靠近路由器後再測一次。Wi-Fi 訊號格數無法完整反映干擾與重傳；若隔著牆速度明顯變慢，先排除無線訊號涵蓋問題。
- 確認實際使用的網路：在系統 Settings → Wi-Fi 確認目前連線的網路；切換至 Cellular 時，確認 Wi-Fi 已中斷連線。沒有行動數據功能的 iPad，可改用另一個已知正常的 Wi-Fi 比對，並記錄連線方式。
- 減少共用頻寬的裝置：暫停其他裝置的大型檔案上傳。上傳頻寬占滿時，網頁請求與傳輸確認也可能排隊，造成下載和互動操作都變慢。
- 排除網路連線限制：需要網頁認證的 Wi-Fi，應先完成認證。如果一般網頁在 Direct 模式下也很慢，先處理網路連線問題，再繼續檢查代理參數。
切換網路後，應重新發出請求，不要只觀察原本仍在下載的工作。連線可能因 IP 位址變更而中斷，或等待重試。如果問題只在切換後發生，可手動中斷連線，再重新連接 Shadowrocket 進行確認；On Demand 主要用來決定何時自動建立連線，並不是提升頻寬的開關。
四、節點與線路層：區分伺服器差異與時段差異
本文所說的「節點」，是指 Home 中一組伺服器連線參數；「線路」則是裝置連到該伺服器，再連至目標服務所經過的網路路徑。更換節點通常也會改變出口位置與網路路徑，因此「換一個就變快」只能證明速度與更換後的路徑有關，不能只憑這點認定舊伺服器效能不足。
從已有的節點中選兩個進行比對，盡量保持協定、目標與本地網路相同。如果只有一個節點持續緩慢，請確認其服務狀態、用量限制與參數是否有變更。如果多個節點只在晚間變慢、白天又恢復，應記錄發生時段，不要立刻重建所有設定。共用線路壅塞、入口負載與目標服務負載都可能造成這種情況。
| 固定條件 | 變更項目 | 範例數據 | 可得出的結論 |
|---|---|---|---|
| 同一個 Wi-Fi、同一個檔案 | 從節點 A 切換至節點 B | 從 0.8 MB/s 變為 5.2 MB/s | 繼續比較兩個節點及其路徑，先不要更改本地 DNS |
| 節點 A、同一個檔案 | 從 Wi-Fi 切換至 Cellular | 從 0.8 MB/s 變為 4.6 MB/s | 優先檢查網路連線，以及通往節點的路徑 |
| 同一個節點、同一個 Wi-Fi | 14:00 與 21:00 | 從 5.0 MB/s 變為 0.7 MB/s | 與時段有關，需連續多日重測才能進一步判斷 |
同時確認自己的服務商管理頁面，是否有流量用盡、服務到期或速率限制。Shadowrocket 的 Data 數據與服務商的計費方式可能不同，不能只用本地的某個累計數字，就直接否定管理頁面的限制資訊。若要更新已有訂閱，先儲存設定，再透過原本的訂閱入口更新，並確認選取的節點參數是否確實有所變更。
五、協定層：先核對參數，再比較傳輸差異
在 Home 開啟目前伺服器的編輯頁面，依照已有的服務商參數核對 Type、位址與連接埠。連接埠號碼本身不代表協定或速度：服務端指定 443，就填入 443；不要因為另一個連接埠看起來常見就自行更換。修改本地連接埠，不會讓服務端自動提供相應服務。
- Shadowsocks：核對加密方式、密碼，以及服務端要求的其他設定。參數錯誤通常會造成連線或資料傳輸失敗，而不是形成一種正常的低速模式。
- VMess / VLESS：核對 UUID、傳輸方式與 TLS 設定。使用 WebSocket 時，也要逐項確認 Host 與 Path；UUID 相同不代表其他參數可以省略。
- Trojan：核對密碼、TLS 與 Server Name。憑證網域、伺服器位址和傳輸入口可能是不同值，應依照已有參數填寫。
- Hysteria2：使用以 QUIC 為基礎的傳輸方式，網路路徑必須允許相應的 UDP 通訊。若服務商提供頻寬參數，請依說明填寫，不要任意調高預估值。
- WireGuard：核對金鑰、Endpoint 與服務端提供的其他參數。MTU 不應作為第一個優化項目；只有出現特定大小的資料傳輸停滯等線索時，再依服務商說明逐項確認。
協定比對的前提是伺服器本來就支援對應的連線入口，不能只在 Type 中把 VLESS 改成 Trojan 來測試。即使兩種入口都可用，也可能位於不同伺服器，測得的差異不一定來自協定。先比較完整參數與網路條件，再討論協定額外負擔。
錯誤：i/o timeout
原因與處理方式：某個網路讀寫階段超過等待時間，單看這行訊息無法確定故障位置。查看同一筆紀錄中的目標與前後文，核對位址和連接埠，並改用另一種本地網路測試同一個節點。
錯誤：connection refused
原因與處理方式：目標連接埠拒絕了連線，可能是服務未在該連接埠監聽，或中間設備主動拒絕。依照已有參數檢查連接埠，並向自己的服務商確認入口狀態，不要只靠反覆測速處理。
錯誤：certificate verify failed
原因與處理方式：TLS 憑證驗證未通過，需依完整錯誤訊息確認原因。檢查系統日期與時間、Server Name 及伺服器憑證狀態，不要把關閉憑證驗證當成加速手段。
錯誤訊息可能來自不同的連線元件，實際呈現以紀錄為準。若持續出現錯誤，應先按連線失敗處理；不要把不斷重試造成的長時間等待，誤認為可用頻寬偏低。
六、規則與 DNS：確認請求實際經過的路徑
如果同一個節點在 Proxy 模式下正常，切回 Config 後卻變慢，應優先檢查目前 Config 的規則與 DNS 行為。規則決定如何處理請求，DNS 則負責解析網域名稱，兩者不是同一個開關。不要一次同時替換設定、解析伺服器與節點，否則無法判斷是哪項變更造成影響。
- 檢查規則比對順序：
DOMAIN-SUFFIX依網域後綴比對，IP-CIDR依 IP 位址範圍比對，GEOIP依 IP 地理位置資料庫比對，FINAL則處理未符合前面規則的請求。較早符合的規則可能讓請求未經過正在測試的節點。 - 確認實際請求：網頁正文、圖片與影片可能來自不同網域。主網域透過代理連線，不代表頁面上的所有資源都採用相同的出站策略。
- 區分解析與傳輸：首次請求等待很久，之後傳輸正常，應檢查解析與交握階段；連線建立後持續低速，就不能只靠更換 DNS 解釋。
- 保留原本設定：修改規則前先儲存原始內容，每次只調整一個與目標相關的項目。不要為了測試任意移動 FINAL 或刪除整段規則。
不建議直接以 IP 位址取代 HTTPS 網域進行一般測速。這可能改變憑證驗證、TLS Server Name、虛擬主機與 CDN 路徑，測試對象也就不再相同。請使用一般網域發出請求，並查看連線紀錄，確認解析是否完成及最後採用哪項策略。
七、常見問題與排查收尾
延遲只有幾十毫秒，為什麼下載還是很慢？
延遲反映的是短時間內的回應速度，下載則需要持續傳輸。固定節點與檔案，連續測試 60 秒並重複三輪；若傳輸速度偏低但延遲穩定，接著檢查限速、負載與出口路徑，不要只依延遲排序下結論。
切換至 Proxy 後變快，需要一直這樣使用嗎？
先把這個結果當作檢查規則的線索。記錄 Home → Global Routing 的比對結果，再回到 Config 檢查目標請求符合哪條規則；完成診斷後，還原成符合日常需求的模式。
換網路後卡住，重新連線就會恢復嗎？
先用新發出的請求進行確認，排除舊連線正在等待重試。接著前往 Settings → On Demand 檢查自動連線條件，並記錄手動連線與自動連線的差異；不要把反覆重新連線當成固定的加速方法。
所有已有節點都很慢，接下來應提供哪些資訊？
提供測試時間、網路連線類型、目標類型、三輪測試數據，以及已進行的單一變項比對。附上已移除敏感資訊的錯誤紀錄，隱藏密碼、UUID、金鑰及訂閱連結中的 token，並向自己的服務商確認服務狀態。
排查結束後，將結論寫成可重現的條件，例如「同一個節點、同一個目標，Wi-Fi 下三輪都很慢，切換至 Cellular 後恢復」，而不是只寫「Shadowrocket 很慢」。若只有單一目標異常，繼續檢查該目標與出口的關係；若所有目標都異常，再檢查共用的網路連線或節點路徑。尚未完成比對前，不要急著歸因。