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

1. 先区分 DNS 解析与连接分流

DNS 的任务是把域名解析为 IP 地址。例如访问 www.example.com 时，解析器可能返回 IPv4 的 A 记录或 IPv6 的 AAAA 记录。拿到地址之后，客户端还需要根据当前路由模式与规则决定如何建立连接。因此，“解析成功”和“网页能够打开”是两个不同的检查点。

这条流程描述常见的域名解析检查顺序，不代表每个请求都会重新查询 DNS。应用缓存、客户端缓存，以及由远端处理域名的连接方式，都可能改变实际查询位置。域名规则也可能在本地解析前完成匹配，不能把 DNS 当作所有规则之前必经的独立步骤。

在 Home 查看 Global Routing 时，应把模式与解析设置分开理解：Config 使用当前配置中的规则，Proxy 与 Direct 改变整体连接策略，Scene 按场景设置工作。切换模式不能替代修复错误的解析器地址；配置了 DoH，也不等于所有业务连接都经过代理。

• DOMAIN-SUFFIX,example.com,DIRECT：按域名后缀匹配，不以某个固定 IP 为判断条件。
• IP-CIDR,192.168.0.0/16,DIRECT：按目标地址网段匹配；判断是否需要解析，还取决于请求形态与规则参数。
• GEOIP,CN,DIRECT：按目标 IP 的地理数据库归属匹配，不能仅凭域名判断。
• FINAL,PROXY：作为前序规则未匹配时的最终策略，不是 DNS 服务器设置。

2. 三种 DNS 方式如何选择

“系统 DNS”和“自定义 DNS”主要回答使用哪个解析器；“DNS over HTTPS”还规定了查询的传输方式。三者并非完全同一层面的分类：手动指定一个 DoH 端点，本身也是一种自定义解析设置。选择时先确认解析目标、网络可达性，再考虑传输加密。

DoH 加密的是客户端到 DoH 解析器之间的查询传输，解析器仍需处理域名查询。它不负责改变网站自身的 HTTPS 行为，也不保证访问更快。增加 TLS 建连可能使首次查询耗时上升；连接复用和缓存又会影响后续结果，不能只用一次网页加载判断优劣。

3. 在 Config 中修改 dns-server

修改前先在 Config 找到当前使用的配置，保留副本，再进入该配置的文本编辑入口。目标是 [General] 段中的 dns-server 字段，而不是 Home 中某个连接条目的 Address。编辑动作以当前界面提供的菜单为准，避免把服务器地址误当成 DNS 地址修改。

1. 在 Config 确认当前选用的配置名称，记录原来的 dns-server 值；如果原本没有该字段，也记录这一状态。
2. 打开配置文本，找到已有的 [General] 段；同一配置已有此段时，在原段内修改，不重复添加整段。
3. 只保留一条本次测试需要的 dns-server 设置，保存后重新选用该配置。
4. 回到 Home，将 Global Routing 设为 Config 以测试配置规则，并在允许短暂断网的情况下断开再连接，让修改后的设置重新载入。
5. 重新访问固定测试域名，记录解析与连接现象；失败时先恢复原值，而不是连续叠加多个解析器。

系统 DNS：作为第一轮基线

[General]
dns-server = system

system 表示使用系统 DNS 信息，并不承诺一定由路由器直接回答，也不代表其他应用的解析一定采用完全相同的路径。切换网络后应重新验证，尤其是需要先完成网络登录的 Wi-Fi。

自定义传统 DNS：使用已确认可达的地址

[General]
dns-server = 192.168.1.1

192.168.1.1 是局域网示例地址，仅在该设备确实提供 DNS 服务且当前网络可达时才有效。网关地址不一定就是 DNS 地址；也不能把家用网络里的私有地址原样带到蜂窝网络。实际填写值应来自用户已有网络或解析服务的配置说明。

DoH：填写完整端点而不是网站首页

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

上面的 dns.example.com 是说明格式的假值，不能直接用于连接。应替换为用户已经确认可用的 DoH 完整端点；路径不一定是 /dns-query，以该解析服务的说明为准。普通 HTTPS 网页即使能打开，也不意味着它能够处理 DNS 查询。

4. 同时核对端点、网络与出站条件

DoH 端点通常以域名表示，建立 HTTPS 连接前可能先需要解析端点自身的地址。如果初始解析不可用，查询还没有到达 DoH 服务就会失败。这类问题不能仅靠把更多域名形式的端点填入列表解决，还要检查端点初始解析、路由与当前网络的可达性。

不要用关闭证书验证来处理 DoH 失败。先检查完整地址、设备日期与时间，以及网络是否处于需要登录的状态。对于“只有开着 Shadowrocket 才失败”的情况，应同时核对 Config 中的规则和端点出站条件，避免把端点本身送入不可达路径。

• 局域网内部名称依赖内部解析器时，直接换成外部解析器可能得到不存在记录的回答。
• AAAA 记录能够返回，不代表当前 IPv6 连接路径一定可用；解析结果与连接能力需要分别验证。
• 应用若使用自己的 DoH 或长期缓存，修改客户端 DNS 后可能看不到对应的新查询。
• 部分请求的域名由远端处理，不能把本地日志中缺少查询记录直接判定为设置失效。

5. 用固定顺序验证 DNS 是否生效

验证时应保留同一个网络、同一份规则和同一个连接条目。先用系统 DNS 建立记录，再替换成一个自定义解析器；每轮都使用相同的目标域名。不要同时刷新已有订阅、切换网络和修改 DNS，否则即使恢复访问，也无法定位真正生效的变化。

1. 记录基线：记下网络类型、启用的配置、Global Routing 模式、测试域名，以及修改前是解析超时还是连接超时。
2. 确认重新载入：保存后重新选用配置并重连；如果访问应用仍在复用旧连接，完全退出该应用后再打开测试。
3. 看解析阶段：在可用的诊断或日志信息中寻找同一域名的查询、回答或超时。已有缓存时未必会产生新查询，不要据此直接判断失败。
4. 看连接阶段：若已经有目标 IP，却在随后建连时超时，继续检查匹配策略、目标端口和已有连接条目的可用性。
5. 重复比较：在相同条件下重复访问数次，区分首次查询和缓存命中。一次偶然成功不应作为长期稳定的依据。

6. DNS 设置常见问题