Shadowrocket（小火箭）的 DNS 设置决定部分域名查询交给谁处理，不直接决定所有业务连接的出口。本文适合已经导入自己已有服务、准备排查域名解析或调整 DNS 的用户：先确认系统 DNS 能否满足当前网络，再比较自定义 DNS 与 DNS over HTTPS，最后用同一域名、同一网络和相同规则验证结果。初始值与可用选项以当前应用显示为准。
一、先区分 DNS 查询与业务连接
DNS 的作用是把域名转换为连接所需的信息。常见的 A 记录返回 IPv4 地址，AAAA 记录返回 IPv6 地址。取得地址后，客户端还需要建立 TCP、UDP 或其他业务连接；因此“域名能解析”和“网页能打开”是两项不同检查。DNS 返回了地址，并不意味着目标端口可达、代理连接成功或网站证书正常。
下列流程描述常见的本地解析情形，并非每个请求都必须经过本地 DNS。部分代理连接可以把域名交给远端处理，部分应用也会使用自己的加密解析。排查时应结合实际请求记录，不能把一处 DNS 设置理解为对所有应用查询的强制接管。
例如网页提示“找不到服务器”，需要检查解析是否超时或返回不存在；如果已经获得地址，但连接随后超时，应继续检查出站路径、目标端口与网络条件。不要仅凭浏览器的一句错误提示就反复更换 DNS。
二、系统 DNS、自定义 DNS 与 DoH 的区别
系统 DNS 通常跟随当前网络的解析配置，可能来自 Wi-Fi 网络、蜂窝网络或设备管理配置。自定义 DNS 是指定解析服务器，而 DNS over HTTPS（DoH）是在 HTTPS 连接中传送 DNS 查询。二者不是互斥分类：手动填写一个 DoH 服务地址，本身也是一种自定义解析设置。
| 方式 | 常见传输 | 适用条件 | 主要检查点 |
|---|---|---|---|
| 系统 DNS | 取决于系统及当前网络配置 | 当前网络解析正常，或需要访问内部域名 | 切换网络后解析服务器与内部域名是否变化 |
| 自定义传统 DNS | 通常为 UDP 53，部分响应需要 TCP 53 | 已有明确可达的解析服务器地址 | 服务器路由、53 端口与返回记录是否符合预期 |
| DNS over HTTPS | 通常为 HTTPS 443 | 已有可达的 DoH 服务，并需要加密查询传输 | 完整 URL、证书、服务域名解析与连接路径 |
DoH 可以保护设备与 DoH 服务之间的查询传输，但解析服务仍然会收到查询内容；它也不负责加密全部业务流量。是否走代理，需要另外核对实际解析路径和出站策略。不能仅因为地址以 https:// 开头，就断定业务连接已改走代理。
取值建议：先保留可用基线，再引入加密解析
当前网络解析稳定时，先记录系统 DNS 的表现；只有出现可复现的解析问题，或有明确的查询传输需求时，再测试一个已知可达的自定义 DNS 或 DoH 服务。不要一次加入多项未知配置。
三、Settings → DNS 的设置顺序与取值记录
打开 Settings → DNS，先记录当前值，再检查 Config 中当前启用的配置是否也包含 DNS 相关设置。应用设置与 Config 可能共同影响实际行为，不能仅看某一处输入框。字段名称、初始值与具体支持格式以当前应用显示为准；不要把旧配置中的取值当成所有设备的默认值。
- 保留原设置。记录 Settings → DNS 当前内容以及当前启用的 Config，必要时保留原 Config 副本。不要直接覆盖唯一可用配置。
- 先选一种方式。测试系统 DNS、自定义传统 DNS、DoH 时，每轮只切换一项；同时固定 Global Routing、服务器选择和测试网络。
- 填入实际服务参数。传统 DNS 使用可达服务器地址；DoH 使用服务方明确提供的完整 URL。不要自行猜测路径，也不要把普通网站首页当作 DoH 端点。
- 按提示保存并应用。若当前界面要求重新连接后生效，按提示操作，再发起新的查询。旧连接和缓存可能继续保留原结果。
- 验证后决定保留。用相同域名检查解析与业务连接，再切换 Wi-Fi、蜂窝网络复测。出现新故障时恢复记录中的原设置。
传统 DNS 记录卡
- 检查入口
- Settings → DNS
- 地址形式
- 解析服务器的 IPv4 或 IPv6 地址
- 常见端口
- UDP 53；必要时 TCP 53
- 记录示例
192.0.2.53，仅为文档示例
示例地址不能作为可用解析服务；实际值须来自用户已有网络或解析服务的说明。
DoH 记录卡
- 地址形式
- 包含 scheme、域名与路径的完整 URL
- 格式示例
https://dns.example.com/dns-query- 常见端口
- HTTPS 443
- 前置条件
- 服务域名可解析、证书有效、端点可达
此 URL 仅展示格式，不是可用服务；路径必须使用实际服务给出的值。
配置多个地址不一定代表严格按书写顺序依次备用。查询如何调度、是否回退以及哪些设置参与当前解析，应以当前应用与 Config 的实际行为为准。为了定位问题，测试阶段使用单一明确来源，比堆叠多组地址更容易解释结果。
四、DoH 连不上时，先检查服务域名的启动解析
DoH 端点本身通常也是域名。建立 HTTPS 连接之前，设备需要先取得这个域名的地址，这一步常称为启动解析。如果唯一的解析路径依赖尚未建立的 DoH 连接，就可能形成循环依赖。表现可能是开启 DoH 后所有新域名都超时，但恢复原解析设置后又能访问。
- 核对 URL。确认没有前后空格、缺失路径或复制截断。
/dns-query是常见路径，但不是所有服务都必须采用的固定值。 - 核对证书。检查设备时间是否正确，HTTPS 证书是否匹配服务域名。不要通过关闭证书验证来掩盖连接问题。
- 核对前置解析。使用原本可用的解析方式确认服务域名能得到地址，再检查当前配置是否存在循环依赖。
- 核对传输路径。443 端口可达只是必要条件之一，普通网页能打开也不能证明 DoH 查询响应有效。
不要把 DoH URL 中的域名随意替换成一个 IP 地址。HTTPS 证书和服务路由可能依赖原域名，直接替换可能引入证书不匹配。若服务提供专门的启动解析或地址绑定说明，应按其实际文档与应用支持项配置，而不是凭经验拼接参数。
五、DNS 与 Global Routing、规则分流的关系
在 Home → Global Routing 中，Proxy、Direct、Config、Scene 用于选择路由姿态；它们与 DNS 服务器地址不是同一个设置。Proxy 使用代理路径，Direct 使用直连路径，Config 按当前配置规则处理，Scene 按所选场景设置处理。排查规则命中前，先确认当前姿态是否确实使用了预期规则。
下面只是规则语法示例，不是可直接替换现有 Config 的完整配置。PROXY 必须在当前配置中能够指向有效策略；文档地址段不代表实际业务目标。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX根据域名后缀匹配，通常不需要仅为了该条匹配而先查询目标 IP。它本身不是 DNS 服务器设置。IP-CIDR根据目标 IP 所属网段匹配；示例中的no-resolve表示不为了该条规则主动解析域名。已有目标 IP 时仍可进行网段判断。GEOIP根据 IP 的地理归属数据匹配。对于尚未取得地址的域名请求，相关判断可能涉及解析；归属判断也不是对目标实际位置的绝对保证。FINAL在前面的规则均未命中时指定兜底策略，不会修复错误的 DNS 响应或不可达的解析服务器。
更换 DNS 可能改变返回的目标地址，进而影响 IP 类规则的匹配结果；反过来，代理出站和网络条件也可能影响解析服务能否连接。处理问题时应把“域名如何解析”和“解析后如何出站”分别记录，避免同时修改两者后无法判断原因。
六、用固定条件验证，不用单次网页加载下结论
DNS 缓存、连接复用以及网站的多地址调度都会影响观察结果。切换设置后，原来的网页连接可能继续工作，新开的域名却失败；这不一定是设置没有保存。建议选择一个自己确认正常的公开域名和一个实际出现问题的域名，保持测试条件一致，分别记录解析阶段与连接阶段。
- 建立基线：固定在同一个 Wi-Fi，记录当前 DNS 方式、Global Routing、选中的服务器、目标域名及错误提示。
- 确认基础连接：在 Home 使用 Connectivity Test 检查其测试目标的连通情况。测试成功只说明该测试路径可用，不代表所有域名与全部 DNS 查询都正常。
- 单项变更：只更换 DNS 方式，按应用提示应用设置；对同一目标进行三轮新的访问，记录成功、超时或明确错误，不把三轮结果包装成长期性能结论。
- 检查网络差异：随后切换到蜂窝网络，保持其他条件不变。若仅 Wi-Fi 失败，优先检查该网络的解析与端口限制。
- 回退复核：恢复原设置后重做同样测试。只有故障随设置切换稳定复现，才有依据把它归因于该解析路径。
判断依据：解析成功后仍超时，就继续查连接
如果记录已经显示目标地址，而失败发生在后续连接阶段，下一步应核对规则命中、出站策略与目标端口；如果始终无法取得地址，再集中检查 DNS 服务可达性、DoH 启动解析和缓存影响。
七、DNS 设置常见问题
DoH 开了以后网页更慢，要不要继续用？
先在同一网络、同一 Global Routing 下与原解析方式对照。DoH 首次连接可能包含启动解析、TLS 建连等开销，后续连接还可能复用。若多轮新访问都明显变慢或超时，先恢复原设置，再检查该端点的可达性；不要把“加密”当成必然更快。
公司或家里的内部域名打不开，换公共 DNS 有用吗？
内部域名可能只有当前网络的解析服务器知道。先恢复网络原有 DNS，确认内部域名是否恢复；若需同时使用不同解析路径，应根据当前 Config 支持的设置进行明确区分。不要把仅内部可用的域名持续发送给不掌握该记录的外部解析服务。
换了 DNS 还是有部分网站打不开，是 IPv6 的问题吗？
不能仅凭部分网站失败就下结论。先查看是否返回 AAAA 记录，以及失败是否发生在 IPv6 连接阶段；有 AAAA 记录只说明存在 IPv6 地址，不证明当前网络具备可用路径。记录现有 IPv6 相关设置后再逐项测试，不要同时修改 DNS、规则和多个网络选项。
订阅更新失败，直接换 DNS 就能修好吗？
先在 Home 对用户已有订阅发起更新，并记录具体错误。若提示域名解析失败，再检查订阅域名的解析；若是 HTTP 状态错误、凭据失效或响应内容无法解析，更换 DNS 通常不能解决。订阅更新与业务连接可能使用不同路径，应分别验证。
保留最终可用设置时，同时记下测试网络与当前 Config。下次更换网络或更新 Config 后出现异常，先比较这些条件，再决定是否调整 DNS。有关 Global Routing 和规则检查，可继续查看选项手册中的 Global Routing 说明与规则说明。