Shadowrocket 已連線但無法上網？檢查伺服器、Global Routing、DNS 與規則

本文重點

Shadowrocket（小火箭）的連線開關已開啟，只能表示裝置端的連線流程已啟動，不能據此判定伺服器、網域解析與分流規則都正常。本文適合已有自己的服務商與訂閱、連線後仍無法開啟網頁的使用者，依序檢查伺服器 → Global Routing → DNS → 規則，並以同一個目標重新測試，避免同時更動多項設定而難以找出原因。

先固定測試條件，區分本地網路與代理故障

系統顯示 VPN 狀態，不代表遠端伺服器已完成驗證，更不代表目標網站已可連線。Shadowrocket 可以先在裝置上建立網路通道，再依請求連線至伺服器；因此，即使無法連上伺服器，連線開關仍可能維持開啟。排查時應觀察實際請求，不要反覆切換開關。

先選一個平常可直接開啟的網頁，再選一個目前無法開啟的目標。兩者都用瀏覽器重新送出請求，記下失敗時間、目前使用的網路與所選伺服器。不要只看已開啟的分頁或應用程式首頁，因為快取可能讓舊內容在網路中斷時仍然顯示。以下步驟以 iPhone / iPad 的介面名稱為主，其他平台請核對同名設定。

確認基本網路

在 Home 關閉連線，再開啟平常可直接瀏覽的網頁。若仍無法連線，請先完成 Wi-Fi 登入驗證、檢查行動數據權限，或排除路由器的上網問題；此時修改分流規則無法修復底層網路中斷。
固定測試目標

記下同一個目標網域、目前使用的 Wi-Fi 或行動網路，以及 Home 中選取的伺服器。之後每次只修改一項，再重新連線至該目標；不要拿不同網站的結果互相比較。
暫停自動連線

前往 Settings → On Demand，記下原本狀態後暫時關閉自動連線。這樣手動中斷連線時，系統就不會立即重新連線；測試完成後請還原原設定。
保留原始設定

修改前記下 Global Routing、目前使用的 Config 與自訂 DNS。若需編輯規則，請先保留設定副本，避免將診斷用的暫時設定留作日常使用。

第一項：伺服器是否可連線並完成實際請求

在 Home 核對選取的項目，不要只看訂閱群組名稱。執行 Connectivity Test 後，先確認結果是延遲數值還是逾時，再用瀏覽器測試實際請求。測試所用的方法與目標都會影響結果：測得延遲數值，可能只代表部分連線階段成功，不能據此確認帳號驗證、TLS 交握與目標網站連線都正常。

如果你已有自己的訂閱，更新後請重新確認伺服器位址、連接埠與選取的項目。舊項目仍顯示在清單中，不代表目前仍可使用。手動匯入的項目則應逐一核對協定與憑證；例如 Trojan 的密碼與 TLS 參數、VLESS 的 UUID，以及 Shadowsocks 的加密方式與密碼都不能混用。連接埠請以自己的設定為準，不要因為使用 TLS 就一律改成 443。

所有項目都逾時：先在 Wi-Fi 與行動網路之間交叉測試。若只在某個網路失敗，優先檢查該網路的出口限制、登入驗證狀態或 UDP 是否可用。
只有一個項目失敗：向自己的服務商確認該伺服器位址、連接埠、驗證資訊與服務狀態，不必先重設整個用戶端。
延遲正常但網頁無法開啟：接著檢查實際請求的錯誤。TCP 連線成功後，仍可能發生 TLS 或驗證失敗，也可能是測試目標與網頁目標的可連線狀況不同。
使用 Hysteria2 時失敗：Hysteria2 以 QUIC 為基礎，依賴 UDP 傳輸；一般 TCP 測試成功，不代表相應的 UDP 路徑可用。WireGuard 也需確認 UDP 通訊條件。

錯誤：connection timed out

原因：連線在期限內未收到所需回應，可能與伺服器無法連線、網路封包遺失或網路過濾有關；單憑逾時無法判定是密碼錯誤。

解決方式：先核對伺服器位址與連接埠，再使用同一個項目切換網路重新測試；若只有該項目持續逾時，請向自己的服務商確認伺服器狀態。

錯誤：connection refused

