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

Shadowrocket DNS 設定與故障排除：延遲測試正常，網頁卻無法開啟？

了解連線測試與網域解析的差異、DNS 設定項目，以及如何逐步排查解析失敗和網頁無法載入。

本文重點

Shadowrocket（小火箭）顯示延遲數值，只能表示當下的測試已完成，不能證明所有網域都能解析，或所有網頁都能連線。本文適合已設定好自己既有服務、但遇到網頁無法載入的使用者，依序確認接管狀態、判斷故障階段、檢查 DNS、核對規則並復原驗證。操作前先備份目前設定，每次只修改一個變數，避免混淆解析故障與代理連線故障。

一、延遲正常，不代表網頁請求完整成功

瀏覽網頁至少會經過目標網域處理、路由選擇、建立連線與應用層互動。DNS 用來取得網域對應的位址等紀錄；HTTPS 網頁還需要與目標完成 TLS 交握。延遲測試可能只檢查伺服器連接埠，也可能向指定的測試位址發出要求，實際方式取決於所選的測試類型。測試不會逐一連線到你正在瀏覽的網頁，以及該頁面的圖片、指令碼和登入介面。

網域處理 路由選擇 建立連線 TLS 交握 載入頁面

這個流程用來區分排查階段，不代表所有請求都必須先在本機完成 DNS 解析。網域規則可在取得目標 IP 前命中；部分代理協定與設定允許將網域交由遠端處理，而 IP 類規則則可能需要解析結果。因此，請分清「裝置本機解析」、「代理伺服器位址解析」與「遠端解析目標網域」，不要看到延遲數值就認為所有 DNS 問題都已排除。

二、先記錄狀態，再進行可重複的比對

先選一個能穩定重現問題的完整網址，記下網路類型、發生時間和錯誤原文。不要只說「所有頁面都不行」，也不要同時更換伺服器、設定檔和 DNS。以下以 iPhone / iPad 的 Home、Config、Settings 介面為操作基準，其他平台請核對對應功能；系統 VPN 圖示只代表通道狀態，不表示遠端服務已可使用。

  1. 保存目前狀態

    在 Config 確認目前生效的設定，備份後再編輯。記下 Home 目前選取的伺服器、Global Routing 狀態，以及 Settings → On Demand 中已有的條件；先不要刪除原有設定。

  2. 確認連線接管

    返回 Home 檢查連線開關。若要手動停用連線進行比對，先檢查 Settings → On Demand，避免系統依原有條件重新建立連線，導致「關閉後測試」的結果失去參考價值。

  3. 核對路由模式

    檢查 Home → Global Routing。Config 會依設定分流，Proxy 可用來比對代理連線路徑，Direct 可用來比對直接連線，Scene 則依已設定的場景運作。測試時請明確選擇一種模式，不要把 Scene 當成固定的代理模式。

  4. 重試相同請求

    在相同網路和伺服器下重試相同網址，記錄錯誤是否一致。接著只切換 Wi-Fi 與行動網路再測一次；若只有其中一種網路失敗，優先檢查該網路的 DNS 是否可連線、是否需要登入，以及有無存取限制。

  5. 還原設定

    完成比對後，還原原本的 Global Routing 和 On Demand 條件。逐項記錄改動及結果，避免暫時切換到 Proxy 後測試成功，就誤以為原本 Config 中的分流問題已修復。

三、設定 DNS 時，分清伺服器、傳輸方式與解析位置

檢查 DNS 時，請同時確認三件事：查詢交給哪個服務、使用哪種傳輸方式，以及查詢流量走哪條路徑。只填入 DNS 位址只能回答第一個問題，並不保證該位址在目前網路中可以連線。加密 DNS 也需要連上解析服務；若解析服務使用網域名稱，還要考慮首次解析所需的引導路徑。

53
傳統 DNS 常用 UDP / TCP 連接埠
853
DNS over TLS 常用 TCP 連接埠
443
DNS over HTTPS 常用 HTTPS 連接埠
檢查項目實際意義排查重點
System DNS使用系統目前提供的解析設定，通常會隨連線的網路而異。同一台裝置切換網路後，結果可能不同；Wi-Fi 下成功，不代表行動網路也能使用。
自訂 DNS明確指定解析伺服器或支援的解析服務位址。核對格式與連線狀態；只接受 IP 的欄位不可填入 HTTPS 服務網址。
DNS over HTTPS透過 HTTPS 傳送 DNS 查詢。檢查完整服務路徑、TLS 連線，以及解析服務本身的網域能否解析；僅連得上連接埠，仍不足以證明服務可用。
DNS over TLS透過 TLS 傳送 DNS 查詢。檢查服務連接埠、憑證驗證，以及目前網路是否允許此連線。
A / AAAA分別對應 IPv4 與 IPv6 位址紀錄。有 AAAA 紀錄不代表目前的 IPv6 路由可用；請搭配連線結果判斷。

如果目前設定使用文字格式的 [General] 區段，可以檢查其中的 dns-server 設定。以下範例表示使用系統 DNS，並非通用的「最佳設定」。這只適合用來進行受控比對：先備份，再修改現有欄位；不要在檔案末尾新增重複的同名欄位，也不要假設這項設定會覆蓋瀏覽器本身的 Secure DNS。

[General]
dns-server = system

四、依錯誤訊息判斷解析失敗、連線逾時或憑證問題

錯誤原文比「無法開啟」更有助於判斷問題。以下是瀏覽器或網路工具可能顯示的實際錯誤文字，不是要你在 Shadowrocket 中尋找同名選單，也不表示每個平台都會顯示相同訊息。看到錯誤後，應依發生階段和記錄判斷，不要只憑一個詞就直接修改設定。

