2026-08-27 · 故障排除 · 約 8 分鐘

Shadowrocket DNS 解析失敗怎麼辦？延遲正常但 Safari 網頁打不開

延遲測試有數值，Safari 卻一直載入，問題可能出在 DNS 解析。本文依序檢查 DNS 設定、規則比對與本地網路，找出解析失敗的原因。

本文重點

Shadowrocket（小火箭）的延遲數值只反映特定測試路徑，無法證明網頁網域已成功解析。若已有自己的服務商與訂閱，連線後仍無法開啟網頁，可依序檢查本地網路、目前 Config 的 DNS、Global Routing 與請求記錄；每次只修改一項，並根據解析結果與連線階段判斷問題所在。

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

先分清兩件事：連上所選伺服器，以及瀏覽目標網站。延遲測試可能只測試伺服器連線或指定的測試位址；Safari 開啟網頁則還需要解析目標網域、選擇出站策略、建立連線並完成 TLS 交握。前一個步驟有回應，後續任何一步仍可能失敗。因此，延遲有數值時，應優先檢查 DNS，而不是直接認定伺服器或整個網路正常。

網域解析 規則比對 出站連線 TLS 交握 網頁回應

這個流程用於區分排查階段，並非所有連線都固定依照此內部順序執行：網域規則可能先參與比對，部分 IP 規則則需要先取得位址。實際檢查時，應分別記錄「是否取得 IP 位址」、「最後採用哪項策略」以及「在哪個步驟發生連線失敗」。若網站出現憑證錯誤或 HTTP 狀態碼，通常表示問題不只是 DNS 沒有回應。

53
傳統 DNS 常用的 UDP／TCP 連接埠
443
DNS over HTTPS 通常使用的 HTTPS 連接埠
A / AAAA
分別代表 IPv4／IPv6 位址記錄

連接埠說明的是服務常用的連線方式，不代表需要在路由器開放入站連接埠。取得 A 或 AAAA 記錄只表示解析已回傳位址；若回傳錯誤位址、IPv6 路徑無法連線，或後續連接埠受到限制，網頁一樣可能無法開啟。

二、先確認本地網路與目前設定

開始修改前，先備份目前設定，並記下出問題的完整網域、使用的 Wi-Fi 或行動網路、Global Routing 目前選項及錯誤發生時間。測試時使用同一個網頁，並另外準備一個目前網路原本可以開啟的網頁作為對照。只觀察單一網站，容易把目標網站本身的故障誤認為所有 DNS 請求都失敗。

  1. 暫停自動連線

    前往 Settings → On Demand，記錄目前啟用狀態與條件，排查期間先暫時停用。接著在 Home 中斷連線，避免中斷後立即因按需條件重新連線。

  2. 檢查原始網路

    中斷連線後，使用 Safari 開啟對照網頁。若公共 Wi-Fi 需要驗證，請先完成網路登入；若原始網路也無法連線，先處理 Wi-Fi、行動數據或網路驗證問題。

  3. 確認目前使用的設定

    前往 Config，確認實際選取的設定檔，再開啟該檔案檢查內容。只編輯另一個未啟用的檔案，不會改變目前請求的處理方式。

  4. 連線後再次測試

    返回 Home，連線至自己已有的伺服器，再用 Safari 重試相同網頁。記錄中斷與連線兩種狀態的差異，不要同時切換伺服器、DNS 與規則。

  5. 切換網路確認

    保持設定與伺服器不變，在 Wi-Fi 與行動網路之間切換後重試。若只有其中一種網路失敗，優先檢查該網路的 DNS 是否可連線、是否需要驗證，以及是否有存取限制。

若自己使用的伺服器位址是網域名稱，建立連線前也可能需要先解析。因此，「目標網頁的 DNS」與「伺服器網域的初始解析」是兩個不同的檢查項目。前者出錯時，連線可能仍維持；後者出錯時，連線本身可能無法建立。不要只根據狀態列的連線標示，就認定這兩項都已完成。

三、檢查 [General] 中的 dns-server

在 Config 中檢查目前檔案的 [General] 區段，找到 dns-server。先確認使用的是系統解析、指定 DNS 位址或 DNS over HTTPS，再檢查拼寫，以及目前網路是否能連上所填的服務。不要直接拼接不同來源的設定，也不要把服務商提供的其他欄位誤填為 DNS 位址。

[General]
dns-server = system

以上是使用系統 DNS 的最小片段，用來說明欄位語法，並非完整設定。若要進行對照測試，請先備份，再取代原有的同名設定項目，不要重複新增 [General] 或堆疊多個 dns-server。儲存後重新連線並送出新請求；恢復正常只能說明解析路徑變更有效，仍需比對原設定找出原因。

