Shadowrocket 已連線但無法上網：伺服器、模式、DNS 與規則排查

一、先確認故障範圍，暫勿重新安裝

先區分基本網路故障，還是開啟連線後才發生的問題。在 Home 關閉連線，用 Safari 開啟兩個平時可直接瀏覽的網站；再開啟連線，測試相同頁面。測試期間固定使用同一個 Wi-Fi 或行動網路，不要同時更換網路、伺服器和設定，否則無法判斷是哪項變更造成影響。

1. 記錄原始設定

   在 Home 記下所選伺服器與 Global Routing，在 Config 記下目前啟用的設定檔。若要編輯設定檔，請先儲存副本；記錄中不要包含密碼、完整訂閱網址或其他憑證。

2. 關閉連線後比對

   關閉 Home 的連線開關後，再試著開啟網頁。若網路自動重新連線，請檢查 Settings → On Demand，測試期間暫時關閉已啟用的觸發設定，排查完成後再還原。

3. 確認基本網路

   若關閉連線後仍無法瀏覽一般網站，請先檢查 Wi-Fi 登入驗證、行動數據權限與網路訊號。若公共 Wi-Fi 要求完成驗證，請先透過系統或 Safari 完成登入流程。

4. 固定測試目標

   選一個確定可直接瀏覽的頁面，以及一個原本需要透過自有伺服器瀏覽的頁面，分別記錄是否成功及是否逾時。不要只憑單一網站的結果判斷整體網路狀態。

關閉連線後仍無法瀏覽，應先處理基本網路問題。只有開啟連線後才失敗，才繼續檢查本文後續項目；若只有特定網站無法瀏覽，也要考慮網站本身故障、存取限制或規則差異。系統顯示 VPN 標示，同樣不能證明已成功連線至特定遠端網站。

二、檢查伺服器：測試結果不代表全面可用

先確認目前選取的伺服器能否完成實際請求。在 Home → Connectivity Test 執行測試，再確認 SERVER 清單中的選取狀態。測試顯示延遲數值，通常只代表在該測試條件下收到回應，不表示所有網域、連接埠和 App 流量都能正常通過。

• 位址與連接埠：開啟目前伺服器的編輯頁面，逐項核對服務商提供的位址與連接埠。連接埠沒有通用固定值；只有既有參數明確標示 443 時才填入 443，不能把它當成所有協定的預設修復值。
• 驗證參數：依使用的協定核對密碼、UUID 或金鑰。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的參數不能互相套用。
• 傳輸參數：若伺服器要求 TLS、SNI、路徑或特定傳輸方式，必須與既有參數一致。不要藉由關閉憑證驗證來掩蓋主機名稱或憑證問題。
• 服務狀態：向自己的服務商確認現有服務是否有效、伺服器是否正在維護，以及連線數是否受限。重新匯入相同資料，無法解決遠端服務停止的問題。

請依發生階段判讀錯誤訊息。以下是連線記錄中可能出現的底層錯誤片段，實際文字會因協定和失敗階段而異；單憑同一段訊息，無法判定一定是服務商、DNS 或規則出錯。

三、檢查 Global Routing：先切換模式比對

Global Routing 用來決定請求採用哪種分流方式，無法修復失效的伺服器。在 Home → Global Routing 記下目前選項，再短暫切換至 Proxy 和 Config 進行比對。測試結束後還原原選項，避免診斷操作長期改變所有請求的連線路徑。

On Demand 控制連線何時觸發，不會取代 Global Routing 的請求分流功能。若問題是關閉後自動開啟，應先檢查 Settings → On Demand；若連線保持開啟但只有部分網站無法使用，應先核對模式和個別請求，不要反覆切換 On Demand。

四、檢查 DNS：分辨伺服器網域與目標網域

排查 DNS 的第一步，是確認哪個名稱解析失敗。伺服器位址若使用網域，建立連線前就可能需要解析；目標網頁若使用網域，則還要考慮該請求實際採用的解析路徑。前者失敗會導致無法連上伺服器；後者失敗則可能只影響部分網站。

連接埠可連通，不代表解析結果一定正確。加密 DNS 還需要解析服務位址可連線、TLS 驗證正常；使用網域的解析服務也可能需要先進行初始解析。一次加入多個陌生解析位址會增加變數，無法據此確認問題已找出。

1. 在 Config 確認目前啟用的檔案，開啟編輯頁面，檢查 [General] 下既有的 dns-server 設定。先儲存原始值，不要直接覆寫整段設定。
2. 如果問題剛好發生在手動變更 DNS 之後，請先還原先前可用的設定。若要進行比對，可在設定檔副本中使用 dns-server = system，測試系統的解析路徑；這是診斷基準，不是適用於所有網路的最終設定。
3. 儲存並啟用測試設定檔後，重新連線並送出新的網頁請求。瀏覽器可能沿用舊連線或快取，僅重新整理一次不足以證明新設定已生效。
4. 若 [Host] 中有手動網域對應，也要檢查是否指向舊位址。還原 DNS 設定不會自動清除設定檔中另行指定的靜態對應。

五、檢查規則：從第一條比對到 FINAL

使用 Config 模式時，應檢查實際啟用的規則，而不只是確認檔案是否存在。規則通常由上而下依序比對，前面的廣泛規則可能導致後面的精確規則無法生效。先在 Config 確認啟用的檔案，再檢查 [Rule] 中與失敗網域相關的項目及最終策略。

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

這段程式碼只用來說明語法，並非可直接取代日常設定的完整方案。example.com 是示範網域，PROXY 必須對應至可用的代理策略；若自己的檔案使用命名策略，應檢查該策略實際選取的伺服器，而不只是查看 Home 清單。

• DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,PROXY 會比對該網域及其子網域。網站也可能會請求其他網域，因此首頁能開啟，不代表圖片、登入或 API 都會符合同一條規則。
• IP-CIDR：192.168.0.0/16 表示一段 IP 位址範圍。範例中的 no-resolve 用來避免僅因這條 IP 規則而觸發網域解析，不代表整個連線不再使用 DNS。
• GEOIP：GEOIP,CN,DIRECT 會依 IP 地理分類決定策略，不等同於依網域後綴分類，結果也會受到所用資料庫影響。
• FINAL：FINAL,DIRECT 會在前面的規則都未命中時直接連線。若目標需要透過既有代理，卻套用到這條規則，即使開關已開啟也可能無法存取。

修正规則時，每次只改一處，並使用同一個目標重新驗證。若 Proxy 模式仍然失敗，只把 FINAL 改成代理並不能修復伺服器驗證錯誤；若只有 Config 模式失敗，應優先檢查命中的規則及其策略。測試結束後，還原不需保留的臨時規則。

六、常見問題與排查收尾

排查結束時，應保留可重現的現象，而不是提交整份含有憑證的設定檔。記錄網路類型、伺服器協定、Global Routing、失敗目標與錯誤階段，通常比「開關已開啟」更有助於定位問題。若要向自己的服務商回報，請先移除密碼、UUID、私鑰與訂閱權杖。