本文重點

Shadowrocket（小火箭）的連線開關表示裝置上的隧道已啟動，不代表目標網站已可連線。本文適用於已匯入自有服務設定的使用者，依序比對伺服器、Global Routing、DNS 與規則，區分本機網路、遠端連線、網域解析及分流問題；每次只變更一項，測試後還原原設定。

開始前：固定測試條件，確認本機網路可用

先記下 Home 中選取的伺服器、Global Routing 狀態，以及 Config 中目前使用的設定檔。排查期間請使用同一部裝置、同一個網路和同一個目標網域，避免同時切換 Wi-Fi、伺服器與設定檔，否則無法判斷是哪項變更影響結果。本文假設使用者已有自己的服務商與訂閱；本站不提供、不銷售，也不推薦節點或訂閱。

關閉 Shadowrocket 連線開關後，先造訪平時可直接開啟的網站。若仍無法連線，優先檢查 Wi-Fi 是否需要登入網頁、行動數據是否可用，以及裝置是否位於受限網路。此時修改代理規則無助於排查；先恢復基本網路連線，再開啟連線開關測試。

  1. 記錄原始狀態

    在 Home 記下選取的伺服器與 Global Routing 狀態，在 Config 記下目前設定檔名稱。編輯前先保留設定檔副本；原始檔案與訂閱中的憑證只儲存在自己的裝置上。

  2. 檢查自動連線

    開啟 Settings → On Demand，記下原設定。若關閉開關後連線又自動建立，可在測試期間暫時關閉 On Demand，避免自動連線影響比對結果。

  3. 建立網路基準

    關閉連線開關，測試一個已知可直接連線的網站。若網路需要驗證，請先完成網路提供的登入流程；不要把尚未完成驗證誤判為伺服器故障。

  4. 固定複測目標

    選定一個可正常直接連線的網域，以及一個無法正常連線的網域，分別記錄開關關閉與開啟後的結果。之後每次變更一項設定，都重新造訪這兩個目標。

第一項：檢查 Home 中選取的伺服器是否能處理請求

返回 Home，確認選取的是準備測試的伺服器，而非名稱相近的舊項目。進入該項目的編輯畫面，核對伺服器位址、連接埠、協定與驗證資訊。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的欄位各不相同；請逐項比對服務商提供的參數，不要只修改 Type，卻保留其他欄位不變。

在 Home 執行 Connectivity Test 時，請區分「測試顯示延遲數值」與「瀏覽請求成功」。不同測試方式檢查的環節不同；TCP 建立連線成功，只能表示相應連接埠可連線，不能單獨證明驗證、TLS 交握、UDP 通道或目標網站存取正常。請繼續使用瀏覽器發出實際請求，才能驗證後續連線。

  • 位址與連接埠：核對伺服器網域或 IP、服務連接埠是否與原始資料一致。連接埠 443 只是常見的 HTTPS 連接埠，不代表所有服務都使用它，也不表示填入後就能連線。
  • 驗證與傳輸：只有在相應協定使用時，才核對密碼、UUID、TLS Server Name 等欄位；不要為了消除錯誤而任意關閉憑證驗證，應先確認伺服器名稱、裝置時間與伺服器端憑證。
  • 既有訂閱：若設定來自自己的訂閱，請在 Home 更新對應訂閱，再重新選取更新後的項目。更新成功只代表清單已取得，不代表其中每部伺服器都能連線至目標網站。
  • 網路差異：同一項目在行動數據下正常、在 Wi-Fi 下失敗時，優先檢查該 Wi-Fi 是否限制連接埠或 UDP。切換網路僅用於比對，請勿同時更換協定與 DNS。

以下是網路記錄中可能出現的一般錯誤字串，並非所有協定都會顯示相同文字。請搭配完整上下文判斷發生錯誤的對象：錯誤位址究竟是伺服器、DNS 解析器，還是目標網站。

錯誤：connection refused

原因：相應連線收到拒絕回應，常見原因是目標連接埠沒有服務監聽，或遭到主動拒絕。

處理方式：先核對記錄中的位址與連接埠；若對象是自己的伺服器，請向自己的服務商確認服務狀態與正確連接埠。

錯誤：i/o timeout

原因：某個讀寫階段未能在時限內完成，可能與網路封包遺失、連接埠無法連線或遠端未回應有關。

處理方式：保持項目參數不變，改用另一個可用網路重新測試，再依錯誤發生階段檢查伺服器連線或 DNS 請求。

錯誤：no such host

原因：相關主機名稱未取得可用的解析結果；發生問題的名稱可能是伺服器網域，也可能是目標網站網域。

處理方式：先確認網域拼寫正確且有效，再進行 DNS 排查；若伺服器網域本身無法解析，單純切換代理策略無法解決問題。

第二項：透過 Global Routing 區分代理連線與設定問題

在 Home → Global Routing 查看目前選項。Proxy 會將可代理的請求交由代理路徑處理；Direct 使用直連路徑；Config 依目前設定檔處理；Scene 則依場景設定決定實際行為。Scene 不等同固定的 Proxy 或 Config，排查時須確認目前場景採用的設定。

在相同伺服器與網路下，先暫時選擇 Proxy，再重試有問題的網域；接著切回 Config 再測試。若 Proxy 可連線而 Config 無法連線，問題較可能出在規則、策略指向或設定檔中的其他處理方式，而非伺服器完全無法使用。測試結束後請還原原模式，避免將暫時比對設定當成長期修復方式。

