Shadowrocket DNS 設定詳解：系統 DNS、自訂 DNS 與 DNS over HTTPS 如何選擇

本文重點

系統 DNS 適合作為目前網路的排查基準，自訂 DNS 可明確指定解析器，DNS over HTTPS 則能加密用戶端與解析器之間的查詢。本文適合已備妥自己的服務商與訂閱、正在使用 Shadowrocket（小火箭）的使用者，說明如何在 Config 中修改 General 區段、區分解析問題與連線問題，以及如何驗證並還原 DNS 設定。

一、先區分 DNS 解析與網站連線

DNS 的用途是將網域名稱解析為 IP 位址，例如查詢 A 記錄取得 IPv4 位址，或查詢 AAAA 記錄取得 IPv6 位址。取得位址後，瀏覽 HTTPS 網站仍須建立連線、完成 TLS 交握並取得內容。因此，「DNS 有回應」不代表「網頁一定能開啟」；「網頁無法開啟」也不代表「DNS 一定有問題」。

發起網域連線查詢解析器取得位址建立連線取得內容

這個流程有助於拆解問題，但不代表所有請求都在本機完成解析。Shadowrocket 的實際解析位置也會受到請求類型、規則與 Proxy 出站方式影響；部分連線可能會將目標網域交由遠端處理。不能只因本機設定了 DNS 位址，就認定所有網域都由該解析器處理。

排查時，先到 Home 確認目前使用的伺服器，再查看 Global Routing。Config 會依目前設定處理分流；Proxy 與 Direct 會改變全域路由模式；Scene 則依所選情境的設定運作。比較 DNS 時應維持相同模式，避免同時變更出站方式與解析器，導致無法判斷是哪項設定造成影響。

查詢逾時：先確認解析器是否可連線，以及目前網路是否限制對應的傳輸方式。
收到 NXDOMAIN：表示解析器回報網域不存在，與網路逾時不同；也應檢查網域拼字及記錄狀態。
已取得位址但連線失敗：接著檢查規則命中、出站連線、IPv4/IPv6 路徑與 TLS，不要一再更換 DNS。

二、系統 DNS、自訂 DNS 與 DoH 的差異

本文所稱的「自訂 DNS」特指直接填入解析器 IP 的傳統 DNS，用來與 HTTPS 端點區分；就設定方式而言，自行填入 DoH 端點也屬於自訂設定。選擇時應考量網路環境、解析器是否可連線，以及查詢所需的傳輸方式，而非名稱聽起來是否更進階。

方式	解析路徑	適用情境	檢查重點
系統 DNS	使用系統目前可用的解析器，通常會受到目前 Wi-Fi 或行動網路影響。	建立排查基準，或需要目前網路提供的內部網域解析。	切換網路後，解析器與解析結果可能改變。
自訂 DNS	將傳統 DNS 查詢傳送至指定的解析器 IP。	需要固定使用某個解析器，且該位址可透過目前網路連線。	UDP/TCP 53 是否可連線，以及解析器是否允許目前來源查詢。
DNS over HTTPS	將 DNS 查詢封裝在 HTTPS 請求中，傳送至 DoH 端點。	需要加密查詢傳輸，且 HTTPS 端點與憑證皆可正常使用。	完整端點路徑、TLS 憑證、端點網域的初始解析，以及實際路由。

傳統 DNS 通常使用 UDP/TCP 連接埠 53

443

HTTPS 未指定連接埠時，預設使用 443

2 種

位址記錄：A 對應 IPv4，AAAA 對應 IPv6

DoH 加密的是用戶端與解析器之間的傳輸。解析器仍會處理並看見收到的查詢；網站連線也仍須遵循各自的出站路徑。啟用 DoH 不會自動將所有流量改為 Proxy，也不能取代對規則與伺服器狀態的檢查。

結論：先確認連線可用，再決定是否使用 DoH

