2026-10-14 · 故障排除 · 約 8 分鐘

Shadowrocket DNS 設定教學：延遲測試正常但網頁打不開怎麼辦

延遲測試有結果，網頁卻打不開？問題可能出在 DNS 解析。本文說明設定檔中的 DNS 選項，並整理解析失敗時的檢查順序。

本文重點

本文適用於已在 Shadowrocket（小火箭）中設定好自己的服務商與連線資訊，卻遇到延遲測試有結果、網頁仍無法開啟的情況。請先區分伺服器連線、DNS 解析與網頁存取，再檢查 Config 中的 DNS 設定、Global Routing 與規則。每次只修改一個項目，並以同一個網域重新測試，避免把規則攔截或連線失敗誤判為 DNS 故障。

一、延遲有結果，為什麼仍可能解析失敗

Home → Connectivity Test 的結果取決於目前使用的測試方式。測試可能只確認是否連上伺服器，也可能連線至某個測試目標。不論採用哪種方式，都無法證明所有網站的 DNS、TLS 與頁面資源皆正常。若某個伺服器位址已在快取中，測試甚至不必重新解析該位址。

開啟新網域時，通常會先查詢位址，再依實際策略建立連線，最後進行 TLS 交握與 HTTP 請求。以下是方便排查的簡化流程；實際是否在本機解析、何時解析，仍取決於規則類型與出站協定。

網域請求 位址解析 策略選擇 出站連線 網頁回應

因此，「延遲正常」只能作為局部線索。若 DNS 已回傳位址但連線逾時，請接著檢查出站連線；若 DNS 完全沒有回傳位址，才優先檢查解析。若網頁文字能顯示、圖片卻載入失敗，也可能是圖片所用的另一個網域解析失敗，不能只檢查網址列中的主網域。

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

判斷方式：先確認是否取得解析結果

取得 A 或 AAAA 記錄後仍無法開啟網頁，就不要反覆更換 DNS。請先記下回傳的位址，再檢查該連線命中的策略與出站結果；連接埠可連通，也不代表整個解析服務正常。

二、在 Config 中確認目前使用的 DNS 設定

先開啟 Config，確認目前選取的設定檔。編輯其他未啟用的檔案，不會改變目前連線的行為。修改前請先保留副本；若設定來自自己使用的遠端設定來源，也要留意後續更新可能覆蓋本機修改。

在 Config 中開啟目前檔案的編輯畫面，查看 [General] 下的 dns-server。此項目用來指定解析伺服器。以下僅示範最基本的語法片段，並非可直接取代原設定的完整檔案。

[General]
dns-server = system

system 表示使用系統提供的 DNS，通常會受目前 Wi-Fi 或行動網路影響，並不代表固定使用某個公共解析服務。若此處填入一個或多個位址，請逐一確認來源與連線狀態；不要只為了「備用」而不斷加入未經驗證的解析端點。

三、依固定順序重新測試，避免同時變更多個因素

選一個平時能正常存取的完整網域作為測試目標，再挑另一個不同網站作為對照。測試期間固定伺服器與網路；不要同時切換 Wi-Fi、伺服器和 DNS，否則即使恢復正常，也無法判斷是哪個項目發揮作用。

  1. 記錄目前狀態

    在 Home 記下選取的 SERVER、Global Routing 目前值，以及 Connectivity Test 結果。記下故障網域、網路類型和瀏覽器顯示的具體錯誤；分享截圖前，請遮住帳號與伺服器資訊。

  2. 確認模式

    開啟 Home → Global Routing，確認目前模式為 Config、Proxy、Direct 或 Scene。若使用 Scene，請先確認實際生效的場景。記下原本的值再進行比對，不要把切換模式當成最終修復方式。

  3. 確認設定檔

    進入 Config，開啟目前選取的檔案，檢查 dns-server 與 [Host]。一次只修改一個項目；儲存後回到 Home 重新連線，再開啟同一個網域測試。

  4. 檢查自動連線

    進入 Settings → On Demand，記下是否已啟用及相關條件。若測試期間連線自動恢復，可暫時關閉 On Demand 再次比對，完成後請還原原設定。On Demand 控制的是連線觸發條件，不是 DNS 伺服器設定。

  5. 更換網路測試

    保持設定檔和 SERVER 不變，再分別透過 Wi-Fi 與行動網路重新測試。若只有某個網路發生故障，請優先檢查該網路的 DNS 可連線性、登入驗證狀態與網路限制。

  6. 還原並確認

    還原不必要的暫時性變更，重新連線後測試兩個網站。修復成功的標準是取得預期的解析結果，且網頁完成載入，而不只是 Connectivity Test 再次顯示數值。

