Shadowrocket 連線已開啟卻無法上網：伺服器狀態、模式、DNS 與規則逐項排查

一、先區分基礎網路與代理連線問題

先別刪除 App 或重置所有設定。在 Home 關閉連線開關，確認目前的 Wi-Fi 或行動網路能否開啟平常可直接瀏覽的網站。若公共 Wi-Fi 需要登入，請先完成網路認證；關閉連線後一般網頁仍無法開啟，應先處理裝置的網路連線或網路存取問題。

若關閉開關時一切正常，開啟後才出現問題，表示狀況可能與啟用後的流量路徑有關，但不能直接認定是伺服器故障。DNS 設定錯誤、規則中的 REJECT、失效的伺服器參數，以及其他網路延伸功能的衝突，都可能造成類似情況。

1. 記下目前設定

   在 Home 記下目前選取的伺服器與 Global Routing 模式，並在 Config 記下目前生效的設定檔。編輯前先保留設定檔副本，切勿將密碼、訂閱連結或存取權杖公開。

2. 測試直接連線

   關閉連線開關，使用瀏覽器開啟已知可直接瀏覽的網頁。若公共 Wi-Fi 顯示認證頁面，請先完成認證，再返回 Home。

3. 固定測試頁面

   選定一個發生問題的完整網址。之後每次變更設定，都重新載入同一網址，以區分頁面逾時、網域解析失敗和正常收到的 HTTP 錯誤。

4. 比較網路

   在允許使用行動數據的情況下，比較 Wi-Fi 與行動網路。伺服器、模式和設定檔都維持不變；若只有其中一種網路無法使用，優先檢查該網路的限制與解析條件。

二、檢查 Home 中的伺服器與連線測試

在 Home 確認目前選取的伺服器確實來自自己的有效服務資料，再執行 Connectivity Test。測試有回應，只能表示測試所經過的連線路徑收到回應，不代表瀏覽器的 DNS、規則比對及目標網站存取都正常。反之，單次逾時也不足以證明伺服器已失效，應搭配實際請求並改用其他網路測試。

點選目前伺服器的編輯項目，依自己的服務商資料核對類型、位址、連接埠與認證欄位。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的欄位各不相同，不要為了「試試看」就任意更改 Type。若原始資料啟用了 TLS，也要核對相關伺服器名稱與憑證驗證設定，別把關閉驗證當成一般修復方式。

• 位址：確認沒有多複製空格，網域拼寫正確；使用網域的伺服器也需要進行網域解析。
• 連接埠：以現有資料為準。例如資料標示 443，就應確認設定為 443；不要因為其他連接埠較常見，就擅自將自己的連接埠改成 80 或 443。
• 認證：密碼、UUID、金鑰與加密參數必須與伺服器端一致。底層連線建立成功，不代表認證已通過。
• 訂閱：若服務商已更新伺服器資料，請在 Home 更新現有訂閱，再確認選取的項目。更新成功不代表其中每一部伺服器都能使用。

依錯誤原文判斷方向，別只看「逾時」兩字

若連線記錄或診斷結果出現以下英文錯誤，可依相應方向檢查。實際錯誤訊息取決於發生問題的環節，網頁無法開啟時不一定會出現這些文字。

若只有訂閱更新失敗，而現有伺服器仍能正常開啟網頁，應視為訂閱網址存取問題，不要因此清除可用設定。訂閱網址中的權杖屬於敏感資訊，回報時只需描述錯誤訊息與發生環節，切勿提供完整連結。

三、使用 Global Routing 比較不同模式

在 Home → Global Routing 查看目前選取的模式。Config 依生效設定檔中的規則處理請求；Proxy 可用來對照代理模式；Direct 可用來對照直接連線；Scene 則須依自己的情境設定判讀，不能視為與 Config 完全相同的選項。暫時切換只是診斷方式，完成後請恢復原本需要的模式。

四、確認 DNS 與 dns-server 設定

DNS 會將網域解析為 IP 位址。伺服器本身使用網域時，建立代理連線前也可能需要先進行解析。因此，「伺服器位址解析失敗」與「目標網站網域解析失敗」是不同環節，應在記錄中分別註明，不能一概視為伺服器無法使用。

