Shadowrocket 延遲正常但網頁無法開啟：DNS 解析失敗的排查順序

一、延遲正常不代表網頁連線正常

先確認延遲數值來自哪種測試。連線至伺服器連接埠的測試，與連線至特定網頁的測試，涵蓋的網路路徑並不相同。若伺服器位址本身是 IP，測試甚至不必解析伺服器網域；瀏覽器瀏覽網站時，仍須先取得目標網域的位址，再建立連線。因此，Home 顯示延遲數值，不能單憑這點排除 DNS 故障。

網頁一直轉圈也不一定是 DNS 解析失敗。即使解析成功，後續連線遭到阻擋、目標伺服器沒有回應或 TLS 交握失敗，都可能造成網頁無法開啟。排查時先記下錯誤訊息與發生階段，再決定是否調整 DNS，避免把所有連線問題都歸咎於同一項設定。

連接埠號碼有助於理解傳輸方式的差異，不代表目前網路一定允許這些連線，也不表示應將伺服器連接埠改成這些數值。代理伺服器連接埠與 DNS 服務連接埠是兩種不同參數；前者必須與你已有的服務端配置一致。

二、先建立可重複的排查基準

不要一開始就同時更換伺服器、DNS 和規則。先固定一個有問題的網址，記錄目前的網路、所選伺服器、Global Routing 與啟用中的配置。比對時請使用完整網域，不要把 HTTPS 網址中的網域換成 IP 來「測試 DNS」：這會改變憑證驗證、SNI 與網站虛擬主機的選擇，測試結果無法直接比較。

1. 記錄目前狀態

   在 Home 記下所選伺服器與連線狀態，接著開啟 Home → Global Routing，記下目前選項；在 Config 確認正在使用的配置，並在修改前保留可還原的副本。

2. 檢查基本網路

   暫時中斷連線，前往目前網路原本就能瀏覽的網站。若公共 Wi-Fi 需要網頁認證，請先完成認證。若中斷連線後仍無法開啟該網站，請優先檢查 Wi-Fi 或行動網路本身。

3. 固定測試模式

   重新連線後，前往 Home → Global Routing，暫時選擇 Proxy，並維持使用同一台伺服器，再測試目標網域。這一步是為了與 Config 進行比對，不是建議採用的最終設定。

4. 切換網路重新測試

   維持伺服器與配置不變，在 Wi-Fi 與行動網路之間進行比對測試。若只有其中一種網路失敗，請記錄該網路下的 DNS 請求與連線錯誤，不要立刻覆寫配置。

5. 還原原有設定

   完成比對後，還原原本的 Global Routing。若中斷連線後又自動連線，請檢查 Settings → On Demand 中啟用的條件；暫時停用相關條件後，再進行中斷連線測試。

三、檢查實際生效的 DNS 設定

進入 Config，確認目前啟用的是哪份配置，再檢查其中的 DNS 設定。修改未啟用的檔案不會影響目前連線；遠端配置更新也可能覆蓋本機修改。因此，請先保留副本，修改後重新連線，再以相同網域進行測試。只更新 Home 中的伺服器訂閱，不能據此認定 Config 中的 DNS 設定也已同步變更。

以下僅為配置語法範例，不是通用的修復方式。這表示使用系統 DNS 作為解析來源，可用於控制變因的比對測試；但若目前網路的系統 DNS 本身異常，此設定也可能失敗。只調整現有配置中的對應欄位，不要為了測試而刪除其他規則、策略或服務端參數。

[General]
dns-server = system

使用 DoH 時，也要檢查「先解析服務位址」這項依賴：若 DoH 端點使用網域名稱，建立 HTTPS 連線前必須先取得端點位址。端點本身無法連線、憑證驗證失敗，或端點網域無法解析，都可能使目標網站的查詢停滯。加密傳輸改變的是查詢的傳輸方式，不會自動確保端點可連線，也無法取代對目前網路的檢查。

四、分別檢查規則命中與解析結果

Global Routing 中的 Direct、Proxy、Config、Scene 並非四種 DNS 協定。Direct 與 Proxy 代表不同的流量處理模式；Config 依所使用的配置處理流量；Scene 則須檢查所選場景的具體設定。排查期間不要同時變更場景與 DNS，否則同一網址前後可能會經過不同路徑。

使用 Config 時，也應檢查規則順序。網域規則與 IP 規則的判斷對象不同；IP 規則可能需要先解析目標網域。若記錄中已出現 IP 位址，但請求套用到不合適的策略，繼續更換 DNS 未必能解決問題。以下保留網域與文件專用位址僅供說明語法，並非可連線的服務。

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

• DOMAIN-SUFFIX 用來檢查網域後綴。若前面較廣泛的規則已命中，後續規則就不會再套用於這次請求。
• IP-CIDR 用來檢查 IP 位址範圍；範例中的 no-resolve 表示不為這條規則主動觸發網域解析，並非關閉整個 App 的 DNS。
• GEOIP 依 IP 地理資訊比對，不能只憑網域語言或網站名稱推斷是否命中。
• FINAL 是前面規則都未命中時套用的最終策略。請確認它實際指向哪個策略，而不只是確認檔案中有這個關鍵字。

也要分辨 A 與 AAAA 記錄：前者回傳 IPv4 位址，後者回傳 IPv6 位址。若解析成功，但使用特定位址家族時連線失敗，這是位址可達性方面的線索。請保留 DNS 回應與後續連線結果，再進一步處理；不要把「出現 AAAA 記錄」本身當成故障，也不要同時變更 IPv6、DNS 與規則三項設定。

五、依照錯誤原文判斷下一步

以下是 Apple 網路錯誤網域中的錯誤代碼，可在錯誤詳細資訊或診斷資訊出現相同內容時，作為判斷線索；這不代表 Shadowrocket 每次都會顯示這些文字。瀏覽器也可能只顯示中文提示。請記錄實際看到的完整訊息，不要只憑「無法開啟」就判斷原因。

若只有某個網站無法使用，而其他網域都能穩定連線，請個別記錄該網域及其相關資源網域。網頁主文件、圖片與指令碼可能來自不同網域；若主頁已顯示但圖片持續載入中，不代表主網域尚未解析成功。比起全面更換 DNS，依據失敗資源的網域檢查規則，更容易找出問題所在。

• 記錄網路類型、Global Routing、啟用中的配置，以及發生錯誤的目標網域。
• 分辨「未取得解析結果」與「已取得 IP 但連線逾時」，並保留相關錯誤訊息。
• 提交診斷資訊前，請遮蔽訂閱 token、密碼、UUID 與個人網路位址；只提供定位問題所需的內容。

六、常見問題與修復確認

修復確認時應回到原本的使用模式，而非停留在暫時使用 Proxy 測試的狀態。還原所需的 Global Routing 與 On Demand 條件後重新連線，再瀏覽最初無法開啟的網站及一個對照網站。確認頁面主體與必要資源都能載入，且不必依賴暫時切換網路才能恢復。

1. 保留最後採用的 DNS 來源與配置副本，並還原沒有證據支持的暫時修改。
2. 在平常使用的網路下重新測試；若涉及 Wi-Fi 與行動網路切換，請分別記錄結果。
3. 若故障仍可重現，請提供已去識別化的錯誤原文、目標網域與規則命中資訊，繼續排查；不要反覆匯入同一份訂閱。