本文速覽

Shadowrocket（小火箭）的連線開關開啟，只代表本機連線狀態，無法證明遠端伺服器、網域解析及目標網站都能正常使用。本文適合已有自己的服務資訊與訂閱，卻遇到網頁無法開啟的使用者：先確認基礎網路，再依序檢查伺服器、模式、DNS 與規則，逐步縮小問題範圍。每次只調整一個項目，最後還原日常設定。

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

先別急著刪除訂閱或重設所有設定。記下 Home 目前選取的伺服器、Global Routing 模式，以及 Config 正在使用的設定檔。同樣是網頁無法開啟，問題可能出在不同環節；保留這些資訊，才能確認後續哪項調整真正有效。

系統顯示連線已建立，通常代表本機 VPN 通道已啟動。遠端伺服器是否接受連線、驗證資訊是否有效、DNS 是否收到回應，仍須分別確認。測試時請使用平常可瀏覽且不需登入的一般網頁，並記下時間與實際錯誤訊息。

  1. 記錄目前設定

    在 Home 記下選取的伺服器與 Global Routing 模式，在 Config 記下目前使用的設定檔。先保存原有設定再進行調整，避免把原本的問題和新變更混在一起。

  2. 關閉連線

    關閉 Home 的連線開關；若連線自動恢復，請檢查 Settings → On Demand，暫時停用觸發條件，再確認連線確實已關閉。

  3. 測試直連

    在 Safari 開啟已知可直連的網頁。若仍無法開啟，先檢查目前 Wi-Fi 是否需要登入認證、行動數據權限及基礎網路，不要先修改規則。

  4. 重新連線測試

    重新開啟連線，以同一個網頁再次測試。測試期間維持相同網路、伺服器與目標，每輪只調整一項設定。

  5. 切換網路比對

    條件允許時，切換 Wi-Fi 與行動網路，再測試相同目標。若只有其中一種網路無法使用，優先檢查該網路的 DNS 解析、連接埠或傳輸限制。

二、確認伺服器位址、連接埠與通訊協定參數

在 Home 確認實際選取的伺服器，不要只看訂閱群組名稱。進入該伺服器的編輯頁面，逐項比對自己已有的服務資訊：Address、Port、Type 及驗證欄位。訂閱更新成功，只代表訂閱內容可取得並解析，不表示其中每台伺服器目前都能正常連線。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 的參數不能互換。伺服器使用哪種通訊協定，就依該協定確認欄位；若涉及 TLS，也要確認伺服器名稱與憑證要求；若涉及傳輸層設定，則檢查路徑、主機名稱等參數。不要隨意更換 Type 來嘗試「修復」。

若連線記錄出現以下原文，可依錯誤發生階段進一步排查。不同通訊協定與錯誤來源可能帶有前綴或其他資訊，請保留完整記錄，不要只憑其中一個詞就下結論。

錯誤：connection refused

原因：目標位址或中間設備拒絕了這次連線，常見原因是連接埠不符或伺服器未監聽。

處理方式：確認 Address 與 Port，並向自己的服務提供者確認該連接埠目前是否正在監聽。

錯誤：i/o timeout

原因：某次網路讀寫未能在指定時間內完成。單憑這項錯誤，無法判斷是網路封包遭丟棄、伺服器沒有回應，或後續交握停滯。

處理方式：記下逾時發生的目標與階段，保持設定不變並切換網路重測，再與同一訂閱中自己已有的另一台伺服器比較。

錯誤：no such host

原因：這次 DNS 解析未取得可用的主機位址，可能是伺服器網域名稱輸入錯誤，也可能是解析連線異常。

處理方式：先確認錯誤訊息中的網域名稱；若是伺服器位址，先排除該位址的 DNS 解析問題，再測試網頁網域。

三、使用 Global Routing 縮小問題範圍

前往 Home → Global Routing，確認目前模式。Direct、Proxy、Config 與 Scene 是不同的流量處理方式，並非連線成功程度的四個等級。測試前先記下原本的模式，暫時切換後，測試完成再還原。

