Shadowrocket（小火箭）的連線開關開啟，代表系統網路隧道已啟用，不代表伺服器、DNS 和目標網站都已連通。本文適用於已有自己的服務商與訂閱、已完成匯入但無法連線的使用者。依照「基本網路 → 伺服器 → Global Routing → DNS → Rule」的順序，每次只調整一項設定，逐步找出問題環節；排查後請還原原有設定，不要長期保留暫時測試用的設定。
開始前：固定測試條件，確認基本網路
先區分「所有網頁都無法開啟」和「只有一個網域無法連線」。前者應先檢查基本網路與伺服器；後者也可能與目標網站、網域解析或特定規則有關。不要只憑系統 VPN 標示判斷網路正常，也不要把一次延遲測試成功視為所有請求都能正常連線。
-
記錄目前狀態
在 Home 記下目前選取的伺服器與 Global Routing 值，再到 Config 記錄目前啟用的設定檔。保留原設定檔副本，並記下無法連線的網域、發生時間，以及使用 Wi-Fi 或行動網路；分享記錄前，請遮蔽密碼、訂閱網址和身分驗證資訊。
-
暫停自動連線
前往 Settings → On Demand，記錄原有設定後暫時關閉隨選連線，再關閉 Home 的連線開關。這樣可避免測試基本網路時，網路狀態變化又觸發隧道連線。
-
測試基本網路
關閉連線後，開啟平時可直接瀏覽的網頁。若仍無法連線，請先完成 Wi-Fi 登入驗證、檢查行動數據權限或切換網路；此時不應先修改 Rule 或 DNS。
-
固定測試請求
確認基本網路正常後重新連線，每一輪測試都使用相同的完整網址。分別記錄是否出現解析錯誤、連線逾時或憑證錯誤，不要只記下「無法開啟」。切換 Wi-Fi 與行動網路時，請另記為一輪測試。
關閉隧道後可以瀏覽，只能表示當時直接連線的路徑可用，不能證明原伺服器正常。反過來說，某個目標在直接連線時失敗，也不能單獨證明基本網路中斷；請另選一個已知可直接瀏覽的目標作為對照。
第一步：在 Home 檢查伺服器與連線參數
在 Home 確認目前選取的是預期伺服器，再開啟該項目的編輯頁面，逐一核對服務商提供的資料。位址、連接埠、Type 和驗證資訊必須彼此相符。連接埠是 443 不代表參數一定正確，也不能只憑連接埠推斷協定。
- 位址與連接埠：檢查是否有多餘空格、拼字錯誤，以及連接埠是否填錯。若伺服器位址使用網域名稱，建立連線前還需要先解析該網域。
- 協定與驗證：Shadowsocks、VMess、VLESS、Trojan、Hysteria2 和 WireGuard 的參數結構各不相同，請選用對應的 Type，並依照已有資料填寫；不要把一種協定的欄位直接套用到另一種協定。
- TLS 相關欄位：使用 TLS 的連線，請核對服務商提供的 SNI、憑證名稱與傳輸參數。連線位址與憑證名稱可能不同，不要擅自將兩者改成相同值。
- 訂閱狀態：若項目來自訂閱，請先在 Home 更新自己的訂閱，再確認目前選取的項目是否仍有效。更新訂閱與啟用 Config 中的設定檔是兩件不同的事，不能互相取代。
在 Home 執行連線測試或延遲測試時，請一併查看測試方式與結果。TCP 建立連線成功，只能表示測試當下可連上相應位址與連接埠，無法完整驗證驗證資訊、TLS、轉送與目標網站回應。若已有多個伺服器，可在其他設定不變的情況下，改用另一個已有項目作為對照。
錯誤：connection refused
原因與處理方式：目標主機或中間設備明確拒絕連線，可能是連接埠沒有監聽，或連線遭到拒絕。請先核對位址與連接埠，再向自己的服務商確認該入口的狀態；不要先修改 DNS 或規則來處理連接埠遭拒的問題。
錯誤：i/o timeout
原因與處理方式：某項網路操作未能在指定時間內完成，問題可能發生在解析、建立連線或後續讀寫階段。請參照錯誤訊息附近的位址與操作判斷問題位置，再透過另一種網路測試同一項目；逾時本身不能直接證明密碼錯誤。
錯誤：no such host
原因與處理方式：網域解析未取得可用結果。請先確認錯誤指向的是伺服器網域還是目標網站網域，再核對拼字與 DNS 設定；尚未確認是哪個網域前，不要同時修改伺服器和設定檔。
以上是網路記錄中可能出現的錯誤原文，不保證每個介面都會顯示相同文字。檢查時請保留實際錯誤訊息及其上下文；只截取一個「timeout」，容易把伺服器連線失敗和網站回應緩慢混為一談。
第二步：透過 Global Routing 區分 Proxy、Direct、Config、Scene
在 Home → Global Routing 確認目前的模式。即使選對伺服器，請求若未沿著預期路徑傳送，一樣會發生開關已開啟卻無法瀏覽的情況。測試時先固定伺服器，再逐一比較模式，不要同時切換伺服器、DNS 和設定檔。
| 模式 | 排查時如何理解 | 需要核對的項目 |
|---|---|---|
Proxy | 以代理路由作為對照，降低 Rule 分流對測試的影響。 | 選取的伺服器、連線參數與目標回應；這不代表「其他設定全部清除」。 |
Direct | 以直接連線路徑作為對照，請求不會經由代理伺服器轉送。 | 本地網路能否連線至測試目標；這不完全等同於關閉系統隧道。 |
Config | 依照目前設定檔中的規則決定請求策略。 | Config 中啟用的檔案、Rule 順序，以及命中後採取的策略。 |
Scene | 依據已設定的場景條件切換路由行為。 | 符合目前網路的場景設定；排查時暫時使用明確固定的模式。 |
結論：每次只比較一個變數
使用同一部伺服器時，Proxy 可以開啟網頁、Config 卻不行，下一步應優先檢查目前設定的規則與策略；若兩者都失敗，則繼續核對伺服器與 DNS。這是縮小問題範圍的方法，不是對故障原因的最終判定。
Direct 可以連線、Proxy 卻失敗，也不能只憑這組結果就判定伺服器故障：代理路徑上的解析、驗證、TLS 或目標網站限制，都可能影響結果。測試完成後請還原原先的 Global Routing；使用 Scene 的使用者也要還原場景條件，以免下次切換網路時出現不同結果。
第三步：透過 DNS 區分伺服器解析與網站解析
DNS 問題可能發生在兩個地方：解析伺服器網域時，或連線時解析目標網站網域。前者失敗會導致代理連線本身無法建立；後者失敗則可能出現伺服器測試有回應、網頁卻無法開啟的情況。請先看清錯誤訊息中的網域，再決定要修改哪項設定。
- 在 Config 開啟目前啟用檔案的編輯畫面，檢查
[General]中的dns-server，並記錄原值。不要編輯尚未啟用的同名副本。 - 若原設定檔使用自訂 DNS，請核對位址、格式與目前網路的可達性。使用 DNS over HTTPS 時，還需要檢查 HTTPS 端點是否可以連線，以及端點網域的解析和憑證是否正常。
- 可在設定檔副本中暫時改用系統 DNS 作為對照，儲存並啟用該副本，再重新建立連線。只修改 DNS，伺服器與 Global Routing 維持不變。
- 再次開啟相同網域。若結果改善，繼續檢查原本的 DNS 路徑；若結果沒有改變，請還原原值，再檢查規則，不要持續疊加未經驗證的修改。
[General]
dns-server = system[General] 是設定檔的通用設定區段；dns-server = system 表示該項設定使用系統 DNS。這是供對照測試的片段，不是完整設定檔，也不應用來覆蓋既有設定檔的其他區段。使用系統 DNS 後，結果仍取決於目前網路提供的解析服務。
DNS over HTTPS 透過 HTTPS 傳送解析請求，但不保證在所有網路環境下都能連線。解析端點、伺服器位址與目標網站是不同對象；只改用另一種 DNS 傳輸方式，無法修復伺服器連接埠遭拒或驗證參數錯誤。
第四步：在 Config 核對 Rule 順序與實際策略
回到 Config，確認測試時啟用的檔案。Global Routing 設為 Config 時，規則通常依序比對；請求一旦符合前面的規則，就不會繼續等待後續同類規則覆蓋。先檢查目標網域對應的規則，再檢查 IP 規則與最終策略；「設定檔中寫了 PROXY」不代表該請求一定符合這條規則。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY[Rule]：規則區段的起始標記。此片段僅用來說明語法，example.com是示例網域，不是連線測試位址，也不代表適合所有使用者的分流方案。DOMAIN-SUFFIX,example.com,PROXY：比對example.com及其子網域，並套用PROXY策略。比對的是請求的網域後綴，不是網頁路徑中的某個詞。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：比對該 IPv4 網段並使用DIRECT。no-resolve表示不為符合此規則的請求主動發起網域解析；它不會全域關閉 DNS。GEOIP,CN,DIRECT：依據 IP 地理資料庫中的國家代碼進行比對，並採用直接連線。判斷依據是 IP 資料，而非網頁語言、網域後綴或服務商名稱；資料庫結果也可能與實際部署位置不同。FINAL,PROXY：前面的規則都未符合時，使用PROXY。最終策略無法覆蓋已符合的DIRECT或REJECT規則。
若目標在 Proxy 下正常、在 Config 下無法連線，請檢查是否符合排在前面的 DIRECT 或 REJECT 規則，以及自訂策略群組是否選取有效成員。需要暫時驗證時，可在副本中加入針對單一目標的 DOMAIN 或 DOMAIN-SUFFIX 規則，並將它放在可能衝突的規則之前；不要只為了一個網域就刪除整個 Rule 區段。
結論：確認規則確實命中，不只檢查規則是否存在
儲存並啟用修改後的設定檔，重新送出相同請求，再透過 App 內的連線記錄或日誌核對目標與策略。只有「目前檔案已啟用、請求符合預期規則、對應策略可用」三項條件同時成立，才算完成這一輪規則驗證。
收尾：依測試結果定位問題，還原原有設定
四步排查的目的不是逐一修改所有設定，而是取得可重現的對照結果。記錄在哪一輪成功或失敗，下次重測時維持相同條件；若只有某個網站無法連線，也要檢查該網站本身是否正常，不要將單一網站故障等同於所有代理連線都故障。
| 對照結果 | 下一步檢查 |
|---|---|
| 關閉連線後，已知可直接瀏覽的網頁仍無法開啟 | 先處理 Wi-Fi 驗證、行動網路權限與基本網路。 |
| 同一項目使用 Wi-Fi 失敗、使用行動網路成功 | 檢查 Wi-Fi 網路上的 DNS、連接埠與傳輸可達性，並保留兩輪的錯誤記錄。 |
| Proxy 成功、Config 失敗 | 檢查啟用的檔案、規則順序、命中策略與策略群組成員。 |
| 只修改 dns-server 後，結果有所改變 | 重新測試原 DNS 的可達性與解析結果，確認並非短暫的網路波動。 |
| 所有模式下都只有同一個目標無法連線 | 核對目標服務狀態、解析結果與憑證錯誤，不要再盲目更換全域設定。 |
- 還原原本的 Global Routing、DNS 和 Settings → On Demand 設定；刪除僅供驗證的暫時規則，或保留已清楚標示的設定檔副本。
- 向自己的服務商回報時，提供協定類型、伺服器位址與連接埠、網路類型、故障時間，以及已遮蔽敏感資訊的錯誤訊息；不要傳送完整密碼或訂閱憑證。
- 更新訂閱後，重新檢查目前選取的項目；修改設定檔後，重新確認 Config 中啟用的檔案，避免實際使用的項目與記錄不一致。
Shadowrocket 是 Apple 平台的付費用戶端，主要供 iPhone、iPad 使用，唯一取得管道為 App Store。系統需求、裝置相容性與是否支援通用購買，請以 App Store 頁面標示為準。購買用戶端與線路服務是兩回事；本站不提供、不銷售，也不推薦節點或訂閱。