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

讲清系统 DNS、自定义 DNS、DNS over HTTPS 三种取法的解析路径与适用场景,附 Config 中的写法示例,以及解析异常时的核对顺序。

本文速览

本文适合已经完成 Shadowrocket 连接配置、需要调整域名解析方式的用户。先区分 DNS 服务器、DNS 传输方式与请求出站策略,再通过 Config 中的最小配置逐项验证。系统 DNS 适合作为基线,自定义 DNS 用于明确指定解析器,DNS over HTTPS 用于加密客户端与解析器之间的查询;三者都需要结合当前网络、规则和实际解析结果判断。

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

Shadowrocket(小火箭)中的 DNS 设置解决“域名对应哪些地址”的问题,Global Routing 和规则解决“连接如何出站”的问题。网页打不开可能发生在这两个环节中的任意一个,也可能是目标服务本身异常。仅更换 DNS,不能修复服务端口不可达、连接认证失败或目标网站拒绝访问。

下面展示需要本地解析时的简化路径。实际处理中,域名规则可能先于地址规则命中;某些代理请求也可能把域名交给远端处理,因此并不是每条连接都会完整经过同一条本地 DNS 路径。

域名请求 解析器选择 地址返回 策略判断 连接建立

还要留意应用自己的解析机制。浏览器或其他应用可能使用独立的加密 DNS,已有连接与缓存也可能复用旧地址。Config 中填写了一个解析器,并不等于设备上所有应用的每一次查询都一定经过它。排查时应固定同一应用、同一域名和同一网络,避免把不同请求混在一起比较。

二、系统 DNS、自定义 DNS 与 DoH 的区别

系统 DNS 通常沿用当前网络提供的解析设置,切换 Wi-Fi 或蜂窝网络后,实际解析器可能变化。自定义 DNS 则由配置明确指定解析器地址。“自定义”描述的是选择方式,不代表传输已经加密;DNS over HTTPS,简称 DoH,描述的是通过 HTTPS 传输 DNS 查询,它也属于可以自定义的解析方式。

设置方式 解析器来源 传输特点 优先核对场景
系统 DNS 当前系统与网络设置 不能仅凭此名称判断是否加密 网络登录页、家庭网络、内部域名
自定义普通 DNS 配置中指定的 IP 地址 通常使用 UDP 53,也可能使用 TCP 53 需要固定解析器并比较解析结果
DNS over HTTPS 配置中指定的 HTTPS 端点 常见端口为 443,需要完成 TLS 连接 需要加密 DNS 查询且端点可达
53
普通 DNS 的标准端口,常用 UDP,也可使用 TCP
443
HTTPS 默认端口,DoH 端点通常使用此端口
2 类
常见地址记录:A 对应 IPv4,AAAA 对应 IPv6

结论:先建立基线,再决定是否改用 DoH

先用系统 DNS 记录目标域名能否解析,再单独切换一种解析方式复测。若普通 DNS 可用而 DoH 超时,应先检查 DoH 端点的 HTTPS 可达性,而不是同时改动规则和连接配置。

DoH 加密的是到所选解析器之间的查询传输,解析器仍然需要处理查询内容。它不保证返回地址一定更快,也不保证内部域名可解析。解析器返回的地址、目标服务的地域调度以及网络路径都可能影响最终访问体验。

三、在 Config 中设置 DNS:先备份,再单项替换

操作前确认用户已有自己的服务商与订阅,并已完成基本连接验证。Subscribe 导入或更新处理的是用户已有的连接信息,不能直接视为 DNS 配置已经完成。本文只调整当前 Config 的解析设置,不涉及服务来源选择。

  1. 进入 Config,确认当前实际使用的配置文件,并保存副本。不要只修改一个未启用的文件。
  2. 打开该配置的编辑入口,找到 [General] 段和 dns-server 项。编辑入口的文字或图标可能随界面变化,以当前显示为准。
  3. 若已经存在 dns-server,修改原有项,不要在文件末尾重复添加多个同名设置。
  4. 保存并确认该配置仍被选用,返回 Home,在可以中断连接的情况下重新连接,再测试同一域名。
  5. 保留改动前后的解析结果与错误信息。未改善时先恢复副本,再进行下一项测试。

以下三个片段是互斥的最小示例,每次只选一个替换当前配置中的对应项。它们不是完整配置文件,不应覆盖原有规则与连接信息。示例中的公共解析器仅用于说明语法,是否采用应结合可达性和其服务政策判断。

方案 A:沿用系统 DNS

[General]
dns-server = system

system 表示使用系统 DNS。它适合建立对照基线,也适合依赖本地解析器的环境。若内部域名在未连接时可用、改成公共 DNS 后不可用,应优先核对该域名是否只有本地网络的解析器知道。

方案 B:明确指定普通 DNS

[General]
dns-server = 1.1.1.1

这里只指定一个解析器,便于隔离变量。普通 DNS 地址不需要加 https://,也不要把网页地址填入普通服务器地址位置。若当前网络限制外部 DNS,指定 IP 后依然可能超时;这时应先恢复系统 DNS 验证,而不是连续增加更多地址。

方案 C:指定 DNS over HTTPS

[General]
dns-server = https://1.1.1.1/dns-query

DoH 需要完整端点,协议、主机和路径均有意义;只填写一个解析服务的首页并不等于填写了 DoH 地址。这个示例使用支持该 IP 地址证书的端点,不能据此把其他域名端点随意改成 IP,否则可能发生证书校验失败。

