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

先区分 DNS 解析与 Global Routing 流量去向

DNS（域名系统）负责把域名转换为可连接的地址。打开一个页面时，解析成功只是前置条件，后面还包括规则匹配、建立连接、TLS 握手与传输响应。网页打不开不能直接归因于 DNS；更换解析器也不能修复所有连接超时。

这条流程用于区分排查阶段，不表示所有请求都严格按同一顺序处理。已有缓存、域名规则提前匹配、远端解析以及应用自带解析机制，都可能改变实际过程。尤其是域名规则可以在本地取得 IP 地址之前完成匹配。

• Home → Global Routing（全局路由）决定流量采用哪种路由姿态，不等同于 DNS 服务器选择。
• Config（配置）姿态按当前配置中的规则分流；Proxy（代理）与 Direct（直连）用于选择相应的全局出站方式。
• Scene（场景）用于场景选择；排查时应记录当前场景及其实际使用的配置，不要把它当成一种解析协议。
• Settings → On Demand（按需连接）控制何时触发连接。测试期间若网络条件改变，连接状态也可能改变，应一并记录。

如果用户已有订阅，更新订阅通常是在更新其中的连接条目，不代表当前 Config 内的 DNS 设置也已更新。排查前分别记录所选连接、当前启用配置与 Global Routing 姿态，避免把三个不同的状态混在一起。

系统 DNS、自定义 DNS 与 DoH 的选择依据

系统 DNS 使用当前系统网络环境提供的解析设置，Wi-Fi 与蜂窝网络可能不同。自定义 DNS 则指定解析入口；若填写普通 DNS 服务器地址，通常使用传统 DNS 传输。DNS over HTTPS（通过 HTTPS 传输 DNS，简称 DoH）改变的是查询传输方式，并不保证返回更快或更适合当前网络的地址。

DoH 端点可能使用显式指定的其他端口；“能访问某个 HTTPS 网站”也不能证明某个 DoH 端点可达。服务器的域名、端口、请求路径与证书必须匹配。查询传输加密后，解析端点仍能处理并看到查询，不能据此推导所有流量均已隐藏。

从当前 Config 核对 DNS，再进行单项修改

先进入 Config（配置）确认当前启用的文件，再查看其中的 [General]（通用设置）与 dns-server（DNS 服务器）项。应用内 DNS 选项可从 Settings → DNS（DNS 设置）核对；不要只修改一个未启用的配置文件，随后误认为解析器没有生效。

1. 保留原值。复制当前配置作为回退副本，记录 DNS 字段、Global Routing 姿态及当前网络。配置中如含凭据，副本应妥善保存。
2. 确认测试对象。选一个已知可以正常访问的公开域名，以及一个确实出现问题的域名。局域网名称单独测试，不与公开域名混为一组。
3. 只修改解析设置。在启用配置中核对 dns-server，或在对应 DNS 设置入口检查已有值。不要同时修改出站、规则、IPv6 与 On Demand。
4. 保存并重新连接。结束当前连接后重新开启，随后产生新的请求。已打开页面、已有连接与缓存命中不适合作为唯一验证依据。
5. 对照失败阶段。核对是解析超时、连接超时还是证书错误；若结果变差，恢复原配置并再次重连。

下面两段只展示同一个字段的两种写法，不能把两段重复追加进同一配置。保留实际文件中其他必要设置；不要为了套用示例而用几行文字覆盖完整配置。

[General]
dns-server = system

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

若已有配置由远端更新管理，应先确认更新是否覆盖本地修改。测试应在保留副本的基础上进行，更新后重新检查启用文件中的实际值，而不是根据上次输入内容判断当前状态。

DoH 地址与普通 DNS 地址怎样填写和核对

普通 DNS 地址与 DoH URL 不是可以随意互换的格式。前者描述服务器地址，后者还包含协议、主机名与请求路径。把普通 DNS 地址前面加上 https://，并不会使该服务器自动支持 DoH。

以域名表示的 DoH 端点存在引导解析需求：建立 HTTPS 连接之前，需要先得到端点自身的地址。如果引导解析不可用，可能出现“为了查询 DNS，先要解析 DNS 服务器域名”的依赖问题。此时应检查当前网络基础解析与端点连接路径，不应继续叠加更多同样无法建立连接的端点。

• 地址可达不等于协议可用：能连到某个 IP，不代表其指定端口提供 DoH。
• HTTP 响应不等于查询成功：浏览器打开端点出现错误页，不能单独证明 DoH 服务失效；浏览器普通访问不等同于合规 DNS 查询。
• 证书失败应查原因：检查设备时间、主机名与网络登录状态，不以关闭证书验证作为解决步骤。

规则、IPv6 与局域网解析为什么会影响结果

DNS 返回地址后，流量仍需经过适用的路由决策。DOMAIN-SUFFIX（域名后缀匹配）依据域名；IP-CIDR（IPv4 地址段匹配）与 GEOIP（IP 地理归属匹配）依据地址信息。修改解析器后，返回地址可能变化，命中的地址类规则也可能随之改变。

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

上例只说明语法与匹配关系，不是完整配置。DIRECT 表示直连，PROXY 表示代理去向；实际使用时须核对当前配置认可的策略名称。规则自上而下匹配，FINAL（最终规则）承接前面未匹配的流量。地址段是文档示例，不应直接作为日常分流配置套用。

• no-resolve 表示不为了该条地址规则主动进行域名解析；它不是“关闭所有 DNS”，也不会清除已有解析结果。
• 同一域名的 A 与 AAAA 记录可能指向不同地址。获得 AAAA 记录只说明解析返回 IPv6 地址，不说明当前 IPv6 连接路径可用。
• 公司或家庭网络的内部域名可能依赖本地解析器。换成外部解析器后，公开网站正常而内部域名失败，是需要单独检查的现象。
• 部分应用会使用自身的加密解析或缓存机制。不能因为某一应用行为未改变，就认定 Shadowrocket 的 DNS 配置未保存。

访问需要网页登录的 Wi-Fi 时，应先完成网络认证，再评估自定义解析。认证未完成时，HTTPS 端点不可达、证书异常或所有外部请求超时，往往是网络准入问题，而不是 DNS 字段写法有误。

修改后如何验证：记录失败阶段而不是只看能否打开

验证应在同一网络、同一出站和同一路由姿态下进行。先用原设置建立基线，再换成候选设置。每轮记录请求时间、目标域名、是否得到地址，以及后续连接的结果；不要将缓存命中的瞬时响应与首次建立 DoH 连接的耗时直接比较。

应用内日志能辅助定位，但不同请求未必都显示相同字段。日志中没有新的 DNS 行，既可能是缓存命中，也可能是解析发生在其他位置。需要结合实际请求时间与路由记录判断，不能只凭一行缺失给出结论。

1. 在可重复的问题域名上，分别记录原设置和新设置的表现。
2. 检查是否得到 A 或 AAAA 记录，再看连接最终采用的地址及策略。
3. 若涉及隐私验证，只使用自己控制的测试域名与服务端记录；不同解析出口地址不一定代表异常。
4. 完成对照后只保留已经验证的改动，删除测试值并保留回退副本。

常见问题：设置保存后仍不生效怎么办