2026-10-14 · 疑難排解 · 約 9 分鐘

Shadowrocket DNS 無法解析？延遲測試正常但網頁打不開的排查方法

從 dns-server、系統 DNS 與設定檔 DNS 的關係著手，逐步排查 DNS 解析失敗或特定網域無法開啟，並說明相關設定的用途。

本文重點

Shadowrocket（小火箭）的延遲測試成功，不代表目標網站的 DNS、規則和 HTTPS 連線都正常。本文適合已有服務商與訂閱的使用者，依序記錄現象、確認設定、比對 DNS、檢查規則及確認 IPv6；每次只變更一個項目，最後以相同網域重新測試，分辨解析失敗與解析後的連線問題。

一、延遲測試正常，為什麼網頁還是打不開

Home 中的延遲結果，只反映所選測試方式對應的目標與路徑。即使測試成功，也不能證明瀏覽器瀏覽的每個網域都能解析，更不能保證網站的 TCP、TLS 或後續資源請求都能完成。先記下無法開啟的網域、發生時間，以及當時使用 Wi-Fi 或行動網路；不要只寫「網路不通」。

瀏覽網頁通常需要先將網域轉換成 IP 位址，再建立連線並完成 TLS 交握。依設定不同，部分網域可能交由 Proxy 端解析，也可能需要先在本機取得位址；不能假設所有請求都遵循固定路徑。以下是排查時的邏輯順序，不代表每種協定的實際封包順序。

網域請求 解析與分流 連線至位址 TLS 交握 載入頁面資源
  • 網域沒有取得位址：優先檢查 DNS 回應、解析器是否可連線，以及本機對應設定。
  • 已取得位址但連線逾時：接著檢查命中的策略、目標連接埠與 IP 位址類型，不能直接判定是 DNS 故障。
  • 頁面顯示 HTTP 403 或 503：至少這次請求已抵達能回傳 HTTP 回應的服務；請檢查網站的存取限制或服務狀態。
  • 首頁顯示但圖片未載入：記下圖片或指令碼使用的網域；主站網域正常，不代表資源網域套用相同規則。

二、先進行一輪單一變因排查

開始前先備份目前的設定，記下 Home → Global Routing 的狀態及目前選用的伺服器。本文以 Config 作為日常規則分流的基準；Proxy、Direct 和 Scene 的行為仍須依各自設定判斷，切換模式本身並不能修復 DNS。

  1. 記錄目前狀態

    在 Home 記下目前的伺服器和 Global Routing 狀態。用瀏覽器重新開啟相同網域並記錄錯誤訊息；不要同時更新訂閱、切換伺服器和修改 DNS。

  2. 確認設定檔

    進入 Config，確認目前實際啟用的設定檔，再查看其中的 [General] 與 [Rule]。先備份，再使用本機副本測試，避免直接修改唯一的設定檔。

  3. 切換網路測試

    維持伺服器和設定不變，在 Wi-Fi 與行動網路間交叉測試一次。若只有 Wi-Fi 無法使用，先確認該網路是否需要網頁認證，再檢查 DNS 與網路限制。

  4. 比對 DNS 解析

    在測試副本中只修改 dns-server，儲存並啟用該副本，接著中斷連線再重新連線。以相同網域重新測試，記錄是否取得位址及頁面是否恢復正常。

  5. 還原設定確認結果

    若修改後沒有改善，請還原原值再測試。需要中斷連線時，可先查看 Settings → On Demand，必要時暫時關閉自動連線條件；測試後再恢復，避免自動重新連線影響判斷。

三、dns-server、系統 DNS 與設定檔的關係

dns-server 位於設定檔的 [General] 區段，用來指定解析器。system 表示使用系統提供的 DNS；系統 DNS 可能來自目前 Wi-Fi 的自動設定或手動設定，並非固定的公共 DNS。切換網路後，系統使用的 DNS 條件也可能改變。

