2026-10-15 · 故障排除 · 約 10 分鐘

Shadowrocket 網頁無法開啟但延遲正常：DNS 解析失敗排查與設定說明

延遲測試有數值，網頁卻無法開啟？從 DNS 著手逐步排查：了解 dns-server 設定、系統 DNS 與自訂 DNS 的差異，以及按步驟恢復連線的檢查順序。

本文快速導覽

本文適合已在 Shadowrocket（小火箭）匯入自己的訂閱，連線後仍無法開啟網頁的使用者。先區分伺服器連線、網域名稱解析與網頁連線三個環節，再確認 Global Routing 和目前使用的 Config，最後只變更一項 DNS 設定進行比對。目的是找出故障所在，而不是把所有無法開啟網頁的問題都歸因於 DNS。

一、為什麼延遲正常不代表網頁能開啟

Home 中伺服器項目的延遲值，只表示目前測試方式涵蓋的連線路徑有回應。不同測試方式檢查的目標與流程各異：連接埠成功建立連線，不代表目標網域已解析成功；即使某個測試網站可以存取，也不能證明另一個網站的 DNS、TLS 和 HTTP 請求都正常。

開啟 HTTPS 網頁時，通常會先取得網域對應的位址，再依策略建立連線，完成 TLS 交握後請求網頁。任何一個環節失敗，都可能讓瀏覽器顯示「無法開啟網頁」。若採用 Proxy 策略，也要考慮目標網域是否交由遠端解析，不能只憑裝置本機的 DNS 測試判斷整條連線路徑。

53
傳統 DNS 常用的 UDP / TCP 連接埠
443
HTTPS 與 DoH 通常使用的連接埠
853
DoT 的預設連接埠

結論：使用相同網址進行比對

保留一個持續無法開啟的網址，在相同網路、相同伺服器及相同 Global Routing 狀態下，比較變更前後的結果。不要同時更換伺服器和 DNS，否則即使恢復正常，也無法確認是哪項變更生效。

二、先確認故障範圍，再修改 dns-server

先記下無法開啟的網址、目前使用的 Wi-Fi 或行動網路、選取的伺服器、Global Routing 狀態，以及瀏覽器顯示的完整錯誤訊息。只需記錄網域和現象，請勿附上訂閱 token、帳戶資訊或完整設定金鑰。訂閱連結應向你的服務商取得，不應公開在排錯截圖中。

  1. 固定測試條件

    在 Home 記下目前使用的伺服器，再前往 Home → Global Routing 確認選項。若目前使用 Scene，先確認實際採用的場景與策略，不要預設它等同於 Config。

  2. 比較兩個網域

    使用 Safari 分別開啟無法存取的網址，以及另一個平時可正常使用的網址。若只有一個網域無法開啟，優先檢查拼字、該網域的解析記錄及符合的規則；若所有網址都無法開啟，再檢查共用的連線路徑。

  3. 比較網路環境

    保持伺服器與設定不變，在 Wi-Fi 和行動網路之間切換後，重試相同網址。若只有特定 Wi-Fi 無法使用，也要確認該網路是否需要先完成網頁認證。

  4. 控制自動連線

    若要測試中斷連線時的情況，請前往 Settings → On Demand 記下目前狀態，必要時暫時關閉。否則按需連線可能會重新建立連線，讓「中斷後測試」的條件失效；測試結束後請恢復原設定。

  5. 保留原有設定

    在 Config 中先保留目前設定的副本，或匯出備份，並記下目前選取的檔案。接下來只修改該檔案中的一項參數，儲存並重新連線後再測試；不要同時更新訂閱或匯入另一份完整設定。

如果系統能解析並存取相同網址，但連線後反而無法開啟，請著重檢查設定中的 DNS、規則命中情況與遠端連線路徑；如果中斷連線後也無法開啟，則還要排查系統網路或網站本身。兩種情況都不能只憑一次測試下定論。

三、dns-server、系統 DNS 與自訂 DNS 的差異

dns-server 是設定檔 [General] 中的 DNS 上游設定。前往 Config，開啟目前檔案的操作選單並選擇 Edit Config，檢查現有的 [General] 區段；選單內容請以目前介面顯示為準。不要將參數寫入 [Rule]，也不要在同一檔案中重複加入多個同名設定。

設定方式說明排查重點
dns-server = system使用系統提供的 DNS 上游。切換網路後，上游可能會改變；這不代表固定使用某個公共 DNS。
dns-server = 1.1.1.1指定一個一般 DNS 上游位址作為比對範例。確認目前網路是否允許存取該 DNS 服務；位址可連線不代表查詢一定成功。
加密 DNS 上游依所用設定支援的語法，透過 DoH 或 DoT 傳送查詢。除了解析服務本身，也取決於端點連線、憑證及可能需要的引導解析。