四、DNS 与 Global Routing、规则如何配合

在 Home 核对 Global Routing:Config 按当前配置规则处理连接,Proxy 和 Direct 分别用于代理或直连姿态,Scene 按已设置的场景选择工作方式。排查规则问题时应先固定姿态;停留在 Proxy 或 Direct 后,再用 Config 中的分流规则解释访问结果,容易得出错误结论。

DNS 配置核对

位置
Config → 当前配置 → 编辑
配置段
[General]
配置项
dns-server
验证条件
保存、选用配置并重新连接

修改未启用的配置,不会改变当前会话的解析设置。

规则关键字核对

DOMAIN-SUFFIX
按域名后缀匹配
IP-CIDR
按 IPv4 地址段匹配
GEOIP
按 IP 地理数据库匹配
FINAL
前面均未命中时使用的最终规则

规则按顺序判断;地址类规则可能涉及解析结果。

下面仅展示规则语法,不能直接替代完整配置。192.0.2.0/24 是文档示例网段,不是需要访问的服务地址。DOMAIN-SUFFIX 可以根据域名匹配,地址类规则则需要结合已知目标 IP;附加 no-resolve 的含义是不为该条地址规则主动触发域名解析,而不是禁止整条连接使用 DNS。

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

DNS 返回了地址,也不代表后续一定按预期出站。应分别核对解析结果与规则命中记录;如果域名已命中前面的规则,继续修改后面的 GEOIP 或 FINAL 不会改变这次匹配。也不要仅凭 Global Routing 的名称推断 DNS 查询本身的出站路径,具体还取决于当前 DNS 相关设置及实际记录。

五、解析异常的核对顺序

Connectivity Test 用于观察所选连接的测试结果,不等同于完整验证某个网站的 DNS、TLS 和业务访问。测试结果正常但网页失败时,应把“没有获得地址”和“获得地址后连接失败”分开排查。以下步骤不依赖虚构的速度数据,每一步都要求记录可复现的现象。

  1. 固定网络与样本。记录 Wi-Fi 或蜂窝网络、目标域名、当前 Config 和 Global Routing。优先选择实际失败的域名,再加一个已知正常的域名作对照。
  2. 确认配置生效。保存后重新连接,检查是否仍使用刚刚修改的文件。若配置会被远程更新覆盖,应在副本中测试,并在更新后重新核对。
  3. 区分错误阶段。没有地址、查询超时、返回不存在,与拿到地址后的连接超时不是同一问题。结合可用的连接记录或目标应用错误提示判断,不能仅凭“网页打不开”认定 DNS 故障。
  4. 恢复系统 DNS 作对照。若恢复后立即可用,而指定解析器持续失败,优先检查该解析器在当前网络是否可达,以及是否需要访问内部域名。
  5. 单测 DoH 条件。检查端点拼写、HTTPS 路径、设备时间和证书错误。普通 HTTPS 网站能打开,只能说明部分 HTTPS 连接可用,不能证明特定 DoH 端点必然可达。
  6. 核对 A 与 AAAA。若已经返回地址但访问仍失败,检查是否只在某一种地址族上异常。IPv6 路径问题不能简单归结为解析器错误,也不应先批量删除 IPv6 相关配置。
  7. 最后处理缓存与自动连接。重新建立连接,并重新打开目标应用;同时核对 Settings → On Demand,避免测试期间自动重连改变连接状态。不要把清缓存当作替代前面核对步骤的固定答案。

结论:得到地址后,转查连接与规则

当同一目标已稳定返回 A 或 AAAA 记录,却仍在连接阶段超时,应检查规则命中、所选连接和目标服务端口。此时继续轮换解析器,通常不能定位真正的失败环节。

六、常见问题:设置后仍异常怎么处理

改成 DoH 后,为什么第一次打开网页更慢?

DoH 连接可能包含端点引导解析、TLS 建连和查询过程。先在同一网络连续测试同一域名,区分首次连接与后续复用;若每次都长时间等待,恢复系统 DNS 作对照,并核对端点可达性,不要只根据一次打开速度下结论。

公共网站能打开,家里的内部域名打不开怎么办?

先把 dns-server 恢复为 system,在原家庭 Wi-Fi 下复测。若恢复后可用,说明内部名称可能依赖本地解析器。需要同时保留公共与内部解析时,应按现有网络设计配置域名对应的解析策略,不要指望公共解析器知道私人网络里的名称。

填了多个 DNS,是不是就会严格按顺序备用?

不要仅根据地址书写顺序推断严格的主备行为,查询选择与回退受实际实现和配置影响。排查时先只保留一个已知可达的解析器,保存并重新连接;单项验证完成后,再按当前设置支持的机制增加其他解析器。

Subscribe 更新成功,为什么 DNS 设置没有变化?

连接信息的 Subscribe 更新与当前 Config 的 DNS 项不是同一个检查点。返回 Config 核对所选文件,再检查 [General] 中的 dns-server。若更新的是远程配置文件,还要核对远程内容是否覆盖了本地修改。

最终应保留一份能复现结果的记录:使用的网络、Config 名称、Global Routing 姿态、DNS 配置值、目标域名以及失败阶段。分享记录前删除订阅地址、认证信息和私人域名。与其一次改动多个选项,逐项测试并能恢复到可用基线,更便于判断问题究竟发生在哪里。

下载 Shadowrocket