先在目前生效的設定檔中搜尋 dns-server，確認是否有重複定義或先前留下的測試值。接著分別在兩份本機測試副本中使用以下兩種寫法；不要將兩個 [General] 區段直接合併到同一份檔案。此處的公共 IP 位址僅供連線能力比對，不保證適用於所有網路。

比對 A：使用系統提供的 DNS

[General]
dns-server = system

比對 B：指定一般 DNS 位址

[General]
dns-server = 1.1.1.1

測試時先只保留一個候選解析器，方便判斷變因。若同時使用多個解析器，請求調度、快取及不同回應可能讓結果難以判斷。若指定的位址沒有回應，而 system 運作正常，應優先檢查目前網路至該解析器的連線路徑，而不是反覆匯入訂閱。

53
一般 DNS 常用連接埠，涉及 UDP 與 TCP
443
DoH 通常使用的 HTTPS 連接埠
2 種
分別查看 A 與 AAAA 位址記錄

連接埠可連線，不代表協定一定可用。一般 DNS 的 UDP 回應遭截斷時，可能需要改用 TCP；DoH 則必須完成 HTTPS 連線。不要將一般 DNS 位址直接改寫成 HTTPS 位址，就當成 DoH 使用；DoH 需要有效的服務端點。若端點使用網域名稱，也要考慮首次連線前如何解析該網域。

結論：使用單一解析器進行比對

若在相同網路和伺服器下，只有更換 dns-server 後問題才消失，請保留這組比對結果，再確認原解析器是否可連線；先不要同時修改規則或協定。

四、依 DNS 錯誤原文判斷原因

以下列出 DNS 回應碼與網路診斷中常見的錯誤文字；不保證 Shadowrocket 的每個畫面都會原樣顯示。若記錄或診斷結果出現這些訊息，請一併記下查詢網域、記錄類型、解析器位址及時間。只截取一行錯誤訊息，通常不足以判斷故障發生在哪個環節。

錯誤：NXDOMAIN

原因：解析器回報此名稱不存在，這與查詢逾時不同。

處理方式：先確認網域拼字，再用另一個解析器查詢相同名稱；若結果持續一致，請向網域或服務的管理者確認 DNS 記錄。

錯誤：SERVFAIL

原因：解析器無法完成查詢，可能與上游、權威伺服器或 DNSSEC 驗證等環節有關。

處理方式：改用另一個解析器比對，並記下是否只有特定網域失敗；不能只憑此錯誤碼判定伺服器已失效。

錯誤：connection timed out

原因：操作未能在指定時間內完成；只有確認這是 DNS 查詢時，才能視為解析逾時的證據。

處理方式：確認錯誤所指的目標與連接埠；若確實是 DNS 查詢，再檢查解析器連線路徑、目前網路及 UDP/TCP 通訊。

也要分清「沒有某類記錄」與「整個網域不存在」：查詢 AAAA 沒有取得位址，但 A 記錄正常，可能只是該網域沒有提供 IPv6 位址。若已取得可用位址，後續卻發生 TLS 憑證錯誤，應改查系統時間、憑證名稱及連線目標，而不是繼續更換 DNS。

五、特定網域無法開啟：檢查規則與 Host 對應

只有部分網站無法使用時，先查看該請求實際命中的規則與策略。DOMAIN-SUFFIX 可直接依網域後綴比對；IP-CIDR 與 GEOIP 依位址判斷時，可能需要進行解析。規則由上往下比對，前面的命中結果會影響後續路徑；FINAL 僅處理先前沒有命中的請求。

