連線開關已開啟，只代表本機連線功能已啟動，不表示遠端伺服器、網域解析和網頁請求都正常。本文假設您已有自己的服務商與訂閱，依序檢查基礎網路、伺服器、Global Routing、DNS 和規則；步驟以 iPhone / iPad 的 Home、Config、Settings 為例，Mac、Windows、Android、Linux 可依相同順序檢查相應設定，實際介面位置以各平台為準。
1. 先建立對照：確認基礎網路是否正常
Shadowrocket（小火箭）顯示已連線，但瀏覽器一直轉圈時，先別同時更換伺服器、DNS 和設定檔。每次只變更一項，並記錄同一網頁修改前後的結果，才能判斷問題出在目前網路，還是代理連線與分流設定。
測試時，先開啟平常可直接瀏覽的 HTTPS 網頁，再試一個原本需要透過既有伺服器瀏覽的網頁。別把單一網站維護、帳號狀態或存取限制當成整體連線故障；也別只因快取頁面仍顯示，就認定網路正常。
-
暫停自動連線
前往 Settings → On Demand，記下目前條件後暫時關閉自動觸發，再回到 Home 關閉連線開關。這樣可避免手動中斷後，因網路切換條件而重新連線。
-
檢查基礎網路
使用瀏覽器重新載入可直接瀏覽的網頁。若關閉連線後仍無法瀏覽，先檢查 Wi-Fi 登入驗證、行動數據權限或目前網路本身，不必立刻修改 Config。
-
切換網路重新測試
條件允許時，讓同一台裝置分別連上 Wi-Fi 與 Cellular，並瀏覽同一網址。若只有其中一種網路失敗，表示問題可能與網路條件有關，但仍須進一步判斷是伺服器連接埠、DNS 還是驗證限制。
-
記錄初始狀態
記下 Home 目前選取的伺服器、Global Routing 模式，以及 Config 目前啟用的檔案。重新開啟連線後再進行下一項檢查，測試期間不要一次更新整份設定。
2. 檢查伺服器：延遲測試結果不等於網頁可用
在 Home 確認目前選取的伺服器屬於您自己的有效訂閱。清單中有伺服器記錄，只能表示設定已匯入；若訂閱內容已變更、帳號已到期或遠端位址失效，本機仍可能顯示舊記錄。先更新自己的訂閱，再確認選取項目是否仍有效。
確認伺服器位址、連接埠、通訊協定與驗證欄位，是否符合您自己的服務商提供的資訊。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的欄位各不相同；不要把某種通訊協定的密碼、UUID 或金鑰直接套用到另一種通訊協定。使用 TLS 的連線也要確認伺服器要求的名稱與裝置時間，不要以關閉憑證驗證取代問題排查。
伺服器測試出現延遲數值，不代表目標網頁的完整要求已成功。測試可能只涵蓋特定探測方式與測試位址；實際瀏覽還涉及網域解析、交握、驗證和目標網站回應。反過來說，探測逾時也不能單憑這點認定帳號已失效，還需要參照實際要求記錄判斷。
錯誤：Connection timed out
原因：連線未能在期限內完成，可能與網路封包遺失、連接埠無法連線或遠端沒有回應有關。
解法：核對記錄中的目標位址與連接埠，切換網路重新測試，再以自己另一個有效伺服器作為對照；不要只憑這項錯誤就修改驗證欄位。
錯誤：Connection refused
原因：目標連接埠明確拒絕連線，可能是連接埠填錯、服務未在該連接埠監聽，或中間設備拒絕連線。
解法：依照自己的服務資訊檢查連接埠；若設定一致仍出現此錯誤，請向自己的服務商確認該連接埠的服務狀態。
以上是網路診斷中可能出現的英文錯誤訊息，不同平台與記錄來源的大小寫、前後綴可能不同。判斷時須一併查看目標位址：連不上代理伺服器與連不上目標網站，故障位置並不相同。
3. 確認 Global Routing：以 Proxy 與 Config 進行單一變數測試
在 Home → Global Routing 查看目前模式。Direct 表示要求直接連線，並非「自動選擇可用伺服器」；Config 才會依目前設定檔的規則決定策略。Scene 則依已設定的場景條件運作，不能假設它一定等同於 Config。
| 模式 | 排查時的作用 | 下一步 |
|---|---|---|
| Proxy | 讓一般網頁要求使用目前選取的代理，減少一般分流規則對結果的影響。 | 確認 Home 目前選取的項目；它可能是策略群組，而非固定伺服器。 |
| Direct | 以直接連線作為對照，不經代理伺服器存取。 | 若目標原本就無法直接存取，在此模式下失敗不代表伺服器故障。 |
| Config | 依目前 Config 的規則比對結果與策略執行。 | 查看失敗要求實際符合的規則及最終策略。 |
| Scene | 依已設定的場景條件選擇相應行為。 | 檢查目前網路適用的場景，排查途中不要新增條件。 |
暫時切換至 Proxy，保持伺服器、網路與測試位址不變，再重新送出網頁要求。若 Proxy 可瀏覽、Config 卻不行，優先檢查規則與策略群組；若兩者都失敗，應繼續檢查伺服器與 DNS，而非直接認定 FINAL 設定錯誤。測試完成後恢復原本模式，避免把暫時的診斷設定當成最終設定。
結論：先找出模式差異
只有在相同網路、相同伺服器與相同位址下，Proxy 成功而 Config 失敗，才有充分理由將下一步排查重點放在規則比對與策略選擇。
4. 檢查 DNS：先分辨解析失敗與連線失敗
網域解析失敗時，要求尚未取得可用來連線的目標位址；伺服器連線失敗則可能發生在解析成功之後。兩種情況都可能讓瀏覽器顯示「無法開啟網頁」，因此要查看具體要求記錄，而不是只看瀏覽器提示或連線開關。
前往 Config，查看目前啟用檔案的 [General] 中與 DNS 相關的參數，並核對 Settings 中既有的 DNS 設定及其覆寫關係。先記錄原值，不要同時更換設定檔與解析位址。自訂 DNS 本身也必須可連線；使用加密 DNS 時，還要考慮其連線路徑與初始解析。
- 只有網域相關要求失敗：查看是否出現解析錯誤，並確認目前的解析服務能否在此網路中連線。直接存取 IP 只能作為輔助判斷，不能取代 HTTPS 網域測試。
- 已有解析結果，但連線仍逾時：繼續檢查目標 IP、符合的策略及伺服器連線，不要反覆更換 DNS。
- 只有 Wi-Fi 出錯：先確認已完成網路驗證，再與 Cellular 的結果比較；網路中的解析限制可能看起來和伺服器故障相似。
- 修改後結果沒有變化：關閉舊的網頁連線，重新連線後再載入同一位址，避免把快取結果或沿用的連線誤認為新設定的效果。
錯誤：Could not resolve host
原因：送出要求的元件無法取得網域對應的位址，錯誤可能出現在本機解析，也可能出現在遠端解析環節。
解法：先確認網域拼字與 DNS 是否可連線，再依要求的路徑判斷是哪一端解析失敗；若錯誤來自測試工具，請以該工具使用的連線路徑為準。
5. 檢查規則：確認要求是否真的套用 FINAL
切換至 Global Routing → Config，開啟目前啟用的設定檔並檢查 [Rule]。規則通常依由上而下的順序比對；要求一旦符合前面的有效規則，就不會再繼續比對 FINAL。FINAL 是前面規則都未符合時使用的預設策略，不是所有流量固定經過的步驟。
以下僅示範規則結構，並非完整設定檔。example.com 與 192.0.2.0/24 是文件範例位址；不要用這段內容覆蓋自己的整份 Config。策略名稱也必須對應實際設定中可用的策略。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：比對指定網域及其子網域。若失敗網頁的網域符合前面的 DIRECT 規則，修改 FINAL 不會影響該要求。
- IP-CIDR：比對目標 IP 網段。範例中的
no-resolve表示不會為了比對此規則而主動觸發網域解析，並非關閉整個應用程式的 DNS。 - GEOIP：依目標 IP 的地理資料比對，不依網頁語言或網域後綴判斷；網域解析結果變更可能影響後續比對。
- FINAL：為未符合前面規則的要求提供最終策略。若指向策略群組，還要確認群組中目前選取的伺服器是否有效。
重現一次失敗要求後，在連線記錄中核對目標網域、符合的規則與最終策略。一個網頁可能會要求多個網域的資源：主文件成功，但指令碼或圖片失敗時，頁面可能顯示空白或載入不完整。此時應分別檢查失敗資源的網域，不要直接把首頁網域整段改用另一種策略。
若記錄顯示符合 FINAL，但最終策略指向失效伺服器，應修正伺服器或策略群組選擇；若符合範圍過廣的前置 DIRECT 規則，應先備份，再縮小該規則的範圍。每次只修改一項並重新測試，避免刪除整段規則後失去排查線索。
6. 常見問題與排查後的設定還原
為什麼延遲測試有數值，網頁卻一直轉圈？
延遲測試未涵蓋所有網頁要求環節。先維持使用同一台伺服器，在 Home → Global Routing 暫時選擇 Proxy，重新瀏覽同一位址，再檢查要求是否完成解析與遠端連線。不要只憑延遲數值反覆切換伺服器。
切換至 Proxy 就正常了，需要一直這樣使用嗎？
這表示應優先檢查 Config 中的規則與策略，但不代表必須長期使用 Proxy。前往 Config 查看失敗要求符合的規則，修正後恢復 Global Routing → Config，再重新測試同一網頁及其資源。
訂閱更新成功，為什麼還是連不上？
更新成功只表示訂閱內容已取得並處理，不保證每台伺服器當下都可使用。返回 Home 核對目前選取項目，檢查位址、連接埠與服務有效期限，再依照自己的服務資訊確認驗證欄位。
剛關閉連線，它又自動開啟了，該怎麼辦？
先前往 Settings → On Demand 檢查自動觸發條件，暫時關閉後再手動測試。排查完成後恢復所需條件，並在 Wi-Fi 與 Cellular 切換時確認行為符合預期。
排查完成後，還原暫時修改的 Global Routing、DNS 與 On Demand。保留能穩定重現問題的最少記錄：裝置平台、網路類型、失敗時間、目標網域、錯誤訊息、符合的規則與最終策略。向自己的服務商回報時，不要公開完整訂閱連結、驗證密碼或金鑰。
- 基礎網路連線失敗：先處理網路登入、路由器或裝置的網路存取權限。
- Proxy 與 Config 都失敗：優先確認伺服器參數、遠端連線狀態與解析環節。
- 只有 Config 失敗：檢查前置規則、FINAL 與策略群組目前的選擇。
- 只有部分資源失敗：逐一查看資源網域的要求結果，保留有效規則，只修改已確認的項目。
需要重新安裝或查看平台安裝說明時，請使用本站的全平台下載頁。Shadowrocket 是閉源商業應用程式，取得用戶端與線路服務是兩回事：用戶端買斷 ≠ 線路方案；匯入與測試仍以您已有自己的訂閱為前提。iPhone / iPad 的系統需求以 App Store 頁面標示為準；Mac 提供 Apple 晶片與 Intel 兩種版本。