原因：目標連接埠未接受連線，常見原因包括連接埠填錯、服務未監聽，或中間設備主動拒絕連線。

解決方式：依照現有設定核對連接埠與協定；明確遭到拒絕時，不要試圖修改 DNS 解決。

以上是網路記錄中常見的錯誤原文片段，不是每次連線失敗都會出現的固定彈出視窗。記錄錯誤時，請一併保留發生時間與目標；提供診斷資料前，請遮蔽訂閱 token、密碼、UUID 與其他憑證。

第二項：Global Routing 是否符合測試目的

前往 Home → Global Routing 查看目前模式。模式會決定請求採用哪種處理路徑，與連線開關是否開啟是兩回事。先確認模式，再判斷規則是否有問題；若目前是 Direct，即使連線開關已開啟，也不能預期一般請求會經由目前的代理伺服器轉送。

4 項

Global Routing：Config / Proxy / Direct / Scene

傳統 DNS 常用連接埠，UDP 與 TCP 皆可使用

443

HTTPS 常用連接埠；連接埠可連線不代表網頁請求成功

模式	處理方式	排查用途
Config	依照目前設定中的規則選擇策略。	確認日常分流是否正確，並一併核對目前使用的 Config。
Proxy	將一般流量交由目前的代理路徑處理。	暫時與 Config 交叉比較，減少一般分流規則對判斷的干擾。
Direct	使用直接連線路徑。	與代理路徑交叉比較；不能據此證明遠端代理伺服器可用。
Scene	依照設定的場景條件決定實際使用的處理方式。	確認目前網路觸發了哪個場景，不要只憑 Scene 這個名稱判斷流量出口。

先記下原本模式，暫時切換至 Proxy，使用同一台伺服器連線至同一個目標，再切回 Config 重試。若 Proxy 可連線而 Config 不行，優先檢查設定中的規則與策略選擇；若兩者都失敗，就不能只歸因於規則。Proxy 對照也無法完全隔離所有網路設定，DNS、伺服器參數與底層連線仍可能共同影響結果。

結論：先透過模式對照縮小範圍

在相同網路、伺服器與目標下，若 Proxy 成功而 Config 失敗，請保留成功的伺服器參數，改查 Config 的命中規則與策略去向；不要同時更換協定與 DNS。

第三項：DNS 故障發生在哪個解析步驟

網頁請求通常會先將網域解析為 IP 位址，再建立連線。DNS 逾時會讓後續連線沒有可用目標，但代理伺服器的網域本身也可能需要先解析。因此請先釐清無法解析的是代理伺服器網域，還是網站網域；兩者後續的排查方向不同。

前往 Settings → DNS 查看目前設定，同時檢查 Config 是否包含會影響 DNS 的設定。不要只修改某個介面選項，就認定所有請求都改用該解析器；應用程式本身的加密 DNS、既有快取與不同的解析路徑，都可能使實際結果與預期不同。

確認錯誤對象。記下記錄中無法解析的主機名稱。若代理伺服器的主機名稱解析失敗，應先修復這個步驟；切換目標網站無法用來驗證伺服器是否正常。
還原近期變更。如果故障是在手動填入 DNS 後開始，請先記下原值，再還原設定並重新測試。不要一次加入多組來源不明的解析位址，以免增加判斷變數。
檢查解析器是否可連線。傳統 DNS 常用連接埠為 53；使用加密 DNS 時，也要確認能連線至對應伺服器並通過憑證驗證。加密不代表一定可連線。
重新送出請求。儲存設定後中斷再重新連線，並關閉後重新開啟目標網頁。若仍懷疑受到快取影響，請重新啟動相關應用程式再測試；不要把舊頁面顯示的內容當成新的解析結果。
區分 IP 位址類型。如果只在部分網路中失敗，請檢查是否與 IPv6 路徑有關。暫時交叉測試有助於定位問題，但請記錄變更，不要把停用 IPv6 當成通用解法。

錯誤：No such host is known

原因：這是 Windows 可能出現的主機名稱解析錯誤，表示目前解析程序未取得可用結果；不能據此判斷遠端連接埠是否開放。

