Shadowrocket DNS 設定：系統 DNS、自訂 DNS 與 DoH 怎麼選

本文重點

先保留目前可正常使用的 DNS 作為基準，再依需求選擇解析器與傳輸方式。本文適合已在 Shadowrocket 使用自有設定的使用者，說明系統 DNS、自訂 DNS 與 DoH 的差異、設定檢查順序，並分別處理解析失敗、規則比對與目標連線失敗。

先分清解析器位址與 DNS 傳輸方式

DNS 用來將網域名稱解析為 IP 位址等記錄。系統 DNS 是裝置從目前網路或系統設定取得的解析設定；自訂 DNS 是自行指定解析器；DNS over HTTPS（簡稱 DoH）則是指透過 HTTPS 傳送 DNS 查詢。因此，「自訂 DNS」與「DoH」並非互斥選項，自訂解析器也可以使用 DoH。

選擇時先釐清兩件事：要將請求交給哪個解析器，以及透過什麼連線傳送。更換解析器可能改變回傳的位址；更換傳輸方式則會改變查詢的傳輸路徑與保護方式。兩者都不會修改網頁本身的 HTTPS 設定，也無法保證一定能連上目標網站。

方式	運作方式	優先確認事項
系統 DNS	使用目前系統取得的解析設定；實際請求路徑仍會受到隧道與設定影響。	切換 Wi-Fi 或行動網路後，解析結果與內網網域是否有所變化。
自訂 DNS	將查詢交給指定的解析器；使用一般 DNS 時，通常會透過 UDP 或 TCP 的 53 埠。	確認位址是否可連線、連接埠是否可用，以及是否需要解析內網網域。
DNS over HTTPS	透過 HTTPS 將 DNS 訊息傳送至解析端點。	確認完整 URL、憑證、端點網域的初始解析，以及實際連線路徑。

判斷原則：先保留可用基準，每次只更動一項

如果目前網路可正常解析，先記錄系統 DNS 的結果；需要固定解析器時再設定自訂 DNS，需要加密查詢傳輸時再測試 DoH。不要同時更改解析器、Global Routing 與代理設定，否則無法判斷是哪項變更影響結果。

DNS 查詢與網頁連線是兩個檢查階段

一般網域存取時，應用程式需要先取得目標位址，再建立連線。實際過程可能使用快取，也可能由應用程式自行解析或交由代理端解析，因此不能假設每次存取都會在本機完成以下所有步驟。

網域請求解析處理回傳位址路由判斷目標連線

排查時，分別記錄「是否取得解析結果」和「取得結果後是否連線成功」。有回傳位址，代表該次查詢已收到回應；但位址是否適用於目前的連線出口、目標連接埠是否可連線，以及 TLS 是否成功，仍須進一步確認。瀏覽器顯示網頁無法開啟，不能單憑這個現象判定是 DNS 故障。

一般 DNS 常用連接埠，可使用 UDP 或 TCP

443

HTTPS 預設連接埠，DoH 端點通常使用此連接埠

連接埠可連線只是必要檢查之一。DoH 還需要正確的 HTTPS 路徑與有效憑證；將一般 DNS 位址的連接埠從 53 改成 443，並不會自動變成 DoH 服務。反過來說，DoH 加密的是傳送至解析端點的查詢，解析器仍看得到查詢內容，也不會自動讓所有網路連線都透過代理傳出。

變更前先備份，並確認目前設定是否參與 DNS 處理

在 Shadowrocket 中，先從 Home 確認目前的連線狀態與 Global Routing，再前往 Settings → DNS 檢查解析設定。同時到 Config 查看目前使用的設定檔：檔案中的 DNS 項目也可能影響實際行為，不能只因 Settings 填入某個位址，就認定最終使用的是該解析器。實際欄位與可選項目請以 App 目前顯示為準。

保留原始設定。記下現有 DNS 項目、目前的設定檔名稱與 Global Routing 選項。修改設定檔前先保留副本，以便逐項還原。
確認基準狀態。在目前網路上存取一個已知可正常使用的公網網域；若需要存取內網資源，也選一個實際使用的內網網域作為對照。
只更改 DNS。使用現有且已獲准使用的解析器參數，不要同時更換伺服器、規則與協定參數。
重新建立連線。儲存後中斷並重新連線，再重新發起存取。既有連線與快取可能仍使用舊結果，不要只重新整理一次頁面就下結論。
依網路分別確認。在實際使用的 Wi-Fi 與行動網路上分別測試；若已設定 Settings → On Demand，測試期間也要確認是否發生自動重新連線。

一般 DNS 參數檢查

位址格式: 解析器 IP 位址
文件範例: 192.0.2.53
常用連接埠: UDP / TCP 53
檢查重點: 可連線性、內網解析需求與實際連線路徑

192.0.2.53 是文件範例位址，不能直接當作實際解析器使用。

DoH 參數檢查

位址格式: 完整 HTTPS URL
文件範例: https://dns.example.com/dns-query
常用連接埠: HTTPS 443
檢查重點: 路徑、憑證、端點初始解析與可連線性

範例端點不提供解析服務；實際 URL 應使用你現有解析服務提供的完整參數。

