本文适合已经在 Home 选好服务器、希望调整域名解析方式的用户。先用系统 DNS 建立可用基线，再在 Config 的当前配置中核对 dns-server。需要 DNS over HTTPS 时，使用自己已确认可用的完整端点，并分别检查解析、规则与连接结果。涉及代理连接的操作以用户已有自己的服务商与订阅为前提。
DNS 设置影响解析，不等于改变连接策略
Shadowrocket（小火箭）中的 DNS 设置用于决定域名如何取得 IP 地址。浏览器访问一个域名时，取得地址与建立连接是两个阶段。解析成功只能说明获得了结果，不能证明该地址对应的服务可达，也不能证明当前服务器能够完成后续连接。
Home 用来选择服务器与控制连接，Config 用来管理配置文件，Settings 用来调整应用设置。本文采用 Config 中的文本配置路径说明 DNS，便于明确记录修改项。开始前先确认当前选中的配置文件，避免只编辑了一个未启用的副本。
Global Routing 下的 Config 按配置规则处理连接；Proxy 与 Direct 用于采用相应的全局路由姿态；Scene 按选定场景应用设置。它们不能与 DNS 传输方式画等号。选中 Proxy 不代表所有解析都自动变成 DoH，选中 Direct 也不能单独证明解析一定来自系统 DNS。
系统 DNS、自定义 DNS 与 DoH 的选择条件
这里的“自定义 DNS”专指手动填写传统解析服务器地址。广义上，手动填写 DoH 端点也属于自定义设置。比较时要区分“解析请求交给谁”与“请求用什么方式传输”，否则容易把一个地址变化误认为传输已经加密。
系统 DNS
推荐使用系统当前提供的解析环境。作为首次配置和故障排查的基线，可以减少额外端点不可达、证书错误等变量。此处推荐的是起步顺序，不是所有网络下的最终选择。
适合：首次连接、恢复基线、访问依赖本地解析的网络资源
自定义传统 DNS
指定一个已知解析服务器的 IP 地址。传统 DNS 本身不提供传输加密；实际可达性取决于当前网络与路由。仅更换 IP 地址不能解决所有域名访问问题。
适合：网络管理员已指定解析服务器、需要对照解析结果
DNS over HTTPS
把 DNS 查询通过 HTTPS 发送到支持 DoH 的端点。必须使用解析服务明确给出的完整 URL，不能把普通网站首页当成解析接口。它保护的是到该端点的传输，解析服务仍能处理查询内容。
适合：已有可信且可达的 DoH 端点、需要加密 DNS 传输
结论：先固定一条可用基线
系统 DNS 可以正常访问目标域名时，先保存这份配置，再单独切换 DoH。若切换后才失败，优先核对端点与到端点的连接，不要同时更换服务器和路由规则。
在 Config 中填写 DNS：先备份，再改一项
文本配置中的常用入口是 [General] 段下的 dns-server。以下操作只修改当前配置的解析设置，不需要重新导入已有订阅。若配置来自远程更新，先保留本地副本，因为后续更新可能覆盖本地修改。
-
记录基线
在 Home 记录已选服务器与 Global Routing 的当前值。在 Config 确认选中的配置，并通过该配置的操作菜单保留一份副本。
-
打开文本
进入 Config → 当前配置右侧 ⓘ → Edit Plain Text。找到已有的
[General]段与dns-server，直接修改原有键值，不重复增加同名键。 -
填写解析
恢复系统解析时填写
dns-server = system。使用传统 DNS 时填写自己已确认可用的解析服务器 IP；使用 DoH 时填写服务说明给出的完整 HTTPS 端点。 -
保存重连
保存后回到 Config，确认启用的仍是刚修改的配置。回到 Home 断开并重新连接，使测试建立在重新加载后的设置上。
-
复测域名
在相同网络、相同服务器与相同路由姿态下重新访问目标域名。记录解析是否返回结果，以及后续连接是否成功，再决定保留或恢复。
恢复系统 DNS 的最小片段如下。它表示配置内容，不是需要整份替换的文件。已有 [General] 时，只修改其中对应的一行，保留其他参数与后续规则。
[General]
dns-server = systemDoH 地址怎么填：完整 URL、证书与起始解析
DoH 地址包含协议、主机名和服务路径。常见路径是 /dns-query，但不是每个服务都使用这个路径。应复制已有解析服务提供的端点，而不是自行拼接。若端点指定了非默认端口，也必须保留该端口。
[General]
dns-server = https://resolver.example.com/dns-query上面的 resolver.example.com 是保留示例域名，只用于解释格式，不能作为可用解析服务粘贴测试。实际填写时应使用自己的有效端点。URL 应保持服务要求的大小写、路径和必要参数，不要将普通网页地址或订阅链接填入 DNS 字段。
- HTTPS 握手：设备时间明显错误、证书不受信任或端点域名不匹配，都可能导致查询发送前失败。先核对时间与服务端证书，不要通过忽略证书验证处理。
- 起始解析：端点使用主机名时，连接它之前仍需取得地址。若起始解析不可用，改成 DoH 后可能仍然超时，不能简单归因于业务域名。
- 端点路由：访问 DoH 服务本身也是一条连接。其路由与依赖条件需要能够成立，避免形成“连接解析服务又依赖该解析服务”的循环。
- 返回内容：普通网页能打开，不代表相同主机名下的 DoH 接口有效。接口路径错误、身份验证失效或返回网页，都不等同于 DNS 应答。
不要把域名直接替换为随意查到的 IP 地址来修复 HTTPS。这样可能破坏证书名称校验，也可能失去服务要求的主机名信息。需要固定地址时，应依据解析服务与应用支持的配置方式处理。
解析异常排查：区分无结果、错误结果与连接失败
排查时先保留失败现场：当前网络类型、目标域名、启用的配置、Global Routing 值和大致错误信息。每轮只改变一个条件。若同时更新订阅、更换服务器并改 DNS，即使恢复访问，也难以确定真正有效的修改。
| 可观察现象 | 先检查 | 下一步操作 |
|---|---|---|
| 切换 DoH 后多个域名均超时 | 端点完整 URL、证书、端点可达性 | 恢复 system 复测；只在基线恢复后重新检查 DoH |
| 已有解析结果，但页面连接超时 | 实际命中的策略与服务器连接 | 核对 Global Routing 与配置规则，不先反复更换 DNS |
| 公共域名正常，内网域名失败 | 是否依赖局域网提供的解析结果 | 恢复当前网络的系统解析验证，再考虑保留本地解析需求 |
| Wi-Fi 正常，蜂窝网络失败 | 两种网络到解析端点的可达性 | 固定服务器与配置，仅切换网络，分别记录结果 |
| 修改后表现没有变化 | 编辑的配置是否已启用、旧连接是否仍在复用 | 确认 Config 选中项，重连并重新发起业务请求 |
规则排查需要同时理解域名条件与地址条件。DOMAIN-SUFFIX 匹配域名后缀；IP-CIDR 与 GEOIP 依据 IP 条件匹配；FINAL 处理前面没有命中的连接。更换解析结果可能影响地址类规则的命中，但不会自动修正规则顺序。
对照 Global Routing 的 Config 与 Proxy 可以辅助判断规则影响，但不要把临时测试姿态当成长期修复方案。若只在 Config 下失败，应检查具体命中的策略。涉及地址类规则时，还要核对是否存在 no-resolve 等影响解析行为的选项。
结论：取得地址后转查连接链路
同一个域名已经稳定返回地址，而失败发生在后续连接时，把排查重点转到策略、服务器和目标服务。继续轮换 DNS 会引入新的变量，反而使故障边界更难确认。
保存配置前的检查与恢复顺序
解析配置应随实际使用网络验证。公共解析服务不一定知道家庭或办公网络的内部名称；加密传输也不意味着结果更适合当前网络。对于需要同时访问内网和公共服务的设备，应先确认本地解析需求，再安排更细的配置。
- 检查配置来源：远程配置更新后重新核对
dns-server。订阅更新主要用于同步服务商提供的服务器信息，不应把它当作 DNS 故障的固定修复步骤。 - 检查自动连接：在 Settings → On Demand 核对是否启用了按需连接。手动断开后若马上再次连接，应先确认自动连接条件，避免误判为修改未保存。
- 检查 IPv6：返回 AAAA 记录与具备可用 IPv6 连接是两件事。存在地址但连接失败时，结合当前网络的 IPv6 可达性判断，不要仅凭记录类型下结论。
- 恢复最小基线：先恢复备份配置或
dns-server = system，再重连并复测。基线恢复后，逐项重新加入需要保留的设置。
Shadowrocket 是 Apple 平台的闭源商业应用，以 iPhone、iPad 使用为主，唯一获取入口是 App Store。系统要求以 App Store 页面标注为准。客户端一次性买断与线路套餐是两项独立事项；DNS 配置也不会增加或替代用户已有的线路服务。