Shadowrocket（小火箭）的 DNS 设置负责域名解析，不等同于代理出口选择。本文以用户已有可用连接配置为前提，从系统 DNS 建立基线，再说明何时改用自定义 DNS 或 DNS over HTTPS、怎样识别配置覆盖，以及如何通过解析记录和规则命中验证修改结果。
一、先区分解析服务器、查询传输与访问出口
打开网站前，设备通常需要把域名解析为 IP 地址。DNS 回答“这个名字对应哪些地址”；Global Routing 和规则回答“这条连接通过哪条路径访问”。两者相互影响，但修改 DNS 不会自动把网站流量改为 PROXY，也不会替换用户已有的连接服务。
“系统 DNS”和“自定义 DNS”主要区分解析服务器从哪里取得；DNS over HTTPS（DoH）描述的是查询如何传输。因此，自定义 DNS 也可以使用 DoH，并不是必须在三个互斥的开关之间选择。下面按实际设置方式分成三类，便于建立测试顺序。
端口只是常见约定，不是可用性的证明。DoH 需要正确的 HTTPS endpoint、有效证书和可达的网络路径；普通网页能通过 HTTPS 打开，不代表同一主机提供 DNS 查询接口。本文中的保留地址和示例域名只用于解释格式，不作为可用解析服务。
二、系统 DNS、自定义 DNS 与 DoH 怎么选
系统 DNS：建立排查基线
推荐沿用系统当前可用的解析安排，通常与接入网络有关。切换 Wi-Fi 与蜂窝网络后，实际解析环境可能变化；系统安装的 DNS 配置也可能参与其中，不能一概等同于路由器地址。
适合:首次验证、恢复默认行为、确认问题是否由自定义设置引起
自定义 DNS：固定解析目标
明确指定解析服务器，减少切换网络时的变量。若填写普通 IP 地址并使用传统 DNS，查询本身不因“自定义”而获得加密；服务器地址也必须能从实际查询路径访问。
适合:已有明确的解析服务器、内网域名要求、需要重复对照的测试
DNS over HTTPS：加密查询传输
把 DNS 查询封装在 HTTPS 中，保护客户端到解析服务之间这段查询传输。它不隐藏解析服务自身看到的查询，也不保证网站访问出口、最终连接质量或解析答案一定符合预期。
适合:已有可信且可达的 DoH endpoint、需要加密 DNS 传输的环境
结论：先确认默认解析，再单独替换 DNS
先保存一份系统 DNS 下的访问结果，再只改解析方式；不要同时更换服务器、Global Routing 和规则文件，否则即使恢复访问，也无法确定是哪项修改起作用。
DoH 不等于“所有 DNS 都经过代理”。查询走直连还是代理，要结合当前配置与实际记录判断。若 endpoint 本身不可达，或者其主机名无法完成初始解析，启用 DoH 反而可能使多个网站同时出现解析超时。
三、修改前先确认 Settings 与 Config 的有效设置
先在 Home 记下当前服务器和 Global Routing，再检查 Settings → DNS 中已有的设置，同时到 Config 查看当前选用的配置文件。活动配置可能带有自己的 DNS 参数；不要只看某个输入框已经改变，就认定所有连接都使用了新解析器。界面分组与配置提供的选项可能存在差异，以实际显示的项目为准。
- 保存原值。记录当前 DNS 地址、活动 Config 名称和路由模式，保留可恢复的配置副本。若配置由订阅或远程文件维护，先确认后续更新是否会覆盖本地修改。
- 建立基线。保持同一 Wi-Fi、同一服务器和同一测试域名，使用系统 DNS 访问一次，记录成功、超时或解析错误，不要只记录页面加载快慢。
- 选择一个修改来源。使用 Settings 中的 DNS 项，或者编辑自己维护的活动 Config；避免在多个位置写入含义不同的设置后再猜测优先关系。
- 核对格式。普通 DNS 输入服务器地址；DoH 输入完整的 HTTPS endpoint，路径也必须与解析服务说明一致。不要把订阅地址或网站首页当作 DNS endpoint。
- 重新建立连接。保存后断开并重新连接 Shadowrocket，关闭旧网页连接，再发起新的域名访问；后续用记录确认本次请求，而不是沿用旧会话作判断。
在自己维护的文本配置中，下面展示三种 dns-server 写法。每次只保留一种，不要把三个 [General] 段合并复制。系统写法可用于恢复基线；其余两项是不可直接使用的格式示例，必须替换为用户已有且经过确认的解析信息。
# 系统 DNS
[General]
dns-server = system
# 自定义 DNS：192.0.2.53 为文档保留地址
[General]
dns-server = 192.0.2.53
# DoH：example.com 仅表示 endpoint 的格式
[General]
dns-server = https://example.com/dns-query四、DNS 结果怎样影响 DOMAIN-SUFFIX、GEOIP 与 IP-CIDR
域名规则与 IP 规则检查的对象不同。DOMAIN-SUFFIX 检查域名及其子域；IP-CIDR 检查目标 IP 是否属于指定网段；GEOIP 根据 IP 数据库归类。DNS 返回不同地址时，后两类规则可能得到不同结果，但域名后缀本身不会因此改变。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 域名先命中。若请求提供的域名是
www.example.com，第一条即可命中并选择 PROXY，后面的 IP 规则不再决定这条请求的策略。 - 地址参与判断。对于没有先命中域名规则的请求，后续 IP 类规则可能依赖已知目标地址或解析结果；具体是否触发额外解析，还要看规则选项与请求状态。
- 理解 no-resolve。示例第二条的
no-resolve表示不为匹配该规则主动解析域名，并非禁用所有 DNS。若请求已经具有目标 IP，仍可进行网段匹配。 - 保留 FINAL 兜底。
FINAL接住前面没有匹配的请求，应置于末尾。示例中的保留网段只用于说明语法，不代表真实业务网段。
验证这类规则前，要在 Home → Global Routing 选择 Config。Proxy 与 Direct 不按这份 Config 规则列表进行同样的分流；Scene 则需要进一步核对当前场景实际采用的设置。否则看到的出口变化，可能来自模式变化而不是 DNS。
同一域名返回不同 IP 并不自动表示解析异常。CDN 调度、缓存、解析器位置以及 A / AAAA 查询类型都可能造成差异。应把“返回了哪个地址”“命中了哪条规则”“最终连接到了哪里”分开记录，而不是要求每次答案完全一致。
五、修改后如何验证生效：分别测解析与访问
“页面打开了”只能证明这次访问完成，不能单独证明 DoH 已经生效。浏览器可能复用旧连接，设备、应用或解析器也可能保有缓存。优先选择自己能控制并能查看查询记录的测试域名；无法控制域名时，至少记录测试时间并区分旧记录与新记录。
验证方案：同一配置，分开测试两种网络
Wi-Fi 下测试
- 固定服务器、Config 和 Global Routing，不同时修改规则。
- 重新连接后访问测试域名，记录 A / AAAA 结果与解析错误。
- 核对 endpoint 的可达性，留意内网域名是否仍能解析。
蜂窝网络下复测
- 只切换接入网络，保留同一套 DNS 参数。
- 重新发起请求，对比是否仅在某一网络超时。
- 若答案正常但访问失败，继续检查规则、出口及 IPv6 路径。
两种网络都测试成功后再保留新设置；仅一侧失败时，优先检查该网络到解析服务的路径。
- 先找解析记录。在可用的 DNS 或连接日志中查找本次测试域名，核对时间、返回地址和错误。若日志没有显示解析服务器或传输方式，就不能仅凭这份日志断言使用了 DoH。
- 再找规则命中。确认记录中的策略与规则行一致。例如域名本应命中
DOMAIN-SUFFIX，却落入FINAL，需要检查实际请求域名和活动 Config。 - 最后看连接结果。有有效地址但 TCP 连接超时、TLS 握手失败，通常还需检查连接路径与目标站点；不要把所有错误都归到 DNS。
- 必要时恢复对照。还原原始 DNS，保持其他设置不变，再测同一域名。如果恢复后立即正常，才有依据进一步检查新解析服务或 endpoint 路径。
若需要证明查询确实通过 DoH，最直接的证据是解析服务端的请求记录，或能够明确显示 HTTPS 查询目标的诊断信息。解析耗时变短、结果地址改变、浏览器出现安全锁标记，都不能替代这类证据。
六、常见问题：超时、内网域名与更新覆盖
填了 DoH 地址后，所有网站都打不开怎么办？
先恢复保存的系统 DNS 基线并重新连接。确认访问恢复后，逐项检查 endpoint 的完整路径、证书、端口与可达性；若主机名自身无法解析，还需检查初始解析条件。不要一次加入多个未知 endpoint 掩盖问题。
网页正常，但公司内网域名打不开，应该换 DNS 吗？
先确认设备已接入所需内网，再确认该域名是否只能由内网 DNS 回答。公共解析服务通常没有企业内部记录；恢复内网可用的解析方式，或按组织提供的域名分流要求配置，不要把内部域名提交给不相关的解析器反复测试。
改完设置，为什么日志里还是旧 IP？
先核对记录时间，关闭旧网页会话并重新连接，再发起新请求。缓存尚未到期或应用复用了旧连接时，可能看不到新的 DNS 查询。若仍无变化，回到 Config 检查实际选用的文件，而不是反复填写同一地址。
只有部分网站失败，需要关闭 IPv6 吗？
先分别查看 A 与 AAAA 结果，再核对失败连接实际使用的地址族。AAAA 回答存在，不代表当前出口具备可用 IPv6 路径。只有记录支持这一判断时，才做单变量对照；不要用全局关闭 IPv6 代替定位。
为什么更新后 DNS 又变回去了？
到 Config 查看活动配置是否来自远程更新，并对照更新前保留的副本。节点订阅更新与完整配置更新不是同一回事，先确认更新对象；需要长期保留本地 DNS 修改时，应维护自己的配置副本并明确后续合并方式。
排查期间若连接状态自动变化，还应检查 Settings → On Demand，确认是否存在自动连接条件。测试时记录其当前状态，避免手动断开后立即重连导致误判；测试结束后再恢复原有自动连接安排。
最终保留设置的标准是：目标网络下解析稳定、所需内网域名可用、规则命中符合预期，并且能够还原原配置。DNS over HTTPS 解决的是查询传输方式，不能替代对服务器连通性、Global Routing 和规则顺序的检查。