四、使用 Global Routing 區分規則與解析問題

前往 Home → Global Routing，先記錄目前選項。Config 會依目前設定中的規則處理請求；Proxy 與 Direct 可用來比對不同出站路徑。切換至 Proxy 後網頁恢復正常，不代表「DNS 已修復」：目標網域可能一直都能解析，只是原有規則將連線交給不合適的出站策略。

測試狀態觀察結果下一步檢查
Config 失敗，Proxy 正常所選出站路徑可完成該網頁請求檢查規則比對結果、策略指向與 DNS 相關設定
Direct 正常，Proxy 失敗直接連線可存取，代理路徑則有差異檢查所選伺服器、出站連線與解析路徑
多種狀態都失敗問題不只與某一條分流規則有關檢查本地網路、解析器連線狀態與目標網站
只有一個網域失敗問題集中在特定目標檢查該網域的解析結果、專用規則與網站狀態

規則會依序比對，命中後採用對應策略。檢查 DOMAIN-SUFFIX 是否涵蓋目標網域、GEOIP 或 IP-CIDR 是否將解析取得的位址導向其他路徑，以及 FINAL 是否位於規則區段末尾。以下片段僅展示語法與順序；example.com 是文件中的示例網域，不是網頁連線測試目標。

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

no-resolve 表示該 IP 規則不會為了比對而主動觸發網域解析，並非關閉所有 DNS。是否已取得目標 IP，以及前面是否已命中網域規則，都會影響後續比對。若目前設定使用具名策略，也應檢查策略最後指向的位置；不能只看到規則列中的名稱，就認定使用的是預期伺服器。

結論：先保留能重現差異的對照

若 Config 與 Proxy 的結果不同，先記錄同一網域命中的規則與最後使用的出站路徑，再修改對應項目；不要同時更換 DNS 與伺服器，否則無法判斷是哪項修改生效。

五、依錯誤階段辨別 DNS、連線與 TLS 問題

Safari 顯示的提示可能依系統語言而異。若錯誤詳細資訊或診斷記錄提供系統錯誤代碼，可用下列原文辨別問題階段；這些是 Apple URL Loading System 的錯誤名稱，不代表 Shadowrocket 一定會逐字顯示。查看與本次瀏覽時間相符的請求記錄，優先找出解析是否失敗、目標 IP、命中策略及後續連線結果。

錯誤：NSURLErrorCannotFindHost（-1003）

原因：請求找不到指定主機，可能與網域拼寫或名稱解析有關。處理方式：先確認完整主機名稱，再比對系統 DNS 與目前 DNS 設定能否取得位址。

錯誤：NSURLErrorDNSLookupFailed（-1006）

原因：DNS 查詢失敗，解析器無法連線或解析過程異常都可能造成此結果。處理方式：檢查目前的解析器與網路路徑，其他條件保持不變，再切換網路或改用系統 DNS 進行比對。

錯誤：NSURLErrorTimedOut（-1001）

原因：請求逾時，可能發生在解析、連線或等待回應的階段。處理方式：先確認記錄中是否已有目標 IP，再檢查對應的出站路徑與連線結果，不要只憑逾時訊息就判定是 DNS 問題。

錯誤：NSURLErrorSecureConnectionFailed（-1200）

原因：安全連線建立失敗，可能與 TLS、憑證或網路中的連線干預有關。處理方式：確認裝置日期與時間及目標主機名稱，查看 TLS 相關記錄；不要以關閉憑證驗證取代問題排查。

若記錄中已有目標 IP，但接著連線至該 IP 逾時，應繼續檢查伺服器出口、目標連接埠及 IPv4／IPv6 路徑，而不是反覆修改 DNS。若只看到 DNS 查詢送出，卻長時間沒有回應，才應優先檢查解析器是否可連線。若只有舊網頁正常、新網域失敗，快取可能掩蓋問題，也需要送出新請求重新測試。

六、確認恢復正常後再還原按需連線

修改後應儲存目前設定，中斷連線再重新連線，並重新開啟目標網頁。Safari 或其他 App 可能保留既有連線與快取，因此重新整理一次成功，不足以證明問題已排除；同樣地，舊連線持續失敗，也不代表新設定沒有生效。請用原本出問題的網頁、對照網頁及另一種網路重複檢查，並記錄結果是否一致。

若問題仍未解決，請向自己的服務商或網路管理員提供必要資訊：發生時間、網路類型、目標網域、Global Routing 狀態、命中策略，以及已移除敏感資訊的錯誤片段。不要傳送完整訂閱連結、驗證密碼或含有存取權杖的設定。明確指出是「解析沒有回應」還是「取得位址後連線失敗」，通常比只提供延遲測試結果更有助於定位問題。

App Store 正版確認