若系統 DNS 能穩定解析，但 DoH 查詢逾時，請先檢查端點與 TLS 路徑；不要同時變更 Global Routing。若需要解析內部網域，先保留系統 DNS 的測試結果，再確認外部解析器是否提供相同記錄。

三、在 Config 中修改 dns-server

dns-server 應寫在設定檔的 [General] 區段，不要放在 [Rule] 區段。以下每個程式碼區塊都是獨立方案，不應直接將三個區塊合併成同一個檔案。修改現有設定時，保留原有規則與其他欄位，只替換本次要測試的 DNS 設定。

在 Config 中確認目前啟用的設定檔，先儲存一份本機副本，並記下原本的 dns-server 值。
開啟該檔案的編輯介面，找到 [General]。若已有 dns-server，請修改原有那一行，避免留下重複的鍵。
每次只選擇一種方案。儲存後確認目前啟用的仍是這份檔案；只編輯未啟用的副本不會改變目前連線。
返回 Home，先中斷連線再重新連線，讓新連線使用儲存後的設定進行測試。先前已建立的連線與快取可能仍會影響觀察結果。

方案 A：使用系統 DNS

[General]
dns-server = system

[General]：宣告一般設定區段。
dns-server = system：使用系統目前可用的 DNS，適合作為與自訂設定比較的基準。

方案 B：指定傳統 DNS 位址

[General]
dns-server = 192.0.2.53

[General]：仍使用一般設定區段，不必另外建立名為 DNS 的區段。
dns-server = 192.0.2.53：示範直接填入 IPv4 位址的語法。此位址屬於文件範例網段，並非可用的解析器；測試前必須換成自己有權使用且已確認可連線的解析器位址。

方案 C：指定 DoH 端點

[General]
dns-server = https://dns.example.com/dns-query

[General]：與前兩種方案相同的設定區段。
https://：指定使用 HTTPS 傳輸；不可省略後再假設 App 會以 DoH 處理。
dns.example.com：範例網域，並非本文提供的 DNS 服務；實際設定時應填入自己已有的解析服務端點。
/dns-query：常見的 DoH 路徑，但並非每個端點都使用此路徑。請依解析服務提供的完整網址填寫，不要自行補上或截短。

四、分開檢查解析設定、規則與 Host

DNS 負責取得位址，規則負責選擇請求策略，Host 則可能為特定網域指定固定對應。三者影響的階段不同。若設定中已有 Host 對應，某個網域可能不會如預期向上游查詢；若 App 保留了舊位址，立即重新整理頁面也可能看不出變化。

解析設定檢查

入口: Config → 目前啟用的檔案 → 編輯
設定區段: [General]
欄位: dns-server
對應檢查: [Host] 中是否有目標網域

先確認正在測試的檔案，再檢查是否有固定對應影響結果。

路由模式檢查

入口: Home → Global Routing
Config: 依目前設定處理分流
Proxy / Direct: 用來確認全域出站模式
Scene: 確認所選 Scene 的實際設定

測試 DNS 時維持路由模式不變，不要在同一次測試中混合變更解析器與出站方式。

例如，DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對位址網段，GEOIP 依據 IP 地理資料庫比對，FINAL 則處理前面規則都未命中的請求。使用 IP 類規則時，應配合解析結果與規則選項檢查實際命中狀況；網域規則命中不能直接作為 DNS 解析成功的證據。

網域規則：先確認目標網域與後綴是否相符，再檢查最終策略。
IP 類規則：記錄實際目標位址；解析結果不同可能影響位址規則的命中。
Host 對應：若目標網域已有固定位址，先確認該對應是否仍符合用途。
FINAL：這是路由的最終規則，不是 DNS 查詢失敗時的備用解析器。

五、變更後的驗證步驟與記錄方式

驗證時應遵循「相同網路、相同目標、相同路由模式、只改一個欄位」的原則。選擇自己有權存取且正常維護的目標網域，先記錄系統 DNS 的表現，再測試傳統 DNS 或 DoH。不要只憑一次開啟頁面的速度判斷解析器優劣：連線重用、頁面快取與網站回應時間都可能掩蓋解析差異。

