Shadowrocket（小火箭）顯示逾時，不代表密碼一定錯誤，也不代表遠端服務一定已停止。本文適用於已有自己的服務商與訂閱的使用者，涵蓋 iPhone、iPad、Mac（Apple 晶片與 Intel）、Windows、Android 及 Linux；操作路徑以 iPhone / iPad 為例，其他平台請對照相應設定項目。先保留原始設定與測試結果，再依序檢查測試方式、協定參數、系統時間和網路出口，每次只變更一項。
一、先分辨延遲測試失敗與實際連線失敗
延遲數值只能表示某種測試當時在該網路上完成，無法單獨證明所有應用程式都能正常連線。TCP 測試主要檢查連接埠連線；透過代理的 HTTP 測試還涉及協定交握與測試目標的回應；ICMP Ping 則可能遭遠端或中間網路丟棄。三者測量的對象不同，不能將其中一種結果當成另一種的結果。
在 Home 確認目前選取的項目，記下使用的測試方式，再對同一項目連續測試三次。若只有一次成功或數值波動明顯，先保留結果，不要立刻更改協定。接著啟用連線，用瀏覽器瀏覽自己有權存取、平時穩定可用的 HTTPS 網頁，觀察是否只有特定目標失敗。不要同時切換項目、修改 DNS 和更換網路，否則無法判斷是哪項變更生效。
| 觀察到的狀況 | 可以得出的結論 | 下一步 |
|---|---|---|
| TCP 測試成功，實際瀏覽失敗 | 連接埠可能可連通，但驗證、TLS 或目標請求仍可能失敗 | 核對協定欄位，並確認請求是否經過所選項目 |
| ICMP 沒有回應，實際瀏覽正常 | ICMP 結果不能代表代理協定無法使用 | 保留設定，以實際瀏覽和協定測試結果為準 |
| 同一訂閱中的所有項目都逾時 | 可能存在共同原因，不能直接判定所有伺服器都故障 | 檢查網路、訂閱狀態、網域解析和裝置時間 |
| 只有一個項目持續失敗 | 問題範圍較可能在該項目或其遠端服務 | 核對該項目的位址、連接埠及服務狀態 |
結論：先固定測試對象
選定一個項目、一種測試方式和一個目標網頁作為基準；固定基準後，切換網路或修正參數的結果才有比較意義。
二、依序核對位址、連接埠與訂閱內容
檢查設定時，應從最基本的連線資訊開始。位址少打一個字元，或把連接埠填成其他服務使用的監聽埠，都可能造成逾時。連接埠並非協定名稱固定搭配的值：使用 TLS 不代表連接埠一定是 443，也不能因為 443 很常見，就擅自將原連接埠改成 443。
-
保留原始設定
在 Home 記下目前項目的名稱、Type 和錯誤發生時間；修改 Config 前，先儲存原始設定的副本。含有密碼、UUID、私鑰的內容只儲存在自己的裝置上，不要上傳至公開討論區。
-
核對位址
從 Home 開啟目前項目的編輯畫面，逐字比對 Address 與自己的服務商提供的原始參數。位址欄位通常填寫網域或 IP，不要連同完整網頁網址、路徑或前後空白一起貼上。
-
核對連接埠
確認 Port 與遠端監聽埠一致。有效連接埠範圍為 1–65535；例如遠端提供 8443，就不能因為瀏覽器常用 HTTPS 而改成 443。連接埠可連通，也不代表該埠上執行的是正確的代理服務。
-
核對驗證資訊
對照原始資料檢查 Password、UUID 或相應的金鑰欄位，留意複製時是否帶入換行或前後空白。不要將訂閱連結中的存取權杖填入節點密碼欄位，兩者用途不同。
-
更新後重新測試
如果項目是由訂閱產生，請在 Home 更新對應訂閱或下拉重新整理；確認操作完成後，再重新選取項目。更新可能會覆寫訂閱產生的欄位；若有暫時修改，請先記錄。更新失敗時，不要刪除仍可使用的舊設定。
訂閱更新成功，只代表訂閱內容可取得並解析，不代表其中每個位址都在線。反過來說，更新失敗也不一定會使已儲存的項目失效。如果服務商變更了連接埠、驗證資訊或傳輸設定，舊項目仍會顯示在清單中，但未必仍適用；此時應向自己的服務商確認變更，而不是反覆匯入相同的舊內容。
三、依協定核對交握與傳輸參數
Address、Port 正確後，再檢查 Type 及其相關欄位。不同協定不能只靠更換名稱就彼此相容；相同的伺服器位址也可能對應多組不同服務。下表用來確認檢查方向，實際欄位是否出現取決於具體協定與設定，不要將某一列的設定直接套用到所有項目。
| 協定 | 核對重點 | 常見判斷限制 |
|---|---|---|
| Shadowsocks | 加密方式、Password、Address、Port | 密碼和加密方式必須完全一致；連接埠可連通不足以證明解密成功 |
| VMess | UUID、加密設定、傳輸方式及服務端指定的附加參數 | 系統時間明顯有誤可能影響驗證，不能只檢查 UUID |
| VLESS | UUID、傳輸方式、TLS 及服務端要求的安全參數 | 只複製 UUID 不代表完整複製了一份可用設定 |
| Trojan | Password、TLS、Server Name 和憑證信任狀態 | 連線 IP 與 TLS 驗證使用的網域可能不同，必須依原始設定填寫 |
| Hysteria2 | 驗證資訊、TLS、服務端指定參數及 UDP 可連通性 | 以 QUIC 為基礎；TCP 測試成功不能證明 UDP 通道可用 |
| WireGuard | 本機私鑰、對端公鑰、Endpoint、通道位址與 Allowed IPs | 依賴 UDP；交握成功後仍須檢查路由與 DNS |
若採用 WebSocket 傳輸，應核對 Path 與 Host。Path 中的斜線、大小寫或結尾字元不同，都可能讓請求送至錯誤的服務路徑。Host 用於 HTTP 請求，Server Name 用於 TLS 交握時的伺服器名稱，兩者不是可任意互換的同一欄位。只有原始設定要求兩者相同時，才填入相同值。
- TLS 名稱：若 Address 使用 IP，但憑證是簽發給網域，請保留服務商指定的 Server Name，不要將所有名稱欄位都換成 IP。
- 傳輸方式：遠端要求 WebSocket 時，不能改成一般 TCP 後期待自動相容；gRPC 等傳輸方式也需要相應的服務端設定。
- 憑證驗證：出現憑證錯誤時，先檢查時間、網域和憑證有效期限；不要長期關閉憑證驗證來當作修復方式。
四、依錯誤訊息定位，不要把所有失敗都當成逾時
在相關請求的記錄或診斷結果中記下完整錯誤訊息。以下列出常見的底層錯誤片段，但各平台顯示的文字可能不完全相同；若只看到籠統的連線失敗，應依發生階段判斷，不要單憑一個詞就認定問題出在本機或遠端。
錯誤：i/o timeout
原因與處理方式：某項操作未能在等待期限內完成，可能發生於解析、連線或交握階段——先查看前後記錄，確認目標位址與發生階段，再使用同一項目切換網路進行比較；不能僅憑這則訊息斷定密碼錯誤。
錯誤：connection refused
原因與處理方式：連線請求遭到明確拒絕，常見原因是連接埠沒有服務監聽或遭到主動拒絕——核對 Port，並向自己的服務商確認該連接埠的監聽狀態，不要試圖靠延長等待時間來處理。
錯誤：no such host
原因與處理方式：網域解析未取得可用結果，可能與拼字、解析設定或網域記錄有關——先逐字核對 Address，再檢查目前網路的 DNS；不要直接將它歸類為驗證失敗。
錯誤：x509: certificate has expired or is not yet valid
原因與處理方式：憑證有效期限與目前裝置時間不符——先校正裝置日期、時間與時區；如果時間正確仍出現錯誤，請由服務端維護者檢查憑證有效期限和憑證鏈。
若記錄顯示連線已建立，之後才出現目標網站的 HTTP 錯誤，應區分代理連線路徑與目標回應。單一網頁回傳 403 或 429，可能是目標網站的存取政策或頻率限制，不等於節點連接埠無法連通。保留回應發生的時間和目標網域，避免將目標網頁拒絕存取誤判為整個用戶端失效。
五、校正系統時間，再檢查網路出口
TLS 會檢查憑證有效期限，某些驗證機制也依賴時間範圍。日期錯到過去或未來，或裝置長期離線後時間未同步，都可能使正確參數無法完成交握。iPhone / iPad 可在系統 Settings → General → Date & Time 檢查 Set Automatically；其他平台則在系統日期與時間設定中啟用自動同步，確認顯示的時間正確後再重新測試。
- 先建立直連基準：暫停 Shadowrocket 連線，用瀏覽器確認目前的 Wi-Fi 或行動網路本身可以正常瀏覽網頁。若飯店、校園等網路要求網頁認證，請先完成網路認證。
- 比較不同網路：使用同一部裝置、同一項目和同一目標，在 Wi-Fi 與行動網路各測試一次。若只有某個網路失敗，優先檢查該網路的出口策略，而不是修改所有協定欄位。
- 檢查 UDP 限制：Hysteria2 與 WireGuard 依賴 UDP。若這兩者在某個網路失敗，而既有的 TCP 類連線可用，只能表示值得檢查 UDP 通道，還不能直接證明協定實作有問題。
- 排除通道衝突：檢查系統中是否有其他 VPN 或網路過濾設定正在接管連線；暫時停用衝突項目後重新測試。受管理的裝置應遵循管理員政策，不要繞過組織限制。
若關閉連線後又自動恢復，請檢查 Shadowrocket 的 Settings → On Demand，並記下原設定後暫時停用自動觸發條件。On Demand 決定何時啟動連線，不負責修正位址、密碼或遠端服務狀態。排除問題後，應依原本用途恢復設定，而不是一直關閉自動連線來當作通用修復方式。
調整 DNS 的時機：只有出現解析失敗或明顯錯誤的解析結果時，才需要針對 DNS 進行檢查。不要一次替換所有 DNS 項目，也不要任意用 IP 取代網域；這可能同時破壞 TLS 名稱驗證，讓原本的故障更難重現。
六、延遲正常但無法瀏覽時，檢查 Global Routing 與 Rule
節點測試和應用程式請求可能經過不同的處理路徑。進入 Home → Global Routing，先記下目前的選項。Proxy 用於代理路由，Direct 用於直連路由，Config 依目前設定處理，Scene 依已設定的情境處理。它們不是四種連線協定，也不能只憑名稱判斷目前網頁使用哪個出口；仍須檢查比對結果與實際使用的項目。
- 短暫比較：了解網路影響後，以 Proxy 與 Config 的瀏覽結果互相比較，測試後恢復原設定。若 Proxy 可用而 Config 無法使用，下一步應檢查規則與策略，而不是先修改驗證欄位。
- 檢查順序：在 Config 開啟目前生效的設定，檢查 Rule 由上至下的比對順序。前面的規則命中後，後面的規則通常不會再參與該請求的選路。
- 檢查對象：DOMAIN-SUFFIX 用於網域後綴，IP-CIDR 用於 IP 網段，GEOIP 依 IP 地理資料庫比對，FINAL 則處理先前未命中的請求。比對對象各不相同，不能用同一項判斷涵蓋所有連線。
- 檢查策略：確認命中的 PROXY、DIRECT、REJECT 或自訂策略群組符合預期；群組名稱存在，不代表群組目前選用的項目可用。
以下僅示範規則順序與語法，並非建議整份覆蓋現有 Config 的設定。example.com 是文件示例網域，192.0.2.0/24 是文件示例網段；請依自己的存取目標理解，不要將示例誤認為真實服務參數。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY結論：依故障階段修改設定
連接埠尚未連通時，先檢查位址與網路；交握失敗時，檢查驗證資訊、TLS 與時間；只有交握和實際代理連線都成功後，才應著重檢查規則是否將特定請求送往錯誤策略。
七、保留可重現的記錄，再向自己的服務商回報
完成以上檢查仍無法連線時，提供能協助定位問題的記錄，比只說「全部逾時」更有效。記錄中應區分測試結果與推測：例如「同一項目在 Wi-Fi 失敗、行動網路成功」是可供查證的現象；「伺服器遭到限制」則只是仍待驗證的推測。不要填入未經測試的結論，也不要為了補齊記錄而公開憑證。
- 裝置與環境：裝置平台、目前的網路類型，以及是否需要網路認證或受組織管理政策限制。
- 重現時間：故障發生時間與時區、系統時間是否已同步，方便比對遠端記錄。
- 設定範圍：協定 Type、傳輸方式、是否使用 TLS，以及是單一項目失敗或同組項目全部失敗。
- 比較結果：測試方式、連續三次的結果、不同網路的測試結果，以及 Global Routing 的選項。
- 錯誤片段：保留必要的階段資訊，遮蔽 Password、UUID、私鑰、訂閱權杖與個人資料。
本站不提供、不銷售、不推薦節點或訂閱；線路狀態、憑證有效性與遠端設定須由使用者自己的服務商確認。用戶端取得方式與線路服務是兩回事，不應以反覆安裝取代參數核對。需要安裝或更換裝置時，請參閱本站的全平台下載指南，依裝置選擇相應入口。