Shadowrocket 節點逾時、連線失敗怎麼排除：延遲測試、協定參數與系統時間檢查順序

一、先確認故障範圍，保留現場資訊以便比對

先分清楚三種情況：訂閱更新失敗、節點測試失敗，以及連線後特定網頁無法開啟。這些問題可能發生在不同環節。訂閱更新是取得設定資料；節點測試則依所選的測試方式執行；網頁連線還涉及路由、DNS、協定交握與目標網站。不能只憑一個「逾時」就把它們當成同一種問題。

開始前，先在 Home 記下目前選取的節點名稱、Global Routing 選項，以及出現錯誤時執行的操作。保留 Config 中的原有設定，不要先清除規則。如果 Settings → On Demand 已啟用，也請記下目前狀態；若要手動中斷連線進行比對，先確認既有條件不會再次觸發連線。

1. 檢查基本網路：暫時中斷連線，確認目前的 Wi-Fi 或行動網路可以開啟平常能直接瀏覽的網頁。如果 Wi-Fi 需要登入網頁認證，請先完成認證。
2. 固定測試對象：選定自己已有的一個節點，後續檢查與測試都使用同一個節點，避免混淆不同設定的結果。
3. 記錄原始結果：記下是測試逾時、連線開關無法維持，還是只有特定 App 的請求失敗，並保留完整錯誤訊息。
4. 每次只改一項：變更後用相同操作重新測試；若問題沒有改善，先還原該項設定，再進行下一步。

二、解讀延遲測試：測得到數值，不代表連線可用

先確認測試方式，再判讀測試結果。TCP 交握主要檢查位址與連接埠是否可連通，不會驗證完整代理協定的認證流程；透過節點發出的 HTTP 請求測試則會涉及更多環節，也包含測試目標本身。兩種方式測得的時間意義不同，不宜直接比較，更不能將數值視為下載速度。

在 Home 對同一個節點重複執行目前的測試，並記錄結果是否穩定。如果 App 選用了不同的測試方式，也一併記下。以下建議測試三次，僅供故障排查紀錄參考，並非 App 規定的次數；目的是分辨持續失敗與偶發波動。

如果同一份設定在 Wi-Fi 下失敗、在行動網路下成功，差異首先可能與網路路徑或該網路的限制有關，但還不能據此確認確切原因。如果兩種網路都失敗，也不能直接判定伺服器停機；位址錯誤、憑證過期、DNS 解析異常與協定不相符都仍須逐項排除。

三、核對位址、連接埠與協定參數，不要猜測數值來替換

從 Home 開啟目前節點的編輯頁，逐項比對自己服務商提供的原始設定。先確認類型是否一致，再檢查位址與連接埠，最後核對認證、TLS 與傳輸欄位。訂閱匯入成功，只代表用戶端取得並解析了資料，不代表其中每個節點都能成功連線。

使用網域名稱時，也要確認解析出的位址是否正確。不要為了略過解析而任意將網域名稱換成 IP：這可能改變伺服器入口選擇，也會影響 TLS 主機名稱驗證。若設定使用 WebSocket，路徑、Host 與 TLS 的 SNI 各有用途；不能因為看起來都是網域名稱就互相替換。

• 複製密碼、UUID 或金鑰時，請檢查前後空格、換行與內容是否截斷；不要憑截圖猜測字元。
• 如果自己的服務商確認參數已變更，請先保留現有設定，再更新對應的訂閱；更新後重新確認實際選取的節點。
• 訂閱更新失敗時，先確認連結有效且目前網路可以連線，不要先刪除唯一一份可用的設定。
• 不要藉由關閉憑證驗證來掩蓋 TLS 錯誤；請先檢查系統時間、SNI 與憑證狀態。

四、先檢查 iPhone 系統時間，再分析 TLS 錯誤

iPhone 的日期、時間或時區明顯不正確，可能影響憑證有效期限的判斷，也可能影響需要時間驗證的認證流程。憑證有生效時間與到期時間；裝置時鐘偏差過大時，即使位址與密碼正確，也可能在交握階段失敗。這不是所有逾時問題的共同原因，但檢查成本低，值得確認。

1. 開啟 iPhone 系統「設定」→「一般」→「日期與時間」，確認「自動設定」是否已開啟。
2. 確認顯示的日期、當地時間與時區合理。如果無法變更開關，請檢查裝置管理或使用限制，不要任意移除管理設定。
3. 返回 Shadowrocket，中斷連線後重新連上同一個節點，再執行相同測試。
4. 如果仍出現 TLS 相關錯誤，請將完整錯誤訊息與發生時間提供給自己的服務商，確認伺服器憑證、憑證鏈與網域設定。

系統時間正確只是必要檢查項目之一，並不能自動修復憑證過期、憑證名稱不符或伺服器設定異常。以下列出常見網路錯誤訊息的判讀方向；只有實際記錄出現相應文字時，才依該項分析，具體措辭可能隨系統與失敗階段而異。

五、連線後仍無法開啟網頁：檢查 Global Routing 與規則比對

連線開關顯示開啟，不代表每個請求都會經過目前的節點。Home → Global Routing 會決定整體路由方式：Proxy 用於代理路由，Direct 用於直接連線，Config 依目前設定處理，Scene 則依已設定的情境選擇相應路由方式。排查時先記下目前選項，不要只檢查節點名稱。

如果要排除規則造成的影響，可先確認測試範圍，再暫時使用 Proxy 對同一個目標發出請求，之後恢復原有選項。這會改變測試期間其他請求的路由，操作前請先了解影響。如果使用 Proxy 成功、使用 Config 失敗，接著檢查 Config 中目前啟用的設定，以及該請求實際套用的策略，不要繼續更換密碼。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

以下僅說明比對順序，並非完整設定。DOMAIN-SUFFIX 比對網域後綴，GEOIP 依 IP 地理位置判斷，IP-CIDR 比對位址範圍，FINAL 則套用到前面都未比對到的請求。規則會依序判斷；範例中的 192.0.2.0/24 是文件專用的示例網段，不應據此修改實際使用的路由。使用時還要確認策略名稱在自己的設定中有效。

• 只有一個網域名稱失敗：比對該請求的網域名稱、解析結果與套用的策略，並排除目標網站本身異常。
• 所有經節點發出的請求都失敗：回頭檢查協定參數與交握，不要擴大修改規則的範圍。
• 網頁可用，但特定服務失敗：確認該服務是否依賴 UDP、其他網域名稱或不同連接埠；一般網頁測試無法涵蓋所有傳輸條件。

六、常見問題與故障紀錄整理

回報問題時，提供能判斷失敗階段的資訊，比只寫「不能用」更有幫助。可依照以下順序整理紀錄；節點名稱可自行匿名處理，認證欄位不應公開。

• 環境：裝置類型、系統資訊、Wi-Fi 或行動網路，以及故障開始的當地時間與時區。
• 測試：測試方式、同一節點三次測試結果，以及切換網路後是否有變化。
• 設定：協定類型、連接埠、Global Routing 目前選項，以及是否啟用 On Demand。
• 現象：完整錯誤訊息、失敗步驟，以及是所有請求都失敗，還是只有單一目標失敗。
• 隱私：遮蔽訂閱連結中的 token、密碼、UUID、私鑰與其他認證資訊，不要公開完整設定。

依照上述順序完成檢查後，應能將問題範圍縮小到基本網路、伺服器連通性、協定交握、裝置時間或請求路由其中一個環節。確認故障所在層級後，再修改相應設定；重新測試成功後，請還原暫時變更，避免將診斷用的路由狀態留作日常設定。