在 Config 核对当前启用配置的 DNS 字段，再根据所用网络决定保留系统解析、指定解析器，还是使用 DNS over HTTPS。本文适合已经具备自己的服务商与配置、需要处理域名解析或分流异常的用户；操作重点是一次只改一项，分别验证解析结果、规则命中和实际连接，不把三类问题混为一谈。
先区分 DNS 解析与连接分流
在 Home 确认当前连接和 Global Routing，再到 Config 核对正在使用的配置。Shadowrocket（小火箭）的 DNS 设置决定部分域名查询如何处理，Global Routing 和规则则决定连接交给哪种策略；修改解析器并不等于修改了所有请求的出口。
这条流程用于区分排查阶段，不表示每次请求都会逐步执行一次新的 DNS 查询。应用、系统和解析器都可能缓存结果；域名规则也可能在需要解析地址之前就确定策略。部分连接由远端处理域名，不能把所有请求都理解为先在本机取得 IP 地址。
在 Global Routing 使用 Config 时，应结合规则判断请求去向。Proxy 和 Direct 是整体路由姿态，不能仅凭其中一个选项推断 DNS 查询的实际路径；Scene 则需要进一步核对场景所关联的设置。排查时先固定路由姿态，不要在修改 DNS 的同时切换场景。
系统 DNS、自定义 DNS 与 DoH 的选择依据
先记录当前网络下可以正常访问的域名，再比较三种取向。系统 DNS 使用系统可用的解析环境；自定义 DNS 是指定解析目标；DNS over HTTPS（DoH）则说明查询通过 HTTPS 传输。后两者并不互斥，指定一个 DoH 地址同样属于自定义解析设置。
| 取向 | 填写内容 | 适用条件 | 需要核对 |
|---|---|---|---|
| 系统 DNS | system |
当前网络解析正常，或需要网络内部域名 | 切换 Wi-Fi 与蜂窝后，解析环境可能变化 |
| 自定义传统 DNS | 已知可用的解析器 IP 地址 | 需要固定查询目标，且该目标在当前网络可达 | 传统查询通常不具备传输加密 |
| DNS over HTTPS | 完整的 https:// 端点 |
需要通过 HTTPS 传输查询，且端点可达 | 端点路径、TLS 证书及首次解析依赖 |
在需要访问路由器管理域名、公司内部服务或其他内网名称时，先保留网络提供的解析路径。公共解析器通常不知道内部名称，把全部查询改交外部解析器后，可能出现公共网站正常而内网服务失败的现象。
结论：先保留可用基线，再替换解析目标
当前系统解析正常时，先保存配置副本；只有明确需要固定解析目标或 HTTPS 查询传输时才替换，并用同一域名、同一网络复查结果。
在 Config 核对 dns-server 与 DoH 地址
在 Config 找到当前启用的配置，先保存副本，再打开编辑入口。使用文本编辑时，定位 [General] 内的 dns-server；如果已有该字段，修改原有值，不要在同一段落追加多个同名字段，以免难以判断最终生效内容。
[General]
dns-server = system上例表示使用系统 DNS。若准备改用指定解析器，应把值替换为用户已核实可达的地址；若准备使用 DoH，应填写服务方给出的完整 HTTPS 端点，而不是只填写域名或在普通 DNS IP 前加上 HTTPS 前缀。
系统解析基线
- 入口
- Config → 当前配置 → 编辑入口
- 配置段
[General]- 字段
dns-server = system- 验证环境
- 先保持同一 Wi-Fi 或蜂窝网络
保存后确认启用的是这份配置，再重新连接进行验证。
DoH 端点核对
- 字段
dns-server- 地址结构
https://example.com/dns-query- 默认端口
- HTTPS 使用 443
- 安全条件
- 主机名与证书匹配，路径支持 DoH
example.com 地址仅展示结构，不是可用的解析服务。
保存后回到 Config，确认修改的配置处于启用状态，再在 Home 重新连接。仅编辑未启用的文件，当前会话不会自动按预期改变。若配置由远程来源维护，还需在更新后重新核对字段；直接修改远程内容的本地副本，可能在后续更新时被覆盖。
- 记录原来的
dns-server值和当前启用配置，保留可恢复副本。 - 一次只换一个解析目标，不同时修改规则、协议参数或连接策略。
- 保存、启用并重新连接，然后使用同一个域名复查。
- 如果结果变差，恢复原值后再次测试，以确认变化是否来自 DNS。
DoH 端点采用域名时，建立 HTTPS 连接前仍需获得端点本身的地址，这涉及首次解析依赖。不要让端点地址的获取完全依赖尚未建立的同一条 DoH 查询通道；应保留配置支持的可用引导解析路径，并结合日志核对失败发生在哪一阶段。
DNS 如何影响 DOMAIN-SUFFIX、GEOIP 与 IP-CIDR
在 Config 检查规则顺序时，先区分按域名匹配和按 IP 地址匹配。DOMAIN-SUFFIX 根据域名后缀判断；GEOIP 和 IP-CIDR 根据地址判断。当规则判断需要取得目标地址时，DNS 返回的结果可能影响匹配；已有域名规则命中时，则不必为了后面的 IP 规则继续判断。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这段语法只用于说明顺序，不应整段覆盖已有配置。第一行将匹配到的 example.com 域名后缀交给 DIRECT；第二行匹配对应私有地址范围，no-resolve 表示不要为了这条规则主动触发域名解析；第三行使用地址归属数据；最后由 FINAL 处理前面未匹配的请求。实际策略必须与配置可用策略保持一致。
- 域名信息：只有请求处理中具备可用于匹配的域名信息时，域名规则才有相应判断依据；直接使用 IP 的请求不能仅靠后缀规则识别。
- 地址结果：不同解析器可能因缓存、网络位置或服务调度返回不同地址，后续 IP 类规则的结果也可能随之变化。
- 规则顺序：宽泛的规则放在前面，可能使后面的精确规则没有机会执行，应先看命中项再改 DNS。
- 记录类型：A 与 AAAA 分别对应 IPv4 和 IPv6 地址，取得某一种地址并不代表该网络一定能连接该地址。
按顺序排查：超时、空结果与网页打不开
在同一个网络下复现异常，并记录域名、时间、当前配置和 Global Routing。随后查看可用的连接记录或日志，先确定是否已有解析结果，再判断连接阶段是否成功；不要把所有失败都归因于 DNS。
- 确认网络本身可用。遇到需要网页认证的 Wi-Fi，先完成网络认证。若 Wi-Fi 异常而蜂窝正常，优先比较两者的解析器可达性与网络限制。
- 确认配置确实生效。回到 Config 查看启用项，并复核
dns-server。若系统自动重新建立连接，可到 Settings → On Demand 核对自动连接条件，避免误判测试时的连接状态。 - 区分查询失败类型。超时表示在等待范围内未得到所需响应；NXDOMAIN 表示解析器认为名称不存在；SERVFAIL 表示解析器未能完成处理。三者不能用同一种原因解释。
- DoH 单独检查 HTTPS。核对完整路径、设备时间、端点证书与可达性。能打开端点所属网站，不代表填入的路径支持 DoH；证书错误也不应通过放宽验证来掩盖。
- 已有地址时转查连接。若解析返回 A 或 AAAA，但随后连接超时，应检查目标端口、IPv4/IPv6 可达性、命中策略以及用户已有连接参数，而不是继续更换解析器。
- 恢复基线对照。改回已保存的系统解析配置，重新连接后再次测试。若恢复后仍失败，应扩大排查范围，而不是连续叠加 DNS 改动。
在两次测试之间，关闭并重新打开用于验证的应用，必要时等待 DNS 记录的 TTL 到期。重新连接不保证清除所有层级的缓存；同一域名短时间返回相同结果，不足以证明修改没有生效。
记录测试结果时，分别写下“是否得到地址”“返回什么类型的地址”“命中哪条策略”“连接在哪一步失败”。这比只写“能用”或“不能用”更容易定位问题。进一步检查连接过程，可参考连接排查说明。
DNS 设置常见问题
改成 DoH 后还是打不开网页，接下来查什么？
先在 Config 核对启用配置与端点完整地址，再重新连接并查看失败阶段。若已获得目标地址，就转查规则命中和目标连接；若端点出现 TLS 错误，核对设备时间与证书，不要把关闭验证当作常规修复。
Wi-Fi 正常，切到蜂窝就解析超时怎么办？
保持同一配置与域名，分别记录两种网络下的结果。若自定义地址属于局域网，例如路由器的私有地址，蜂窝通常无法直接访问；改回 system 做对照，再决定是否需要一个在两种网络下均可达的解析目标。
设置 DoH 就能保证所有 DNS 查询都加密吗？
不能只凭一项字段作此判断。它描述的是相应查询通道；应用自行处理的解析、端点首次解析以及其他解析路径仍需分别核对。先查看当前配置和实际查询记录，再判断观察到的请求是否走了预期通道。
更新已有配置后，手动填写的 DNS 又变了怎么办？
到 Config 对照更新前后的文件，确认修改的是远程配置还是独立本地副本。需要保留个人设置时，先备份，再维护明确启用的本地副本；后续同步规则时逐项比较，避免把连接参数与 DNS 改动混在一起。
完成验证后，保留一份可用基线和本次修改记录。DNS 的选择以网络可达性、内部名称需求和查询传输要求为依据，不以解析器数量多少判断效果；同时填写多个目标也不意味着一定严格按书写顺序逐个回退。