系統 DNS 會依目前網路環境取得，適合用來還原接近系統預設值的狀態作為比對。自訂 DNS 可明確指定上游，但不保證在所有 Wi-Fi 或行動網路中都能連線，也無法自動修正錯誤規則、伺服器故障或網站憑證問題。企業內網的專用網域也可能只能透過內部 DNS 解析。

[General]
dns-server = system

上方僅示範參數的位置，並非完整設定檔。若原檔案已有 [General]，只要在原區段中替換對應的那一行，不要用這兩行覆蓋整份檔案。若要比較自訂上游，再將該行單獨改為 dns-server = 1.1.1.1，儲存、重新連線，並測試相同網域。此位址僅用於說明語法，不代表適用於所有網路。

四、依錯誤類型區分無記錄、服務失敗與逾時

瀏覽器顯示的概括提示通常不足以判斷原因。如果診斷記錄提供 DNS 回應碼或錯誤文字，可依下列三種類型進行判斷。這裡的英文是 DNS 回應碼及常見網路錯誤文字，不代表 Shadowrocket 的每個介面都會逐字顯示這些內容。

錯誤：NXDOMAIN

原因：此次 DNS 回應表示查詢的網域不存在，也可能與上游回傳的結果有關。

處理方式：先確認網域拼字，再以相同網域比對系統 DNS 與一個可連線的自訂上游；若兩者都回傳此回應，請向網域或服務維護方確認記錄狀態。

錯誤：SERVFAIL

原因：解析服務未能完成查詢，可能與上游遞迴查詢或驗證失敗有關，不等同於網域不存在。

處理方式：保持連線策略不變，改用另一個已確認可連線的解析上游重新測試，並記下是否只有單一網域受影響；避免直接刪除現有規則。

錯誤：timed out

原因：某個步驟在等待時間內未收到回應；若未標明查詢階段，也可能是連線或交握逾時，而不只是 DNS 問題。

處理方式：先確認錯誤發生在 DNS 查詢還是目標連線，再比較不同網路環境；只有 DNS 查詢逾時時，才優先檢查解析上游的連線狀態。

收到 NOERROR 也不一定代表取得了可用位址：回應中可能沒有對應的 A 或 AAAA 記錄。如果已取得位址，之後才出現 TLS 憑證錯誤或 HTTP 錯誤，應改為檢查裝置時間、目標網站、連線路徑與規則，不要再將問題視為單純的 DNS 故障。

五、解析成功後，檢查 Global Routing 與規則命中情況

在 Home → Global Routing 中，Config 會依目前設定的規則決定策略，Proxy 會將流量交由代理策略處理，Direct 則採用直連策略；Scene 則須依目前的場景設定判斷。這裡的模式控制與 DNS 上游選擇是兩回事，切換至 Proxy 不代表一定能連上某個 DNS 服務。

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

這段內容僅說明規則的含義，不應直接取代現有規則：DOMAIN-SUFFIX 會比對 example.com 及其子網域；FINAL 是前面的規則都未符合時使用的兜底規則。規則會依序比對，前面較寬泛的條件可能已決定策略。IP-CIDR 和 GEOIP 涉及目標 IP，排查時也要留意取得位址後的比對結果；它們不是 DNS 伺服器設定。

六、恢復後的確認與常見問題

找到有效的修改方式後，請保留最終設定及簡要記錄：原先現象、修改的設定行、使用的網路、測試網址與結果。將暫時變更的 Global Routing 和 On Demand 恢復為日常狀態，再測試一次。如果切回 Config 後故障重現，應繼續檢查規則，不要長期依賴臨時切換來掩蓋問題。

修改 DNS 後，結果為什麼還是沒變？

先確認修改的是 Config 目前選取的檔案，而且已成功儲存；重新連線後，關閉再重新開啟測試用的 App。快取可能暫時保留舊結果，第一次重測沒有變化時，不建議立刻接連修改多個項目。

直接輸入網站 IP，能證明是 DNS 有問題嗎？

不能據此可靠判斷。HTTPS 需要使用網域進行憑證驗證及選擇網站，直接存取 IP 可能會進入其他網站或觸發憑證錯誤。應比對同一網域的解析回應與後續連線結果，而不是用 IP 取代網址。

為什麼切換到行動網路就正常了？

保持伺服器與設定不變，再重新測試。若差異持續存在，請檢查 Wi-Fi 的認證狀態、系統 DNS，以及網路對所用 DNS 傳輸方式的限制；將設定還原為 dns-server = system 進行一次比對，再決定是否保留自訂設定。

網頁恢復正常，但訂閱更新仍然失敗，該怎麼辦？

訂閱更新使用的是另一條請求路徑。先確認現有訂閱連結仍有效，再向自己的服務商確認是否有存取限制或帳戶狀態問題。網頁恢復正常，不代表訂閱網域、驗證參數和伺服器回應都正常。

從 App Store 下載請先確認正版資訊