Shadowrocket（小火箭）的連線開關開啟，代表本機連線功能已啟動，但不表示遠端伺服器、DNS 和目標網站都正常運作。本文適用於已有自己的服務商與設定，但連線後仍無法存取網頁的使用者：先固定測試條件，再依序檢查伺服器、Global Routing、DNS 和規則。每次只調整一個變數，以同一個目標重測並保留結果。
排查前：區分本機連線與遠端可用性
狀態列顯示 VPN，不能單憑這點判定代理伺服器已完成驗證，也無法證明網頁請求經由預期的出口。瀏覽網頁還涉及網域解析、路由選擇、遠端連線及網站回應；任一環節出錯，都可能讓瀏覽器一直等待。因此，第一次逾時後不要同時更新訂閱、更換 DNS 和重寫 Config，否則很難判斷是哪項變更發揮作用。
先選一個平時能正常開啟的一般 HTTPS 網頁作為對照，再選一個目前無法開啟的網頁。測試時記錄完整網域、目前使用 Wi-Fi 或行動網路、選取的伺服器，以及 Global Routing 模式。本文不提供連線服務；以下操作均以使用者已有的伺服器或訂閱為前提。
- 關閉連線後仍無法上網：先檢查裝置的基本網路。需要登入驗證的 Wi-Fi，請先完成網路登入，再測試代理連線。
- 關閉連線時正常，開啟後全部失敗：優先檢查伺服器是否可連線、驗證參數及目前的路由模式。
- 只有少數網域無法連線：記下具體網域，後續優先核對 DNS 結果與該請求命中的規則。
- 關閉開關後又自動開啟：檢查
Settings → On Demand。排查期間可暫時關閉 On Demand，完成後再恢復原設定，避免自動連線影響測試對照。
第一步：檢查伺服器連線狀態與連線參數
在 Home 確認實際選取的伺服器，再使用 Home 中的 Connectivity Test 測試連線。測試結果只能反映測試目標及測試方式下的連線狀況：顯示延遲不代表所有網站都能存取，出現逾時也不一定表示帳號失效。應搭配實際網頁請求結果一起判斷，尤其不要把單純的延遲結果當成驗證、TLS 和服務存取都成功的證明。
-
確認選取項目
開啟 Home，確認目前選取的伺服器名稱；進入該項目的編輯頁面，檢查位址、連接埠、協定及驗證資訊是否與服務商提供的內容一致。名稱相似的項目可能對應不同位址，請勿只憑顯示名稱判斷。
-
執行測試
在 Home 使用 Connectivity Test，記錄所選伺服器的測試結果，再開啟固定的測試網頁。分別記錄「測試有回應但網頁無法開啟」和「測試與網頁都失敗」，後續處理方向不同。
-
切換網路
保持伺服器及設定不變，只在 Wi-Fi 與行動網路之間切換後重複測試。如果只有其中一種網路失敗，優先檢查該網路的登入驗證、出口限制及 UDP 連線狀況，不要直接修改所有協定參數。
-
核對原始設定
若服務商已通知位址或憑證變更，請更新原有訂閱，再重新選取伺服器。確認更新是否成功；訂閱更新失敗與現有伺服器連線失敗是兩個不同問題，不要以反覆刪除設定代替核對。
不同協定所需欄位不盡相同。Shadowsocks 的加密方式與密碼必須相符；VMess、VLESS 的身分欄位與傳輸設定須符合伺服器端設定；Trojan 的密碼及 TLS 設定也必須相符。使用 Hysteria2、WireGuard 時，還要留意目前網路是否支援 UDP。不要因為某個連線失敗就任意更換協定名稱，伺服器必須支援相應設定。
錯誤：connection refused
原因：目標端或中間設備明確拒絕連線，常見情況包括連接埠沒有服務監聽，或存取遭到拒絕。
處理方式：核對伺服器位址、連接埠及傳輸類型；若與原始設定一致，請向自己的服務商確認該入口是否仍在運作，不要盲目更換本機 DNS。
錯誤：i/o timeout
原因：某個網路讀寫階段超過等待時間，可能涉及本機網路、遠端連線狀態或協定交握，單憑這則訊息無法確定問題所在環節。
處理方式：保留錯誤訊息前後的脈絡，使用同一台伺服器切換網路重測，再依實際失敗階段排查；不要直接把逾時解讀為密碼錯誤。
錯誤：no such host
原因：目前的解析程序未取得相應主機的位址；請先確認錯誤中的主機是伺服器網域，還是正在瀏覽的網站網域。
處理方式：檢查網域拼寫及 DNS 是否可用。若伺服器網域解析失敗，應先恢復基本解析，不能仰賴尚未連通的代理完成所有前置作業。
以上是常見網路錯誤訊息的原文片段，實際畫面可能包含位址、連接埠或更完整的系統提示。排查時請以完整錯誤脈絡為準。若遇到憑證驗證錯誤，請檢查裝置日期、伺服器網域與 TLS 設定，不要把停用憑證驗證當成一般解決方式。
第二步：使用 Global Routing 區分代理與規則問題
進入 Home → Global Routing，先記錄目前模式。Proxy、Direct、Config、Scene 不是連線品質等級，而是不同的路由選擇方式。Proxy 用於測試代理路徑，Direct 用於測試直連路徑，Config 依目前設定的規則處理，Scene 則依已設定的情境運作。排查時不要只停留在 Scene 模式下猜測結果，應確認目前生效的情境與設定，或暫時切換至可直接比較的模式。
| 測試模式 | 觀察結果 | 下一步 |
|---|---|---|
| Proxy | 同一網頁仍無法開啟 | 繼續檢查伺服器、DNS 或網站本身，先不要急著重寫規則。 |
| Direct | 一般網頁正常，Proxy 模式下失敗 | 優先檢查代理路徑；直連成功不代表伺服器可用。 |
| Config | Proxy 正常，Config 模式下失敗 | 檢查生效中的設定、規則順序及請求最後採用的策略。 |
| Scene | 切換網路後結果不同 | 核對 Scene 實際選用的路由設定，先固定模式再重測。 |
結論：Proxy 成功後再檢查 Config
如果在同一網路、使用同一伺服器瀏覽同一網頁，Proxy 模式下成功、Config 模式下失敗，請保留伺服器設定不變，改查目前使用的設定與請求記錄；這樣可避免把規則問題誤判為伺服器故障。
每次切換模式後都重新發出網頁請求；必要時先中斷再重新連線，以減少重用舊連線的影響。測試完成後，請恢復日常使用的模式。Proxy 只是對照工具，不是所有「網頁無法開啟」問題的最終設定。
第三步：區分 DNS 解析失敗與後續連線失敗
DNS 負責將網域轉換為位址。若解析未完成，後續連線通常無法開始；但取得位址，只能證明解析階段有結果，不代表該位址能連線或憑證有效。進入 Settings 的 DNS 設定，先記下目前設定，再確認使用的是系統 DNS、自訂 DNS 還是 DNS over HTTPS，並依現有設定逐項核對。
這些連接埠是協定常見的預設值，不代表必須把自己的伺服器連接埠改成 53 或 443。使用自訂 DNS 時，裝置必須能連到指定的解析伺服器；DNS over HTTPS 也需要能連上相應的 HTTPS 服務。若 DNS 服務本身使用網域，可能還需要先解析該網域；不要假設改用加密 DNS 就能自動解決所有前置連線問題。
- 所有網域都無法解析：先確認 DNS 位址輸入正確，並還原修改前可用的設定作為對照；同時確認裝置的基本網路正常。
- 只有一個網域失敗：檢查網域是否拼錯、是否只有某個子網域失敗，並保留具體查詢結果，不要立刻更換整套 DNS。
- 取得位址後仍連線逾時：接著檢查該位址對應的路由與遠端連線；這已不只是「有沒有解析結果」的問題。
- 修改後看起來沒有變化：儲存設定、重新建立連線並重新發出請求；既有連線或 App 快取可能仍在使用舊結果。
第四步：核對 Config 與實際命中的規則
確認伺服器與 DNS 大致正常後，再進入 Config 檢查目前實際生效的設定。編輯某個檔案，不代表連線正在使用該檔案；請先確認選取的設定，再檢查 [Rule] 中的規則順序。規則通常由上而下比對，命中後採用相應策略；FINAL 應放在具體規則之後。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT這段最簡範例會將 example.com 及其子網域交由 PROXY 處理，其他請求則交由 DIRECT 處理。這只用來說明比對邏輯，並非適用於所有使用者的完整設定，也不會建立可用的伺服器。若目標網頁還會請求其他網域，那些請求不一定符合第一條規則；主頁能開啟，但圖片、登入或 API 失敗時，應檢查實際失敗的請求，而不只是網址列中的主網域。
- DOMAIN-SUFFIX：比對網域本身及其子網域，不是比對任意包含該字串的內容。先確認實際請求的網域是否符合指定的後綴。
- IP-CIDR：依位址網段比對，例如
IP-CIDR,192.168.0.0/16,DIRECT；這是位址條件，不是網域後綴條件。 - GEOIP：依位址在地理資料庫中的歸屬進行比對，例如
GEOIP,CN,DIRECT。結果會受解析位址與資料庫影響，不能據此推斷網站內容的語言或營運所在地。 - FINAL：處理前面規則都未命中的請求。若將
FINAL,DIRECT提前，後面的具體代理規則就沒有機會被檢查。
在 Data 中搭配可用的請求或連線記錄，核對時間、目標網域、目標位址及最後採用的策略；具體欄位以目前介面顯示為準。若介面沒有直接顯示命中的規則，可用同一個請求在 Proxy 與 Config 模式下的結果作為輔助判斷。檢查時也要留意排在目標規則前面的規則，以及策略組是否仍指向預期的伺服器。
如果命中 DIRECT，但預期應走代理，請先調整目標規則及其順序；如果已命中 PROXY 卻仍然失敗，就回頭檢查伺服器與目標連線階段，不要繼續疊加相同規則。每次修改一條規則後先儲存，確認正在使用該 Config，再重新連線測試。不要在沒有保留記錄的情況下批次替換設定。
常見問題：部分網頁、訂閱與自動重新連線
測試有延遲，為什麼瀏覽器還是一直轉圈？
Connectivity Test 的結果不代表整條網頁存取路徑都正常。保持使用同一台伺服器，先在 Global Routing 選擇 Proxy，重新開啟原本的網頁，再檢查 DNS 與連線錯誤；若只有一個網站失敗，也應檢查該網站及其相關網域，不要只憑延遲數值判定一切正常。
Wi-Fi 無法使用，切換到行動網路就正常？
先保持其他設定不變，確認這種差異能否重現。檢查 Wi-Fi 是否需要登入、是否限制目標連接埠或 UDP；同時確認 Scene 與 Settings → On Demand 是否因網路變化而改變連線行為。不要把只在某一種網路出現的故障直接歸因於訂閱失效。
訂閱更新失敗，需要先刪除所有項目嗎？
不必先刪除。保留現有設定，確認服務商提供的訂閱網址仍有效，再於 Home 更新相應訂閱。訂閱網址是否可連線與現有伺服器是否可用，應分開測試；回報問題時請遮蔽連結中的 token，避免外洩存取憑證。
關閉開關後又自動連線，如何進行對照測試？
進入 Settings → On Demand，記下原有設定後暫時關閉自動連線，再測試連線關閉時的基本網路。排查完成後恢復原設定。若開關行為仍不如預期，再檢查裝置中是否有其他自動連線管理設定，不要反覆重新安裝 App。
若仍無法找出原因，請整理一份精簡的排查記錄：發生時間、網路類型、所選伺服器的去識別化名稱、Global Routing 模式、Proxy 與 Config 的對照結果、失敗網域、DNS 是否取得位址，以及完整錯誤脈絡。向自己的服務商確認伺服器狀態時，這些資訊比「開關已開啟」更能說明問題所在。
排查完成後，恢復 On Demand、日常使用的路由模式及需要保留的設定，並移除暫時新增的測試規則。最後應綜合實際網頁存取、預期策略及連續數次新請求的結果確認問題已解決，不要只看一次延遲測試或狀態列標示。