Shadowrocket（小火箭）顯示已連線，只代表系統 VPN 通道已建立，不表示每台伺服器、目標網站和傳輸協定都能正常運作。本文假設你已經有自己的服務商與訂閱，先固定測試條件，再依序檢查節點、線路、協定和本機網路；透過首屏等待時間、持續傳輸狀況、錯誤訊息及網路切換結果，逐步找出可核對的問題環節。
一、先確認請求路徑，再判斷慢在哪裡
結論：先確認請求是否依預期策略處理，不要只看連線開關或 VPN 標誌來判斷伺服器速度。在 Home 確認目前選取的伺服器，再查看 Global Routing。Proxy 會依代理模式處理流量，Direct 會以直連模式處理，Config 則依目前設定中的規則決定策略；不同模式下的測試結果不可混在同一組紀錄中。
使用 Config 時，先在 Config 確認目前使用的設定檔。同一個網頁可能符合 DIRECT 規則，另一個網頁才會經過代理。如果 Global Routing 目前使用 Scene，先確認相應場景的設定，再固定排查條件；不要同時切換場景和伺服器。若要暫時使用 Proxy 作為對照，先記下原本的模式，測試後再還原。
- 選定同一個目標網頁，分別確認「首次開啟等待很久」和「開始傳輸後速度很慢」的情況。
- 在 Home 執行 Connectivity Test，記下測試方式、結果和選取的伺服器；測試數值僅供該測試目標參考。
- 重新送出目標請求，並參考可用的連線紀錄確認目標網域及實際套用的策略；不要把 DIRECT 請求當成伺服器速度測試。
- 若連線間歇中斷，請檢查 Settings → On Demand 的連線條件，確認測試期間不會因網路變化而反覆重新連線。
二、建立對照紀錄：每次只變更一個條件
結論：每次測試只更換一個條件，結果才有比較價值。不要同時更新訂閱、切換伺服器、變更協定和更換 Wi-Fi。先暫停其他裝置的大量傳輸，並固定使用同一台 iPhone 或 iPad、同一個目標及同一種測試方式，同時記錄測試時段。網頁快取可能讓第二次開啟明顯變快，因此也要分開記錄命中快取和重新取得內容的結果。
以下是紀錄範本，不是本站的實測結果。A、B 代表你現有訂閱中的兩台伺服器；選擇 B 時，盡量讓協定、地區等其他條件相近。如果訂閱中沒有合適的對照項目，請註明條件不同，不要將結果歸因於單一因素。
| 測試組別 | 固定條件 | 唯一變更的條件 | 紀錄內容 |
|---|---|---|---|
| 基準組 | 伺服器 A、原設定、同一目標 | 不變更 | 首屏等待時間、持續傳輸狀況、是否出現錯誤 |
| 節點組 | 原網路、相同路由模式 | 由 A 換成 B | 速度是否穩定改善、是否仍有停頓 |
| 網路組 | 伺服器 A、原協定、同一目標 | 由 Wi-Fi 切換至行動網路 | 同一請求是否能完成；另行記錄重新連線所需時間 |
| 時段組 | 伺服器 A、原網路、原設定 | 測試時段 | 尖峰與離峰時段是否有規律性差異 |
結論：先找出可重複的差異
如果只有某一次請求變快，先重複同一組測試；只有在其他條件固定、差異持續出現時，才沿著該變數繼續檢查，避免把快取或短暫波動誤認為修復效果。
三、節點層：低延遲不代表持續傳輸速度快
結論：節點測試有助於判斷是否可連線及回應時間，但不能直接代表頻寬。一次短請求只傳輸少量資料，即使很快收到回應，也不代表大型檔案或影片片段能持續快速傳輸。伺服器負載、對外連線容量，以及連往目標網站的路徑，都可能在延遲正常時限制傳輸量。
- 只有一台伺服器速度慢：在 Home 切換至現有訂閱中條件相近的另一台伺服器，並重複測試同一個目標。如果只有 A 持續異常，優先確認 A 的狀態與連線參數。
- 只有一個目標速度慢：保持伺服器不變，改測另一個平常會使用的目標。若其他目標正常，接著檢查該目標的規則、解析結果，以及伺服器連往目標的路徑。
- 所有伺服器都很慢：先保留目前的設定，改做本機網路對照測試，不要立刻認定訂閱中的所有伺服器都有問題。
- 訂閱資訊可能已過期：使用應用程式內的訂閱更新功能，取得服務商提供的最新資訊；確認更新成功後，再重新選取伺服器。不要直接修改訂閱管理中的項目，長期覆蓋錯誤資訊。
地區名稱只是服務商提供的標示，不能單憑名稱推斷實際中轉路徑或可用頻寬。聯絡自己的服務商回報時，提供項目名稱、測試時間、網路類型和異常目標，比只說「延遲很低但很卡」更有助於找出問題。
四、線路層：比較時段與目標，找出路徑問題
結論：單看一個延遲數字，通常無法判斷是接入鏈路、中轉路徑、伺服器出口還是目標網站發生壅塞。排查線路問題應依據對照結果：同一台伺服器是否只在特定時段變慢、同一個網路連接多台伺服器時是否都不穩定，以及更換目標後現象是否消失。
- 固定伺服器，比較不同時段。在不同時間重複同一組請求。若晚間持續變慢、其他時段恢復，只能說明可能有與時段相關的壅塞，還無法確定問題發生在哪一段。
- 固定目標，比較不同路徑。使用現有的伺服器進行對照。若只有部分伺服器連往同一目標時速度較慢，記錄這些伺服器的共同條件，請服務商進一步確認。
- 區分等待時間與傳輸狀況。首次回應等待很久、之後傳輸正常，較需要檢查解析和連線建立；已開始傳輸卻反覆停頓，則可繼續觀察壅塞、封包遺失或目標限速的可能性。
- 分開測試網頁與媒體。影片應用程式的畫質自動調整和緩衝會影響觀看感受，不宜只憑一次播放流暢就認定線路容量充足。
不要反覆中斷再連線來取代測試紀錄。重新連線後可能建立了新的連線階段，也可能只是剛好避開短暫壅塞；若沒有固定伺服器、目標和網路，就無法確認改善來自哪個環節。伺服器線路或出口資訊需由服務商確認，使用者端的觀察只能逐步縮小範圍。
五、協定層：先核對參數，不要盲目更換類型
結論：協定必須與伺服器端設定一致，不能把類型改成另一種協定來「加速」。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的驗證、傳輸方式和伺服器端設定各不相同。只有服務商已提供相應連線資訊時，才能進行對照；比較時也要註明伺服器與路徑是否相同。
| 協定或傳輸方式 | 優先核對項目 | 排查注意事項 |
|---|---|---|
| Shadowsocks | 位址、連接埠、密碼、加密方式 | 加密方式必須與伺服器設定一致。 |
| VMess / VLESS | UUID、傳輸類型、TLS、Host、Path | 是否需要填寫 Host 與 Path，取決於使用的傳輸方式，兩者不能互相替代。 |
| Trojan | 密碼、連接埠、TLS 與伺服器名稱 | 憑證名稱不相符時應檢查設定，不要以關閉驗證來加速。 |
| Hysteria2 | 驗證、TLS、UDP 可達性及頻寬相關參數 | 以 QUIC 為基礎，依賴 UDP；若網路限制 UDP，可能無法正常建立連線。 |
| WireGuard | 金鑰、Endpoint、位址與 MTU | 以 UDP 為基礎；MTU 必須配合路徑進行驗證，沒有適用於所有網路的固定最佳值。 |
連接埠也要逐項依原始設定核對。例如 HTTPS 常用 TCP 443，但填入 443 不代表任何協定都能使用該連接埠，更不代表該連線一定使用 TCP。不要混淆 Hysteria2 的 UDP 連線與 TCP 443 的可達性。頻寬相關欄位也不要填入遠高於線路實際能力的數值，試圖藉此提高速度。
若小型請求可以完成，但大型回應經常停住，可將 MTU 或路徑 MTU 問題列入檢查項目，但這並非直接診斷。先排除目標網站差異和本機網路問題，再依服務商提供的設定進行受控測試。調整前先記下原值，每次只變更一個參數；若測試失敗就還原，不要套用所謂通用最佳化數值。
六、本機網路層：交叉測試 Wi-Fi 與行動網路
結論：相同伺服器與設定只在某個本機網路下變慢時，應優先檢查該網路的無線品質、上傳流量占用和傳輸限制。Wi-Fi 訊號格數不等於實際可用容量；即使靠近路由器，也可能受到干擾。行動網路則會受所在位置、訊號品質、資費方案狀態及基地台負載影響。
- 固定伺服器與目標，先在原本的 Wi-Fi 完成一組測試，並暫停本機及其他裝置正在進行的大量上傳或備份。
- 切換至行動網路，等待 Shadowrocket 重新連線後，再送出相同請求。將切換網路所需的重新連線時間與網頁回應時間分開記錄，並留意行動數據用量。
- 若行動網路正常，但 Wi-Fi 持續異常，請靠近路由器再測；情況允許時，也可分別測試同一路由器的不同 Wi-Fi 頻段。
- 若使用需要網頁認證的 Wi-Fi，請先完成網路登入。尚未完成登入時，VPN 標誌不能證明網際網路出口可用。
- 在 Settings → On Demand 檢查隨選連線條件，避免切換網路後的自動連線行為影響測試；調整前記下原設定，測試後還原。
DNS 也需要另外觀察。一般 DNS 查詢可透過 UDP 或 TCP 53 傳輸，加密 DNS 則使用不同的傳輸方式。如果每次首次連線都要等待很久，但連線建立後傳輸正常，請檢查目前設定中的 DNS、解析是否成功，以及是否發生重試。不要只因為「換了 DNS 後有一次變快」，就判定所有速度問題都由 DNS 引起。
七、出現錯誤時：依原始訊息判斷失敗階段
結論：錯誤訊息指出某個階段失敗，不代表已直接找出根本原因。以下列出網路診斷或連線記錄中可能出現的常見原文片段，實際完整內容請以裝置記錄為準。記下發生時間、目標和對應伺服器，切勿一併公開訂閱網址、密碼、UUID 或金鑰。
錯誤：connection refused
原因與處理方式：連線遭到明確拒絕，可能是連接埠沒有監聽，或連線遭到主動拒絕。先核對伺服器位址和連接埠，再請服務商確認該入口的監聽狀態。
錯誤：i/o timeout
原因與處理方式：某個網路讀取或寫入步驟未能在時限內完成，單憑這句訊息無法判斷是本機網路還是遠端故障。固定使用同一台伺服器，分別切換 Wi-Fi 與行動網路，並搭配完整記錄確認逾時發生的階段。
錯誤：TLS handshake failed
原因與處理方式：TLS 交握未完成，可能與名稱、憑證、裝置時間或連線中斷有關。核對原始 TLS 參數與系統時間，再改用另一個網路比較；不要把關閉憑證驗證當成一般處理方式。
若沒有錯誤訊息，但連線一直很慢，保留成功與失敗兩組紀錄同樣重要。連線建立後才出現的停頓，與驗證失敗或 TLS 交握失敗並非同一類問題。不要只截取最後一行就判定需要更換協定，應搭配前後請求與重現條件一起檢視。
八、常見問題與結束排查的判斷標準
延遲很低，為什麼影片還是一直緩衝？
先保持伺服器不變，比較同一個目標的持續傳輸狀況，再檢查播放畫質和緩衝狀態。短時間的延遲測試不涵蓋持續傳輸量，也無法反映伺服器連往影片內容伺服器的完整狀況。
切換到 Proxy 後速度變快，應該一直使用 Proxy 嗎？
先回到 Config 確認該目標符合的規則與策略。DOMAIN-SUFFIX、GEOIP、IP-CIDR 和 FINAL 都會影響請求的去向；兩種模式的速度不同，是檢查規則的線索，並不足以成為永久切換模式的理由。
只有 Wi-Fi 速度慢，需要重新匯入訂閱嗎？
先固定伺服器，分別在 Wi-Fi 和行動網路重複測試。如果同一份設定在行動網路下穩定正常，應優先檢查 Wi-Fi 連線與路由器，不要先刪除訂閱；更新訂閱也無法排除無線干擾。
換成 Hysteria2 就一定會更快嗎？
不一定。先確認服務商有提供 Hysteria2 參數，並確認目前網路允許相應的 UDP 通訊；比較時固定目標與時段，註明伺服器路徑差異，不要只憑協定名稱推斷結果。
結束排查時，至少應整理出一項可重現的描述，例如：「固定同一台伺服器和設定，在同一地點，Wi-Fi 下持續停頓，行動網路下三次請求都能完成。」這類紀錄只能指出優先檢查本機網路或接入路徑，仍需進一步驗證；但比籠統地說「已連線但很慢」更有助於繼續排除問題。
- 還原測試期間的變更：恢復原本的 Global Routing、On Demand 條件及暫時調整的協定參數，確認日常使用的設定仍然正確。
- 提供必要資訊：提供測試時段、網路類型、伺服器項目名稱、目標與錯誤訊息片段；請遮蔽驗證資訊和訂閱權杖。
- 分別處理各自的問題：本機網路問題請檢查路由器與接入條件；伺服器入口或線路問題請向服務商確認；規則問題則回到 Config 檢查。