如果 DoH 端點使用網域名稱，建立 HTTPS 連線前也需要先取得該網域的位址，這通常稱為初始解析或 bootstrap。不可讓端點唯一的解析來源依賴尚未建立的同一條 DoH 連線。若目前設定涉及這類依賴，應檢查初始解析的安排，而不是反覆填入相同 URL。也不要任意將端點網域名稱換成 IP，否則可能導致憑證名稱驗證失敗。

DNS 與分流規則的關係：回傳位址不等於符合路由策略

Home → Global Routing 中的 Config 會依目前設定檔中的規則處理流量；Proxy 與 Direct 是不同的全域路由選項，不能以它們的測試結果取代 Config 下的規則驗證。使用 Scene 時，也要先確認該場景實際生效的路由設定。DNS 查詢的傳輸路徑與目標連線套用的策略，應分開檢查。

網域規則依據可用的網域資訊比對，IP 規則則依據目標位址比對。對需要判斷 IP 的流量，解析結果可能影響後續規則比對；但這不代表所有規則都必須先完成一次本機 DNS 查詢。例如，應用程式直接請求 IP 時，可能沒有可供比對的原始網域名稱。

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

DOMAIN-SUFFIX,example.com,PROXY 用來比對 example.com 及其子網域，並交由指定策略處理。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve 展示位址網段規則；no-resolve 表示不會為了比對此規則而主動觸發網域解析。
GEOIP,CN,DIRECT 依據位址歸屬資料庫進行比對，不是根據網域文字判斷。
FINAL,PROXY 是未符合前面規則時的後備規則。規則順序會影響結果，通常由上往下檢查。

以上僅為語法說明，範例網域與網段皆供文件說明使用，不能直接套用為完整設定。若更換 DNS 後，某次存取符合了不同的 IP 規則，應先比較回傳位址，再檢查規則順序；不要為了修正單一網域就直接刪除所有規則。如果解析器請求也必須透過代理，還要檢查是否形成「連線代理前必須先解析，但解析又依賴該代理」的循環依賴。

依現象排查解析失敗，別把所有逾時都歸因於 DNS

每次重新測試時，建議記錄四項資訊：目前網路、查詢網域、回傳結果或錯誤，以及後續連線是否成功。比較時維持設定與目標一致，並留意快取。Home 的 Connectivity Test 可作為連線狀況的參考，但單次延遲結果不代表下載頻寬，也無法單獨證明所有網域都能正常解析。

改用 DoH 後，所有網域都逾時怎麼辦？

先還原原本的 DNS，確認能否恢復基準狀態。接著檢查 Settings → DNS 中的完整 URL、端點網域是否可解析、裝置時間是否正確，以及目前路由是否阻擋端點連線。一般網頁可以開啟，不代表指定的 DoH 路徑一定可用。

公網網頁正常，但家中內網網域無法開啟？

先確認裝置仍連接到對應的內網，再比較系統 DNS 與自訂 DNS 的解析結果。公用解析器通常沒有區域網路的私有記錄；應保留相應的內網解析路徑，而非繼續更換公網解析器。也要分清一般 DNS 名稱與使用 .local 的 mDNS 名稱。

已經取得 IP，網頁卻一直轉圈，是 DNS 出問題嗎？

先查看該次連線符合的規則與套用的策略，再檢查目標連線逾時或 TLS 錯誤。若同時回傳 A 與 AAAA 記錄，也要確認 IPv4、IPv6 路徑是否都能正常使用。若只有其中一條位址路徑失敗，不宜直接判定整個解析器失效。

為什麼修改設定後，看起來還是原本的結果？

先儲存設定並重新建立連線，再關閉舊頁面重新存取；同時確認 Config 中是否仍有相關 DNS 設定。App 內建的 DoH、系統或 App 快取，以及既有的長連線，都可能讓單次重新整理無法反映新設定，應搭配對應的請求紀錄判斷。

若結果顯示 NXDOMAIN，代表解析器回報網域不存在；這與「沒有收到回應」的逾時不同。SERVFAIL 則表示解析器無法完成處理，可能涉及上游、DNSSEC 驗證或其他解析故障。先檢查網域名稱是否拼錯，再比較相同網域在基準解析路徑下的結果，不要把不同錯誤一律當成「網路很慢」。

完成驗證後，保留可還原的設定紀錄

最終選擇應依實際存取需求決定。系統 DNS 適合用來對照目前網路狀況；固定解析器適合需要明確控制解析來源的設定；DoH 適合需要透過 HTTPS 傳送查詢，且端點可正常連線的環境。是否保留某種方式，應同時檢查公網網域、內網網域與目前分流狀況，而不只是看單次查詢耗時。

保留設定來源。記下解析器參數的來源與用途；公開截圖時，不要透露私人位址、憑證或訂閱內容。
確認自動更新。既有訂閱的更新與本機設定修改是兩回事；更新後應重新檢查相關設定，避免將更新造成的變化誤判為 DNS 不穩定。
保留還原步驟。記下原本的 DNS 值與 Global Routing 選項，遇到問題時先還原基準，再逐項重新測試。
每次只驗證一項變更。若需要同時調整規則與 DNS，請分兩輪儲存並測試，讓每輪結果都能對應到特定修改。

Shadowrocket 是 Apple 平台上的閉源商業 App，主要供 iPhone、iPad 使用；其他裝置的相容性與系統需求請以 App Store 頁面標示為準。App 採一次性買斷，購買 App 與線路服務分開。本文以使用者已有自有設定為前提；本站不提供、不販售也不推薦任何節點或訂閱。