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

本文重點

本文適用於 Shadowrocket（小火箭）已啟用連線，但瀏覽器或部分 App 無法連線的情況。假設你已有自己的服務商與設定，依序建立直連基準、檢查伺服器、切換 Global Routing 進行比對，再檢查 DNS 與規則命中情況。每次只調整一項，記錄同一網頁的測試結果，最後還原原有設定。

一、先區分 VPN 已啟動與目標網頁是否可連線

Home 的連線開關開啟，表示本機 VPN 連線已啟動；這不代表遠端伺服器已通過驗證，也不代表目標網站可以連線。系統顯示 VPN 標示，同樣無法證明 DNS、伺服器出口與規則策略都正常。不要只憑開關狀態判斷故障位置。

先選一個平常在目前網路可直接開啟的網頁作為對照，再選一個發生問題的網頁。後續都測試這兩個目標。測試時重新載入頁面；必要時關閉原分頁再重新開啟，避免把先前載入的快取頁面誤認為這次連線成功。

4 項

固定順序：伺服器 → 模式 → DNS → 規則

1 項

每輪只調整一個變數，測試後記錄結果

2 個

固定測試目標：直連對照頁與故障頁

記錄目前狀態

在 Home 記下目前選用的伺服器與 Global Routing 模式；在 Config 記下目前選取的設定檔。修改設定前先保留副本，並記錄原有 DNS 設定。
檢查自動連線

前往 Settings → On Demand，記錄目前設定。若測試期間可能因此重新觸發連線，可暫時關閉；排查完成後再還原。
建立直連基準

返回 Home 關閉連線開關，確認連線確實停止，再直接開啟對照網頁。若仍無法連線，先檢查目前 Wi-Fi 是否需要登入，以及行動數據是否可用。
重現問題

重新開啟連線，維持原伺服器、原模式與原設定，再開啟兩個測試目標。記錄是全部無法連線，還是只有特定網域或 App 發生問題。
固定測試條件

先在同一個網路環境完成伺服器與模式檢查。若要切換 Wi-Fi 和行動數據，請另做一輪測試，不要同時更新設定或更換伺服器。

二、檢查伺服器：先確認連線，再核對驗證欄位

前往 Home → SERVER 確認目前選取的項目，再執行 Connectivity Test。延遲測試有回應，只能表示在該測試方式下收到回應。不同測試方式涵蓋的連線路徑不同，單次測試結果無法證明所有網域、傳輸方式或完整服務請求都正常。

若所有伺服器都逾時，先回頭檢查直連基準與目前網路；若只有一台伺服器失敗，再核對該項目的位址、連接埠與協定欄位。位址可能是網域名稱，而網域本身也需要解析，因此伺服器連線逾時不一定代表遠端服務已停止。

位址與連接埠：開啟所選伺服器的編輯頁面，逐項比對自己的服務商提供的資訊。連接埠 443 常用於 HTTPS，但伺服器是否使用此連接埠，仍須以實際設定為準；不要看到 TLS 就把連接埠改成 443。
驗證欄位：分別核對 Shadowsocks 的密碼與加密方式、VMess 和 VLESS 的 UUID，以及 Trojan 的密碼。只有位址與連接埠，並不代表匯入內容完整。
傳輸欄位：使用 TLS、WebSocket 等設定時，核對 TLS 服務名稱、Host 與 Path。這些欄位可能與伺服器位址不同，應依原始設定填寫，不要自行統一。
訂閱內容：只有在服務商明確告知設定已變更時，才更新自己原有的訂閱。更新後重新核對選取項目；更新成功只代表已取得設定，不表示其中每台伺服器都能使用。

日誌原文有助於判斷失敗發生在哪個階段。以下列出常見的網路錯誤片段；不同協定與系統環境可能會在片段前後附上位址或錯誤網域。只有在實際日誌出現相應文字時，才參考對應判斷；不要直接把瀏覽器空白頁歸類為某種錯誤。

錯誤：connection refused

