本文適用於已在 Shadowrocket（小火箭）中匯入自有服務商設定的使用者。先區分延遲測試逾時、協定交握失敗和網頁請求失敗，再逐項核對伺服器參數、路由與系統時間。每次只變更一個項目，記錄相同請求變更前後的結果；測試數值不能證明整條連線都正常。
一、先記錄狀況，區分測試失敗與請求失敗
進入 Home，確認目前選取的伺服器，再執行 Connectivity Test。記下測試方式、顯示結果和使用的網路；若能選擇測試方式，請分別記錄 TCP 測試與實際請求測試。測試結果只反映特定探測流程，不能代表所有網站、協定和網路環境下的連線狀態。
TCP 測試主要檢查是否能與指定位址和連接埠建立 TCP 連線。即使顯示毫秒數，也不能證明密碼正確、TLS 憑證驗證成功或目標網站可連線。Hysteria2 使用以 UDP 為基礎的 QUIC，WireGuard 也使用 UDP；單純的 TCP 探測無法取代實際通訊驗證。
| 觀察到的狀況 | 可能代表什麼 | 下一步檢查 |
|---|---|---|
| TCP 測試有毫秒數，但網頁無法開啟 | 可能已成功建立 TCP 連線，但後續流程仍可能失敗 | 檢查驗證、TLS、路由與 DNS |
| 測試逾時，但實際請求可用 | 探測方式或目標與實際請求不同 | 記下測試方式，先別急著修改協定參數 |
| 相同設定只有在 Wi-Fi 下失敗 | 問題可能與該網路路徑有關 | 切換至行動網路後重送相同請求 |
| 只有一個網站無法連線 | 尚無法判定是整條連線出了問題 | 檢查該請求的 DNS、命中規則及目標服務狀態 |
結論：以實際請求確認測試結果
保留相同伺服器與設定，使用已知可連線的 HTTPS 網頁重新測試。應綜合測試結果與實際請求的表現，再決定下一步要檢查什麼。
二、依固定順序重新測試，避免同時修改多項設定
先確認 iPhone 在關閉 Shadowrocket 連線時可正常使用目前的網路。若公共 Wi-Fi 需要網頁驗證，請先完成驗證再啟用連線。接著依照下列順序排查；現有訂閱與伺服器參數請以你所使用的服務商提供的資料為準。
-
記錄基準狀態
在 Home 記下選取的伺服器、Connectivity Test 結果和 Global Routing 目前的值，同時記錄使用 Wi-Fi 或行動網路。先別一次刪除多筆設定。
-
重新確認位址
開啟 Home 中該伺服器的編輯頁面，核對位址和連接埠。位址欄前後不應有多餘空格；一般伺服器位址不可填入訂閱連結，也不要自行加上
https://或路徑。 -
核對參數
依照服務商提供的資料，逐項核對 Type、驗證資訊、TLS 和傳輸參數。儲存後重新建立連線，再送出新的網頁請求，避免以舊連線的結果作判斷。
-
切換網路測試
保持參數不變，在 Wi-Fi 和行動網路之間切換。若只在其中一種網路下逾時，請記錄網路差異；暫時恢復正常不代表密碼已重新驗證。
-
檢查時間
前往 iPhone「設定」→「一般」→「日期與時間」，確認「自動設定」以及目前的日期、時間和時區。調整後重新連線，並再次測試相同的 HTTPS 請求。
三、逐項核對位址、連接埠與協定參數
進入 Home 的伺服器編輯頁面，先確認協定類型與服務商提供的資料完全一致，再逐一比對欄位。連接埠是伺服器指定的監聽入口：即使填入 443，也不代表該連接埠一定提供可用的 HTTPS 或 TLS 服務；不要因為某個連接埠很常見就自行取代原設定。
| 協定 | 核對重點 | 常見錯誤 |
|---|---|---|
| Shadowsocks | 伺服器、連接埠、加密方式、密碼，以及伺服器要求的外掛參數 | 只複製密碼，漏掉加密方式或外掛設定 |
| VMess | UUID、加密設定，以及伺服器要求的傳輸方式與 TLS 參數 | 把 UUID 填入其他驗證欄位，或漏掉傳輸參數 |
| VLESS | UUID、傳輸方式，以及伺服器要求的 TLS、Reality 或 flow 參數 | 以為同一個 UUID 可以搭配任意傳輸方式與安全設定 |
| Trojan | 密碼、TLS、伺服器名稱與傳輸設定 | 位址可以連線，就忽略憑證所對應的伺服器名稱 |
| Hysteria2 | 驗證資訊、TLS 伺服器名稱，以及伺服器要求的混淆設定 | 以 TCP 探測結果判定 UDP 路徑一定可用 |
| WireGuard | 本機私鑰、對端公鑰、Endpoint、介面位址與路由範圍 | 混淆本機私鑰與對端公鑰，或忽略 UDP 是否可連線 |
TLS 伺服器名稱不一定與實際連線位址相同。連線位址決定請求要送往哪裡；伺服器名稱則用於 TLS 協商與憑證身分驗證。使用 WebSocket 時，Host 和 Path 也會參與應用層請求。這些值可能相同，但不能因為看起來相似就互相替換。
- 密碼與 UUID：確認複製時沒有帶入換行、引號或尾端空格，也不要公開貼上完整的驗證資訊。
- Path：例如
/connect只是路徑格式範例，實際值必須以伺服器設定為準，並確認大小寫和開頭的斜線。 - 位址與連接埠：使用網域名稱時也需要 DNS 解析。改用 IP 並非通用解法，尤其不要因此一併刪除 TLS 伺服器名稱。
- 更新訂閱：服務商可能會調整伺服器位址或參數。保留自訂變更的記錄，更新自己的訂閱後重新核對選取項目，避免繼續使用過期欄位。
四、依錯誤訊息縮小範圍，別用同一種方式處理所有連線失敗
記錄連線失敗前後的日誌內容，優先查看最先出現的錯誤及其對應目標。以下是網路或 TLS 日誌中可能出現的錯誤片段；每次失敗的措辭不一定相同，單獨一行訊息也無法證明問題一定出在伺服器端。
錯誤：i/o timeout
原因與處理方式：某個讀取或寫入步驟未能在期限內完成，可能與名稱解析、網路路徑或遠端回應有關。先確認錯誤訊息對應的目標，再保持參數不變，切換網路並重測相同請求。
錯誤：connection refused
原因與處理方式：目標或中間設備明確拒絕了連線請求，常見原因是該連接埠沒有服務監聽或拒絕連線。核對服務商指定的位址與連接埠，再向自己的服務商確認該入口的狀態。
錯誤：certificate has expired or is not yet valid
原因與處理方式：憑證有效期間與裝置目前時間不符，也可能是遠端憑證確實已過期。先校準 iPhone 時間；若時間正確仍失敗，請服務商檢查憑證，不要以略過驗證取代修復。
錯誤：no such host
原因與處理方式：相關網域名稱未能解析成可用位址。先檢查網域拼字，再確認是伺服器網域還是目標網站的網域解析失敗，接著檢查目前設定的 DNS 與基本網路連線。
相同錯誤連續出現時，別只延長等待時間。先判斷失敗發生的位置：伺服器網域無法解析時，檢查位址和 DNS；已進入 TLS 協商時，檢查時間、伺服器名稱與憑證；驗證失敗則回頭檢查協定參數。失敗階段不同，處理方向也不同。
五、已建立連線時，檢查 Global Routing 與 DNS
返回 Home → Global Routing，記錄目前的選項。Proxy、Direct、Config、Scene 會影響請求採用的路由方式，並非四種不同的連線協定。系統顯示 VPN 已連線，主要表示系統隧道已建立，不能據此判定每個請求都經過選取的伺服器並成功抵達目標。
- Proxy：用來對照測試代理路徑。暫時切換後重新送出請求；請留意本機網路資源的存取方式可能隨之改變，測試後請恢復原設定。
- Direct：請求採用直連路徑；在此模式下網頁可以開啟，不代表伺服器驗證與轉送功能正常。
- Config：依照目前選取的設定檔套用規則。在 Config 中確認實際啟用的檔案，再檢查 Rule 區段，不要只查看未選取的檔案。
- Scene：依照已設定的場景決定路由行為。排查時也要核對場景實際使用的設定，不可將其視為固定的 Proxy 或 Direct 模式。
在 Config 模式下，Rule 區段會依序比對。前面的 DOMAIN-SUFFIX、IP-CIDR 或 GEOIP 規則可能先決定請求的路由；FINAL 用來處理未符合前面規則的請求，應放在規則末尾。若同一目標在 Proxy 下可用、在 Config 下失敗，應先檢查命中規則與對應策略，不要立刻修改密碼。
六、最後校準系統時間，並保留有效的排查記錄
開啟 iPhone「設定」→「一般」→「日期與時間」，確認「自動設定」。若日期、時間或時區顯示異常，先恢復正確設定並確認裝置實際時間。憑證驗證會參照目前時間；單純變更時區顯示不代表裝置時鐘已校正。VMess 等具備時間相關驗證機制的協定，也可能受到明顯時鐘誤差影響。
時間正確仍無法連線時，整理最精簡的故障記錄提供給自己的服務商：發生時間與時區、網路類型、協定、測試方式、已去識別的錯誤片段，以及切換網路後的結果。請勿傳送密碼、私鑰、完整 UUID 或完整訂閱連結。
延遲測試有數值，為什麼網頁還是打不開？
先確認數值來自哪一種測試。返回 Home → Global Routing，記錄目前模式，再使用 Proxy 送出一次對照請求；若仍然失敗，再核對協定驗證與 TLS 參數。TCP 連線建立成功，不代表後續驗證和目標網站存取也成功。
Wi-Fi 逾時、行動網路正常，需要重新輸入密碼嗎？
先保留目前的密碼。確認 Wi-Fi 已完成網頁驗證，再使用相同伺服器和請求重新測試；使用 Hysteria2、WireGuard 時，也要留意該網路是否能連通 UDP。向服務商回報網路差異，比反覆輸入相同參數更有助於定位問題。
訂閱更新成功，就代表所有伺服器都能連線嗎？
不是。更新成功只代表已取得並處理訂閱內容。返回 Home 選取特定伺服器，分別檢查測試結果與實際請求；訂閱內容中的位址和驗證參數仍可能需要服務商確認。
需要先刪除系統 VPN 設定或重新購買嗎？
不建議將這兩項作為排查逾時的起點。若系統隧道可以建立，先檢查位址、協定、路由與時間；只有系統授權或隧道本身無法建立時，再依照首次連線教學確認授權流程。
結論：透過單一變因重新測試，確認問題已排除
修正一個項目後，重新連線並連續送出幾次相同請求，確認原有錯誤不再出現，再恢復暫時調整的路由與 On Demand 條件。一次成功只能作為線索，不能取代對原故障情境的重新測試。