本文適用於已有自己的服務商與訂閱,但在 Shadowrocket(小火箭)中遇到逾時或連線失敗的使用者。先區分本機網路、測試結果與實際代理請求,再逐項核對位址、連接埠、驗證、TLS 和系統時間;最後對照規則與網路,縮小故障範圍並留下可供日後查核的紀錄。
一、先區分測試逾時與實際連線失敗
延遲測試回傳數字,只能表示這次測試所涵蓋的連線路徑有收到回應,不能據此判定所有網站、驗證流程與傳輸方式都可正常使用。反過來說,單次測試逾時也不足以證明伺服器已停止服務。測試方法、目標位址、網路狀態與伺服器端限制都可能影響結果。
Shadowrocket 的連線開關已開啟,表示系統 VPN 通道已建立或正在建立,不代表遠端伺服器已完成驗證。排查時應分別記錄「開關能否維持開啟」、「測試是否有回應」和「實際請求是否成功」,不要把這三項都歸為「連不上」。
- 基本網路異常:關閉 Shadowrocket 後,已知可直接存取的網頁也無法開啟,應先處理 Wi-Fi、行動數據或網路登入頁面。
- 測試失敗:Home 中的測試逾時,但尚未確認實際存取情況,目前只能判定問題出在測試環節。
- 代理請求失敗:基本網路正常,選取伺服器後實際請求仍失敗,接著檢查參數與記錄。
- 特定目標失敗:其他目標正常,只有某個網域異常,優先檢查該目標、DNS 與分流規則。
二、固定測試條件,再比較延遲結果
初次排查時先不要更改設定。選定同一筆既有伺服器記錄,使用相同的測試方法,並在相近時間內重複測試幾次。只比較數字而不記下測試方法,容易把不同意義的結果混為一談。
-
確認本機網路
關閉 Home 的連線開關,在 Safari 開啟已知可直接存取的網頁。若公共 Wi-Fi 需要登入,先完成登入,再返回 Shadowrocket。
-
選定同一筆記錄
返回 Home,選取要檢查的伺服器。記下目前使用的 Wi-Fi 或行動數據,並確認測試的不是名稱相近的另一筆記錄。
-
重複進行延遲測試
在 Home 執行 Connectivity Test,確認目前使用的測試方法;在相同條件下測試三次,分別記錄有回應或逾時。請勿以連續快速點按取代間隔一段時間後的重新測試。
-
驗證實際請求
開啟連線後,以同一個目標頁面確認實際存取情況。分別記錄測試結果與頁面結果;兩者不一致時,先保留差異,不要急著刪除設定。
-
切換網路後重新測試
在裝置與資費方案允許的情況下,切換 Wi-Fi 與行動數據,重做前述測試。除了網路之外,不要更改任何欄位,以免失去對照條件。
結論:先判斷故障是否隨網路改變
同一筆記錄只在某個網路下失敗時,先檢查該網路的 DNS、登入狀態與傳輸限制;兩種網路都失敗時,再集中核對伺服器參數與服務狀態。無論是哪種情況,都不能只憑延遲值判定根本原因。
三、依序核對協定參數:位址、連接埠、驗證與傳輸
在 Home 開啟對應記錄的編輯頁面,對照服務商提供的原始資訊,先確認 Type,再檢查其他欄位。不同協定需要的參數各不相同,不能只把伺服器位址和密碼搬到另一種 Type。編輯前先保留可還原的副本,尤其不要覆蓋仍可使用的記錄。
| 核對項目 | 具體檢查內容 | 常見誤判 |
|---|---|---|
| 位址與連接埠 | 確認伺服器位址完整,連接埠與原始資訊一致;連接埠範圍應為 1–65535。 | 把 443 當成通用答案。連接埠是 443,不代表所有協定都能使用,也不表示一定採用 TLS。 |
| Shadowsocks | 核對加密方式與密碼;若伺服器端使用外掛程式,也要核對外掛程式及相關參數。 | 以為位址與連接埠正確,就可以忽略加密方式不一致。 |
| VMess / VLESS | 核對 UUID、傳輸方式及該記錄實際啟用的安全選項。若 VLESS 使用 flow,也必須與伺服器端設定一致。 | 以為兩種協定都使用 UUID,就可以互換 Type。 |
| Trojan | 核對密碼、TLS 設定、Server Name 與指定的傳輸方式。 | 只更新密碼,卻漏掉伺服器端變更的網域或傳輸參數。 |
| Hysteria2 | 核對驗證、TLS、連接埠與可能啟用的混淆參數,並確認目前網路允許相應的 UDP 通訊。 | 只做一次 TCP 連接埠測試,就推斷 UDP 連線正常。 |
| WireGuard | 核對金鑰是否成對、Endpoint、通道位址與 AllowedIPs 等設定。 | 把金鑰、路由與握手問題一概當成密碼錯誤。 |
| WS / gRPC | 只有該記錄使用相應傳輸方式時,才核對 WS 的 Path、Host 或 gRPC 的 Service Name。 | 把 Path、Host、Server Name 當成同一個欄位。 |
Server Name 通常會影響 TLS 握手時使用的名稱與憑證驗證;WS 的 Host 屬於 HTTP 請求資訊,Path 則是請求路徑。三者即使使用相似文字,也不能自行合併。路徑的大小寫、開頭斜線,以及 UUID 中多出的空格,都應依照原始資料逐字核對。
四、檢查系統時間與 TLS,不要略過憑證驗證
憑證有有效期限,裝置日期明顯錯誤時,即使網路與密碼正確,也可能在 TLS 階段失敗。部分協定的驗證同樣會受到時間影響。應在核對參數後檢查時間,但不必等到所有嘗試都失敗才查看。
- 在 iPhone 或 iPad 開啟系統 Settings → General → Date & Time,檢查 Set Automatically,並確認顯示的日期和時間合理。
- 若自動設定受到裝置管理或其他限制,應先處理限制;不要把日期調回過去來規避已過期的憑證。
- 校正時間後,先中斷再重新連線,以同一筆記錄和同一個目標重新測試,避免只查看舊頁面的快取內容。
- 時間正確但仍出現憑證問題時,核對伺服器位址、Server Name 與憑證涵蓋的網域,再向自己的服務商確認有效期限和憑證鏈。
不要把關閉憑證驗證當成一般修復方式。這會改變安全性,也可能掩蓋連到錯誤伺服器、網域設定錯誤等問題。裝置時間正確與憑證正確是兩項獨立條件,應分別確認。
五、根據記錄原文判斷失敗階段
失敗後查看連線記錄,記下錯誤發生時間、目標位址和相關行。以下是網路或 TLS 記錄中可能出現的原文片段;實際顯示內容可能包含前後文,而且各協定的提示不一定完全相同。錯誤訊息只能協助判斷問題階段,不能單獨證明是哪一方造成問題。
錯誤:i/o timeout
原因:某個讀取或寫入階段未能在期限內完成,可能與網路封包遺失、遠端沒有回應或中間連線路徑受限有關。
處理方式:根據前後記錄確認正在連線的位址,以相同設定切換網路後重測,再核對連接埠與遠端服務狀態。
錯誤:connection refused
原因:連線要求遭到主動拒絕,常見情況是目標連接埠沒有程式監聽,也可能是中間設備回傳拒絕訊息。
處理方式:優先核對伺服器位址與連接埠,將發生時間及錯誤訊息提供給自己的服務商,確認監聽狀態;不要隨機嘗試不同連接埠。
錯誤:x509: certificate has expired or is not yet valid
原因:憑證有效期限與目前時間不符,可能是裝置時間錯誤,也可能是遠端憑證本身異常。
處理方式:先檢查系統的 Date & Time,再確認遠端憑證有效期限;維持憑證驗證啟用。
錯誤:EOF
原因:資料流提早結束,可能發生於協定不符、驗證失敗或遠端主動關閉等不同階段。
處理方式:依據前面的握手資訊核對 Type、驗證與傳輸參數,不能只憑這一行就認定是密碼錯誤。
六、連線建立後,再檢查分流與 On Demand
若測試有回應,但網頁仍無法開啟,應檢查請求是否真的經過所選伺服器。Home → Global Routing 中的 Proxy、Direct、Config、Scene 分別代表不同的路由模式,並非連線品質等級。Direct 不會因為一次直連成功就替你驗證代理伺服器;使用 Config 時則須配合目前啟用的設定判斷。
- 短暫比對:若要確認特定請求,可暫時使用 Proxy,排除規則分流的影響;測試後還原原本的 Global Routing。請記下變更前的模式,避免長期誤用。
- 檢查設定:使用 Config 時,前往 Config 確認目前啟用的檔案,再檢查規則順序與策略名稱。使用 Scene 時,則須核對實際生效的場景設定,不能只看名稱。
- 判斷規則:
DOMAIN-SUFFIX符合網域及其子網域;IP-CIDR依 IP 網段比對;GEOIP依 IP 地理資訊比對;FINAL是前面規則都未符合時的預設策略。網域解析與規則順序都可能影響最後採用的策略。 - 排除自動觸發:在 Settings → On Demand 檢查隨選連線設定。若要手動重新測試,可暫時停用 On Demand,再自行控制連線;測試後依原設定還原。
On Demand 會依條件觸發連線,無法修正錯誤密碼、失效憑證或未啟用監聽的連接埠。若手動中斷後又自動連線,應先核對觸發條件,而不是一再刪除系統 VPN 設定。系統 VPN 授權問題與遠端伺服器逾時屬於不同環節。
七、常見問題與排查紀錄整理
延遲很低,為什麼網頁還是打不開?
先確認目前的測試方法涵蓋哪些階段,再到 Home 核對所選記錄與 Global Routing。使用 Proxy 做一次短暫比對,同時查看失敗請求的記錄;若只有特定網域失敗,再檢查 DNS、規則與目標網站狀態,不要只按延遲重新排序。
Wi-Fi 會逾時,行動數據卻正常,需要更改協定嗎?
先維持設定不變,確認 Wi-Fi 已完成登入,再對同一個目標重新測試。若差異持續存在,記錄協定使用的傳輸方式,再向網路管理者或自己的服務商確認限制。尤其是 UDP 相關問題,不能只因 TCP 可連線就排除網路因素。
更新訂閱後全部逾時,是不是更新失敗?
先區分更新失敗與更新後連線失敗。在 Home 確認是否出現新記錄,以及選取的記錄是否正確,再依服務商提供的資訊核對 Type、位址與連接埠。訂閱能正常取得,不代表其中每個遠端服務都可使用;也不要一再更新來取代協定參數檢查。
需要把完整設定和訂閱連結傳給別人嗎?
不需要。先整理錯誤原文、發生時間與時區、目前使用的網路、協定類型、測試方法和對照結果。請遮蔽密碼、UUID、私鑰與訂閱 token;需要服務端協助確認的內容,請透過自己的服務商提供的私人支援管道提交。
結論:每次只變更一項條件
每次重新測試只變更網路、參數、時間或路由中的一項,並記錄結果。向自己的服務商說明「哪一步失敗、在哪種網路下重現、出現什麼錯誤」,會比只說「節點不能用」更容易找出問題。
排查完成後,還原暫時更改的 Global Routing 與 On Demand 設定,並保留一份確認可用的設定。Shadowrocket 是 Apple 平台上的閉源商業用戶端,買斷用戶端 ≠ 購買線路方案;取得 App 與排查遠端服務是兩回事,重新購買 App 無法取代遠端參數修復。