模式主要作用排查用途
Direct採用直連方式處理檢查基礎直連路徑；無法用來確認代理伺服器是否可用。
Proxy採用代理方式處理暫時測試目前的代理連線路徑，減少設定規則分流對結果的影響。
Config依目前設定檔中的規則處理適合檢查規則順序、策略名稱與最後的預設處理方式。
Scene依已設定的情境條件處理檢查目前網路觸發了哪個情境，以及該情境實際採用的設定。

使用同一台伺服器與同一個網址進行比對：若 Proxy 可以開啟、Config 卻無法開啟，優先檢查規則與策略；但也要留意模式切換可能改變請求路徑與 DNS 解析方式。若 Proxy 也無法使用，應先回頭檢查伺服器參數與 DNS，不要只靠反覆新增網域規則碰運氣。

結論：先固定連線路徑，再調整規則

只有在相同目標於固定代理路徑下可正常使用、在 Config 下卻持續失敗時，才優先檢查分流規則。若兩種模式都失敗，先保留規則不變，排查兩者共用的伺服器與 DNS 解析路徑。

四、檢查 DNS：先確認哪個網域解析失敗

DNS 問題至少分成兩個層次：連線到遠端伺服器時，需要解析伺服器的網域；瀏覽網頁時，則需要解析網站網域。前者失敗會導致代理連線根本無法建立；後者失敗可能呈現已連線、網頁卻持續載入。先查看錯誤訊息中的實際網域，比反覆更換 DNS 位址有效。

前往 Settings → DNS，確認 App 端的 DNS 設定；同時檢查目前 Config 檔案是否包含相關設定。記下目前數值與設定來源，避免只修改 Settings，卻忽略正在使用的設定檔仍有其他 DNS 要求。不同設定實際如何生效，應配合請求記錄確認。

53
傳統 DNS 通常使用的 UDP / TCP 連接埠
853
DNS over TLS 的標準預設連接埠
443
DNS over HTTPS 通常使用的 HTTPS 連接埠

五、檢查規則順序、策略與 FINAL

在 Config 確認目前選取的設定檔，再檢查其中的規則。規則通常依序比對，前面的規則命中後，後續規則可能就不會再處理該請求。只在檔案末尾新增網域規則，可能完全無法改變已被前面規則處理的流量。

以下片段僅供辨識語法，不建議直接用來取代目前設定。example.com 是示範網域，192.0.2.0/24 是文件示例網段；實際排查時，請依據發生問題的網域、請求記錄與自己的策略判斷。

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

若設定檔引用了自訂策略群組，還要確認群組內目前選取的項目。規則命中某個群組名稱，不代表該群組最後一定透過代理連線；群組內可能選到直連，或目前無法使用的伺服器。請依請求記錄確認「目標網域 → 命中規則 → 策略群組 → 實際出口」，比只檢查規則內容更可靠。

六、常見問題與排查收尾

為什麼顯示有延遲，網頁還是打不開？

先確認 Connectivity Test 採用的測試方式。一次 TCP 連線或測試位址回應，只能驗證部分連線路徑；請再用實際無法開啟的網站測試，並檢查驗證、DNS 與規則命中狀況。不能把延遲數值當成所有網站都可正常使用的證明。

只有一個網站打不開，需要重新匯入訂閱嗎？

先用同一台伺服器測試其他網頁，再查看該網站失敗請求的網域與策略。若 Proxy 可用、Config 卻失敗，優先檢查該網域的規則與相關資源；重新匯入訂閱通常無法修正設定檔中的網域分流錯誤。

關閉後又自動連線，如何測試直連？

前往 Settings → On Demand，暫時停用相關觸發設定，再回到 Home 關閉連線並觀察狀態。比對測試完成後，請還原原有設定，避免把 On Demand 再次觸發誤認為手動切換沒有生效。

訂閱已更新，為什麼原本的伺服器仍無法使用？

更新只會重新整理清單內容。回到 Home 確認目前實際選取的項目，再檢查位址、連接埠與驗證資訊是否有變更；若清單內容與自己有效的服務資訊不符，請向原有服務提供者確認，不要反覆匯入相同連結，造成重複項目。

恢復正常後，撤銷僅為測試而做的暫時變更：還原日常使用的 Global Routing 模式、確認 Config 選取正確的設定檔，並恢復所需的 On Demand 條件。接著重新測試直連網頁、需要透過代理處理的網頁，以及先前失敗的具體功能，避免只確認首頁，漏掉登入或圖片請求。