以下片段僅說明語法，不應直接取代現有設定。example.com 和 192.0.2.0/24 是文件範例值；PROXY 在實際設定中必須對應可用的策略。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
檢查項目說明排查方式
DOMAIN-SUFFIX比對指定網域及其子網域。確認失敗的網域是否被前面優先命中的規則分配到其他策略。
IP-CIDR比對 IP 位址範圍。檢查位址是否落入非預期的直連範圍。
no-resolve避免只為了比對這條 IP 規則而觸發網域解析。不要將它解讀為停用整份設定的 DNS。
[Host]提供本機名稱對應。確認是否留有舊位址；在測試副本中移除可疑對應後再比對。
FINAL處理先前沒有命中的請求。確認最終策略實際可用，不要只確認規則存在。

若暫時改成 Home → Global Routing → Proxy 後問題消失，但在 Config 下仍失敗，只能說明兩種路由條件不同，不能直接證明是某項 DNS 設定出錯。記錄兩次測試的命中策略、連線位址及失敗階段，再回到 Config 縮小範圍。測試完成後請還原原本的模式，避免將臨時比對設定留作日常使用。

六、已有解析結果時，接著檢查 IPv6、快取與網路條件

A 記錄提供 IPv4 位址，AAAA 記錄提供 IPv6 位址。收到 AAAA 回應，只能證明解析器回傳了位址，不代表目前網路能連線至該位址。若網域同時有這兩種位址，應分別釐清「沒有記錄」、「取得記錄但連線逾時」及「應用程式選用了哪種位址」這三個問題。

  • IPv4 可連線，IPv6 逾時：保留 DNS 回應作為證據，檢查目前網路的 IPv6 連線狀況；若需調整相關選項，先記下原值，只做暫時比對，不要同時修改 DNS 和分流規則。
  • 修改設定後看起來仍是舊結果：確認新設定檔已啟用，中斷連線後重新連線，再關閉瀏覽器並重試。瀏覽器、應用程式及解析器都可能有快取；重新連線不保證會清除所有快取。
  • 只有在飯店或公共 Wi-Fi 失敗：先完成網路要求的網頁認證。尚未通過認證時，DNS 回應或 HTTPS 連線都可能受到影響。
  • 只有特定瀏覽器無法使用：比較另一個應用程式對相同網域的結果，並檢查該應用程式是否有自己的解析、快取或連線設定，不要立刻修改全域設定。
  • 伺服器位址使用網域名稱：還要確認伺服器網域能否在建立連線前完成解析；不能仰賴尚未建立的連線，來完成啟動連線本身所需的所有解析。

結論：取得位址後，改查連線階段

若相同網域已穩定回傳 A 或 AAAA 記錄，而故障發生在連線或 TLS 階段，請先停止更換解析器，改查實際使用的位址、命中策略與目標連接埠。

七、還原設定並整理可重現的紀錄

修復後，恢復測試期間暫時關閉的 On Demand 條件，確認 Global Routing 與目前設定檔，再分別測試主站和資源網域。不要只以某個頁面第一次成功開啟作為結論：快取可能掩蓋問題，至少在重新連線後再以相同步驟測試一次。

訂閱用於提供及更新伺服器資訊，不代表能替你修復目前網路的 DNS。訂閱是從你的服務商取得；更新後伺服器清單正常，也不能證明目標網站的 DNS 解析正常。若只修改了本機設定，也要確認之後更新設定時會不會覆蓋這項修改。

  1. 記下無法連線的網域及完整錯誤訊息，並確認是所有網站還是特定網域有問題。
  2. 記下使用 Wi-Fi 或行動網路、Global Routing 狀態、目前設定檔及伺服器；對外回報時請隱去敏感位址和憑證資訊。
  3. 記錄修改 dns-server 前後的值，以及 A、AAAA 是否取得位址。
  4. 記錄請求命中的規則、策略和最終失敗階段，區分 DNS、連線、TLS 與 HTTP 回應。
  5. 說明是哪一項單獨修改讓現象改變；不要提供完整訂閱連結、token 或密碼。

若要繼續排查連線問題，可查看問題診斷；不確定關鍵字的意思時，可參閱術語表。保留這次單一變因測試的紀錄，比連續更改多組設定更容易重現及判斷。

前往 App Store