Shadowrocket（小火箭）顯示已連線，不代表整條存取路徑都有足夠頻寬。本文適合已持有自己的服務商設定或訂閱的使用者，依序檢查直連基準、Global Routing、協定參數、跨網路線路與節點負載。透過固定測試目標、每次只變更一項條件，區分網頁首次開啟緩慢、持續下載緩慢與連線逾時，避免反覆調整不相關的設定。
一、先分辨延遲、傳輸速度與連線失敗
存取速度取決於多個環節：iPhone 到無線基地台或行動網路基地台、本地電信業者到遠端伺服器、伺服器處理能力，以及伺服器到目標網站的路徑。Home 中的延遲結果僅涵蓋特定測試方式下的回應過程，不能直接換算成下載速度。單次延遲很低，也無法證明長時間傳輸沒有封包遺失或壅塞。
先描述症狀，再選擇測試方式。網頁第一次開啟時停頓、之後正常，優先檢查網域解析與建立連線；檔案一開始下載就很慢，優先比較頻寬與路徑；下載速度忽快忽慢，優先檢查無線干擾、封包遺失與共用負載。若連線一直逾時，這是可連線性問題，應先恢復連線，再討論如何提升速度。
例如，80 Mbps 理論上相當於 10 MB/s，但實際檔案傳輸仍會受到協定額外負擔、目標網站限速與網路波動影響。這只是單位換算，不代表速度保證。測試時記下網路類型、所選節點、路由模式、目標網站與時段，之後才能有效比較。
二、第一層：建立本地網路的直連基準
先選擇一個不透過代理也能正常存取的網站或檔案，作為基準。在安全且允許直連的情況下，暫時停止 Shadowrocket 連線後再測試。如果直連速度已經很慢，繼續調整代理協定通常無法解決問題。不要用兩個不同網站的下載速度來判斷代理是否拖慢網路，因為兩者可能使用不同的伺服器，也可能有不同的頻寬限制。
-
記錄原有設定
在 Home 記下所選節點與 Global Routing 的目前值，再前往 Settings → On Demand 查看隨選連線狀態。診斷期間若要手動中斷連線，可暫時停用 On Demand，避免系統依據既有條件重新建立連線。
-
測試直連基準
在 Home 停止連線，確認連線狀態已變更。使用 Safari 開啟固定的測試目標，記錄首次載入與持續傳輸的表現；此時不要同時執行系統更新、照片同步或大型檔案上傳。
-
更換網路連線
在 iPhone 的 Settings → Wi-Fi 切換無線網路，分別透過 Wi-Fi 與行動網路測試同一個目標。留意行動數據用量，並盡量在相近時段完成兩組測試。
-
恢復設定後再次測試
返回 Home，恢復使用同一節點與路由設定，並在相同網路下再次測試。完成後恢復原有的 On Demand 條件，避免讓診斷時的暫時設定一直保留下來。
若只有 Wi-Fi 速度慢，先靠近路由器，比較不同頻段的連線，並確認是否有人正在大量上傳。上傳頻寬被占滿，也可能讓網頁請求排隊。若只有行動網路速度慢，可比較不同地點與時段，並確認目前的數據方案是否有速度限制。不要只憑狀態列的訊號格數，就認定網路頻寬充足。
三、第二層：確認路由模式與協定參數
本地網路正常後，先確認測試流量實際經過哪裡。Home → Global Routing 中的 Proxy、Direct、Config、Scene 是不同的路由模式。Config 會依目前設定中的規則決定流量去向；Scene 則依設定的場景條件套用相應設定，不能視為固定的全域代理模式。若目標網站符合 DIRECT 規則，測試結果就不能用來評估所選代理節點。
| 設定項目 | 意義 | 排查時確認 |
|---|---|---|
| Proxy | 採用代理路由模式 | 確認測試期間所選代理或策略群組沒有切換。 |
| Direct | 採用直連路由模式 | 適合用於路由比較，不代表代理節點的速度。 |
| Config | 依目前設定套用規則 | 查看目標連線符合的規則與最終策略。 |
| Scene | 依場景設定套用條件 | 確認目前網路符合的場景及其路由設定。 |
在 Config 中，可用以下規則了解測試目標的流量去向。這是規則語法範例，並非完整設定；example.com 是示例網域，PROXY 代表代理策略，實際使用前應確認目前設定中的策略定義。規則會依序比對，較早符合的規則可能決定最終結果。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT接著在 Home 開啟既有節點的編輯頁面，確認類型、位址、連接埠與認證資訊。Shadowsocks 的加密方式、VMess 或 VLESS 的識別資訊與傳輸設定、Trojan 的密碼與 TLS 參數，都必須符合伺服器設定。伺服器使用 TCP 連接埠 443，不代表任意協定填入 443 就能正常運作；連接埠相同，也不表示傳輸內容相同。
- TLS 與 SNI：依自己的設定確認伺服器名稱與憑證驗證條件。不要透過允許不安全驗證來掩蓋憑證錯誤；同時檢查 iPhone 的 Settings → General → Date & Time，確認系統時間正確。
- 傳輸設定：若既有設定使用 WebSocket，路徑與 Host 必須符合伺服器要求。表單能夠儲存，不代表參數已通過伺服器驗證。
- UDP 條件：Hysteria2 以 QUIC 為基礎並使用 UDP，WireGuard 也使用 UDP。若目前網路限制 UDP，連線表現可能與使用 TCP 的設定不同，不能只憑協定名稱判斷速度。
- 訂閱更新：匯入或更新訂閱是為了取得設定，不會增加線路本身的頻寬。更新既有訂閱後，應再次確認所選項目，避免把位址或參數變動誤認為單純的速度波動。
錯誤：certificate has expired
原因與處理方式：這類 TLS 錯誤表示憑證時間驗證未通過，可能是憑證已過期或裝置時間異常。先校正系統時間，再向自己的服務商確認憑證狀態，並保持憑證驗證開啟。
錯誤：Connection refused
原因與處理方式：目標端點或中間設備明確拒絕連線，常見原因是連接埠沒有監聽服務，或存取策略拒絕連線。確認位址、連接埠與協定，不要把反覆測速當成修復方式。
錯誤：Operation timed out
原因與處理方式：請求未能在限定時間內完成，可能與路徑封包遺失、連接埠無法連線或遠端沒有回應有關。先更換網路，使用同一組設定測試，再向自己的服務商確認遠端狀態。
以上是網路與 TLS 診斷中常見的錯誤原文，實際顯示內容可能包含額外資訊。記錄完整錯誤訊息與發生時間，分辨問題發生於解析、連線、交握或傳輸階段；不要只截取「逾時」兩個字就直接歸因於節點負載。
四、第三層：透過交叉測試辨識線路問題
線路品質是本地網路與遠端之間的路徑表現，包含往返延遲、抖動、封包遺失與壅塞。它與伺服器的地理距離有關，但並非單純由距離決定。標示相同地區的兩個既有節點，也可能經過完全不同的互連路徑；節點名稱不能取代路徑品質的證據。
使用自己已有的設定進行交叉測試：先固定節點、更換網路；再固定網路、更換既有節點。測試目標與方式都要一致，每組重複三次並記錄中間結果。不要把一次瞬間峰值當成持續速度，也不要高頻率並行測試，否則測試本身可能占滿連線。
| 觀察到的組合 | 優先檢查方向 | 下一步 |
|---|---|---|
| 同一節點在 Wi-Fi 下速度慢，行動網路正常 | Wi-Fi 網路連線或其電信業者路徑 | 搭配直連基準，分辨無線網路問題與遠端路徑差異。 |
| 同一節點在兩種網路下都慢，其他既有節點正常 | 該節點的路徑或伺服器狀態 | 保持節點設定不變，換個時段再次測試。 |
| 只有一個網站速度慢，其他目標正常 | 目標網站、網域解析，或節點到目標網站的路徑 | 比較同一網站的不同資源，確認實際套用的路由策略。 |
| 所有節點與直連同時變慢 | 本地網路或測試目標 | 暫停其他傳輸，換一個固定測試目標後重新建立基準。 |
結論：固定變因後再更換網路
若同一組設定只在某一種網路下出現異常，先保留協定參數，將排查重點放在該網路及其遠端路徑；不要同時修改 DNS、連接埠與協定，否則無法判斷是哪項變動影響結果。
只有在網頁首次開啟緩慢、但持續傳輸正常時，才需要優先檢查 DNS：比較同一網域第一次與再次開啟的表現，並搭配連線記錄確認解析與連線耗時。第二次開啟較快也可能是瀏覽器快取造成，不能只憑這點就斷定 DNS 有問題。任意更換解析位址可能改變目標分配或規則比對結果，修改前應先備份目前設定。
五、第四層：分辨節點負載與目標網站限制
節點負載包含伺服器處理能力、出口頻寬、並行連線與伺服器端限速。用戶端能觀察的是回應與傳輸表現，通常無法直接讀取遠端 CPU 或出口使用量。因此，「延遲不高但下載很慢」只能說明延遲與傳輸速度不一致，不能直接證明伺服器過載。
- 比較不同時段：相同網路、節點與目標在尖峰時段持續較慢，其他時段恢復正常，可能符合共用線路壅塞或負載變化的情況，但仍需確認遠端狀態。
- 比較多個目標：同一節點存取多個互不相關的目標都很慢，比只有一個網站速度慢更值得檢查節點出口或共用路徑；單一網站異常也可能是目標網站限速。
- 比較持續傳輸表現：記錄傳輸速度是穩定在某個範圍，還是間歇停頓。穩定的速度上限可能與限速有關；明顯停頓可能涉及封包遺失、重傳或連線中斷，但僅憑用戶端都無法確診。
- 確認服務狀態：向自己的服務商確認既有服務是否設有頻寬、流量或並行連線限制。提供已去識別化的問題記錄，不要傳送訂閱網址、密碼或身分憑證。
不要為了提高測速數字而直接增加並行連線，或持續執行下載。多連線測速可能暫時得到較高的總傳輸量，但不代表單一網頁請求更快，也會消耗流量。若兩種協定使用的伺服器、連接埠、出口或路徑不同，測試結果就不能概括成「某種協定一定比較快」。
結論：根據證據定位遠端瓶頸
只有在直連正常、參數一致、多個目標都慢，而且在不同網路下都能重現時，才優先向服務商確認該節點的出口與負載；提供時段與比較結果，比反覆更換用戶端設定更有助於找出問題。
六、整理記錄並還原日常設定
一輪排查結束後，應能回答三個問題：本地直連是否正常、目標請求實際採用哪一項策略，以及異常是否會隨節點或網路變化。若仍無法判斷，請保留最小可重現條件，不要繼續疊加修改。尤其不要同時更新訂閱、更換規則並調整協定，否則原始問題將失去可比較性。
- 記錄 iPhone 使用的是 Wi-Fi 還是行動網路，以及每次測試的日期、時間與持續時間；不必公開完整的公網位址。
- 記錄 Home → Global Routing 的值、目前設定與所選節點的去識別化名稱，並註明測試期間是否發生自動切換。
- 記錄直連基準、同一節點跨網路的結果，以及同一網路下不同既有節點的結果，並註明速度單位是 Mbps 還是 MB/s。
- 保留錯誤訊息原文，傳送前遮蔽位址中的敏感資訊、認證欄位與訂閱憑證。
- 還原日常使用的 Config、規則與 Settings → On Demand 條件，確認常用網站的路由符合預期。
若要進一步確認規則與路由模式，請參閱技術參考或代理模式說明。Shadowrocket 是 Apple 平台上的閉源商業應用程式，主要供 iPhone 與 iPad 使用；系統需求以 App Store 頁面標示為準。用戶端一次性買斷不等於線路方案，本文僅說明如何檢查使用者既有的設定，不提供、販售或推薦節點與訂閱。