本文重點

先保留系統 DNS 作為比較基準；需要指定解析上游時，再設定自訂 DNS；需要加密 DNS 查詢傳輸時，可考慮 DNS over HTTPS。本文適合已有可用服務設定，正排查網域無法開啟或切換網路後解析異常的使用者，說明三種方式的適用範圍、dns-server 的填寫方式，以及如何判斷問題出在解析或連線階段。

DNS 負責解析，不等於連線出口

Shadowrocket（小火箭）的 DNS 設定主要決定「網域如何取得 IP 位址」。這和 Home 中的 Global Routing 是不同設定：前者影響名稱解析，後者決定連線採用哪種路由方式。網頁無法開啟時，應先分辨是「無法取得位址」還是「取得位址後連線失敗」，不要同時修改 DNS、規則和伺服器參數。

網域查詢 解析上游 回傳位址 判斷連線 存取目標

這個流程描述一次需要本機解析的典型存取方式，不代表所有連線都會經過完全相同的步驟。應用程式可能沿用快取，也可能自行使用加密 DNS；部分代理連線則可將目標網域交由遠端解析。因此，修改 dns-server 後，不應預期裝置上的每次名稱查詢都會立即改用新設定。

系統 DNS、自訂 DNS 與 DoH 有何不同

系統 DNS 是使用目前系統網路環境提供的解析器，通常來自 Wi-Fi 或行動網路設定。自訂 DNS 則是手動指定上游；若只填入一般 IP 位址，通常會使用傳統 DNS 傳輸。DNS over HTTPS，簡稱 DoH，則透過 HTTPS 與解析端點交換 DNS 訊息。這三者並非完全互斥：DoH 本身也是手動指定解析上游的一種方式。

三種 DNS 設定方式比較
設定方式 上游來源與傳輸方式 適合優先驗證的情境 注意事項
系統 DNS 使用系統提供的解析器；實際傳輸方式取決於系統網路設定。 建立故障比較基準，或存取區域網路及組織內部網域。 切換 Wi-Fi 與行動網路後，上游和解析結果可能不同。
自訂一般 DNS 填入指定解析器 IP，通常透過 UDP 53 查詢，必要時使用 TCP 53。 確認問題是否與目前網路提供的解析器有關。 只更換 IP 位址，不會自動為 DNS 查詢加密。
DNS over HTTPS 填入完整的 HTTPS 端點，通常使用 TCP 443。 需要加密用戶端至解析端點之間的查詢傳輸。 端點連線狀況、憑證驗證，以及端點網域的初始解析都可能影響可用性。

結論：使用同一網域進行單一變因比較

保持網路、Global Routing 和預設伺服器不變，只更換 DNS 設定；確認結果可重現後再保留變更。一次修改多個項目，即使網頁恢復正常，也無法判斷是哪項設定發揮作用。

DoH 加密的是通往解析服務這一段的 DNS 傳輸，並非整個存取過程。解析服務仍需處理查詢，網站連線也仍會依照相應路由建立。不能因為「已使用 DoH」就推論「所有 DNS 都經由代理」或「連線出口已改變」。

在 Config 的 [General] 中填寫 dns-server

先在 Config 中確認目前選用的設定檔，接著備份原有內容，並開啟該檔案的文字編輯功能。以下三個程式碼區塊是互相替代的獨立範例，不要一次全部貼上。若檔案已有 [General]，請在原有區段修改 dns-server，避免重複加入同名設定。

  1. 記下 Home 中目前的 Global Routing 選項和已選取的伺服器，以便維持後續比較條件。
  2. 開啟 Config 中目前使用的檔案，找到 [General] 和現有的 dns-server。
  3. 只替換這個設定，儲存後確認仍選用該檔案；為方便驗證，可先中斷連線再重新連線。
  4. 重新送出目標網域的請求並檢查結果。既有連線和快取可能仍沿用舊結果，不能只重新整理一次頁面就下結論。

使用系統解析器

[General]
dns-server = system

system 是設定值，不是需要替換的網域。它適合作為排查基準，尤其適用於網路中有內部網域、路由器名稱或組織專用解析記錄的情況。公共解析器通常不會有這些記錄，改用公共 DNS 後，內部服務反而可能無法存取。

指定一般 DNS 位址

[General]
dns-server = 1.1.1.1

這裡的 1.1.1.1 是公開解析器的格式範例，不代表它在所有網路環境下都比較快。多個上游可用英文逗號分隔，但不要直接將排列順序視為嚴格的「主要、備用」切換保證。排查時先只保留一個上游，更容易確認它是否可連線，以及回傳了什麼結果。

指定 DNS over HTTPS 端點

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