瀏覽器、系統與解析伺服器都可能有各自的快取。重新連線有助於建立明確的測試條件，但不保證清除所有快取。比對時應記錄是否重複使用相同結果；不要以任意 HTTPS 數字位址取代網域測試，這會造成憑證與虛擬主機差異。

四、依實際錯誤分成三類處理

以下是 DNS 協定或診斷輸出中可能出現的原文，不代表 Shadowrocket 的每個畫面都會逐字顯示這些內容。瀏覽器可能只顯示概括性的提示。請以實際記錄為準，不要把所有「無法開啟」都歸為同一類問題。

NXDOMAIN

原因：解析伺服器回覆網域不存在；網域拼字錯誤、記錄已撤除或解析端策略，都可能導致此結果。

解決方式：先確認完整網域，再使用另一個已確認可用的解析來源進行比對；若只有單一網域持續發生此情況，請向該網域的維護方確認記錄。

SERVFAIL

原因：解析伺服器未能完成查詢，可能與上游異常、權威伺服器無法使用或 DNSSEC 驗證失敗有關，並不代表網域不存在。

解決方式：保持網路與出站設定不變，改用現有且可用的解析設定重新測試；若只有此網域異常，請保留發生時間與回傳狀態，提供給相關維護方。

timeout

原因：在等待時間內沒有收到回應，可能是解析端點無法連線、封包遭到丟棄，也可能是加密解析連線未能建立。

解決方式：先確認設定中的位址、協定與連接埠相符，再換另一個網路比對；不要只延長等待時間，掩蓋持續無法連線的問題。

查詢完成但沒有所要求類型的記錄，也不一定代表故障。例如，網域只有 A 記錄，查詢 AAAA 時可能收到成功回應，但沒有相應答案。應同時查看回應狀態與記錄類型，不能只因「沒有 IPv6 位址」就判定解析服務失效。

五、解析正常後，檢查 Global Routing 與規則

Global Routing 的 Config 會依目前設定檔中的規則決定連線去向；Proxy 與 Direct 用於相應的全域路由模式；Scene 則依已設定的場景運作。這些並非四種 DNS 伺服器選項。切換模式後網頁恢復，只能說明路徑變更影響了結果，仍需找出具體的規則或出站差異。

在 Config 中檢查目前檔案的 [Rule]。以下是語法說明片段，使用文件範例網域與保留位址範圍，不應直接加入實際設定作為修復方案。FINAL,DIRECT 僅表示此片段的預設策略，並非通用建議。

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

同一連線通常會依序比對規則，因此前面的攔截或策略選擇，可能使後面的規則無法生效。若使用規則集，也要檢查其實際內容與更新狀態。不要只在主檔案中搜尋網域，找不到就認定沒有相關規則。

六、確認修復結果並保留可供複查的記錄

有效的修復必須能重複驗證：在固定網路、固定 SERVER 和固定設定檔下，故障網域可正常解析，連線路徑符合預期，網頁與必要資源都能載入。接著還原原本需要的 On Demand 設定，再確認切換網路後是否仍正常。

若兩個解析來源都能正常回傳位址，但同一伺服器上的網頁連線仍失敗，請改查伺服器可用性、TLS、出站限制與規則。持續增加 DNS 位址只會增加變數，不會自動解決這些問題。若要繼續排查，可參閱本站故障排除與概念速查。

Shadowrocket 是 Apple 平台上的閉源商業 App，主要供 iPhone 與 iPad 使用，唯一取得管道為 App Store。開發者為 Shadow Launch Technology Limited，App 採一次性買斷；App 買斷 ≠ 線路方案。本文以使用者已有自己的服務商與設定為前提，系統需求請以 App Store 頁面標示為準。

App Store 正版核對