Shadowrocket（小火箭）的延遲數值、VPN 連線狀態與網頁是否能開啟，分別反映不同層面的結果。本文適用於已備妥自己的服務商與設定，卻遇到 timeout 或連線失敗的使用者：先保留設定並重複測試，再核對協定、連接埠與路由，最後檢查系統時間及網路差異，避免把所有故障都歸咎於節點。
一、先區分測試逾時、通道連線與網頁無法開啟
先確認故障發生在哪個環節，再調整相應設定。Home 中某個項目顯示 timeout，只代表該次測試未能在限定時間內完成；系統顯示 VPN 標誌，也不代表遠端服務已完成驗證，更不表示所有網站都能正常存取。判斷時應一併記錄測試方式、選取的項目、Global Routing 目前狀態及具體目標。
這個流程用來拆解排查環節，並不表示每個請求都會嚴格依照相同順序執行。網域解析可能在裝置端或遠端進行，規則也可能依據網域、IP 或其他條件決定連線出口。單看一筆延遲結果，無法涵蓋所有環節。
- 只有測試逾時：先以相同條件重測，再嘗試實際連線；不要立刻刪除設定。
- 連線開關無法維持開啟：先檢查系統 VPN 授權、其他 VPN 連線與 On Demand，再檢查遠端參數。
- 連線已開啟但所有目標都失敗：檢查目前選取的項目、Global Routing、驗證資訊與 DNS。
- 只有一個網域無法連線：優先檢查該網域的規則、解析結果與目標本身的狀態。
二、在 Home 重複測試延遲，固定比對條件
在 Home 確認測試的是既有設定中的哪個項目，並記錄名稱與協定。先在相同網路下，對同一項目連續測試三次，每次間隔約 10 秒；測試入口與方式以目前 App 顯示為準。若使用 TCP 測試，結果主要反映 TCP 連線是否建立，不能直接證明以 UDP 為基礎的協定通路正常。
- 確認 Wi-Fi 已完成網路驗證，或行動數據可正常使用。暫時關閉 Shadowrocket 連線，再用瀏覽器開啟平時可直接存取的頁面，建立基本網路的比對基準。
- 返回 Home，以相同測試方式對同一項目測試三次並記錄結果。測試期間不要同時更換連接埠、DNS 與路由狀態。
- 選取該項目並開啟連線，前往固定目標；記錄是立即出現錯誤、長時間等待，還是只有部分網頁資源載入失敗。
- 若還有其他可用項目，可在相同網路及相同目標下進行比對；不同測試方式得出的數值，不宜直接排序比較。
| 測試結果範例 | 可得出的判斷 | 下一步 |
|---|---|---|
| 三次都顯示 timeout | 測試持續失敗，原因尚未確認 | 核對位址、連接埠與網路連線狀況 |
| 120 ms、timeout、135 ms | 結果不穩定；數字僅為記錄範例 | 改用另一種網路連線，重複相同測試 |
| TCP 測試成功，但網頁無法開啟 | 連接埠可建立連線，不代表驗證成功 | 檢查協定參數、TLS 與路由 |
| 網頁可正常使用，但某種測試逾時 | 測試路徑與實際使用情況不一致 | 核對測試方式，不要只憑這項結果修改設定 |
結論：先固定變數，再判斷故障範圍
同一項目在 Wi-Fi 下失敗、行動網路下成功時，下一步應先檢查 Wi-Fi 路徑與連線限制；不要同時重填密碼又修改 DNS，否則無法判斷是哪項變更影響結果。
三、逐項核對協定、服務位址與連接埠
從 Home 開啟既有項目的編輯頁面，逐項比對自己保存的原始設定。顯示名稱只是備註，不能證明服務位址或協定正確。連接埠必須與遠端監聽的連接埠一致：原始設定是 443 就保留 443，不能因另一份設定使用 8443 就照抄。使用 443 也不代表該項目一定採用 TLS。
| 協定 | 優先核對項目 | 容易混淆之處 |
|---|---|---|
| Shadowsocks | 服務位址、連接埠、加密方式、密碼 | 加密方式必須與遠端一致，不能只核對密碼 |
| VMess / VLESS | UUID、傳輸方式，以及原始設定要求的 TLS 參數 | WebSocket 的 Host 與 Path 並非服務位址 |
| Trojan | 密碼、連接埠、TLS Server Name | 改用 IP 後，憑證所需的網域資訊仍須正確 |
| Hysteria2 | 驗證資訊、TLS 參數、UDP 通路 | TCP 連接埠測試無法驗證 UDP 通路 |
| WireGuard | PrivateKey、對端 PublicKey、Endpoint、位址與 AllowedIPs | 金鑰用途、UDP 連線能力與路由範圍需分別檢查 |
網域、TLS Server Name 與 WebSocket Host 可能剛好相同，也可能依原始設定使用不同值，不要為了「統一」而全部取代。Path 中的斜線與查詢內容也應完整保留。複製參數時，留意前後空格、換行及遭截斷的驗證資訊，但不要將私鑰、密碼或完整訂閱連結貼到公開紀錄中。
四、依錯誤原文判斷，不要把 timeout 當成唯一原因
在 App 提供的連線記錄或日誌中，保留與此次請求相對應的錯誤原文及發生時間。以下是網路連線中常見的錯誤片段；完整文字可能因協定、底層錯誤及 App 介面而異。若沒有出現相應文字，不要據此認定發生了某類故障。
錯誤：timeout
原因與處理方式：操作未能在限定時間內完成，可能與解析、連線或交握有關——先依日誌所處階段判斷，再以相同參數切換網路連線重測。
錯誤：connection refused
原因與處理方式：目標或中間設備主動拒絕連線——核對位址與連接埠，並請自己的服務商確認相應服務是否正在監聽。
錯誤：no such host
原因與處理方式：網域解析未取得可用結果——先檢查網域拼字、目前 DNS 與基本網路，再確認該網域是否仍有效。
錯誤：certificate has expired or is not yet valid
原因與處理方式：憑證有效期間與目前時間不符——先校正系統日期與時間；若時間正確仍出現錯誤，再核對遠端憑證的有效期限。
同一筆記錄中，可能先出現連線重試，最後才彙整為 timeout。因此應保留前後相鄰的錯誤訊息，而不只是截取最後一行。若訂閱更新失敗，但已儲存的項目仍可使用，也應分開記錄：訂閱取得失敗不代表現有遠端連線已失效。
五、檢查 Global Routing、Config 與 DNS
Home 中的 Global Routing 決定目前採用哪種路由狀態。Proxy、Direct、Config、Scene 不應視為同一個開關：Direct 用於直接連線；Config 依目前設定規則選擇路由；Scene 則需一併核對目前的場景設定。排錯時先記下原本的值，必要時暫時使用 Proxy 對固定目標進行比對，測試後再還原原設定。
- 在 Home 確認目前選取的項目，記錄 Global Routing 原本的值，避免測試時仍停留在 Direct。
- 若使用 Config，請在 Config 確認目前生效的設定檔，核對目標網域或 IP 符合哪條規則，以及對應策略是否有效。
- 若使用 Scene，請核對場景實際採用的路由與策略，不要只根據場景名稱判斷請求的連線方向。
- 區分「遠端服務網域無法解析」與「目標網站網域無法解析」。前者可能在建立代理連線前就失敗；後者則需配合設定中的 DNS 與實際連線記錄檢查。
以下是規則語法範例，不是可直接覆蓋現有設定的修復檔案。規則通常依序比對，較前面的符合項目可能導致後續規則不再參與這次選路。DOMAIN-SUFFIX 依網域後綴比對；IP-CIDR 與 GEOIP 用於 IP 條件；FINAL 則是未符合前面規則時採用的預設策略。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY其中 no-resolve 表示這條 IP 規則不會主動觸發網域解析來嘗試比對；這不等於關閉整份設定的 DNS。若固定目標在 Proxy 下可用，切回 Config 後卻失敗，應優先檢查規則與策略，而不是再次修改遠端密碼。不要為了解決單一網域問題就直接刪除所有規則。
六、最後檢查系統時間、網路路徑與 On Demand
時間錯誤可能影響憑證有效期判斷，也可能影響依賴時間驗證的驗證流程。在 iPhone 或 iPad 的系統設定中，前往「一般 → 日期與時間」，檢查「自動設定」是否開啟，以及顯示的日期、時間與時區是否正確。關鍵是系統時間準確；時區顯示不同本身不一定代表故障。若選項受到裝置管理限制，請依該裝置的管理要求處理。
- 比對 Wi-Fi 與行動網路：使用相同項目、相同目標與相同路由狀態，各測試一次。若只有某種網路失敗，優先檢查該網路的 DNS、存取限制與 UDP 連線能力。
- 網路驗證：飯店、校園或公共 Wi-Fi 可能需要先完成網頁驗證。基本網路尚未開放連線時，修改協定參數通常無法解決問題。
- On Demand：前往 Settings → On Demand 檢查按需連線條件。若手動中斷後立刻重新連線，或切換網路後狀態自動改變，可暫時停用相關條件；完成手動測試後再恢復。
- 系統 VPN 狀態：檢查是否有其他 VPN 連線正在接管流量。不清楚用途時，不要刪除裝置管理設定；先確認目前實際啟用的是哪個連線。
- 訂閱更新：保留原有可用項目與設定備份。確認原訂閱內容已變更後再更新，避免把連線排錯與替換設定混成同一個步驟。
結論：提供最精簡的重現紀錄，而非整份設定
問題仍未排除時，請提供自己的服務商發生時間、網路類型、協定、連接埠、三次測試結果及已隱去敏感資訊的錯誤片段；公開截圖中不應出現密碼、PrivateKey、完整 UUID 或訂閱 token。
七、常見問題與恢復後的檢查
延遲測試有數值，為什麼網頁還是打不開？
先確認測試方式。TCP 測試成功只表示該次連接埠連線成功；返回 Home 核對選取的項目與 Global Routing，再確認實際請求是否在驗證、TLS、DNS 或規則環節失敗。
只有 Wi-Fi 逾時，行動網路正常，需要重新安裝嗎？
先不要重新安裝。使用相同設定確認這種差異可以重現，再檢查 Wi-Fi 驗證、DNS 與網路限制。重新安裝無法直接解除網路對特定連接埠或 UDP 通路的限制。
更新訂閱後連線失敗，可以把原有項目全部刪除嗎？
先保留原設定，核對更新前後的位址、連接埠與協定參數。若清單為空或內容缺漏，應先處理訂閱取得問題；尚未備份就刪除原有項目，會失去可供比對的紀錄。
恢復連線後還需要調整哪些設定？
將 Global Routing 與 On Demand 條件還原至排錯前的狀態，再用平時存取的目標測試一次。保留確實有效的修正，撤銷暫時的比對設定，並記下這次真正造成故障的欄位或網路條件。
完整排查應以「某項變更能帶來可重複的結果差異」作為結束條件，而不是只看開關是否亮起。若所有既有項目在兩種網路下都失敗，但基本網路正常，應集中檢查共用設定、系統時間與遠端狀態；若只有單一目標失敗，則繼續釐清該目標的解析與規則。