Shadowrocket DNS 设置详解:系统 DNS、自定义 DNS 与 DNS over HTTPS 怎么选

本文速览

系统 DNS 适合作为当前网络的排查基线，自定义 DNS 用来明确解析器，DNS over HTTPS 用来加密客户端与解析器之间的查询。本文面向已拥有自己的服务商与订阅、正在使用 Shadowrocket（小火箭）的用户，说明如何在 Config 中修改 General 段，如何区分解析故障与连接故障，以及怎样验证并回退一次 DNS 改动。

一、先区分 DNS 解析与网站连接

DNS 的任务是把域名解析为地址，例如查询 A 记录得到 IPv4 地址，查询 AAAA 记录得到 IPv6 地址。拿到地址后，访问 HTTPS 网站还需要建立连接、完成 TLS 握手并获取内容。因此，“有 DNS 响应”不等于“网页一定能打开”；“网页打不开”也不等于“DNS 一定出错”。

发起域名访问查询解析器取得地址建立连接获取内容

这条链用于拆分故障，不代表所有请求都在本机完成解析。Shadowrocket 的实际解析位置还与请求类型、规则和代理出站方式有关；某些连接可以把目标域名交给远端处理。不能只依据本地设置了一个 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	向明确指定的解析器 IP 发送传统 DNS 查询。	需要固定解析器，且该地址在当前网络可达。	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 传输，不能省略后再假定应用会按 DoH 处理。
dns.example.com：示例域名，不是本文提供的 DNS 服务；实际应填写自己已有的解析服务端点。
/dns-query：常见的 DoH 路径，但不是所有端点都使用该路径。必须照解析服务提供的完整地址填写，不应自行补写或截短。

四、把解析设置与规则、Host 分开核对

DNS 负责取得地址，规则负责选择请求策略，Host 则可能为特定域名提供固定映射。三者影响不同阶段。若配置中已有 Host 映射，某个域名可能并未按你预期向上游查询；若应用保留了旧地址，立即刷新页面也可能看不出变化。

解析设置核对

入口: Config → 当前启用文件 → 编辑
配置段: [General]
字段: dns-server
映射检查: [Host] 中是否存在目标域名

先确认正在测试的文件，再检查是否有固定映射影响结果。

路由姿态核对

入口: Home → Global Routing
Config: 按当前配置处理分流
Proxy / Direct: 用于区分全局出站姿态
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，保存配置并重新连接。结束目标应用中的旧请求，再发起新的域名访问。
核对解析：在应用可用的 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:// 不能证明查询经过某个出站，也不能证明所有应用都使用这一解析路径。

切换 Wi-Fi 后故障复现，应检查什么？

先检查系统 DNS 是否随网络变化，以及自定义端点在新网络中是否可达。若配置了 Settings → On Demand，还应核对按需连接条件，确认测试时的连接状态没有被自动规则改变。On Demand 管连接触发条件，不是 dns-server 的替代项。

怎样恢复到修改前的状态？

在 Config 中恢复原来的 dns-server 行，或重新启用先前保存的本地副本，然后回到 Home 重连。若原文件没有该字段，回退时恢复原样，而不是额外添加猜测值。再用同一个目标复测，确认恢复效果；之后每次只改一项。

DNS 设置的目标是取得符合用途、可验证的解析结果，不是追求某一种方式在所有网络中都适用。系统 DNS、传统自定义 DNS 与 DoH 都需要结合实际网络检查；保留配置副本与测试记录，比频繁切换多个设置更有助于定位问题。