模式排查用途結果判讀
Proxy測試選取的代理路徑可連線表示此請求在目前條件下可透過代理完成，不代表所有網域都能使用。
Direct建立直連對照僅測試已知可直接連線的網站；若目標在目前直連環境下不支援，測試失敗不足以定位問題。
Config驗證目前設定若結果與 Proxy 不同，請繼續檢查規則命中、策略目標與 DNS 等設定差異。
Scene檢查場景選擇先確認目前場景的實際設定，再與固定模式比對，避免場景變更帶入其他變因。

結論：確認 Proxy 正常後再檢查規則

同一目標在 Proxy 下正常、在 Config 下失敗時，保留可用伺服器，改為核對目前設定檔與命中策略；不要同時重建伺服器項目，否則會失去已建立的有效比對基準。

第三項：區分伺服器網域解析與網站網域解析

DNS 至少可能涉及兩個位置：先將伺服器網域解析為位址，再為存取目標取得位址。前者失敗會中斷伺服器連線；後者失敗則可能出現連線已建立、網頁卻無法載入的情況。檢查記錄時，先找出發生解析錯誤的完整網域；不要只看到 DNS 字樣就替換所有解析設定。

在 Config 開啟目前使用的設定檔，檢查 [General] 中的 dns-server，並查看是否有影響目標網域的 [Host] 對應項目。設定檔若保留舊的內網 DNS、無法連線的解析器，或將網域對應至過期位址，都可能影響結果。若有多處 DNS 設定，應一併確認目前生效的設定，避免修改未使用的檔案。

2 個位置
分別檢查伺服器網域與目標網域的解析
53
傳統 DNS 常用 UDP 或 TCP 連接埠
443
DoH 通常使用 HTTPS 連接埠，並非所有 DNS 都使用該連接埠
  1. 先核對錯誤網域的拼寫是否正確，確認問題並非來自已失效的伺服器網域或錯誤的網頁位址。
  2. 保留設定檔副本後，可暫時使用 dns-server = system 比對系統解析結果；這不是通用建議值，系統 DNS 也可能受目前網路影響。
  3. 檢查 [Host] 中是否為問題網域設定了舊位址。只移除已確認有問題的對應項目，不要整段刪除其他用途的記錄。
  4. 儲存並確認已選取該設定檔，重新建立連線後再次請求同一網域，記錄與修改前的差異。

第四項：檢查 Config 中的規則順序與實際策略

若 Proxy 可用而 Config 失敗，請在 Config 確認已選取的檔案，再檢查其中的 [Rule]。規則通常由上而下比對，命中後便採用相應策略；前方較寬泛的規則可能會優先涵蓋後方的精確規則。修改其他未啟用的檔案，不會影響目前連線使用的規則。

DOMAIN-SUFFIX 比對指定網域及其子網域；IP-CIDR 比對 IP 網段；GEOIP 依據 IP 地理資料庫分類；FINAL 處理先前未命中的請求。網域規則與 IP 規則的比對對象不同；涉及 IP 分類時，也須考量是否已取得位址，因此規則順序並非完全不受 DNS 影響。

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

此段設定僅用於說明語法：example.com 是示例網域，192.0.2.0/24 是文件範例網段。請勿用它們判斷實際服務是否可連線，也不要整段覆蓋自己的正式設定。no-resolve 表示該 IP 規則不會主動觸發解析；它不是關閉全域 DNS 的開關。

  • 命中 DIRECT：請求採用直連路徑；若目標在目前網路下無法直接連線，請檢查是否被過於寬泛的網域或位址規則提前比對。
  • 命中 REJECT：請求遭規則拒絕。請找出具體規則及其用途，確認誤擋後再精確調整，而非一併刪除所有拒絕規則。
  • 命中 PROXY：繼續核對目前使用的代理目標；若規則指向自訂策略群組，也要確認該群組實際選取的成員，不能只看 Home 中的選取標示。
  • 落到 FINAL：表示先前的規則都未命中。檢查末尾策略是否符合預期，並將確實需要的精確規則放在可能涵蓋它的寬泛規則之前。

重新測試時，在 Shadowrocket 的請求記錄或日誌中搜尋同一個目標網域，核對命中規則與最終策略。單一網頁也可能載入圖片、指令碼和登入介面；若主網域正常但頁面空白，應檢查失敗的資源網域，而非反覆為主網域新增重複規則。

常見問題：依照現象決定下一步

有延遲數值，為什麼瀏覽器仍無法開啟網頁？

先確認 Connectivity Test 使用的測試方式，再以實際網頁請求驗證。若只有連接埠可連線、驗證卻失敗，仍可能出現此情況；請在 Home 核對協定與驗證參數，並查看失敗發生於連線、交握或請求階段。

只有 Wi-Fi 無法使用、行動數據正常，應先檢查什麼？

保持伺服器與 Global Routing 不變，先檢查 Wi-Fi 的基本網路連線與驗證頁面，再比對 DNS 與連接埠是否可連線。若服務依賴 UDP，也要確認該網路是否限制 UDP；不要只因網路不同就判定帳號失效。

只有一個網站無法開啟，需要重設所有設定嗎？

先比對 Proxy 與 Config，再檢查該網域的解析結果及命中策略。其他網站正常，表示連線至少部分可用；若兩種模式都只有同一個目標失敗，也要考量目標網站的回應與存取限制。

修改設定後沒有變化，應該檢查哪裡？

在 Config 確認已選取修改後的檔案，返回 Home 確認 Global Routing 設為 Config，再重新建立連線測試。若正在使用 Scene，先檢查場景的實際設定；測試結束後，還原 Settings → On Demand 的原設定。

若仍無法定位問題，請整理故障發生時間、網路類型、協定名稱、Global Routing 狀態、失敗網域及已去識別化的錯誤片段，交由自己的服務商確認。不要公開完整訂閱連結、密碼、UUID、私鑰或包含存取權杖的截圖；這些資訊應與定位問題所需的現象紀錄分開保存。