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

比較系統 DNS、自訂 DNS 與 DNS over HTTPS,了解適用情境、對規則比對與網域解析的影響,以及解析異常時的排查順序。

本文重點

在 Config 確認目前啟用設定中的 DNS 欄位,再依使用的網路決定保留系統解析、指定解析器,或使用 DNS over HTTPS。本文適合已有自己的服務供應商與設定,並需要處理網域解析或分流異常的使用者;操作時一次只修改一項,分別確認解析結果、規則命中與實際連線,避免混為一談。

先分清 DNS 解析與連線分流

在 Home 確認目前連線狀態與 Global Routing,再到 Config 檢查正在使用的設定。Shadowrocket(小火箭)的 DNS 設定會影響部分網域查詢的處理方式;Global Routing 和規則則決定連線採用哪種策略。變更解析器不代表所有請求的連線出口都會改變。

網域請求 解析處理 位址結果 策略判定 建立連線

這個流程是用來區分排查階段,並不表示每次請求都會逐步觸發新的 DNS 查詢。App、系統和解析器都可能快取結果;網域規則也可能在需要解析位址之前就判定策略。部分連線會在遠端處理網域,不能假設所有請求都會先在本機取得 IP 位址。

在 Global Routing 使用 Config 時,應搭配規則判斷請求的去向。Proxy 和 Direct 代表整體路由模式,不能只看其中一個選項就推定 DNS 查詢的實際路徑;Scene 則需另外確認該場景套用的設定。排查時先固定路由模式,不要一邊修改 DNS、一邊切換場景。

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

先記下目前網路中可正常存取的網域,再比較這三種方式。系統 DNS 使用系統可用的解析環境;自訂 DNS 是指定解析目標;DNS over HTTPS(DoH)則表示查詢透過 HTTPS 傳輸。後兩者並不互斥,指定 DoH 位址同樣屬於自訂 DNS 設定。

方式 設定內容 適用情況 注意事項
系統 DNS system 目前網路解析正常,或需要解析網路內部網域 切換 Wi-Fi 與行動網路後,解析環境可能不同
自訂傳統 DNS 已確認可用的解析器 IP 位址 需要固定查詢目標,且該目標在目前網路中可連線 傳統 DNS 查詢通常未加密
DNS over HTTPS 完整的 https:// 端點 需要透過 HTTPS 傳送查詢,且端點可連線 端點路徑、TLS 憑證及首次解析依賴
53
傳統 DNS 常用連接埠,可使用 UDP 或 TCP
443
DoH 預設使用 HTTPS 連接埠,端點也可明確指定其他連接埠

若需要存取路由器管理網域、公司內部服務或其他區域網路名稱,應先保留網路提供的解析路徑。公用解析器通常無法解析內部名稱;若將所有查詢都改由外部解析器處理,可能出現公用網站正常、內部服務卻無法使用的情況。

結論:先保留可用基準,再更換解析目標

如果目前使用系統 DNS 解析正常,先儲存設定副本;只有在確定需要固定解析目標或透過 HTTPS 傳輸查詢時才更換,並在相同網域、相同網路下再次確認結果。

在 Config 確認 dns-server 與 DoH 位址

在 Config 找到目前啟用的設定,先儲存副本,再開啟編輯畫面。若使用文字編輯,請在 [General] 中找到 dns-server;如果已有這個欄位,請修改原有值,不要在同一區段新增多個同名欄位,以免無法判斷實際生效的內容。

[General]
dns-server = system

上例表示使用系統 DNS。若要改用指定解析器,請將值換成已確認可連線的位址;若要使用 DoH,請填入服務提供者給的完整 HTTPS 端點,不要只填網域,也不要在一般 DNS IP 前加上 HTTPS 前綴。

系統解析基準

路徑
Config → 目前設定 → 編輯畫面
設定區段
[General]
欄位
dns-server = system
驗證環境
先保持使用同一個 Wi-Fi 或行動網路

儲存後確認啟用的是這份設定,再重新連線測試。

確認 DoH 端點

欄位
dns-server
位址格式
https://example.com/dns-query
預設連接埠
HTTPS 使用 443
安全條件
主機名稱須與憑證相符,且路徑支援 DoH

example.com 位址僅用來示範格式,並非可用的解析服務。

儲存後回到 Config,確認修改的設定已啟用,再到 Home 重新連線。只編輯未啟用的檔案,不會讓目前連線自動依預期改變。若設定由遠端來源維護,更新後還需再次確認欄位;直接修改遠端內容的本機副本,後續更新時可能會被覆寫。

  1. 記下原本的 dns-server 值與目前啟用的設定,並保留可還原的副本。
  2. 一次只更換一個解析目標,不要同時修改規則、協定參數或連線策略。
  3. 儲存、啟用並重新連線,再使用相同網域重新確認。
  4. 如果結果變差,還原原值後再測試,確認變化是否由 DNS 設定造成。

