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

本文快速導覽

設定 Shadowrocket（小火箭）的 DNS 時，建議先保留可用的基準設定，再依需求調整：系統 DNS 可先確認目前網路能否正常解析；自訂 DNS 可指定解析伺服器；DNS over HTTPS 則會加密裝置與指定解析服務之間的查詢傳輸。本文假設你已有自己的服務商與訂閱，說明設定檔中 dns-server 的位置、三種寫法及逐步驗證方式。調整 DNS 無法取代伺服器連線檢查，也不會自動決定網站流量的連線路徑。

一、先區分網域解析與連線分流

DNS 會將網域查詢轉換成可用來建立連線的位址資訊。例如，存取 www.example.com 時，App 可能需要查詢 A 或 AAAA 記錄，再連線至取得的 IPv4 或 IPv6 位址。解析成功只代表收到回覆，不代表目標連接埠可連線、TLS 交握成功，或網頁一定能完整載入。

App 發出請求查詢網域取得位址連線分流目標回應

這個流程有助於區分排查階段，但不代表所有連線都依照相同的內部順序處理。符合網域規則時，客戶端可能直接依網域決定策略；由遠端處理網域的連線，也未必會先在本機取得目標位址。App 自行使用的加密 DNS、既有快取及設定檔中的其他 DNS 選項，也會影響實際觀察到的流程。

Global Routing 與 DNS 並非同一個開關。Proxy、Direct、Config、Scene 用來選擇流量處理模式；dns-server 則用來指定解析來源。填入解析伺服器位址，不代表所有連線都會改用 Proxy，也不代表查詢一定會經由目前選取的代理伺服器傳送。

二、三種 DNS 寫法分別會改變什麼

在設定檔的 [General] 中，dns-server 可使用系統解析來源、指定的解析伺服器位址，或受支援的加密 DNS 位址。以下比較的是設定方式，不是速度排名。實際回應時間會受到目前網路、解析服務的連線狀況、快取及回傳結果影響，請在自己的網路環境中測試。

方式	範例值	適用情境	注意事項
系統 DNS	`system`	先確認目前網路提供的解析功能，或需要存取區域網路中的名稱	切換 Wi-Fi 與行動網路後，解析來源可能不同
自訂 DNS	`1.1.1.1`	需要固定指定已確認可連線的解析伺服器	一般 DNS 查詢本身不會加密傳輸
DNS over HTTPS	`https://cloudflare-dns.com/dns-query`	需要加密用戶端與指定解析服務之間的查詢傳輸	需要端點可連線、TLS 驗證正常，且端點網域可先完成解析

表中的公共解析位址僅用來說明語法，不代表適用於所有網路。公司或家中的內部名稱可能只存在於內部 DNS；改用公共解析服務後，一般網站仍可存取，但內部名稱可能無法解析。這是解析範圍改變所致，不能只憑公開網站能否開啟，就判斷所有設定都正確。

一般 DNS 使用的服務連接埠；傳統查詢通常使用 UDP，也可能使用 TCP

443

HTTPS 預設連接埠；DoH 端點通常透過此連接埠接收查詢

判斷原則：先選擇可驗證的來源，再考慮加密傳輸

若目前解析正常，先保留原有設定作為基準；若選用 DoH，先確認端點可連線且憑證驗證正常，再測試目標網域。不要因為位址以 https 開頭，就省略伺服器連線與規則檢查。

三、在目前設定檔中修改 dns-server

修改前，先確認 Home → Global Routing 目前的連線模式，再進入 Config 確認正在使用哪個設定檔。如果儲存了多個檔案，只修改未啟用的檔案，實際運作結果不會如預期。為避免混淆，請先複製或備份目前設定，記下原有的 dns-server 內容，再進入該檔案的編輯畫面。

在 Config 找到目前使用的設定檔，開啟檔案編輯頁面；實際按鈕名稱請以 App 內顯示為準。
找到 [General] 區段及現有的 dns-server 行。若已有這一行，請直接替換值，不要在檔案末尾重複加入同名設定。
從以下三組範例中擇一使用。保留檔案中的其他必要設定，不要用這幾行取代整份設定檔。
儲存後確認仍選用這份設定檔，回到 Home 中斷連線再重新連線，並重新測試。

系統 DNS：建立比較基準

[General]
dns-server = system

system 代表使用系統提供的 DNS 來源，不是在設定檔中指定某個公共位址。若 Wi-Fi 需要網路登入驗證，請先完成驗證；網路尚未開放前，改用公共解析位址或 DoH 端點不一定能解決存取問題。

自訂 DNS：指定解析伺服器

[General]
dns-server = 1.1.1.1

此處的 IP 位址是解析伺服器位址，不是你的代理伺服器位址，也不是要存取的網站位址。若要填入多個一般解析位址，可用英文逗號分隔，例如 dns-server = 1.1.1.1, 8.8.8.8。不要將清單順序直接視為固定的主備切換機制；排查初期建議只填一個，方便釐清問題。

DNS over HTTPS：填入完整端點

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

DoH 的值應為解析服務提供的完整 HTTPS 端點，而非服務介紹頁面。請勿漏掉 https://，也不要自行刪除或修改 /dns-query 路徑。網域形式的端點必須先解析出位址才能建立連線，因此使用 DoH 不代表完全不需要任何初始解析。

設定檔檢查

位置: Config → 目前使用的設定檔
區段名稱: [General]
鍵名: dns-server
操作: 修改現有值、儲存並重新連線

範例僅顯示 DNS 設定行，不能取代原有的完整設定檔。

DoH 端點檢查

