Shadowrocket（小火箭）的連線開關代表本機通道狀態，不代表遠端伺服器、網域解析與目標網站都已連通。本文以使用者已有自己的伺服器與訂閱為前提，依序從本機網路、伺服器參數、Global Routing、DNS 與規則找出故障原因；每次只變更一個設定，並以相同目標重新測試，避免將偶然恢復誤判為問題已解決。
1. 區分通道連線與網頁連通
iPhone 或 iPad 顯示 VPN 標示，表示系統已建立相應的本機網路通道。網頁載入還需經過解析、策略選擇、遠端連線與目標回應等步驟，其中任何一個環節失敗，都可能造成連線開關已開啟、頁面卻持續載入。反覆切換開關，無法判斷故障所在。
先記下是所有 App、所有網頁，還是特定網域無法使用；同時記錄當時使用 Wi-Fi 或行動網路。瀏覽器能開啟某個頁面，只能證明該次請求成功，不能代表其他協定或目標也能連線。以下測試請使用固定的自選頁面，不必連續造訪大量不同網站。
-
保留目前狀態
在 Home 記下目前選取的伺服器、Global Routing 設定值與故障時間。在 Config 記下目前啟用的設定檔名稱，修改前先保留副本，不要直接覆寫原設定檔。
-
測試本機網路
前往 Settings → On Demand，記下原本的狀態，暫時關閉自動連線，再關閉 Home 的連線開關。開啟原本不需代理即可瀏覽的頁面；若仍無法使用，先處理 Wi-Fi 登入、訊號或本機網路問題。
-
切換網路連線
分別使用 Wi-Fi 與行動網路測試同一個頁面，再重新連線 Shadowrocket。若只有一種網路無法使用，先維持伺服器與設定不變，優先檢查該網路的解析、存取限制與連線狀況。
-
重新送出請求
每次變更設定後，請重新連線並開啟新頁面送出請求。既有的長連線與頁面快取可能沿用舊結果，不能只看舊分頁的畫面判斷新設定是否生效。
2. 檢查伺服器參數與實際對外連線
在 Home 查看目前選取的伺服器，開啟該項目的編輯畫面，對照自己的服務原始參數，確認位址、連接埠、Type 與驗證資訊。伺服器清單中有項目，不代表該項目仍有效；延遲測試有結果，也不保證載入目標網頁所需的完整連線一定成功。
| 檢查項目 | 檢查內容 | 判斷限制 |
|---|---|---|
| 位址與連接埠 | 逐項比對自己的服務參數，確認位址是否過期、連接埠是否填錯。 | 遠端服務可能使用 443，但不能因為網頁無法開啟，就把任何伺服器的連接埠改成 443。 |
| Type 與驗證資訊 | 依照實際服務，核對 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 所需欄位。 | 不同協定的密碼、識別碼與金鑰欄位不能互換。 |
| TLS 與傳輸方式 | 服務使用 TLS 時，確認服務名稱與憑證要求；使用額外傳輸方式時，核對路徑等參數。 | 不要以關閉憑證驗證來取代修正服務名稱、憑證或裝置時間問題。 |
| 訂閱狀態 | 在 Home 更新自己的 Subscribe 項目，再確認目前選取的是更新後仍有效的伺服器。 | 更新成功只代表已取得項目，不保證每個遠端伺服器都能連線。 |
若有多個有效伺服器，可在不變更 Global Routing 與 DNS 的情況下，只切換伺服器進行比較。若只有一個項目失敗，優先檢查該項目的參數與遠端狀態；若全部項目都失敗，再一併檢查本機網路與共用的解析設定。本文不提供、販售或推薦伺服器或訂閱。
3. 利用 Global Routing 縮小問題範圍
前往 Home → Global Routing 確認目前的模式。Proxy、Direct、Config 與 Scene 的作用各不相同，排除問題時應先確認流量實際採用哪種策略。Proxy 可作為短暫的比較測試，但不能解決所有網路問題。
| 模式 | 檢查重點 | 比較用途 |
|---|---|---|
| Proxy | 請求依全域代理模式處理，並確認使用的伺服器或策略選擇。 | 若相同目標在 Proxy 下可用、Config 下失敗，請優先檢查規則與策略引用。 |
| Direct | 請求依直連模式處理，目標必須能透過目前的本機網路直接連線。 | 可用來區分代理路徑與直連路徑，但不等同於關閉系統通道。 |
| Config | 使用 Config 中目前啟用設定檔的分流規則。 | 檢查命中的規則、策略組與 FINAL，不要只確認 Home 中選取的項目。 |
| Scene | 檢查自行設定的場景條件與對應動作。 | 若模式會隨網路環境變更，先排除場景切換的影響，再比較結果。 |
比較測試時，請固定使用相同伺服器與目標網域，先在原模式下重現問題，再短暫切換至 Proxy，重新連線後測試，最後恢復原模式。Proxy 下仍失敗，不能直接排除 DNS 問題；Config 失敗而 Proxy 成功，也不能只憑這點判定 FINAL 設定錯誤，還要確認命中的策略是否指向另一台無法使用的伺服器。
- 只有 Config 失敗：檢查目前啟用的設定檔、目標命中的規則，以及策略組中實際選取的項目。
- 只有特定場景失敗：記錄目前的網路環境，檢查 Scene 的條件與結果，避免切換網路後沿用先前的判斷。
- Proxy 與 Config 都失敗：繼續檢查共用的伺服器參數、解析路徑與本機網路。
4. 檢查 DNS：解析成功不代表連線成功
若伺服器位址使用網域名稱，也需要先進行解析；目標網站的網域解析則是另一項請求。因此，「伺服器延遲測試有結果」與「網頁網域解析成功」並非同一件事。檢查 DNS 時，先分辨無法解析的是伺服器網域還是目標網域，再檢查相應的解析路徑。
- 前往 Config，開啟目前啟用的設定檔並檢查 DNS 項目；同時檢查 Settings → DNS 相關設定，確認沒有把另一份未啟用設定檔中的值，誤認為目前使用的設定。
- 確認解析器位址、使用方式與連線狀況。加密解析也需要網路連線；填入 HTTPS 解析位址，不代表目前的路由一定能連上該服務。
- 若先前修改過 DNS，先記下原值，再暫時還原為自己已確認可用的設定，並對相同目標送出新請求。不要同時更換伺服器、解析器與規則。
- 若記錄顯示已取得目標 IP，但後續連線逾時，請繼續檢查對外連線路徑與目標服務；若明確停在解析階段，則檢查解析器連線與網域本身。
不要只用「在瀏覽器直接輸入目標 IP」作為驗證方式。HTTPS 服務通常依賴網域、TLS 服務名稱與虛擬主機設定，直接存取 IP 可能造成憑證錯誤，或連到不同內容。IPv4 與 IPv6 的連線狀況也可能不同，應根據記錄中的位址類型找出問題，而不是長期停用某一種位址族來掩蓋網路問題。
5. 依規則順序檢查 FINAL 與策略引用
Global Routing 設為 Config 時，請開啟 Config 中實際啟用的設定檔並檢查規則順序。一般分流規則會依序比對，前面的規則一旦命中，後面的規則可能就不會生效。FINAL 是最後的兜底規則，不能取代前面的所有規則，也無法修復伺服器驗證失敗。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上僅用於說明語法，並非建議直接替換的完整設定。example.com 是示例網域；PROXY 必須對應目前設定中有效的代理策略或策略組。若此名稱在設定中指向其他項目，應依實際定義檢查，不要只憑英文名稱猜測最終的對外連線。
DOMAIN-SUFFIX：檢查目標主機名稱是否符合此網域後綴。一個頁面可能會請求多個資源網域，主文件載入成功，不代表圖片、介面與登入請求也採用相同路徑。IP-CIDR：依 IP 網段比對。範例中的no-resolve表示該規則不會主動進行網域解析比對，應配合請求中已有的位址資訊判讀結果。GEOIP：依 IP 地理位置資料庫比對，不能僅憑網頁顯示的文字、網域後綴或使用者所在地判斷比對結果。FINAL：處理此前未命中的請求。若它指向無法使用的策略組，未命中前置規則的頁面可能會接連失敗。
修改前先複製設定檔，接著只調整與故障目標相關的一項規則或策略，再重新啟用並連線測試。若調整後恢復，仍須確認請求記錄確實命中預期規則；不要因網頁偶然開啟，就全面替換規則或永久切換成 Proxy。
6. 根據錯誤記錄重新測試並還原設定
在 App 內的連線記錄或日誌中，找到與問題重現時間及目標網域相符的請求，查看解析結果、策略與錯誤資訊。以下是網路日誌中可能出現的錯誤片段；實際訊息可能包含位址或其他內容。這些資訊可協助判斷故障階段，但不能直接對應為某項設定出錯。
錯誤：connection refused
原因與處理方式：常見原因是目標連接埠拒絕連線，也可能是中間設備主動拒絕。先確認記錄指向代理伺服器還是目標網站，再核對相應位址、連接埠與服務監聽狀態。
錯誤：i/o timeout
原因與處理方式：某項網路操作未能在期限內完成，不能只據此判定密碼錯誤。請根據同一筆記錄中的連線階段，分別檢查網路、伺服器或解析器，並重新測試。
錯誤：no such host
原因與處理方式：網域解析未取得有效結果，可能與網域拼寫、記錄狀態或解析路徑有關。先找出解析失敗的網域，再檢查位址與 DNS 設定，不要直接變更無關規則。
若沒有明確錯誤訊息，可將「網路、伺服器、Global Routing、目標網域、發生時間、現象」整理成一筆記錄。例如「Wi-Fi 下 Config 載入逾時，伺服器維持不變，切換至 Proxy 後相同頁面可開啟」，會比「顯示已連線但無法使用」更有助於繼續排查。這只是記錄範例，並非本文的實測結果。
- 還原測試期間暫時變更的 Global Routing、DNS 與設定，只保留經比較確認為必要的修改。
- 確認手動連線穩定後，再依原本需求恢復 Settings → On Demand，並驗證切換網路後的運作情況。
- 分別測試一個原本可直接連線的頁面與先前無法開啟的頁面，確認頁面中的介面與資源也能正常載入。
- 若要聯絡自己的服務提供者，請提供協定、連接埠、時間與已隱去敏感資訊的錯誤記錄；遮蔽完整訂閱網址、密碼、金鑰與帳戶識別資訊。