原因與處理方式：目標或中間設備明確拒絕連線，常見原因是連接埠未監聽，或位址、連接埠不符。先核對伺服器位址與連接埠，再向自己的服務商確認該入口狀態；單憑此錯誤無法證明密碼錯誤。

錯誤：connection timed out

原因與處理方式：連線未能在等待時間內完成，可能與網路路徑、連接埠過濾或伺服器未回應有關。先測試同一設定在另一個網路下的狀況，再與已知可用的其他伺服器進行單一變數比對。

錯誤：certificate verify failed

原因與處理方式：TLS 憑證驗證未通過，可能與裝置時間、服務名稱不符或憑證鏈異常有關。檢查系統日期與設定中的 TLS 服務名稱，再請服務商核對憑證；不要把關閉驗證當作一般修復方式。

三、Global Routing：透過模式比對縮小範圍

前往 Home → Global Routing 查看目前模式。排查時，Proxy 與 Direct 可協助區分代理路徑與直連路徑；日常使用 Config 時，也要檢查設定中的具體規則。Scene 則須配合目前選取的場景設定判斷，不能只看名稱推測流量去向。

模式	檢查用途	結果判讀
Proxy	讓一般目標請求依目前代理策略傳送，作為短時間的比對。	若 Proxy 可用而 Config 失敗，優先檢查規則與策略選擇，但仍須核對 DNS 路徑差異。
Direct	讓目標連線直接存取，確認目前網路能否直連。	若 Direct 可用而 Proxy 失敗，優先檢查伺服器與代理連線路徑；不能因此認定所有目標都應直連。
Config	依目前選取設定中的規則分流。	核對 Config 中選取的檔案、規則順序，以及規則指向的策略是否可用。
Scene	依目前場景設定處理路由。	檢查實際選取的場景及其設定；若要排除場景影響，先記錄原設定，再暫時改用明確的對照模式。

判斷方式：Proxy 成功後檢查 Config

同一伺服器、同一網路、同一目標在 Proxy 下成功、在 Config 下失敗時，先回到 Config 檢查實際命中的規則與策略，不要立刻重建所有伺服器；完成比對後還原原模式。

切換模式後，重新發出請求。瀏覽器或 App 可能保留原有連線，只重新整理畫面不一定會建立新連線。若只有某個 App 異常，可先完全結束該 App 再重新開啟，並在瀏覽器中測試同一服務，以區分 App 快取與連線路徑問題。

四、檢查 DNS：有延遲不代表網域已成功解析

DNS 會將網域名稱解析為位址。伺服器可連線、Connectivity Test 有結果，與目標網域成功解析是不同的事。即使取得位址，若回傳的是無法連線的 IPv6 位址、錯誤位址，或不適用於目前網路的結果，網頁仍可能逾時。

前往 Config，開啟目前選取的設定並查看 DNS 相關選項。先記錄解析器位址、是否使用加密 DNS，以及 DNS 查詢依賴的網路路徑。不要只檢查未選取的設定檔，也不要同時修改 DNS 與伺服器，否則無法判斷哪個步驟生效。

檢查位址格式：一般 DNS 通常使用連接埠 53；DoH 通常透過 HTTPS 的 443 連接埠存取。若設定了其他連接埠，請以實際服務要求為準。連接埠正常不代表協定與位址格式也正確。
檢查解析器是否可連線：若解析器只能透過特定代理路徑存取，而代理伺服器的網域又依賴該解析器解析，就可能出現啟動依賴問題。請依設定原始說明核對解析路徑，不要反覆開關連線。
檢查故障範圍：多個無關網域都發生解析錯誤時，優先檢查解析器；只有一個網域失敗時，記錄完整網域名稱與回應狀況，再檢查該網域的規則與目標服務。
確認變更是否生效：儲存設定後重新連線，再重新開啟測試 App。DNS 快取可能影響觀察結果；不要把舊連線仍可存取，當作新設定已通過驗證。

五、檢查規則：確認實際命中項目，不要只搜尋 REJECT

