Shadowrocket DNS 怎么配:系统 DNS、自定义 DNS 与 DNS over HTTPS 取舍

本文速览

本文适合已经导入自己的订阅、准备调整 DNS 的用户。先区分解析与出站，再检查 Settings → DNS 和当前启用的 Config，最后通过同一域名、同一网络、单项改动验证结果。读完可以判断何时保留 system、何时填写自有解析地址，以及 DoH 超时应先查哪一层。

一、调整 DNS 前先确认连接基线

Shadowrocket（小火箭）是 Apple 平台的付费客户端，主要用于 iPhone 与 iPad，唯一获取入口是 App Store。产品页可核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118；应用采用一次性买断，系统要求和通用购买以 App Store 页面标注为准。客户端买断 ≠ 线路套餐，本文以用户已有自己的服务商与订阅为前提。

DNS 把域名转换为 IP 地址，不负责保证后续连接成功。网页打不开，可能是解析超时，也可能是已经得到地址，但目标端口、代理连接或 TLS 握手失败。先记录原始设置，避免把所有异常都归因于 DNS。

在 Home 确认当前使用的连接项目；测试期间固定同一项目，不同时更新订阅或切换协议。
记录 Global Routing 当前选项。使用 Config 时还要记录 Config 中当前启用的配置，后续比较保持一致。
记录 Settings → DNS 的现有内容，并检查启用配置的 [General] 是否已有 dns-server。
检查 Settings → On Demand。测试期间保持连接状态稳定，避免自动连接条件改变导致前后结果不可比。

二、系统 DNS、自定义 DNS 与 DoH 的区别

“系统 DNS”指使用当前网络提供或系统管理的解析器；“自定义 DNS”通常指明确指定一个解析器地址；DNS over HTTPS（DoH）则描述查询的传输方式。自定义地址也可以是 DoH，所以这三项不是完全互斥的协议分类。

域名查询解析器选择查询传输地址返回连接目标

方式	填写形式	适用条件	检查重点
系统 DNS	`system`	当前网络解析正常，或需要访问局域网内部名称。	切换 Wi-Fi 后，网络提供的解析器可能变化。
自定义传统 DNS	用户确认可用的解析器 IP 地址	需要固定解析器，且所在网络允许访问。	通常使用 UDP 53，部分查询会使用 TCP 53；传输本身不提供加密。
DoH	完整的 HTTPS 端点	有可用的 DoH 服务地址，且 HTTPS 路径可达。	通常使用 TCP 443；需检查主机名、证书、路径与初始解析。

传统 DNS 的常用服务端口，涉及 UDP 与 TCP。

443

HTTPS 的默认端口，DoH 常使用此端口。

2 类

常见地址记录：A 对应 IPv4，AAAA 对应 IPv6。

DoH 加密的是设备与所选解析服务之间的查询传输，并不使解析服务无法看到查询，也不自动改变网站流量的出站方式。它还可能增加首次连接的建连成本；速度取决于网络、缓存与端点状态，不能仅凭名称认定更快。

结论：正常解析时先保留原值

只有确认现有解析出现超时、答案异常或不满足查询传输要求时，才单独替换 DNS；不要同时改路由模式和连接项目。

三、在 Settings 与 Config 中填写 DNS

从 Settings → DNS 检查当前解析设置。需要保留系统解析时使用 system；指定传统 DNS 时填写你已确认可用的解析器地址；使用 DoH 时填写服务方提供的完整 HTTPS 端点。地址里必须保留正确路径，不能只填写网站首页，也不能把订阅地址当作 DNS 地址。

如果当前 Config 已明确设置 dns-server，还应在 Config 中打开当前配置的编辑内容，检查 [General]。以下两张卡用于解释填写结构，示例地址均为文档保留值，不是可用解析服务，不应直接保存为实际配置。

传统 DNS 填写结构

检查入口: Settings → DNS
系统解析: system
地址结构示例: 192.0.2.53
配置字段: dns-server

192.0.2.53 是文档示例地址；实际操作使用你已确认可访问的解析器。

DoH 填写结构

地址结构示例: https://dns.example.com/dns-query
传输要求: HTTPS 与有效证书
路径要求: 保留端点提供方给出的完整路径
前置依赖: 端点主机名可解析、连接路径可达

dns.example.com 是文档示例域名；不要将此地址用于实际查询。

若只想在已有配置中明确使用系统解析，可检查该配置现有的 [General] 段是否包含下面的字段。不要为了粘贴示例再创建第二个同名段，也不要删除原有规则和其他参数。

[General]
dns-server = system