進入 Config，確認目前生效的檔案，再開啟其編輯內容，查看 [General] 下的 dns-server。以下是使用系統解析器進行單項診斷的範例，並非建議所有使用者覆蓋現有設定；若網路本身的系統解析有問題，改成 system 也不會自動修復。

[General]
dns-server = system

1. 先保存原本的 dns-server 設定行及相關 DNS 設定，以便修改後還原。
2. 檢查是否有拼寫錯誤、失效位址或複製後殘留的內容。DNS 伺服器必須能在目前的網路與路由條件下連線，不能只因位址格式正確就認定可用。
3. 若要與系統解析進行比較，只替換這一項並儲存；確認使用的是修改後的設定檔，再重新建立連線並載入網頁。
4. 若結果沒有變化，請還原原值，接著檢查規則與伺服器。若恢復連線，則應配合網路環境確認原解析器無法連線的原因。

五、檢查 REJECT、規則順序與 FINAL

若只有部分網站無法開啟，尤其是 Proxy 正常而 Config 異常時，請檢查 Config 中生效檔案的 [Rule]。規則會依序比對，符合後便採用該規則指定的策略；範圍過廣的規則若排在太前面，後續較精確的規則就沒有比對機會。

DOMAIN-SUFFIX 用於比對網域及其子網域，IP-CIDR 用於比對 IP 網段，GEOIP 則依據 IP 地理資料庫進行比對。這些規則的判斷方式不同；使用 IP 類規則時，也可能涉及網域解析結果。排查時先找出失敗請求的網域與實際符合的規則，不要任意互換規則關鍵字。

[Rule]
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT

這段範例會拒絕 example.com 及其子網域，其他未符合規則的請求則交由 DIRECT 處理。此例僅用來說明故障原因，並非建議設定。若實際網站誤中類似規則，即使連線開關正常、伺服器測試有回應，網頁仍可能無法載入。

• 先檢查 REJECT：確認拒絕規則的比對範圍是否過大。網站可能還需要登入、圖片或 API 網域；若主頁能開啟但登入失敗，應檢查發生問題的具體請求。
• 再檢查目標策略：規則設定為 DIRECT 時會直接連線；設定為 PROXY 時，請確認目前選取的代理可用；若使用自訂策略群組名稱，名稱必須與已定義的策略一致。
• 最後檢查 FINAL：FINAL,DIRECT 與 FINAL,PROXY 的預設處理方向不同。FINAL 應放在規則清單末尾，不能排在仍需比對的規則之前。
• 確認編輯的檔案：修改並儲存的檔案必須是目前生效的設定檔。若設定檔來自遠端更新，請先保留本機副本，避免之後更新覆蓋診斷期間的修改。

修正規則後，使用 Global Routing → Config 重新測試同一網址。若主頁恢復正常但資源仍載入失敗，請繼續找出失敗資源的網域，不要反覆修改 FINAL。依賴多個網域的網站，只允許主網域不一定能涵蓋所有請求。

六、檢查 On Demand 與自動重連情況

若關閉開關後很快又自動連線，或切換網路時測試條件總是改變，請進入 Settings → On Demand，記下目前狀態。診斷期間可暫時關閉已啟用的 On Demand，再返回 Home 手動控制連線，避免自動連線影響比較結果；排查完成後，依原本需求恢復設定。

• 連線自動恢復：先確認是否由 On Demand 觸發，不要直接將自動重新連線視為伺服器反覆斷線。
• 存在其他網路延伸功能：前往裝置的系統設定，檢查其他 VPN 或網路過濾設定。確認可以暫停後，再逐一暫停並重新測試，不要一次刪除多項設定。
• 只有一個 App 無法使用：用瀏覽器開啟相同服務進行比較，再檢查該 App 的網路權限與服務狀態；不要直接把所有請求都改用同一種策略。
• 需要進一步回報：整理發生時間、網路類型、Global Routing 模式、是否只有部分網域異常、錯誤原文及已完成的比較測試。請隱去伺服器密碼、UUID、私鑰與訂閱權杖。

不要把重新安裝 App 當成第一步，因為可能會遺失用於比較的設定與記錄。伺服器資料失效時，請向自己的服務商確認；規則比對錯誤時，應修正规則；基礎網路無法連線時，先處理網路存取問題。將故障定位到具體環節，通常比反覆切換開關更容易驗證。

七、常見問題與還原檢查