錯誤：ERR_NAME_NOT_RESOLVED

原因與處理方式：瀏覽器未能取得可用的名稱解析結果。先核對網域拼字，再比對系統解析與目前設定中的 DNS，並檢查是否為瀏覽器自訂的 Secure DNS 路徑失敗。

錯誤：DNS_PROBE_FINISHED_NXDOMAIN

原因與處理方式：診斷結果表示網域不存在，但設定錯誤的解析服務也可能回傳異常的否定結果。請確認完整網域，改用可信且已知可用的解析路徑比對，不要只是不斷重新整理頁面。

錯誤：ERR_CONNECTION_TIMED_OUT

原因與處理方式：連線未能在指定時間內完成，原因不一定是 DNS。檢查目標解析位址、命中策略和遠端連線，並使用相同網址比對 Config 與 Proxy 的結果。

錯誤：ERR_CERT_DATE_INVALID

原因與處理方式：憑證日期驗證失敗，可能與裝置時間或網站憑證的有效期限有關。先核對系統日期與時區，再確認目標網站狀態；不要藉由關閉憑證驗證來處理。

如果查詢工具明確回傳 NXDOMAIN，表示該次回應判定網域不存在；回傳 SERVFAIL 則表示解析服務無法完成查詢，兩者都不同於「沒有收到回應」的逾時。記下回應類型、查詢網域和使用的解析伺服器，比只記錄「DNS 錯誤」更方便後續核對。

五、檢查規則：解析正確，也可能走錯連線路徑

在 Global Routing 選擇 Config 時，規則通常依由上而下的順序處理，命中後便執行對應策略。DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依 IP 網段比對，GEOIP 依 IP 地理資料庫判斷，FINAL 則處理未命中前面規則的請求。DNS 回傳正確位址，只表示解析階段完成，不代表後續策略適合該請求。

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

以下僅供閱讀語法：example.com 是範例網域，192.0.2.0/24 是文件專用的範例網段，不應直接當作日常規則使用。no-resolve 表示不為這條 IP 規則主動觸發網域解析；若請求已帶有 IP，仍可能符合規則。範例中的 PROXY 需要目前環境中有可用的代理選項，不會自動產生可用的連線路徑。

如果記錄中看得到請求網域、目標位址和策略，請一併保存。提供診斷資訊前，先遮蔽驗證憑證、私人位址和訂閱權杖。不要為了排查而公開完整設定；本文以使用者已有自己的服務商與訂閱為前提，本網站不提供、不販售、不推薦節點或訂閱。

六、IPv6、快取與瀏覽器 DNS 常見問題

更換 DNS 後，為什麼錯誤還是一樣？

先確認修改的是 Config 中目前使用的檔案，而且已經儲存。重新建立連線，關閉舊頁面後再送出新請求；瀏覽器、系統或遠端服務都可能保留快取，更換 DNS 不保證各層快取會立即清除。記下新請求的時間，避免把舊分頁的錯誤當成新結果。

關閉 IPv6 就能開啟，應該一直關著嗎？

這只能表示 IPv6 路徑或位址選擇值得進一步檢查。記下 AAAA 查詢結果，在同一網路分別測試 IPv4 與 IPv6 是否可連線，再核對路由與服務端支援情況。暫時停用相關選項可用來比對，但不要把它當成所有 DNS 故障的固定解法。

只有一個瀏覽器無法開啟網頁，該怎麼查？

在同一台裝置上用另一個瀏覽器開啟完全相同的網址。檢查故障瀏覽器的 Secure DNS、自訂代理設定和擴充功能；暫時改用系統解析進行比對，測試後再還原原設定。無痕視窗可協助排除部分網站資料的影響，但不保證能繞過 DNS 快取。

用 IP 能開，網域卻打不開，一定是 DNS 問題嗎？

不一定。HTTPS 網站通常需要網域提供 SNI 並驗證憑證；直接輸入 IP 可能會連到其他網站或出現憑證錯誤。請綜合解析查詢結果，以及帶有正確網域的連線測試判斷，不要只用 IP 頁面能否開啟作為唯一依據。

訂閱可以更新，為什麼網頁還是打不開？

訂閱更新只能驗證當時連往訂閱網址的路徑，無法驗證所有伺服器和目標網站。返回 Home 確認實際選取的伺服器，再檢查 Global Routing 和故障網域；不要反覆更新訂閱來取代 DNS 與規則排查。

七、使用相同網址重新測試，只保留必要變更

排查完成的標準不是「延遲出現數字」，而是在預期的網路和路由模式下，原本無法開啟的網址能重複載入，重要資源也能正常請求。若小型請求正常、大型資源卻卡住，才需要進一步檢查鏈路 MTU 或傳輸層問題；尤其使用 WireGuard 時，不要一遇到網頁打不開就隨意修改 MTU，以免將其他層的故障混入 DNS 排查。

  1. 還原日常使用的 Global Routing，重新測試原網址和先前無法載入的資源網域。
  2. 分別在 Wi-Fi 與行動網路下驗證，記錄是否只有其中一種網路有問題。
  3. 還原原有的 On Demand 條件，確認切換網路後的連線行為符合預期。
  4. 只保留經比對證實有效的變更；還原無效的 DNS、IPv6 或規則調整。
  5. 若問題仍未解決，整理錯誤原文、發生時間、網路類型、策略及已進行的比對，再向自己既有服務的維護方確認。
下載 Shadowrocket