保存 Settings 中的改动，或保存正在编辑的配置，确认 Config 中启用的是刚才检查的那一份。
在 Home 断开后重新连接，让新的连接会话使用修改后的设置。重新连接不等同于清空所有应用缓存。
用固定域名重新测试；如果出现新的超时，先恢复记录的原值，而不是继续叠加更多解析地址。

四、DoH 端点与规则分流要分开判断

DoH 使用域名形式的端点时，设备需要先知道端点主机名对应的地址，才能建立 HTTPS 连接，这一步常称为初始解析。如果现有解析已经失效，而新设置又依赖它来找到 DoH 端点，就可能出现“换成 DoH 后所有域名都打不开”的现象。优先恢复可工作的解析基线，再检查端点。

Global Routing 决定连接如何处理，DNS 设置决定如何取得解析结果，两者不能互相替代。排查时注意下列边界，不要为了让某一个网页打开而长期改变整份配置的处理方式。

Config：按启用配置的规则处理。DOMAIN-SUFFIX 根据域名后缀匹配；IP-CIDR 和 GEOIP 涉及地址判断，是否需要本地解析还受具体规则选项和处理路径影响。
Proxy：用于按该姿态处理业务连接，但不能仅据此断言每一条 DNS 查询都经过代理；还要检查 DNS 设置、端点路由和实际记录。
Direct：用于直接连接，并不意味着当前网络的 DNS 一定可用。直接访问与解析是否成功是两个独立检查项。
Scene：涉及所配置场景的选择，不应当作为 DNS 修复按钮。先检查实际应用的场景，再判断测试条件是否一致。

五、怎样验证 DNS 已生效

验证至少要区分三件事：解析器是否响应、返回了什么地址、随后连接是否成功。仅凭网页打开或某次延迟下降，无法确认使用了哪个解析器；缓存可能让一次请求根本没有产生新的 DNS 查询。

固定条件：保持相同 Wi-Fi 或蜂窝网络、同一连接项目、同一 Global Routing 选项和同一 Config。先记录改动前的现象。
选定查询对象：使用你有权限测试、记录状态已知的域名。先测试 A，再检查 AAAA；只有 AAAA 查询失败或 IPv6 连接失败时，应把问题单独记录。
查看解析结果：若当前界面提供 DNS 查询工具，记录结果、耗时及错误；同时结合可用日志检查是否出现端点连接失败、解析超时或证书错误。
排除缓存：已有结果可能来自应用、系统或解析服务缓存。可以关闭并重新打开测试应用，或使用自己域名下另一个已配置记录的名称，不能把不存在的随机域名当成正常解析样本。
检查业务连接：得到 A 或 AAAA 结果后，再观察对应连接的路由与错误。解析成功但 HTTPS 超时，应继续查目标连接，而不是反复改 DNS。

观察现象	能说明什么	下一步
查询超时，没有返回结果	解析链路未完成，尚不能确定是哪一环失败。	恢复原解析器，对比端点可达性与所在网络。
返回 NXDOMAIN	解析器报告该名称不存在，不等同于连接超时。	检查拼写、域名记录和内部域名所需的解析范围。
返回地址，网页仍超时	DNS 已完成至少一次地址查询。	查规则命中、目标端口和后续连接日志。
只有第二次访问变快	可能与缓存或连接复用有关。	分别记录首次与重复访问，不据此推断 DoH 必然更快。

结论：记录错误阶段，比只记“打不开”更有用

每次至少记录网络、解析方式、A 或 AAAA 结果及后续连接错误；若缺少能识别解析器的记录，就只报告“现象改善”，不要认定已证明查询路径。

六、常见 DNS 设置问题

换成 DoH 后一个网页也打不开，先改哪里？

先恢复 Settings → DNS 或当前 Config 中记录的原值，并重新连接。恢复正常后，再逐项核对 DoH URL 的主机名、完整路径、初始解析和证书错误；一次只重新引入一项改动。

公共网站正常，家里设备的名称打不开怎么办？

检查该名称是否由家中路由器或内部 DNS 提供。公共解析器通常不知道局域网内部记录，先恢复 system 进行对照；内部名称还可能涉及 mDNS，不能把所有发现问题都当作普通 DNS 处理。

填写多个 DNS 地址就一定更稳定吗？

不一定。多个解析器的答案、响应时间和内部域名可见性可能不同，也不能默认会严格按填写顺序回退。排查时先保留一个已确认可用的解析来源，记录结果后再评估是否需要增加其他来源。

Settings 改过了，为什么重新启用 Config 后又不一样？

回到 Config 检查当前启用文件的 [General] 和 dns-server，确认是否指定了另一组解析器。如果配置会远程更新，还要检查更新后字段是否被恢复；记录改动位置，避免反复修改没有实际生效的设置。