本文適合已在 Shadowrocket（小火箭）匯入自己的伺服器或訂閱，但開啟連線開關後仍無法瀏覽網頁的使用者。建議依序確認基本網路、測試所選伺服器、核對 Global Routing、檢查 DNS，最後確認規則與自動連線條件。每次只變更一個項目，並以相同目標重新測試，分清楚「隧道已啟動」和「目標請求已成功」。
一、先確認問題範圍，別把連線開關當成連線成功
Home 的連線開關和系統 VPN 狀態，只表示隧道已啟動，不能證明遠端伺服器連得上、登入資料有效，或每個網站都能正常回應。瀏覽器持續等待、立即顯示找不到伺服器，或只有特定網站無法開啟，代表的問題層面各不相同，不能一概歸因於伺服器故障。
先暫停自動連線的干擾，再比較關閉與開啟連線時的狀況。若關閉後一般網頁也無法瀏覽，請先確認 Wi-Fi、行動數據或目前網路是否需要登入驗證；此時反覆更新規則通常無濟於事。若公共 Wi-Fi 要求登入，請先完成驗證再測試。
-
暫停自動連線
前往 Settings → On Demand，記下原有設定後暫時關閉隨選連線，再返回 Home 關閉連線開關。這樣可避免手動中斷後又自動連線，影響比較結果。
-
確認基本網路
在瀏覽器開啟平常可瀏覽的網頁，確認目前的 Wi-Fi 或行動數據本身可正常使用。不要只用原本就無法直接連線的目標來判斷。
-
確認所選項目
在 Home 確認選取圓點所在的伺服器，並記下名稱和協定。清單中有伺服器，不代表目前實際選取的就是它。
-
執行連線測試
開啟連線後，使用 Home → Connectivity Test，並記下測試方式與結果。測試成功後，再開啟原本無法瀏覽的網頁；測試請求和目標網頁並非同一個請求。
-
固定重測條件
記下網路類型、Global Routing 目前模式、測試目標及錯誤訊息。之後每次只變更一個項目，以相同網址重測，再決定是否保留變更。
二、核對伺服器參數與訂閱狀態
伺服器位址、連接埠、協定和驗證參數必須組成一套有效設定。先在 Home 開啟目前伺服器的編輯畫面，逐項比對服務商提供的原始資料。不要為了嘗試連線，就把所有連接埠都改成 443，也不要將不同協定的欄位互相套用。
- 位址與連接埠：位址欄位不要填入不屬於該欄位的路徑、空格或整段訂閱連結。連接埠必須符合伺服器的監聽設定，不能因為網站使用 HTTPS，就推定代理也監聽 443。
- Shadowsocks：核對加密方式和密碼；即使位址與連接埠正確，仍可能無法建立有效的代理連線。
- VMess / VLESS：核對 UUID、傳輸方式，以及相應的 Host、Path、TLS 參數。傳輸層參數不一致，也可能造成逾時或交握失敗。
- Trojan：核對密碼、TLS 和伺服器名稱。若伺服器名稱用於憑證驗證或交握，不可任意改成與憑證無關的值。
- Hysteria2 / WireGuard：也要確認目前網路是否可連通 UDP。某項 TCP 測試成功，不能證明 UDP 路徑和協定驗證都正常。
如果伺服器項目是由訂閱產生，請先更新該訂閱，再確認伺服器是否遭到刪除、更名或替換。訂閱請向自己的服務商取得。更新失敗只代表這次未能取得訂閱內容，不能直接推斷已匯入的所有伺服器都已失效；更新成功也不代表每台伺服器都通過連線驗證。
買斷用戶端 ≠ 購買線路方案。Shadowrocket 是閉源商業應用，購買用戶端不會自動建立服務商帳戶、增加服務額度或延長訂閱期限。帳戶狀態與伺服器維護情況，請向自己的服務商確認。
三、透過 Global Routing 比較模式與規則問題
在 Home → Global Routing 核對目前模式。Config 依目前啟用的設定進行規則分流；Proxy 可用來比較所有流量都經過代理的情況；Direct 則可比較所有流量都直接連線的情況。如果目前使用 Scene，也要檢查所選場景的設定，不要只憑場景名稱判斷流量的實際去向。以下三種是本次排查的比較條件，並非完整的模式清單。
| 比較設定 | 觀察到的狀況 | 下一步檢查 |
|---|---|---|
| Direct | 原本可直接連線的網頁也無法開啟 | 基本網路、DNS，以及隧道內仍生效的相關設定 |
| Proxy | 多個測試目標都失敗 | 所選伺服器、驗證資料、傳輸參數及網路連通性 |
| Proxy 與 Config | 同一目標在 Proxy 下可連線，在 Config 下失敗 | 規則命中、策略指向、目前啟用的設定及 DNS 差異 |
| Config | 只有少數網域無法連線 | 檢查特定網域及其依賴網域的匹配結果，不要先替換所有設定 |
比較時必須維持相同的伺服器、網路和目標網址。如果切換模式時也更換伺服器，即使網頁恢復正常，也無法判斷是哪項變更發揮作用。切換後請重新發出請求；既有長連線可能仍沿用舊路徑，必要時關閉並重新開啟測試頁面。
四、檢查 DNS：分辨解析失敗與連線失敗
DNS 會將網域名稱解析成位址。解析失敗時，連線可能尚未到達目標伺服器；解析成功後，仍可能在連線、TLS 或應用程式回應階段失敗。如果伺服器使用網域名稱，其位址解析也是連線流程的一環，因此 DNS 故障有時會呈現為代理伺服器無法連線。
此流程用於區分檢查階段，不代表所有請求都遵循固定的內部執行順序：部分網域規則可能先行匹配，位址類規則可能需要解析結果，而遠端解析也會改變解析發生的位置。排查時請查看實際請求記錄，不要只根據流程圖推斷用戶端行為。
- 確認設定來源：在 Config 確認目前啟用的設定，並檢查其中與 DNS 相關的選項；若曾在 Settings 調整相關選項，也請一併記下。不要同時更換設定檔、解析器和伺服器。
- 確認解析器是否可連線：自訂 DNS 位址必須能透過預期路徑連線。即使 DoH 使用 443，也可能因網域解析、TLS 或連線路徑問題而失敗。
- 還原原始設定：如果問題在修改 DNS 後出現，先還原已記錄的原始值再測試，不要接連加入多個未經驗證的解析器。
- 區分 IPv4 與 IPv6：如果網域有 AAAA 記錄，但目前網路的 IPv6 路徑異常，部分目標可能會等待較久或連線失敗。請根據實際連線位址確認，不要把所有逾時都歸因於 IPv6。
不要只在瀏覽器輸入網站 IP，便據此判斷 HTTPS 是否正常。HTTPS 通常仰賴網域對應的憑證和伺服器名稱，直接存取 IP 可能觸發憑證錯誤，或連到其他網站。較可靠的做法是保留原網域，分別查看解析結果、連線位址和交握結果。
五、核對 Config 規則順序與實際策略
如果 Proxy 可以連線、Config 卻不行，應優先檢查 Config 中實際啟用的規則，而不只是查看儲存了哪些檔案。一般規則會依序匹配，最先符合的規則決定策略；前置規則若範圍過大，後續較精確的規則可能就無法生效。FINAL 是最後的兜底規則，請確認它最終指向何處。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上片段用來說明語法，並非可直接取代現有設定的完整檔案。example.com 和 192.0.2.0/24 是文件範例；PROXY 的實際指向仍須在目前使用的設定中核對。不要把片段中的策略名稱視為已驗證可用的伺服器。
- DOMAIN-SUFFIX：依網域後綴匹配。範例涵蓋 example.com 及其子網域，但網頁也可能載入其他網域的圖片、指令碼或登入介面。
- IP-CIDR：依 IP 位址範圍匹配。範例中的 no-resolve 用來避免這條位址規則主動觸發網域解析，不代表關閉整個用戶端的 DNS。
- GEOIP：依 IP 地理位置資料匹配，不是根據網頁語言、網域後綴或網站營運者所在地判斷。
- FINAL：處理先前未命中的流量。若它指向無法使用的策略，未被前面規則涵蓋的請求可能都會失敗。
重現一次失敗請求後，查看可用的請求或日誌記錄，核對網域、命中規則、最終策略及錯誤訊息。首頁可以開啟但登入失敗時，請單獨檢查登入介面的網域；頁面文字已顯示但圖片未載入時，則檢查圖片資源請求。一個網頁可能包含多個連線，單一請求成功不代表整個頁面都正常。
六、根據錯誤原文判斷下一步，不要只憑單一字詞下結論
以下列出網路日誌中常見的錯誤片段，但不代表每次故障都會出現，也不是所有介面都會顯示相同提示。請保留實際出現的完整訊息及其上下文，確認失敗對象是代理伺服器、DNS 解析器還是目標網站，再採取相應的檢查方式。
錯誤：connection refused
原因：該次連線遭到明確拒絕，常見原因是連接埠沒有監聽，或連線遭到主動拒絕。處理方式：核對錯誤訊息中的位址和連接埠，再向自己的服務商確認監聽狀態；不要直接認定是密碼錯誤。
錯誤：i/o timeout
原因：某個操作未能在時限內完成，可能與網路封包遺失、伺服器沒有回應或後續連線停滯有關。處理方式：先確認逾時發生在哪個階段，再使用相同伺服器和目標，比較 Wi-Fi 與行動數據的結果。
錯誤：no such host
原因：相關網域沒有取得可用的解析結果，可能是位址填寫錯誤或 DNS 解析異常。處理方式：核對錯誤訊息中提到的完整網域，確認它屬於伺服器、解析器還是目標網站，再檢查相應的 DNS 路徑。
錯誤：certificate has expired or is not yet valid
原因：憑證有效期限與目前時間不符，可能是遠端憑證已過期，也可能是裝置時間異常。處理方式：確認裝置日期、時間和伺服器名稱；若遠端憑證有問題，應交由負責維護的一方處理，不要把停用憑證驗證當成一般修復方式。
如果沒有明確的錯誤訊息，也可以整理最基本的重現資訊：使用哪種網路、選取哪種協定、Global Routing 目前模式、Connectivity Test 的測試方式、失敗的目標，以及關閉連線後是否恢復。分享記錄前，請移除密碼、UUID、私鑰及訂閱連結中的 token，不要公開完整的設定憑證。
七、重新測試並恢復 On Demand，保留有效結論
恢復連線後，先在目前網路重新測試，再切換至另一種網路驗證。若只有行動數據成功、Wi-Fi 失敗，通常應進一步檢查該 Wi-Fi 的連線條件；若只有某一台伺服器失敗，就繼續檢查該伺服器的參數或狀態。這兩種結果都比「重新開啟一次就好了」更有助於後續排查。
- 將 Global Routing 恢復為日常使用的模式，確認目前啟用的 Config 和所選伺服器都符合預期。
- 分別測試一般網頁、原本無法開啟的目標，以及該目標的登入或資源載入狀況，避免只確認首頁。
- 前往 Settings → On Demand，依原有設定恢復隨選連線；切換網路後，確認是否發生非預期的重新連線或模式變更。
- 記下最後證實有效的變更，以及仍未解決的狀況。需要服務商協助時，請提供已移除敏感資訊的錯誤訊息與重現步驟，不要繼續隨機修改多項設定。
若要確認用戶端來源，Shadowrocket 僅於 Apple 平台發行，以 iPhone / iPad 為主，唯一取得管道是 App Store。開發者為 Shadow Launch Technology Limited，採一次性買斷；系統需求請以 App Store 頁面標示為準。重新取得用戶端無法取代伺服器、DNS 和規則排查，操作前請妥善保留自己的設定。