返回 Home，將 Global Routing 還原為 Config，再於 Config 確認目前選取的檔案。規則通常依序檢查，第一條命中的規則會決定該連線採用的策略。檔案中出現 REJECT，不代表所有請求都會遭到拒絕；只有目標實際命中相關規則時，才能用它解釋問題。

以下為語法教學片段，並非完整設定，也不建議直接取代現有規則。範例網域與文件專用的示例位址僅用於說明欄位：第一欄是規則類型，第二欄通常是比對條件，最後一欄是策略；FINAL 沒有比對條件欄位。

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

DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,REJECT 會比對 example.com 及其子網域。若實際服務網域命中同類規則，單獨更換伺服器通常不會改變遭拒絕的結果。
IP-CIDR：依目標 IP 網段進行比對。範例中的 192.0.2.0/24 是文件專用的示例網段；no-resolve 表示不會為了比對這條規則而主動解析網域，不能解讀為「整份設定都關閉 DNS」。
GEOIP：依目標 IP 的地理位置資料比對，不是根據網頁語言或網域後綴判斷。解析結果變動，可能影響後續 IP 類規則的比對。
FINAL：處理前面規則都未命中的連線。範例指向 PROXY；若實際設定使用自訂策略群組，也要檢查該群組目前選取的項目，而不只是規則末尾的名稱。

透過 App 的請求記錄或日誌，核對故障網域、命中規則與最終策略。網頁通常會同時存取主網域、登入網域與靜態資源網域；若主頁能開啟、登入按鈕卻沒有反應，應檢查實際失敗的請求，不要只查網址列中的主網域。

六、常見問題：部分連線失敗、自動連線與還原設定

為什麼延遲測試有數值，網頁還是打不開？

延遲測試與網頁瀏覽使用的目標和完整連線路徑可能不同。先在 Home 確認目前選取的伺服器，再用 Proxy 測試故障網頁；若仍無法連線，檢查伺服器驗證與 DNS。不要把延遲數值當作網頁可正常存取的證明。

只有一個網站打不開，也需要更換伺服器嗎？

先記錄該網站實際失敗的網域，再比對 Proxy 與 Config。若只有 Config 失敗，優先檢查該網域命中的規則；若兩種模式都失敗，再檢查解析結果、目標服務狀態與代理出口路徑。

關閉開關後，為什麼又自動連線？

前往 Settings → On Demand，檢查是否設定了自動觸發條件。排查時先記錄原值，再暫時關閉，然後返回 Home 確認連線已停止；測試結束後還原原有設定，避免把自動重新連線誤判為開關失效。

切換行動數據後恢復正常，代表伺服器沒有問題嗎？

這表示同一設定至少能在另一個網路下使用，故障範圍較可能與原網路路徑有關。切回原 Wi-Fi，檢查網路登入驗證、解析器連線狀況與連接埠限制；維持相同伺服器與模式再次測試，但不能因此保證所有網路都能連線。

七、確認恢復：留下可供複查的結果

成功的標準不是開關再次亮起，而是原本無法連線的目標能在預期模式下完成請求。還原日常使用的 Global Routing、設定檔與 On Demand 設定後，再測一次直連對照頁與故障頁。若還原原設定後問題重現，表示暫時比對只是繞過問題，尚未完成修復。

記錄最終可用的網路類型、選取的伺服器、設定檔與 Global Routing 模式。
重新開啟發生問題的 App，確認頁面載入、登入或資源請求正常，而不只是看到首頁標題。
確認暫時的 DNS 調整、規則例外與自動連線設定都符合日常需求，並保留修改前的設定副本。
若仍需向自己的服務商回報，請提供故障時間、協定類型、錯誤片段與模式比對結果；密碼、UUID、訂閱權杖等敏感欄位請先隱藏。

Shadowrocket 是 Apple 平台的付費用戶端，唯一取得方式為 App Store，開發者為 Shadow Launch Technology Limited。買斷用戶端 ≠ 線路方案。本文以使用者已有的設定為基礎進行排查，不提供、不販售、不推薦節點、訂閱或服務商。系統需求以 App Store 頁面標示為準。