2026-10-03 · 进阶配置 · 约 10 分钟

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

从配置文件 [General] 段的 dns-server 写法讲起,对比系统 DNS、自定义 DNS 和 DNS over HTTPS 在解析速度、可靠性与隐私上的差异,并给出示例写法。

本文速览

Shadowrocket（小火箭）的 DNS 排查应先确认当前配置，再决定解析器：普通网络先用 system 建立基线，需要固定解析器时填写 IP，需要加密 DNS 传输时再测试 DNS over HTTPS。本文适合已有自己的服务商与订阅、能够正常建立连接的用户，给出可单独替换的配置片段，并说明如何区分解析失败、规则选择错误和目标连接失败。

先区分 DNS 解析与网页连接

DNS 把域名转换为 IP 地址；网页能否打开，还取决于后续的路由选择、目标端口连接和 TLS 握手。Home 中延迟测试有数值，只能说明相应测试条件下获得了响应，不能据此认定 Safari 正在访问的域名一定能够解析，也不能认定网页所需的全部连接均可建立。

域名请求DNS 查询地址结果连接目标页面加载

上面的流程适用于需要本地解析的访问，不代表每一条代理连接都必须先在设备上查出目标 IP。域名可能直接交给远端处理，规则也可能先按域名命中。排查时应分别观察“是否取得解析结果”和“取得结果后是否连接成功”，不要把全部失败都归到 DNS。

53
传统 DNS 常用 UDP / TCP 端口
443
DNS over HTTPS 通常使用的 HTTPS 端口
[General]
dns-server 所在的配置段

端口只用于辨认传输方式。443 可达并不代表某个 DNS over HTTPS 端点可用，53 可达也不代表回答一定正确。需要核对实际返回的地址、错误类型以及后续访问结果。

三种 DNS 设置如何选择

system 适合作为初始基线，尤其是依赖本地网络解析的场景。固定 IP 的自定义 DNS 便于做重复测试，但填写 IP 本身不会给查询加密。DNS over HTTPS，简称 DoH，把查询放入 HTTPS 传输，适合希望降低沿途网络直接读取查询内容的场景；它仍然需要一个可达、可信的解析端点。

设置方式速度与可靠性隐私边界优先测试场景
system取决于当前系统与网络提供的解析路径，通常便于访问本地资源。不能仅凭 system 判断查询是否加密。建立基线、办公网络、局域网名称解析。
自定义 DNS IP结果取决于到指定解析器的链路；固定地址有利于复现问题。普通 DNS 查询本身没有 HTTPS 传输保护。隔离网络默认解析器的问题。
DNS over HTTPS首次连接可能涉及端点解析和 TLS 握手，连接复用与缓存会改变后续耗时。保护到 DoH 端点的传输，端点运营方仍能处理查询。需要加密查询，且已确认 HTTPS 端点可达。

三者没有固定的速度排名。距离较近但拥塞的解析器可能比远端解析器更慢；更换解析器还可能改变 CDN 返回的地址，使 DNS 查询更快、网页反而更慢。因此，测试必须包含实际页面访问，不能只比较单次 DNS 查询耗时。

在 Config 中修改 dns-server：每次只测试一种写法

先进入 Config，确认当前启用的配置文件，保留一份原始副本，再进入该文件的编辑入口。找到已有的 [General] 段，修改其中的 dns-server。以下三个片段是互斥的测试方案，不是要求同时粘贴的完整配置。

方案一：使用 system 建立基线

[General]
dns-server = system

system 使用系统提供的解析器来源，具体表现受设备与当前网络影响。连接 Wi-Fi 后能够解析局域网名称，而换成公共解析器后失败，可能是该名称只存在于网络内部。此时应核对网络提供的解析条件，而不是继续增加公共 DNS 地址。

方案二：指定传统 DNS 解析器

[General]
dns-server = 1.1.1.1

这里的地址仅用于展示 IP 写法，不表示对解析服务作速度或可用性承诺。实际使用前，应确认该解析器在当前网络可达，并符合自己的使用要求。不要在未记录基线的情况下同时更改解析器、规则文件和代理选择，否则很难判断是哪项修改产生了影响。

方案三：使用 DNS over HTTPS

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

此处展示完整 DoH 端点的格式：https://、主机名和 /dns-query 路径共同组成请求地址，普通网站首页不能替代它。主机名端点在建立 HTTPS 连接之前还需要能够被解析；如果故障发生在这个启动环节，单纯把目标 DNS 换成 DoH 并不能自动解决。

  1. 只替换当前 [General] 中对应的设置，保留其余字段，避免重复创建同名段或重复键。
  2. 保存并确认启用的是修改后的配置，断开后重新连接，再进行访问测试。
  3. 回到 Home 核对 Global Routing。需要验证文件内分流规则时使用 Config；Proxy、Direct 或 Scene 的效果应按当前所选姿态另行判断。
  4. 若文件来自远程配置，先确认更新会不会覆盖本地改动；用于测试的副本与日常自动更新文件分开管理。

