本文適用於已在 Shadowrocket（小火箭）匯入自己的既有設定，卻遇到延遲測試逾時，或連線開關已開啟但請求失敗的使用者。依序檢查測試結果的意義、本機網路、協定欄位、系統時間與 TLS；每次只變更一項條件，最後以相同請求重新測試，分辨伺服器無法連線、參數不符或規則未命中。
一、先分辨延遲測試與實際連線
「逾時」只表示某個步驟未能在等待期限內完成，不代表密碼錯誤或伺服器停止運作。延遲測試採用的探測方式不同，涵蓋的連線路徑也不一樣：TCP 交握成功，只能表示當下可與目標位址及連接埠建立 TCP 連線；透過代理執行 HTTP 請求，還會涉及協定交涉、連線至目標網站及接收回應。兩者不能互相取代。
先在 Home 記下選取的設定名稱、測試方式與結果，再用瀏覽器開啟平常可正常瀏覽的 HTTPS 網頁。這只是診斷操作，不需要提供任何帳號資訊。不要把單次測試結果視為長期狀態，也不要只憑 VPN 圖示判定代理連線已可使用：系統通道建立與遠端驗證成功是不同階段。
| 觀察結果 | 可判斷的事項 | 下一步 |
|---|---|---|
| TCP 測試成功，網頁無法開啟 | 連接埠可建立連線，不代表協定驗證或 TLS 成功 | 檢查 Type、登入資料與 TLS 欄位 |
| 延遲測試逾時，網頁可開啟 | 測試方式、測試目標或探測路徑可能不同 | 記下測試方式，重複相同的實際請求 |
| Wi-Fi 失敗，行動網路成功 | 問題與網路連線方式有關，但尚無法確定是哪個環節 | 檢查 Wi-Fi 登入、DNS 與網路限制 |
| 只有一個網站無法開啟 | 不宜直接判定整條連線無法使用 | 查看該請求命中的規則與目標回應 |
結論：保留一項實際連線測試
若延遲數值與網頁結果不一致，先保留目前設定，記下測試方式與實際請求結果，再依失敗階段逐項排查；不要立刻大量更換協定或重設所有設定。
二、用六個步驟固定測試條件
排查期間請使用一筆既有設定和同一個測試頁面。切換網路、更新訂閱或變更路由模式都可能影響結果；若一次修改多項條件，就難以判斷原因。以下步驟用來建立可重複的測試基準，不代表建議長期維持某種路由模式。
-
記錄原有設定
在 Home 記下選取的設定，以及 Global Routing 目前的模式；前往 Settings → On Demand 查看隨選連線狀態。若測試期間會自動重新連線，先記錄原有條件，再暫時停用，測試結束後恢復。
-
確認本機網路
暫時關閉連線，確認目前的 Wi-Fi 或行動網路可正常開啟日常網頁。若公共 Wi-Fi 需要透過網頁登入，請先完成登入，再開啟 Shadowrocket 的連線開關。
-
固定設定
返回 Home 選取要檢查的設定，確認不是另一筆名稱相同的紀錄。測試期間先不要反覆更新訂閱，以免位址、連接埠或登入資料中途變更。
-
排除規則影響
前往 Home → Global Routing，暫時選取 Proxy，使用同一個測試頁面確認代理連線路徑。Proxy 可用來排除規則造成的影響，但不保證所有網頁都能開啟；Direct 會直接連線，不能用來證明所選代理可用。
-
切換網路
保持設定與頁面不變，分別透過 Wi-Fi 和行動網路重複測試。建議各測三次，記錄成功或逾時及發生時間；這是記錄方式的建議，不是預設測試結果。
-
恢復原有模式
測試結束後，將 Global Routing 恢復為原本的 Config、Scene 或其他模式，並恢復 On Demand 設定。若 Proxy 可用但 Config 無法使用，接著檢查 Config 中啟用的設定與規則。
若切換至行動網路後恢復正常，請優先檢查原本的 Wi-Fi，而非立即更改密碼。反之，若兩種網路都在同一階段失敗，只能表示需要繼續檢查共通條件，例如位址、連接埠、驗證參數或伺服器狀態，不能據此判定是哪個項目出錯。
三、逐項檢查位址、連接埠與協定欄位
在 Home 開啟該設定的編輯頁面，逐項比對自己的服務供應商提供的原始資料。Type 決定用戶端採用的協定，不要只因位址相同就任意更換。位址欄位通常填寫主機名稱或 IP，不應將整段訂閱 URL 當作伺服器位址，也不要把網頁路徑填入主機名稱欄位。
| 設定項目或協定 | 檢查內容 | 常見誤判 |
|---|---|---|
| 位址與連接埠 | 檢查主機名稱拼字、連接埠數字及前後空格；以原始設定資料為準 | 443 只是常見連接埠範例，不代表所有服務都應改用 443 |
| Shadowsocks | 加密方式與密碼須和伺服器設定一致；若使用外掛程式，也要一併核對其設定 | 只確認連接埠可連線，卻忽略加密方式不符 |
| VMess / VLESS | 核對 UUID、傳輸方式，以及設定使用的 TLS、Host、Path 等參數 | 把 UUID 當成一般密碼，或遺漏傳輸層欄位 |
| Trojan | 核對密碼、TLS 與 SNI，確認符合伺服器憑證及設定 | 以為連接埠可連線就代表 TLS 和密碼都正確 |
| Hysteria2 | 核對驗證資料、TLS 及既有設定中的混淆參數，並確認網路允許所需的 UDP 通訊 | 用 TCP 探測結果判斷以 QUIC 為基礎的連線狀態 |
| WireGuard | 核對金鑰、Endpoint、通道位址與路由範圍，並檢查 UDP 是否可連線 | 將沒有 TLS 憑證的協定也當成 SNI 問題處理 |
例如，原始資料明確標示連接埠為 8443 時，就應檢查編輯頁面是否仍為 8443，而不是因為使用 TLS 就改成 443。同樣地，TLS 的 SNI 是交握時使用的伺服器名稱；傳輸層的 Host 則是該傳輸方式所需的主機資訊。即使兩者在某份設定中相同，也不能推定所有設定都必須相同。
- 複製登入資料時，檢查前後空格、換行與全形符號，避免手動重新輸入長字串。
- 不要靠「逐一嘗試所有加密方式」排查；先取得原始欄位資料，再逐項比對。
- 更新訂閱後，重新確認 Home 目前選取的紀錄；新增或更名的紀錄不一定是先前選取的那一筆。
- 回報問題時，請遮蔽密碼、UUID、私鑰與訂閱 token。通常只要提供協定類型及錯誤發生階段，就足以開始排查。
四、檢查 iPhone 系統時間與 TLS 憑證
TLS 驗證不只會檢查憑證名稱，也會檢查有效期限。若 iPhone 時間與實際時間相差甚遠，可能導致系統誤判憑證尚未生效或已過期。前往 iPhone「設定 → 一般 → 日期與時間」，檢查「自動設定」及目前顯示的時間；若選項受管理政策限制，請先確認裝置管理要求。
修正時間後，重新建立連線再測試。若仍出現憑證錯誤，請分辨原因是裝置時間不正確、伺服器憑證過期，還是 SNI 與憑證名稱不符。裝置時間正確，無法修復伺服器已過期的憑證；將連線位址改為 IP，也不會自動解決憑證名稱不符的問題。
不要用 Allow Insecure 掩蓋憑證問題
Allow Insecure（允許不安全）會降低憑證驗證強度，不應作為一般修復方式。請保留驗證功能，核對 SNI 與原始資料，並請自己的服務供應商確認伺服器憑證。不要只為消除錯誤訊息就任意啟用此選項。
- 檢查時間：確認日期、時間與時區設定合理，尤其是手動調整過時間時。
- 檢查名稱：SNI 應使用既有設定要求的名稱，不要填入含
https://的完整 URL，也不要附加路徑。 - 檢查有效期限：若裝置時間正確，仍顯示憑證已過期，請記下原始錯誤訊息並聯絡自己的服務供應商確認。
- 區分協定：只有實際使用 TLS 的連線才需要依本節檢查；WireGuard 的金鑰與交握問題無法透過調整 SNI 解決。
五、依據記錄中的錯誤定位失敗階段
同樣是「網頁無法開啟」，實際問題可能出在名稱解析、建立連線、TLS 交握或驗證階段。重現問題後，在應用程式提供的診斷記錄中尋找相應時間的紀錄，並保留完整錯誤文字。以下列出常見的底層錯誤片段；實際大小寫、前綴與顯示位置可能因協定實作而異，不代表每次都會出現相同訊息。
錯誤：i/o timeout
原因與處理方式：某次讀取或寫入操作超過等待期限；單憑這句無法判斷是哪一層失敗。請參照前後記錄確認目標位址與失敗階段，再保持設定不變，切換 Wi-Fi 與行動網路重新測試。
錯誤：connection refused
原因與處理方式：目標端或中間設備明確拒絕連線，可能與連接埠未監聽或存取政策有關。先核對連接埠與協定；若都正確，請自己的服務供應商確認該連接埠的服務狀態。
錯誤：no such host
原因與處理方式：名稱解析階段未取得可用的主機位址，可能是拼字錯誤或 DNS 回應異常。請核對伺服器主機名稱，並透過另一種網路重新測試，不要直接更改驗證參數。
錯誤：x509: certificate has expired or is not yet valid
原因與處理方式：憑證有效期限與目前時間不符。先檢查 iPhone 是否使用自動設定時間；若時間正確，請向自己的服務供應商確認伺服器憑證，不要以關閉驗證作為長期處理方式。
記錄時請寫清楚「哪個請求、使用哪種網路、何時失敗」，不要只提交一張紅色逾時截圖。若記錄只顯示連線已關閉，也不能直接推斷是密碼錯誤：伺服器政策、傳輸參數不符或網路中斷，都可能使連線提前關閉；請搭配前述欄位檢查一併判斷。
結論：從最早失敗的階段著手修改
若同一請求最早在主機名稱解析階段失敗，就先處理位址與 DNS；只有連線已進入 TLS 或驗證階段，才繼續檢查相應欄位，避免反覆修改尚未到達的階段所用參數。
六、連線恢復後重新檢查規則與訂閱
若使用 Proxy 模式時可以連線，恢復 Config 後卻失敗，請檢查目前使用的設定中的規則與策略目標。DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依 IP 網段比對，GEOIP 使用地理 IP 條件，FINAL 則負責最終比對；這些條件不能視為完全相同的網域判斷。規則順序、實際請求的網域與最後命中的策略都要一併檢查。
例如，自己的既有設定中 FINAL,DIRECT 表示未命中前面規則的連線會直接連線；某個網頁可以開啟，不足以證明它是透過代理連線。反過來說，網站首頁與資源網域可能不同，只比對主網域也不代表所有資源都走相同路徑。請先查看請求記錄中的實際網域與命中規則，再決定是否修改 Config。
為什麼延遲測試有數值，網頁還是無法開啟？
先確認測試方式。TCP 可連線不代表協定驗證成功；在 Home 檢查選取的紀錄與 Global Routing，暫時使用 Proxy 重新測試，再查看協定欄位與 TLS 記錄。測試結束後恢復原有模式。
訂閱更新逾時，代表所有設定都失效了嗎？
不代表。更新訂閱會連線至訂閱位址，與已儲存設定的連線是兩個不同請求。在 Home 檢查訂閱紀錄，確認自己的訂閱仍有效，並查看 Settings → Subscribe → Update via Proxy 是否符合目前可用的連線方式；代理本身無法使用時，不要反覆依賴它更新。
切換到 Direct 後網頁可以開啟，就算修好了嗎？
這只能證明該網頁可以直接連線，不能證明代理設定已恢復。返回 Home → Global Routing，使用 Proxy 測試所選設定，再恢復 Config 檢查規則；若原本使用 Scene，也要檢查該場景實際採用的路由設定。
為什麼手動中斷後又自動連線？
前往 Settings → On Demand 檢查隨選連線條件。為固定測試環境，可先記下條件並暫時停用，排查完成後再恢復；系統自動重新建立連線，不代表遠端驗證已成功。
七、整理可重現的紀錄再回報問題
完成以上檢查後若仍無法連線，請整理出最精簡的紀錄，並向自己的服務供應商確認伺服器狀態。不要在公開回報中貼上完整訂閱位址；訂閱連結中的 token 通常具有存取權限，截圖也應遮蔽 QR Code 與登入資料。用戶端購買資訊與連線服務設定應分開處理；購買應用程式不會補上缺少的伺服器參數。
- 環境：iPhone 或 iPad、實際系統資訊、Wi-Fi 或行動網路；系統相容性要求以 App Store 頁面標示為準。
- 設定：協定 Type、連接埠、是否使用 TLS 與傳輸方式；不要附上密碼、私鑰或完整訂閱連結。
- 模式：Global Routing 使用 Proxy、Direct、Config 或 Scene，以及測試期間是否啟用 On Demand。
- 結果：同一頁面在兩種網路下各測三次的成功或失敗紀錄，以及採用的延遲測試方式。
- 記錄：重現問題的時間點與最早出現的錯誤原文；刪除敏感欄位後，保留必要的前後文。
若位址與連接埠、協定欄位及裝置時間都已確認無誤，且換用不同網路仍持續在同一階段失敗，接著請自己的服務供應商檢查監聽狀態、驗證資料與憑證，通常比繼續隨機修改本機設定更有效。最後恢復原本的規則與 On Demand 條件，確認日常連線也符合預期。