2026-09-24 · DNS 與網路 · 約 9 分鐘

Shadowrocket DNS 設定教學：系統 DNS、自訂 DNS 與 DNS over HTTPS

了解系統 DNS、自訂 DNS 與 DNS over HTTPS 的差異、適用情境，以及 DNS 解析結果如何影響規則比對；並學會確認設定是否生效。

本文重點

Shadowrocket（小火箭）的 DNS 設定負責網域名稱解析，與代理連線出口的選擇不同。本文假設你已有可用的連線設定，先以系統 DNS 建立基準，再說明何時改用自訂 DNS 或 DNS over HTTPS、如何辨識設定遭覆寫，以及如何透過解析紀錄與規則命中情形確認修改結果。

一、先分清解析伺服器、查詢傳輸方式與連線出口

開啟網站前，裝置通常需要先將網域名稱解析為 IP 位址。DNS 負責回答「這個名稱對應哪些位址」；Global Routing 和規則則決定「這條連線要經由哪條路徑存取」。兩者會互相影響，但修改 DNS 不會自動將網站流量改為 PROXY，也不會取代你已有的連線服務。

「系統 DNS」和「自訂 DNS」主要差異在於解析伺服器的來源；DNS over HTTPS（DoH）描述的則是查詢的傳輸方式。因此，自訂 DNS 也能使用 DoH，並非只能在三種互斥選項中擇一。以下依實際設定方式分成三類，方便安排測試順序。

53
傳統 DNS 通常使用 UDP 或 TCP 的 53 埠
443
DoH 通常透過 HTTPS 的 443 埠傳輸
A / AAAA
分別回傳 IPv4 位址與 IPv6 位址

埠號只是常見慣例，不能據此確認服務可用。DoH 需要正確的 HTTPS endpoint、有效憑證，以及可連通的網路路徑；能透過 HTTPS 開啟一般網頁，不代表同一主機也提供 DNS 查詢介面。本文的保留位址與範例網域僅用來說明格式，不是可用的解析服務。

二、如何選擇系統 DNS、自訂 DNS 與 DoH

系統 DNS：建立排查基準

建議

沿用系統目前可用的解析設定，通常會隨網路連線環境而異。從 Wi-Fi 切換至行動網路後，實際的解析環境可能改變；系統安裝的 DNS 設定也可能會參與解析，因此不能一概視為路由器位址。

適用情境：首次驗證、還原預設行為，或確認問題是否由自訂設定造成

自訂 DNS：指定固定的解析目標

明確指定解析伺服器，減少切換網路時的變因。若填入一般 IP 位址並使用傳統 DNS，查詢不會因為「自訂」而加密；此外，解析伺服器也必須能從實際查詢路徑連線。

適用情境：已有明確的解析伺服器、需要解析內網網域，或想重複比對測試結果

DNS over HTTPS：加密查詢傳輸

將 DNS 查詢封裝在 HTTPS 中，保護用戶端與解析服務之間的查詢傳輸。這不會隱藏解析服務本身看到的查詢，也不保證網站連線出口、最終連線品質或解析結果一定符合預期。

適用情境：已有可信且可連線的 DoH endpoint，並需要加密 DNS 傳輸

結論：先確認預設解析，再單獨更換 DNS

先記下使用系統 DNS 時的連線結果，再只修改解析方式；不要同時更換伺服器、Global Routing 和規則檔，否則即使恢復連線，也無法判斷是哪項修改生效。

DoH 不代表「所有 DNS 查詢都會經過代理」。查詢走直連還是代理，必須依目前設定與實際紀錄判斷。如果 endpoint 無法連線，或其主機名稱無法完成初始解析，啟用 DoH 反而可能導致多個網站同時發生解析逾時。

三、修改前先確認 Settings 與 Config 中的有效設定

先在 Home 記下目前使用的伺服器和 Global Routing，再查看 Settings → DNS 中已有的設定，並前往 Config 確認目前選用的設定檔。啟用中的設定檔可能包含自己的 DNS 參數；不要只因某個輸入欄位已變更，就認定所有連線都使用新解析器。介面分組和設定檔提供的選項可能不同，請以實際顯示的項目為準。

  1. 記下原始設定。記錄目前的 DNS 位址、啟用中的 Config 名稱和路由模式，並保留可還原的設定檔副本。如果設定檔由訂閱或遠端檔案管理，先確認後續更新是否會覆蓋本機修改。
  2. 建立基準。固定使用同一個 Wi-Fi、同一台伺服器和同一個測試網域，以系統 DNS 存取一次，記錄成功、逾時或解析錯誤；不要只記錄頁面載入速度。
  3. 選定一個修改位置。使用 Settings 中的 DNS 設定，或編輯自己管理的啟用中 Config；避免在多個位置填入含義不同的設定，再猜測哪一項優先。
  4. 確認格式正確。一般 DNS 請輸入伺服器位址；DoH 則需輸入完整的 HTTPS endpoint，路徑也必須符合解析服務的說明。請勿將訂閱網址或網站首頁當成 DNS endpoint。
  5. 重新建立連線。儲存後中斷連線，再重新連上 Shadowrocket，關閉舊網頁連線，然後重新存取網域。接著用紀錄確認這次的請求，不要依舊有工作階段判斷結果。

在自己管理的文字設定檔中，以下列出三種 dns-server 寫法。每次只保留一種，不要將三個 [General] 區段合併複製。系統 DNS 寫法可用來還原基準；另外兩項僅供說明格式，不能直接使用，必須替換為你已有且已確認的解析資訊。

# 系統 DNS
[General]
dns-server = system

# 自訂 DNS：192.0.2.53 為文件保留位址
[General]
dns-server = 192.0.2.53