建立基準：記錄 Wi-Fi 或行動網路、Home 目前使用的伺服器、Global Routing 模式、已啟用的 Config 檔案，以及目標網域。
儲存並重新連線：只修改 dns-server，儲存設定後重新連線。結束目標 App 中的舊請求，再重新連線至網域。
檢查解析結果：在 App 可用的 DNS 查詢工具或記錄中查看目標網域的結果。記錄 A、AAAA、逾時或錯誤回應；若工具可另外選擇解析器，也要確認使用的是本次要測試的解析器。
檢查連線：接著確認實際請求是否成功、命中了哪項策略，以及是否出現連線或 TLS 錯誤。不要只記下一個延遲數值。
測試不同網路：完成同一網路中的比較後，再分別測試 Wi-Fi 與行動網路。若只有其中一種網路失敗，應優先檢查該網路的連線可用性差異。

觀察到的情況	下一步檢查	不應直接下的結論
傳統 DNS 逾時，DoH 有回應	檢查目前網路至解析器的 UDP/TCP 53 路徑。	不能因此認定所有網站連線都正常。
DoH 回報 TLS 錯誤	檢查端點網域、憑證效期、系統時間與連線路徑。	不能把憑證錯誤當成一般的 DNS 速度較慢。
A 有結果，AAAA 沒有結果	確認網域是否提供 AAAA；區分沒有記錄與查詢逾時。	沒有 AAAA 記錄不代表 DNS 整體故障。
已取得位址，但網頁仍逾時	檢查規則命中、目前的出站方式，以及回傳位址是否可連線。	不能認定更換解析器就一定能解決問題。
變更後結果完全相同	檢查啟用的檔案、Host 對應、快取與舊連線。	結果相同本身不能證明設定變更未生效。

結論：依據查詢結果與連線結果兩項證據判斷

只有解析回應正常且實際連線成功，才能認定這次設定符合目前用途。若只在某個網路發生問題，先保留該網路的錯誤記錄，再還原至已驗證的設定，並單獨檢查失敗環節。

六、常見問題與安全還原

填入多個解析器後，一定會依序自動備援嗎？

不能只依書寫順序推斷查詢順序、並行方式或失敗後的備援行為。初步排查時，建議只保留一個已確認可連線的解析來源；確認有效後，再依實際設定需求調整。同時混用系統 DNS、傳統 DNS 與 DoH，會更難判斷某次回應來自哪個解析器。

啟用 DoH 後，查詢一定會經過 Proxy 嗎？

不一定。DoH 描述的是查詢傳輸方式，並不等同於路由策略。實際路徑還須配合目前的設定、Global Routing 與 DNS 相關選項檢查。僅憑 https:// 無法證明查詢經過特定出站方式，也不能證明所有 App 都使用這條解析路徑。

切換 Wi-Fi 後再次發生問題，該檢查什麼？

先確認系統 DNS 是否隨網路切換，以及自訂端點在新網路中是否可連線。若已設定 Settings → On Demand，也應檢查按需連線條件，確認測試時的連線狀態未受自動規則影響。On Demand 管理連線觸發條件，不能取代 dns-server。

如何還原變更前的設定？

在 Config 中還原原本的 dns-server 行，或重新啟用先前儲存的本機副本，再返回 Home 重新連線。若原檔案沒有這個欄位，還原時就維持原狀，不要自行新增猜測值。接著使用相同目標重新測試，確認還原效果；之後每次只變更一項。

DNS 設定的目的，是取得符合用途且可驗證的解析結果，而非追求某一種方式適用於所有網路。系統 DNS、傳統自訂 DNS 與 DoH 都應配合實際網路檢查；保留設定檔副本與測試記錄，比頻繁切換多項設定更有助於找出問題。