本文适合已经在 Shadowrocket 配好连接、需要核对 DNS 的用户。先区分解析服务器、查询传输与流量策略，再在 Config 中检查 dns-server，最后按单变量方法排查超时、返回地址异常与网络切换问题。所有操作以用户已有自己的服务商与订阅为前提，示例不提供可用线路或公共解析服务清单。
一、先区分 DNS 解析与连接出站
Shadowrocket（小火箭）是 Apple 平台的闭源商业应用，以 iPhone / iPad 使用为主，唯一购买安装入口为 App Store，采用一次性买断。客户端买断 ≠ 线路套餐；本站不提供、不销售、不推荐节点、订阅或服务商。价格、系统要求与通用购买适用性以 App Store 页面标注为准。DNS 设置是客户端配置的一部分，不会替代用户已有的线路服务。
DNS 的任务是把域名查询为地址等记录，而不是建立网页连接。浏览器访问一个域名时，可能先使用缓存，也可能发起新的查询；获得地址之后，还要完成路由、传输连接与 TLS 握手。因此，“能解析”不等于“能打开”，“连接失败”也不能直接归因于 DNS。
这条流程只用于理解依赖关系，不表示所有请求都会在设备上按相同顺序完整执行。命中缓存时可以跳过查询；某些代理处理方式会把域名交给远端解析；应用自身使用加密解析时，也不一定使用配置里指定的服务器。排障时要先确定正在观察哪一类请求。
二、系统 DNS、自定义 DNS 与 DoH 的取舍
“系统 DNS”和“自定义 DNS”主要描述服务器来源，“DNS over HTTPS”描述查询传输方式，两者不是完全平行的概念：手动指定一个 DoH 地址，同样属于自定义 DNS。系统提供的解析路径也可能受设备上的 DNS 配置描述文件等设置影响，不能简单认定它必然是明文传输。
| 设置方式 | 来源或传输 | 适用前提 | 优先核对 |
|---|---|---|---|
| 系统 DNS | 采用当前系统解析设置 | 当前网络解析正常，需要建立基线 | Wi-Fi 与蜂窝网络的结果是否不同 |
| 自定义传统 DNS | 手动指定服务器，通常使用 UDP / TCP 53 | 已知服务器地址与访问权限 | 服务器可达性、端口与内网访问范围 |
| DNS over HTTPS | 通过 HTTPS 请求解析端点 | 已有可信且可达的完整 DoH 地址 | 域名、路径、TLS 证书与初始解析 |
端口号并不构成服务可用性的证明。某个地址开放 443，不代表它提供 DoH；传统 DNS 也可能在较大响应或特定条件下使用 TCP，不能只检查 UDP。DoH 加密的是客户端到解析服务之间的查询传输，解析服务仍能处理查询内容，也不意味着网页连接自动使用同一条出站路径。
结论：保留可用基线，再替换解析方式
当前网络正常时先记录系统 DNS 的表现；只有明确需要指定解析服务或加密查询传输时，再单独更改 DNS，避免同时修改规则、连接与解析设置。
三、在 Config 中找到并修改 dns-server
先在 Home 确认 Global Routing 的当前选项，再进入 Config 确认正在使用的配置文件。不要只修改一个名称相近但未启用的文件。本文使用配置文本中的 [General] 与 dns-server 说明位置，不依赖不同界面布局中的按钮排列。
- 在 Config 选中当前配置，先保存原文件副本或记下原始 DNS 行，确保能够恢复。
- 打开该配置的编辑菜单，进入可编辑配置文本的入口，找到
[General]分区。菜单显示以当前应用界面为准。 - 查找已有的
dns-server，修改原行，而不是在文件末尾或其他分区追加同名设置。 - 保存后确认该配置仍处于选中状态。需要重新加载时，可在 Home 关闭再开启连接；操作会短暂中断现有连接。
- 使用相同网络与相同测试域名复测，并记录改动前后的结果。失败时先恢复原行，验证是否随之恢复。
系统 DNS 基线
- 配置分区
[General]- 设置键
dns-server- 设置值
system- 核对动作
- 保存、确认选中、重新建立连接
system 表示使用系统 DNS，不代表固定的服务器地址。
DoH 地址核对
- 配置分区
[General]- 设置键
dns-server- 地址组成
- HTTPS scheme、主机名、服务路径
- 文档示例
https://dns.example.com/dns-query
example.com 为文档示例域名，该地址不是可用解析服务，不能直接用于连接。
恢复系统 DNS 时，可将对应设置改为下面的形式。代码只展示相关分区，不是完整配置，不要用它覆盖整份文件。如果当前配置由远程更新维护，更新可能覆盖本地改动，应保留副本并在更新后重新核对。
[General]
dns-server = system四、DNS 与 Global Routing、规则的关系
Home → Global Routing 控制流量处理姿态，不是 DNS 服务器选择器。Config 按当前配置规则处理流量，Proxy 使一般流量采用代理处理，Direct 采用直接连接；Scene 用于按已设置的场景条件处理。切换这些选项不能代替检查 dns-server，也不能单凭选项名称证明 DNS 请求已经加密或走某条特定路径。
DOMAIN-SUFFIX按域名后缀匹配，规则本身不要求先拿到目标 IP；实际连接仍可能需要后续解析。IP-CIDR与GEOIP按 IP 信息匹配，相关行为还取决于请求中是否已有 IP，以及规则是否带有影响解析的选项。FINAL是前序规则未匹配时的最终策略，不是“DNS 失败后的备用服务器”。- Settings → On Demand 控制按条件触发连接，不负责把传统 DNS 转换成 DoH。排查时应记录它是否改变了实际连接状态。
DNS 返回的地址可能影响后续 IP 类规则命中，但也不能反过来把所有规则命中差异都归结为解析。若改 DNS 后访问路径发生变化，应同时检查返回的 A / AAAA 记录、命中的规则和最终出站。不要为了获得某一次访问结果，立即重写整套规则。
五、解析异常按单变量顺序排查
先写清楚现象：是仅一个域名失败，还是所有域名都失败；是查询超时，还是已经返回地址后连接失败；是只在 Wi-Fi 出现，还是蜂窝网络也能复现。一次仅改一项，并记录恢复原配置能否恢复访问，才能把相关性逐步收敛为可验证的原因。
- 确认配置生效。回到 Config 核对当前选中的文件，以及
[General]内的实际值。订阅更新与配置文件更新不是同一件事，更新节点列表并不能证明 DNS 行已改变。 - 恢复系统基线。暂时改回
dns-server = system，保持 Global Routing 与选中连接不变。若立即恢复，再集中检查自定义解析端点，而不是继续更换线路设置。 - 分开测试网络。在 Wi-Fi 与蜂窝网络分别测试。内网 DNS 只在 Wi-Fi 可达属于合理边界；需要网页认证的网络，应先完成该网络的认证。
- 检查 DoH 依赖。核对完整地址、服务路径、设备日期时间与证书错误。端点主机名通常需要先得到地址，初始解析失败可能导致后续 HTTPS 查询无法建立。
- 区分缓存与新结果。重新打开测试页面，留意应用自身及系统缓存。断开再连接并不保证清除所有缓存；不要把仍然命中旧结果判断为设置未保存。
- 核对地址族。只在返回 AAAA 后失败时，应检查当前网络及出站的 IPv6 可达性。不要仅因为存在 AAAA 就删除所有 IPv6 相关配置，应先确认实际失败发生在解析还是连接阶段。
| 观察到的现象 | 优先检查 | 不能直接推断 |
|---|---|---|
| 系统 DNS 正常，自定义 DNS 超时 | 目标地址、端口、网络可达性 | 不能据此认定所有自定义 DNS 都不可用 |
| DoH 出现 TLS 相关错误 | 主机名、证书有效性、设备时间 | 不应靠关闭证书校验掩盖错误 |
| 已返回地址，网页仍无法连接 | 规则命中、出站、目标端口与 TLS | 不能仅凭网页失败认定 DNS 超时 |
| Wi-Fi 正常，蜂窝网络失败 | 解析端点是否为内网地址、两种网络的可达性 | 不能假定同一地址在两种网络中都可访问 |
不要直接用浏览器打开 DoH 端点后，凭空白页或错误页面判断服务是否失效。DoH 需要符合协议的 DNS 请求，普通网页访问不是等价测试。同样，直接访问一个网站的 IP 可能因为 HTTPS 证书、SNI 或虚拟主机配置失败，不能作为“绕开 DNS 后一定正常”的判据。
六、常见操作问题
改成 DoH 后更慢，应该一直等吗？
先恢复系统 DNS，用同一网络与同一域名复测。DoH 可能增加连接建立成本，缓存与连接复用也会影响结果；不要用一次页面加载耗时评价解析速度。确认差异可以重复后，再核对端点可达性及请求路径。
可以把 DoH 域名直接换成 IP 吗？
不要自行替换。HTTPS 证书与主机名校验可能因此不匹配，端点还可能依赖对应主机名。保留已有解析服务提供的完整地址；遇到初始解析问题时，先恢复可用基线，再依据该服务的正式配置说明处理。
填了多个 DNS，就一定按顺序备用吗？
不能把多地址列表直接理解为严格的主备顺序。并发、缓存及具体处理机制可能影响结果。定位问题时先保留一个已知可用的设置，确认其独立工作，再增加其他地址，避免无法判断响应来自哪里。
订阅更新成功，为什么网页还是打不开？
订阅更新只说明获取和解析该订阅内容的流程成功，不能覆盖所有域名与连接路径。回到 Config 检查 DNS，再在 Home 核对 Global Routing 与选中连接；若 DNS 已返回地址，继续检查规则和出站，而不是反复更新订阅。
最终应保留一份能够恢复的配置和一条简明记录：使用的网络、DNS 设置、测试域名、是否返回地址、失败阶段及恢复结果。向已有服务的支持渠道求助时，只提交必要信息，隐藏订阅令牌、认证字段与个人网络信息，不要公开整份配置。