2026-09-03 · 进阶设置 · 约 10 分钟

Shadowrocket DNS 怎么设:系统 DNS、自定义 DNS 与 DNS over HTTPS 的取舍

对比系统 DNS、自定义 DNS 和 DNS over HTTPS 三种写法的解析路径与适用场景,给出 dns-server 的书写格式,以及改完后的验证方法。

本文速览

Shadowrocket（小火箭）的 DNS 设置应先保留可用基线，再按需要改动：系统 DNS 适合先确认当前网络能否正常解析，自定义 DNS 用来明确指定解析服务器，DNS over HTTPS 则加密到指定解析服务之间的查询传输。本文以用户已有自己的服务商与订阅为前提，说明配置文件里 dns-server 的位置、三种写法与逐项验证顺序；DNS 调整不替代服务器连接检查，也不自动决定网站流量的出站路径。

一、先区分域名解析与连接分流

DNS 负责把域名查询转换成可用于建立连接的地址信息。例如访问 www.example.com 时，应用可能需要查询 A 或 AAAA 记录，再连接取得的 IPv4 或 IPv6 地址。解析成功只说明得到了回答，不代表目标端口可达、TLS 握手成功，或网页一定能够完整加载。

应用请求 域名查询 取得地址 连接分流 目标响应

这条流程用于区分排查阶段，并不表示所有连接都按同一种内部顺序处理。命中域名规则时，客户端可能直接根据域名决定策略；由远端处理域名的连接，也未必先在本地取得目标地址。应用自行使用的加密 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 中；替换成公共解析服务后，公开网站仍可访问，内部名称却可能无法解析。这属于解析范围改变，不能仅凭公开网页打开就判断全部设置正确。

53
普通 DNS 常用服务端口；传统查询通常使用 UDP，也可能使用 TCP
443
HTTPS 默认端口；DoH 端点通常使用此端口接收查询

判断：先选可验证的来源，再考虑加密传输

若现有解析正常，先保存基线；若选择 DoH，先验证端点可达与证书验证是否正常，再测试目标域名。不要因为地址以 https 开头，就跳过服务器连接与规则检查。

三、在当前配置中修改 dns-server

修改前先确认 Home → Global Routing 的当前姿态，并进入 Config 确认正在使用哪个配置文件。如果同时保存了多个文件，只修改未启用的文件，不会得到预期的运行结果。为避免混淆，先复制或备份当前配置，记录原来的 dns-server 内容，再进入该文件的编辑入口。

  1. 在 Config 找到当前使用的配置文件，打开该文件的编辑页面；具体按钮以应用内当前显示为准。
  2. 找到 [General] 段及已有的 dns-server 行。已有此行时替换值，不要在文件末尾反复追加同名设置。
  3. 从下面三组示例中只选一组。保留文件其他必要设置，不要用这几行覆盖完整配置。
  4. 保存后确认仍选用该配置，回到 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

Settings → On Demand 负责按条件触发或断开连接，不负责选择 DNS 解析服务器。测试时若它在切换 Wi-Fi 后自动改变连接状态，前后两次请求就可能不在相同条件下。应先记录或暂时停用会干扰测试的触发条件，完成验证后恢复原设置。

用户已有订阅的更新与 Config 文件的更新也应分开理解。服务器列表发生变化，不代表当前配置里的 DNS 行已经同步变化；若重新获取或替换了配置文件，则需要再次检查 [General]，确认自己的修改是否仍保留。

五、改完之后，按同一条件验证

不要用“某个网页偶尔打开”作为唯一结论。应固定网络、服务器、Global Routing 与测试目标，只改变 dns-server。缓存可能让设置刚改完时仍沿用旧结果，现有连接也可能继续工作，因此测试要包含重新连接和重新发起请求，而不只是切回已打开的网页。

  1. 记录基线。保存原 DNS 值、所用网络和 Global Routing 姿态，用同一服务器执行 Connectivity Test，并记录成功或失败。
  2. 单项修改。只改一个 DNS 值，保存当前配置，断开再连接。暂不同时调整规则、服务器协议或 On Demand 条件。
  3. 重新请求。重新打开一个已知可访问的域名，再访问一个先前失败的域名；如需局域网服务，也测试其内部名称。
  4. 查看现象。在 Data 的连接记录中核对目标、规则与处理结果；界面未显示解析细节时，不要仅凭流量计数推断使用了哪个解析服务。
  5. 复测网络。分别在 Wi-Fi 和蜂窝网络验证，记录结果。只在一种网络失败时，先排查该网络对解析服务器或 DoH 端点的可达性。
  6. 回退对照。恢复原值再测一次。如果失败随设置变动稳定出现，才进一步检查新解析来源或端点，而不是继续叠加修改。

Connectivity Test 用于确认连接可用性，但一次成功不能证明所有域名都经过了指定解析服务器，也不能证明 DNS 查询的出站路径。类似地，Data 中出现 DIRECT 或 PROXY，首先说明相应连接的处理结果，不应直接扩展成对全部 DNS 查询的判断。

六、常见问题与回退方法

填了 DoH，为什么反而打不开网页？

先把 Config 当前文件中的 dns-server 恢复为原值，重新连接并复测。若恢复后正常，再核对完整端点、网络可达性与设备时间；端点需要初始解析，证书验证也依赖正确时间。不要同时更换服务器和规则，否则无法区分是哪项改动产生影响。

自定义 DNS 后，家里的内部名称不能用了？

先恢复 system，在同一 Wi-Fi 下重新请求内部名称。公共解析服务通常不了解家中路由器或单位内部维护的名称。确认属于此类需求后，应保留能够回答内部名称的解析来源，再依据实际网络规划处理公共域名，不要直接把内部名称失败归因于代理服务器。

修改保存了，但看起来完全没变化？

到 Config 核对实际选用的文件，检查是否改到了另一个副本，再查看是否重复写入 dns-server。保存后从 Home 断开再连接，重新发起请求。若目标应用使用自己的加密解析或缓存，观察结果未必直接反映此项设置。

用了 DoH，就能认定所有 DNS 都加密了吗？

不能。该值指定的是相应解析请求使用的端点，不足以覆盖端点初始解析、应用自带解析与其他配置分支。先确认配置生效，再结合可见记录检查实际请求；DoH 加密的是到解析服务的传输，解析服务本身仍需要处理查询内容。

最后保留一份已验证可用的配置与测试记录。需要回退时，只恢复本次改动的 DNS 行，保存并重新连接；若完整配置也被更换，则恢复备份并重新确认 Global Routing。这样可以把“解析来源变化”与“流量策略变化”分开检查，而不是依靠反复切换多个选项碰运气。

Shadowrocket 是 Apple 平台的闭源商业应用，唯一获取入口是 App Store，以 iPhone/iPad 使用为主，系统要求以 App Store 页面标注为准。客户端一次性买断不等于线路套餐；本文不提供、不销售、不推荐节点或订阅，连接与解析验证均以用户已有服务为前提。

App Store 正版核验