DoH 設定值須包含 https://、主機名稱和服務要求的路徑；一般網站首頁網址不能取代 DNS 端點。此範例僅用來說明格式，實際填寫前請核對解析服務公布的端點。不要任意將主機名稱換成 IP：憑證識別、服務路由和端點支援狀況都可能不允許這種替換。

透過連接埠與設定值確認設定是否正確

53
傳統 DNS 的標準服務連接埠，使用 UDP 或 TCP
443
HTTPS 的預設連接埠，DoH 通常使用此連接埠
2 種
常見位址記錄：A 對應 IPv4，AAAA 對應 IPv6

連接埠號碼用來辨識傳輸方式，不是速度排名。一般 DNS 的 53 連接埠可連線，不代表 DoH 端點的 HTTPS 連線一定正常；能開啟某個一般 HTTPS 網頁，也不代表指定的 DoH 服務可用。應測試實際使用的解析器，而不是把任意網站的連線狀況當作解析服務的連線狀況。

系統 DNS 基準

設定區段
[General]
設定名稱
dns-server
設定值
system
觀察重點
在相同網路下，確認公共網域和內部網域是否都能解析。

先記錄基準，再更換解析上游。

DoH 端點檢查

通訊協定前綴
https://
範例主機名稱
cloudflare-dns.com
範例路徑
/dns-query
觀察重點
確認端點初始解析、HTTPS 連線與憑證驗證是否正常。

逐項核對端點位址，不能只檢查通訊協定前綴。

若網域傳回 AAAA 記錄後存取不穩定，應進一步檢查 IPv6 路徑，而不是立刻認定 DNS 傳回錯誤位址。解析器能傳回某個位址，與目前網路能否連線至該位址，是兩個不同條件。也不要只以瀏覽器直接存取 IP 作為判斷依據：HTTPS 網站可能需要透過網域完成憑證驗證及虛擬主機選擇。

DNS 與 Global Routing、規則的關係

在 Home 的 Global Routing 中，Config 會依目前設定檔中的規則判斷連線；Proxy 和 Direct 分別代表代理和直連路由方式；Scene 則涉及已設定場景的選擇。排查 DNS 時，請記下目前的選項，不要把切換路由後的所有差異都歸因於解析器。

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

這是用來說明規則關係的片段，並非完整設定，也不代表需要覆蓋現有規則。GEOIP 與 IP-CIDR 是依位址判斷，可能會用到解析所得的 IP；DOMAIN-SUFFIX 則使用網域條件。分析連線去向時，應同時查看符合的規則和最終策略，不能只看 DNS 傳回的位址。

網域無法開啟時的排查順序

先選一個先前可以存取的目標網域，並記錄問題發生在 Wi-Fi、行動網路，還是兩者皆有。以下列出的是依觀察結果進行檢查的方向，並非本頁的實測結論；每次變更後都應重新送出請求，記錄時間、網路和結果，避免比較不同條件下的狀況。

DNS 故障現象與後續檢查
觀察到的現象 優先檢查項目 驗證方式
改用 DoH 後，多個網域都無法解析。 端點拼寫、端點網域的初始解析、HTTPS 連線狀況。 恢復使用 system 進行比較；若恢復正常，應集中檢查 DoH 端點，不要重寫所有規則。
公共網站正常，內部網域無法使用。 是否改用了不含內部記錄的公共解析器。 在原有網路中恢復系統解析器，再次測試同一個內部網域。
已取得位址，但連線仍逾時。 符合的策略、伺服器連線狀況、目標連接埠和 IPv6 路徑。 先確認連線記錄中的策略與目標，不要再盲目更換 DNS。
修改設定後，個別應用程式的狀況沒有改變。 快取、既有連線，以及應用程式自行採用的解析方式。 結束相關請求後再試一次，並比較新請求，不要只觀察已開啟的頁面。

Connectivity Test 可協助檢查伺服器連線狀況，但無法單獨證明所有服務網域都已正確解析。反之，DNS 查詢成功一次，也不能證明所選伺服器和目標網站都能存取。應分開記錄解析結果、連線測試和實際頁面請求。

結論：確認故障階段後，再修改相應設定

沒有取得位址時，檢查解析器和端點；已取得位址但無法連線時，檢查路由與連線路徑；只有單一應用程式異常時，再檢查其快取和解析行為。保留原始設定，驗證未通過就還原，避免接連疊加未確認的變更。

依使用環境保留最終設定

最終應保留的是容易理解、能重現且方便還原的設定，而不是上游數量最多的設定。本文以使用者已有自己的服務設定為前提，不提供或推薦服務訂閱。若想進一步了解設定檔與連線驗證，請參閱完整手冊或使用教學。