解決方式：先確認主機名稱拼寫正確，再檢查目前使用的網路與 DNS 設定；若這是你自己的伺服器網域，請向服務商確認網域目前是否有效。

第四項：規則是否命中 REJECT 或 DIRECT

回到 Home → Global Routing → Config，再進入 Config 核對目前實際啟用的設定。一般規則依序檢查，由第一條符合的規則決定後續處理方式；只有前面的規則都未符合時，才會套用 FINAL。更新訂閱伺服器與更新規則設定是兩回事；更新伺服器清單不代表目前的規則也有變更。

以下僅示範規則結構，使用 example.com 與文件專用位址範圍，不能直接套用為實際設定。此處的 PROXY 代表代理策略；實際設定時，請確認相應策略名稱與目標都存在。

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

DOMAIN-SUFFIX：第一行會比對 example.com 及其子網域，並交由 REJECT 處理。後面的 FINAL 不會取代先前已命中的拒絕規則。
IP-CIDR：依目標 IP 網段進行比對。範例中的 no-resolve 表示不會為了比對這條規則而主動解析網域，不代表停用所有 DNS 請求。
GEOIP：依目標 IP 的地理位置資料進行比對，而不是依網站介面語言或網域後綴判斷；歸屬判定也可能受資料庫與實際解析結果影響。
FINAL：處理未符合前面規則的流量。若實際設定為 FINAL,DIRECT，未命中的目標會直接連線，不會自動使用 Home 中選取的伺服器。

若只有特定網站無法連線，請查看該次請求對應的網域、命中規則與最終策略。網頁通常會同時連線至主網域、登入網域、指令碼與圖片網域；首頁能顯示但無法登入，可能只是某個必要網域遭到拒絕。請針對失敗的請求修正規則，不要只為了解決一項資源就刪除整組過濾規則。

DIRECT 不代表錯誤，它只是直接連線。若目標在目前網路無法直連，命中 DIRECT 時才會出現連線失敗。同樣地，即使規則選擇代理策略，也要繼續確認該策略實際使用的伺服器是否可用；不要只看到 PROXY 就停止排查。

結論：修正實際命中的規則層級

若記錄顯示目標命中 REJECT，先檢查對應規則與順序；若經由 DIRECT 連線後逾時，確認該目標是否原本應走代理；若已走代理但連線失敗，請回頭檢查伺服器與 DNS，不要反覆調整無關規則。

常見問題與還原檢查

完成四項排查後，請將診斷用的暫時變更還原為有明確依據的設定。尤其是 Proxy、On Demand 與暫時調整的 DNS，不應因測試成功就忽略原本的使用需求。以下問題可協助確認是否遺漏自動重新連線、規則回退或網路差異。

為什麼關閉連線後又自動開啟？

先檢查 Settings → On Demand 是否已啟用。記下原本狀態後暫時關閉，再手動中斷連線重新測試；同時確認裝置上沒有其他自動連線管理設定。排查完成後依原本需求還原。

延遲很低，為什麼網頁還是一直載入？

延遲測試不能取代完整請求。固定使用該伺服器，檢查網頁請求是否完成解析，以及是否在 TLS 或驗證階段失敗，再比較 Proxy 與 Config。不要只根據延遲數值反覆切換項目。

切換到 Proxy 就正常了，是否要一直使用？

這表示應優先檢查 Config 的分流路徑，不代表所有請求都適合長期走代理。切回 Config，檢查失敗目標命中的規則、FINAL 的去向，以及策略實際選用的伺服器。

Wi-Fi 無法連線、行動網路可以，應先改什麼？

保留伺服器參數，先確認 Wi-Fi 已完成登入驗證，再檢查該網路的 DNS、出口限制與 UDP 條件。相同設定換到其他網路後成功，是定位網路差異的線索，不是必須重新安裝應用程式的理由。

還原所需的 Global Routing 模式，並確認目前的 Config 符合預期。
還原 On Demand 原本的狀態，並確認切換網路後實際採用的處理路徑。
保留變更記錄：故障現象、修改項目，以及修改前後的結果，避免下次重複排查。
若需向自己的服務商回報，僅提供必要的錯誤時間、協定、網路類型與已遮蔽敏感資訊的記錄，不要公開完整訂閱連結或憑證。