協定: https://
主機: cloudflare-dns.com
路徑: /dns-query
必要條件: 端點可連線，且 TLS 驗證正常

一般網頁顯示錯誤頁面，不能單獨證明 DoH 查詢失敗。

四、DNS 與規則、On Demand 的關係

若要檢查規則分流，請先在 Home → Global Routing 選擇 Config，再檢查目前檔案中的 [Rule]。網域規則與位址規則使用的資訊不同：DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依位址範圍比對，GEOIP 依位址歸屬資料庫比對。需要取得位址才能判斷的規則，可能會受到 DNS 回傳結果影響。

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

DOMAIN-SUFFIX,example.com,DIRECT 用來比對該網域及其子網域，不是用來指定它的 DNS 伺服器。
IP-CIDR 範例涵蓋一個私有位址範圍；no-resolve 表示不會為比對此規則額外觸發網域解析，並非停用所有 DNS。
GEOIP,CN,DIRECT 依位址判斷，結果不能簡單等同於網站使用的語言或網域後綴。
FINAL,PROXY 會在前面的規則都未符合時作為後備規則；此範例僅用於說明語法，不應直接取代自己的完整規則集。

Settings → On Demand 負責依條件觸發或中斷連線，不負責選擇 DNS 解析伺服器。測試期間，若它在切換 Wi-Fi 後自動變更連線狀態，前後兩次請求的條件可能不同。請先記錄或暫時停用會干擾測試的觸發條件，完成驗證後再還原原設定。

已有訂閱的更新與 Config 檔案更新也應分開看待。伺服器清單變更，不代表目前設定中的 DNS 行也已同步變更；若重新取得或替換設定檔，請再次檢查 [General]，確認自己的修改是否仍保留。

五、修改後在相同條件下驗證

不要只憑「某個網頁偶爾能開啟」就下結論。請固定網路、伺服器、Global Routing 模式與測試目標，只變更 dns-server。快取可能讓設定剛修改後仍沿用舊結果，既有連線也可能繼續運作；因此測試時應重新連線並重新發出請求，而不只是切回已開啟的網頁。

記錄基準。記下原有 DNS 值、使用的網路與 Global Routing 模式，使用同一台伺服器執行 Connectivity Test，並記錄成功或失敗。
單項修改。只修改一個 DNS 值，儲存目前設定後中斷連線再重新連線。暫時不要同時調整規則、伺服器協定或 On Demand 條件。
重新發出請求。重新開啟一個已知可存取的網域，再測試一個先前無法存取的網域；若需要使用區域網路服務，也請測試其內部名稱。
檢查結果。在 Data 的連線記錄中確認目標、規則與處理結果；若介面未顯示解析細節，請勿只憑流量計數推斷使用了哪個解析服務。
在不同網路重測。分別透過 Wi-Fi 與行動網路驗證並記錄結果。若只有其中一種網路失敗，先檢查該網路能否連線至解析伺服器或 DoH 端點。
還原比較。恢復原值後再測一次。若問題會隨設定變更而穩定重現，再進一步檢查新的解析來源或端點，不要繼續層層疊加修改。

Connectivity Test 用來確認連線是否可用，但單次成功不能證明所有網域都經由指定的解析伺服器，也不能證明 DNS 查詢的傳送路徑。同樣地，Data 中出現 DIRECT 或 PROXY，首先只代表相應連線的處理結果，不應據此推論所有 DNS 查詢的狀況。

六、常見問題與還原方式

設定 DoH 後，為什麼反而無法開啟網頁？

先將 Config 目前使用的設定檔中 dns-server 還原為原值，重新連線並再次測試。若還原後恢復正常，請檢查完整端點、網路連線狀況與裝置時間；端點需要初始解析，憑證驗證也仰賴正確的時間。不要同時更換伺服器與規則，否則無法判斷是哪項變更造成影響。

設定自訂 DNS 後，家中的內部名稱無法使用？

先還原為 system，在相同的 Wi-Fi 網路下重新查詢內部名稱。公共解析服務通常不會知道家用路由器或公司內部維護的名稱。確認有這類需求後，應保留能解析內部名稱的來源，再依實際網路規劃處理公共網域；不要直接將內部名稱解析失敗歸咎於代理伺服器。

修改並儲存後，看起來完全沒有變化？

前往 Config 確認實際使用的檔案，檢查是否修改了另一份副本，以及是否重複加入 dns-server。儲存後從 Home 中斷連線再重新連線，並重新發出請求。若目標 App 使用自己的加密解析或快取，觀察到的結果未必會直接反映這項設定。

使用 DoH，就能確定所有 DNS 查詢都已加密嗎？

不能。這個值指定的是相關解析請求使用的端點，無法涵蓋端點的初始解析、App 內建的解析功能及其他設定分支。請先確認設定已生效，再搭配可查看的記錄檢查實際請求；DoH 加密的是與解析服務之間的傳輸，解析服務本身仍需處理查詢內容。

最後請保留一份已驗證可用的設定檔與測試記錄。需要還原時，只恢復本次修改的 DNS 行，儲存後重新連線；若整份設定檔也已更換，則還原備份並重新確認 Global Routing。如此可分別檢查「解析來源變更」與「流量策略變更」，不必反覆切換多個選項碰運氣。

Shadowrocket 是 Apple 平台上的閉源商業 App，唯一取得管道為 App Store，主要供 iPhone/iPad 使用；系統需求請以 App Store 頁面標示為準。一次性購買客戶端不等於購買線路方案；本文不提供、不販售也不推薦節點或訂閱，連線與解析測試均以使用者已有服務為前提。