适合已有自己的连接配置、正在排查域名解析或希望调整解析方式的读者。先以系统 DNS 建立可用基线；需要指定解析服务器时再改 dns-server；需要加密 DNS 查询时检查 DoH 地址及其可达性。每次只改一项，并分别验证域名访问与连接状态。
先分清 DNS、规则匹配与连接出口
DNS 将域名转换为可用于连接的地址。Shadowrocket 中的一次访问还可能经过规则匹配，再按规则决定连接出口。因此，“网页打不开”不能直接归因于 DNS：域名解析成功后，所选服务的连接也可能失败；反过来，某条规则需要地址信息时，解析结果又可能影响匹配。
在 Home 查看当前连接状态与 Global Routing。Proxy 表示流量统一经过所选连接，Direct 表示直接连接，Config 按当前配置中的规则处理，Scene 则依场景设置工作。调整 DNS 前先记下当前姿态：如果切换姿态的同时修改解析设置，之后很难判断是哪一处改变了访问结果。
规则也要分类型看。DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址段匹配，GEOIP 涉及地址归属判断，FINAL 处理前面未命中的请求。解析方式并不能替代规则；例如将 dns-server 改为另一个地址，不会自动把 FINAL,DIRECT 改成代理出口。
三种方式各解决什么问题
系统 DNS 适合作为第一轮排查的基线。它沿用设备当前网络环境提供的解析设置，少了一项需要手动维护的服务器地址。切换 Wi-Fi 与蜂窝网络后，所使用的上游解析环境可能随网络变化；如果只有某个网络无法打开特定域名，就值得分别记录两种网络的表现。
系统 DNS 与自定义 DNS
- 系统 DNS
- 先保留当前网络的解析方式
- 自定义 DNS
- 在 Config 指定可达的解析服务器地址
- 先查什么
- 同一域名在 Wi-Fi、蜂窝下是否表现一致
需要稳定复现问题时，固定测试网络和 Global Routing。
DNS over HTTPS
- 传输
- 通过 HTTPS 向 DoH 服务端发送 DNS 查询
- 地址
- 使用服务端提供的完整 HTTPS URL
- 先查什么
- 该 URL 在当前网络下是否可达
DoH 加密的是对应的 DNS 查询传输，不等于改变全部连接的出口。
自定义 DNS 适合需要明确指定解析服务器、或比较不同上游解析结果的情形。传统 DNS 通常使用 53 端口；DoH 则通过 HTTPS 连接，通常使用 443 端口。端口不同只说明传输方式不同，不能单凭端口判断域名是否会解析成功。
选择顺序：先建立基线，再增加变量
首次排查先用系统 DNS 测试同一域名；只有需要固定解析上游时才填写 dns-server。选择 DoH 时，还要单独验证 DoH 服务端的可达性，不能把解析失败直接当成连接规则错误。
在 Config 中填写 dns-server 与 DoH
先在 Config 找到正在使用的配置，确认它是当前启用的那一份，再编辑其中的 [General] 段。修改前保存一份原有文本，尤其要保留已有的规则和其他设置。不同配置来源可能会覆盖手工改动；若配置由用户已有的订阅更新而来，更新后应重新核对这一段。
- 在 Home 确认当前配置名称与 Global Routing，记录一个可重复测试的域名。
- 打开 Config，编辑对应配置的 [General]；先只调整 DNS 相关行，不同时改动 Rule 内容。
- 保存后回到 Home，用相同网络、相同路由姿态重试访问；若失败，恢复原值并检查配置文本是否正确保存。
以下片段分别演示三种写法，属于替换选择，不应把三个示例的 dns-server 行原样叠加到同一个 [General] 段。系统解析可写为：
[General]
dns-server = system指定解析服务器时，dns-server 填入实际可用的 DNS 地址。下面的地址仅用于说明字段格式；是否适合当前网络，应由实际连通测试决定：
[General]
dns-server = 1.1.1.1使用 DoH 时，doh-server 填写服务端提供的完整 HTTPS 地址。下例中的 example.com 是格式示意，不能作为可用的 DoH 服务端；实际配置时应替换为你已确认可用的地址，并按应用内当前字段说明核对写法：
[General]
doh-server = https://example.com/dns-query改动后怎样验证，怎样定位失败
验证应分两层进行。第一层看 DNS：目标域名在相同网络下是否能够得到可访问的结果。第二层看连接：地址已有结果后，请求是否按预期规则走向正确出口。只测试一个网页无法区分这两层，因为浏览器缓存、站点自身状态以及现有连接都可能干扰观察。
- 记录修改前的网络类型、Global Routing、所选配置与目标域名；在 Home 运行 Connectivity Test，留下一次连接状态基线。
- 保存一项 DNS 改动，断开后重新连接。先访问一个此前可稳定打开的域名，再访问需要排查的域名，分别记录现象。
- 若两者都失败，检查 [General] 拼写、DNS 地址或 DoH URL 的可达性；若只有特定域名失败，再检查该域名所命中的规则及服务本身。
- 恢复原设置重复测试。恢复后立即正常，说明新设置值得继续排查；恢复后仍失败，则应回到连接、网络与规则层面查找变化。
对 IP-CIDR 或 GEOIP 相关规则尤其要留意解析结果与匹配顺序。规则自上而下检查，先命中的规则会影响后续处理；FINAL 是兜底，不会纠正前面已经命中的规则。检查时不要只看 DNS 字段，还要对照 Config 的规则段以及 Home 中是否选择了 Config 姿态。
判断依据：复现条件要相同
比较两次结果时固定网络、配置、Global Routing 和测试域名，每轮只改一项 DNS 设置。若同时切换 Wi-Fi、更新配置并改写规则，测试结果无法明确归因。
常见疑问与边界
填了 DoH 地址，为什么网页反而打不开？
先确认 URL 是实际服务端提供的完整地址，而不是本文的 example.com 示意值。再恢复原 DNS 设置测试同一域名；若恢复后正常，检查当前网络能否连接该 DoH 服务端，以及配置是否保存到了正在使用的 Config。
系统 DNS 能访问，自定义 DNS 失败，该改规则吗？
先不要改规则。保持 Home 中的 Global Routing 不变，核对 dns-server 是否填写了可用地址，并在同一网络重试。只有确认解析已有结果、连接仍不符合预期时，再检查 DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 的匹配顺序。
切换 DNS 后，为什么旧网页看起来没有变化？
先断开并重新连接，再发起一次新的访问。已有连接与缓存可能继续呈现旧状态；测试时记录一个之前未访问过的目标，并与稳定可访问的域名对照，不要只反复刷新同一页面。
订阅更新后，手工填写的 dns-server 不见了？
在 Config 核对当前启用配置及其 [General] 内容。若更新替换了配置文本，手工修改可能随之消失；保留原设置记录，并根据自己的配置管理方式决定修改应放在哪一份配置里。
Shadowrocket 是 Apple 平台的付费应用，获取入口是 App Store；iPhone、iPad 为主要使用设备，其他兼容设备及系统要求以 App Store 页面标注为准。客户端买断与连接服务是两回事：本文只讨论应用内 DNS 设置，操作前提是用户已经拥有自己的连接配置。