DoH 端點若使用網域名稱,建立 HTTPS 連線前仍須先取得端點本身的位址,這會涉及首次解析依賴。不要讓端點位址的取得完全仰賴尚未建立的同一條 DoH 查詢通道;應保留設定支援且可用的引導解析路徑,並查看記錄確認失敗發生在哪個階段。

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

在 Config 檢查規則順序時,先區分以網域比對與以 IP 位址比對的規則。DOMAIN-SUFFIX 依網域後綴判斷;GEOIP 和 IP-CIDR 則依位址判斷。若規則判斷需要取得目標位址,DNS 回傳的結果可能影響比對;若已命中網域規則,就不需要再判斷後續的 IP 規則。

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

以下語法僅用來說明規則順序,不應整段取代現有設定。第一行會將符合 example.com 網域後綴的請求交由 DIRECT 處理;第二行比對相應的私人位址範圍,no-resolve 表示不要為了這條規則主動觸發網域解析;第三行使用位址歸屬資料;最後由 FINAL 處理前面未命中的請求。實際策略必須符合設定中可用的策略。

依序排查:逾時、空結果與網頁無法開啟

在同一個網路中重現異常,並記下網域、時間、目前設定與 Global Routing。接著查看可用的連線記錄或日誌,先確認是否取得解析結果,再判斷連線階段是否成功;不要把所有失敗都歸因於 DNS。

  1. 確認網路本身可正常使用。若 Wi-Fi 需要網頁認證,請先完成認證。若 Wi-Fi 異常但行動網路正常,優先比較兩種網路的解析器連線能力與網路限制。
  2. 確認設定確實生效。回到 Config 查看啟用中的項目,並再次確認 dns-server。若系統會自動重新建立連線,可到 Settings → On Demand 確認自動連線條件,避免誤判測試時的連線狀態。
  3. 區分查詢失敗類型。逾時表示等待期間未收到所需回應;NXDOMAIN 表示解析器認為網域不存在;SERVFAIL 表示解析器無法完成處理。這三種情況不能用同一個原因解釋。
  4. 單獨檢查 DoH 的 HTTPS。確認完整路徑、裝置時間、端點憑證與連線能力。能開啟端點所屬網站,不代表填入的路徑支援 DoH;也不應透過放寬驗證來掩蓋憑證錯誤。
  5. 已取得位址時,改查連線問題。若解析已回傳 A 或 AAAA,但後續連線逾時,應檢查目標連接埠、IPv4/IPv6 連線能力、命中策略及使用者原有的連線參數,而非繼續更換解析器。
  6. 還原基準進行比對。改回已儲存的系統解析設定,重新連線後再次測試。若還原後仍然失敗,就應擴大排查範圍,而不是不斷疊加 DNS 變更。

兩次測試之間,可關閉後重新開啟用來驗證的 App;必要時等待 DNS 記錄的 TTL 到期。重新連線不保證清除所有層級的快取;短時間內同一網域回傳相同結果,也不足以證明設定變更沒有生效。

記錄測試結果時,分別寫下「是否取得位址」、「回傳哪種位址」、「命中哪條策略」及「連線在哪個階段失敗」。這比只記錄「可以用」或「不能用」更容易找出問題。若要進一步檢查連線過程,請參閱連線問題排查說明。

DNS 設定常見問題

改用 DoH 後仍無法開啟網頁,接下來該檢查什麼?

先在 Config 確認啟用中的設定與端點完整位址,再重新連線並查看失敗階段。若已取得目標位址,請改查規則命中與目標連線;若端點出現 TLS 錯誤,請確認裝置時間與憑證,不要把停用驗證當成一般修復方式。

Wi-Fi 正常,切換到行動網路後解析逾時,該怎麼辦?

使用相同設定與網域,分別記錄兩種網路下的結果。若自訂位址屬於區域網路,例如路由器的私人位址,行動網路通常無法直接連線;改回 system 進行比對,再決定是否需要改用兩種網路都能連線的解析目標。

設定 DoH 就能確保所有 DNS 查詢都經過加密嗎?

不能只根據單一欄位判斷。該欄位描述的是相應的查詢通道;App 自行處理的解析、端點首次解析及其他解析路徑仍須分別確認。先查看目前設定與實際查詢記錄,再判斷觀察到的請求是否使用預期通道。

更新現有設定後,手動填寫的 DNS 又變了,該怎麼辦?

到 Config 比較更新前後的檔案,確認修改的是遠端設定還是獨立的本機副本。若要保留個人設定,請先備份,再維護明確啟用的本機副本;後續同步規則時逐項比較,避免將連線參數與 DNS 變更混在一起。

完成驗證後,保留一份可用的基準設定與本次修改記錄。DNS 的選擇應依據網路連線能力、內部名稱需求與查詢傳輸要求,不應以解析器數量判斷效果;同時填入多個目標,也不代表一定會嚴格依照書寫順序逐一嘗試。

App Store 正版入口確認開發者與 App ID