# DoH：example.com 僅用於示範 endpoint 格式
[General]
dns-server = https://example.com/dns-query

四、DNS 結果如何影響 DOMAIN-SUFFIX、GEOIP 與 IP-CIDR

網域規則與 IP 規則檢查的對象不同。DOMAIN-SUFFIX 檢查網域及其子網域；IP-CIDR 檢查目標 IP 是否位於指定網段；GEOIP 則依據 IP 資料庫分類。DNS 回傳不同位址時，後兩類規則可能產生不同結果，但網域後綴本身不會因此改變。

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

驗證這類規則前，請先在 Home → Global Routing 選擇 Config。Proxy 與 Direct 不會依照這份 Config 規則清單進行相同的分流；若使用 Scene，還需要確認目前場景實際採用的設定。否則，看到的出口變化可能是模式改變所致，而不是 DNS。

同一個網域回傳不同 IP，不代表解析一定異常。CDN 調度、快取、解析器所在位置，以及 A / AAAA 查詢類型都可能造成差異。應分開記錄「回傳了哪個位址」、「命中了哪條規則」和「最後連線到哪裡」，而不是要求每次的答案完全一致。

五、修改後如何確認生效：分別測試解析與連線

「網頁開得起來」只能證明這次存取成功，不能單獨證明 DoH 已生效。瀏覽器可能沿用舊連線，裝置、應用程式或解析器也可能保留快取。優先使用自己能控制、也能查看查詢紀錄的測試網域；若無法控制網域，至少記下測試時間，並區分新舊紀錄。

測試方式：使用相同設定，分別測試兩種網路

在 Wi-Fi 下測試
  • 固定伺服器、Config 和 Global Routing，不要同時修改規則。
  • 重新連線後存取測試網域，記錄 A / AAAA 結果與解析錯誤。
  • 確認 endpoint 是否可連線，並留意內網網域是否仍能解析。
在行動網路下重新測試
  • 只切換網路，保留相同的 DNS 參數。
  • 重新送出請求，比較是否只有其中一種網路發生逾時。
  • 若解析結果正常但連線失敗，請接著檢查規則、連線出口與 IPv6 路徑。

兩種網路都測試成功後，再保留新設定；若只有其中一種網路失敗，優先檢查該網路連往解析服務的路徑。

  1. 先查看解析紀錄。在可用的 DNS 或連線日誌中尋找這次測試的網域，核對時間、回傳位址和錯誤。如果日誌未顯示解析伺服器或傳輸方式，就不能只憑這份日誌斷定使用了 DoH。
  2. 接著查看規則命中情形。確認紀錄中的策略與規則行一致。例如網域原本應命中 DOMAIN-SUFFIX，卻落入 FINAL，就要檢查實際請求的網域和啟用中的 Config。
  3. 最後檢查連線結果。已有有效位址，但 TCP 連線逾時或 TLS 交握失敗時，通常還需要檢查連線路徑與目標網站；不要將所有錯誤都歸因於 DNS。
  4. 必要時還原設定進行比對。還原原本的 DNS，其他設定維持不變，再測試同一個網域。若還原後立即恢復正常，才有依據進一步檢查新解析服務或 endpoint 路徑。

若要證明查詢確實經由 DoH 傳送，最直接的證據是解析服務端的請求紀錄，或明確顯示 HTTPS 查詢目標的診斷資訊。解析時間縮短、回傳位址改變，或瀏覽器顯示安全鎖頭，都不能取代這類證據。

六、常見問題：逾時、內網網域與更新覆寫

填入 DoH 位址後，所有網站都打不開怎麼辦？

先還原已保存的系統 DNS 基準並重新連線。確認能正常存取後，逐項檢查 endpoint 的完整路徑、憑證、埠號和可連線性；若主機名稱本身無法解析，也要檢查初始解析條件。不要一次加入多個未知 endpoint，讓問題更難判斷。

網頁正常，但公司內網網域打不開，該更換 DNS 嗎？

先確認裝置已連上所需的內網，再確認該網域是否只能由內網 DNS 回應。公共解析服務通常沒有企業內部紀錄；請還原內網可用的解析方式，或依組織提供的網域分流要求設定。不要將內部網域交給無關的解析器反覆測試。

修改設定後，為什麼日誌裡仍是舊 IP？

先核對紀錄時間，關閉舊網頁工作階段並重新連線，再送出新請求。快取尚未到期或應用程式沿用舊連線時，可能看不到新的 DNS 查詢。若仍未改變，請回到 Config 確認實際選用的設定檔，不要反覆填入相同位址。

只有部分網站連不上，需要停用 IPv6 嗎？

先分別查看 A 與 AAAA 的結果，再核對失敗連線實際使用的位址類型。AAAA 有回應，不代表目前的連線出口具備可用的 IPv6 路徑。只有在紀錄支持這項判斷時，才進行單一變因對照；不要以全域停用 IPv6 取代問題定位。

為什麼更新後 DNS 又恢復原狀？

前往 Config 查看啟用中的設定檔是否由遠端更新，並與更新前保存的副本比對。節點訂閱更新和完整設定檔更新並非同一回事，請先確認更新的對象。若要長期保留本機 DNS 修改，應管理自己的設定檔副本，並明確規劃後續合併方式。

排查期間若連線狀態自動改變，也應檢查 Settings → On Demand，確認是否設有自動連線條件。測試時記下目前狀態，避免手動中斷後立即重新連線而誤判；測試結束後再恢復原有的自動連線設定。

保留設定的標準是：目標網路下解析穩定、所需的內網網域可正常使用、規則命中符合預期，而且能還原原始設定。DNS over HTTPS 解決的是查詢傳輸方式，不能取代對伺服器連線狀況、Global Routing 和規則順序的檢查。

前往 App Store