配置边界：DNS 返回地址，Rule 决定策略

dns-server 不负责把某个网站指定为 DIRECT 或 PROXY。规则位于 [Rule] 段，按顺序匹配。域名规则可以直接依据域名判断，IP 类规则则涉及目标地址；因此，解析结果变化可能影响后续 IP 规则的匹配，但修改 DNS 并不等于修改分流策略。

解析设置核对

配置段
[General]
字段
dns-server
系统来源
system
加密端点
https://cloudflare-dns.com/dns-query

先验证端点能回答，再检查目标连接。

规则语法核对

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

这里分列关键字与参数，完整配置需要用逗号连接。

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

这段规则用于解释语法，不是适用于所有网络的完整方案。no-resolve 表示不为了匹配该条 IP 规则额外发起域名解析，并不表示所有 DNS 都被关闭。FINAL 放在规则段最后，为前面的规则均未命中的请求提供兜底策略。

如果解析已经返回地址，但网页仍超时，应继续检查命中的策略以及该策略对应的连接。用户已有的 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 连接信息属于另一层配置；切换 DNS 不会修复其中错误的凭据、端口或服务端设置。

用固定步骤比较速度与可靠性

一次成功不能证明设置长期可靠，一次失败也不能直接判定解析器不可用。测试时固定同一设备、同一网络、同一配置规则和同一组访问目标，按 system、固定 DNS IP、DoH 的顺序逐项比较。若切换 Wi-Fi 与蜂窝网络，应作为新一组测试单独记录。

  1. 记录基线：使用 system，访问一个日常正常的域名和一个当前失败的域名，记录能否解析、能否打开以及具体错误。
  2. 只改解析器：替换 dns-server，重新连接，保持 Global Routing 和已选连接不变。
  3. 区分缓存：分别观察首次访问与重复访问。设备、浏览器和解析器都可能缓存结果，重复刷新通常不等于重新查询。
  4. 检查返回值：若应用内相应诊断或记录中提供 DNS 结果，查看是否有 A 或 AAAA 回答、是否超时以及是否返回 NXDOMAIN。不要仅以地址不同认定回答错误。
  5. 验证实际连接：能解析但页面失败时，继续观察目标连接、规则策略和 IPv4 / IPv6 路径，不再反复堆叠 DNS 地址。
  6. 确认后再保留：只保留能稳定复现改善的设置；没有改善就恢复副本，避免把临时试验变成长期配置。

NXDOMAIN 表示解析器报告名称不存在，与“等待回答超时”不同；而缺少 AAAA 回答也不等于解析失败，目标可能只提供 IPv4 地址。如果 A 和 AAAA 都有回答，但设备所处网络的 IPv6 路径异常，现象可能是部分页面等待较久。此时应分开核对地址族与连接错误，而不是直接把 DoH 判断为失效。

常见问题：DoH 超时、局域网失效与隐私范围

填了 DoH 之后全部网页打不开，先改哪里？

先在 Config 的当前文件中把 dns-server 恢复为 system，保存并重新连接。若访问恢复，再单独检查 DoH 地址是否完整、端点主机名能否解析、HTTPS 连接是否被当前网络限制，以及设备时间是否正常。不要同时替换规则和连接信息。

公共网站正常，打印机和内网域名却打不开？

先恢复 system，在同一 Wi-Fi 下重试相同名称。内部域名可能只由本地 DNS 提供，公共解析器无法回答。还要区分普通 DNS 名称与依赖本地发现机制的名称，不能认为所有局域网访问问题都由 dns-server 控制。

已经用了 DoH，为什么还要检查规则？

DoH 只定义解析传输方式。回到 Home 核对 Global Routing；验证文件规则时使用 Config，再检查相应请求命中的 DIRECT 或 PROXY。能够取得 IP 但连接超时，通常需要继续检查出站路径，而不是只看解析器。

填多个 DNS 地址是不是一定更稳？

先用单一解析器完成对照测试。多个地址的调度与失败处理取决于具体实现，不能仅凭填写顺序断言主备关系；混合普通 DNS 与 DoH 也不能直接认定全部查询都已加密。确认各地址单独可用后，再依据应用内说明调整。

DoH 能让解析服务看不到查询吗？

DoH 端点需要处理查询，因此端点运营方仍能看到交给它的解析请求。HTTPS 主要保护设备到端点之间的传输内容。选择解析器时应核对其服务说明，并把“传输加密”“解析服务信任”和“代理路由”作为三个独立问题处理。

最终保留的配置应以当前网络的可达性、实际页面访问和所需的隐私边界为依据。更多字段说明可查看配置字段参考；如果问题只在特定网络发生，可结合疑难解答继续排查。Shadowrocket 以 iPhone / iPad 为主要使用设备，系统要求与设备兼容性以 App Store 页面标注为准。

App Store 正版核对