本文适合已经完成 Shadowrocket 连接配置、需要调整域名解析方式的用户。先区分 DNS 服务器、DNS 传输方式与请求出站策略,再通过 Config 中的最小配置逐项验证。系统 DNS 适合作为基线,自定义 DNS 用于明确指定解析器,DNS over HTTPS 用于加密客户端与解析器之间的查询;三者都需要结合当前网络、规则和实际解析结果判断。
一、先区分 DNS 解析与连接出站
Shadowrocket(小火箭)中的 DNS 设置解决“域名对应哪些地址”的问题,Global Routing 和规则解决“连接如何出站”的问题。网页打不开可能发生在这两个环节中的任意一个,也可能是目标服务本身异常。仅更换 DNS,不能修复服务端口不可达、连接认证失败或目标网站拒绝访问。
下面展示需要本地解析时的简化路径。实际处理中,域名规则可能先于地址规则命中;某些代理请求也可能把域名交给远端处理,因此并不是每条连接都会完整经过同一条本地 DNS 路径。
还要留意应用自己的解析机制。浏览器或其他应用可能使用独立的加密 DNS,已有连接与缓存也可能复用旧地址。Config 中填写了一个解析器,并不等于设备上所有应用的每一次查询都一定经过它。排查时应固定同一应用、同一域名和同一网络,避免把不同请求混在一起比较。
二、系统 DNS、自定义 DNS 与 DoH 的区别
系统 DNS 通常沿用当前网络提供的解析设置,切换 Wi-Fi 或蜂窝网络后,实际解析器可能变化。自定义 DNS 则由配置明确指定解析器地址。“自定义”描述的是选择方式,不代表传输已经加密;DNS over HTTPS,简称 DoH,描述的是通过 HTTPS 传输 DNS 查询,它也属于可以自定义的解析方式。
| 设置方式 | 解析器来源 | 传输特点 | 优先核对场景 |
|---|---|---|---|
| 系统 DNS | 当前系统与网络设置 | 不能仅凭此名称判断是否加密 | 网络登录页、家庭网络、内部域名 |
| 自定义普通 DNS | 配置中指定的 IP 地址 | 通常使用 UDP 53,也可能使用 TCP 53 | 需要固定解析器并比较解析结果 |
| DNS over HTTPS | 配置中指定的 HTTPS 端点 | 常见端口为 443,需要完成 TLS 连接 | 需要加密 DNS 查询且端点可达 |
结论:先建立基线,再决定是否改用 DoH
先用系统 DNS 记录目标域名能否解析,再单独切换一种解析方式复测。若普通 DNS 可用而 DoH 超时,应先检查 DoH 端点的 HTTPS 可达性,而不是同时改动规则和连接配置。
DoH 加密的是到所选解析器之间的查询传输,解析器仍然需要处理查询内容。它不保证返回地址一定更快,也不保证内部域名可解析。解析器返回的地址、目标服务的地域调度以及网络路径都可能影响最终访问体验。
三、在 Config 中设置 DNS:先备份,再单项替换
操作前确认用户已有自己的服务商与订阅,并已完成基本连接验证。Subscribe 导入或更新处理的是用户已有的连接信息,不能直接视为 DNS 配置已经完成。本文只调整当前 Config 的解析设置,不涉及服务来源选择。
- 进入 Config,确认当前实际使用的配置文件,并保存副本。不要只修改一个未启用的文件。
- 打开该配置的编辑入口,找到
[General]段和dns-server项。编辑入口的文字或图标可能随界面变化,以当前显示为准。 - 若已经存在
dns-server,修改原有项,不要在文件末尾重复添加多个同名设置。 - 保存并确认该配置仍被选用,返回 Home,在可以中断连接的情况下重新连接,再测试同一域名。
- 保留改动前后的解析结果与错误信息。未改善时先恢复副本,再进行下一项测试。
以下三个片段是互斥的最小示例,每次只选一个替换当前配置中的对应项。它们不是完整配置文件,不应覆盖原有规则与连接信息。示例中的公共解析器仅用于说明语法,是否采用应结合可达性和其服务政策判断。
方案 A:沿用系统 DNS
[General]
dns-server = system
system 表示使用系统 DNS。它适合建立对照基线,也适合依赖本地解析器的环境。若内部域名在未连接时可用、改成公共 DNS 后不可用,应优先核对该域名是否只有本地网络的解析器知道。
方案 B:明确指定普通 DNS
[General]
dns-server = 1.1.1.1
这里只指定一个解析器,便于隔离变量。普通 DNS 地址不需要加 https://,也不要把网页地址填入普通服务器地址位置。若当前网络限制外部 DNS,指定 IP 后依然可能超时;这时应先恢复系统 DNS 验证,而不是连续增加更多地址。
方案 C:指定 DNS over HTTPS
[General]
dns-server = https://1.1.1.1/dns-query
DoH 需要完整端点,协议、主机和路径均有意义;只填写一个解析服务的首页并不等于填写了 DoH 地址。这个示例使用支持该 IP 地址证书的端点,不能据此把其他域名端点随意改成 IP,否则可能发生证书校验失败。
四、DNS 与 Global Routing、规则如何配合
在 Home 核对 Global Routing:Config 按当前配置规则处理连接,Proxy 和 Direct 分别用于代理或直连姿态,Scene 按已设置的场景选择工作方式。排查规则问题时应先固定姿态;停留在 Proxy 或 Direct 后,再用 Config 中的分流规则解释访问结果,容易得出错误结论。
DNS 配置核对
- 位置
- Config → 当前配置 → 编辑
- 配置段
[General]- 配置项
dns-server- 验证条件
- 保存、选用配置并重新连接
修改未启用的配置,不会改变当前会话的解析设置。
规则关键字核对
- DOMAIN-SUFFIX
- 按域名后缀匹配
- IP-CIDR
- 按 IPv4 地址段匹配
- GEOIP
- 按 IP 地理数据库匹配
- FINAL
- 前面均未命中时使用的最终规则
规则按顺序判断;地址类规则可能涉及解析结果。
下面仅展示规则语法,不能直接替代完整配置。192.0.2.0/24 是文档示例网段,不是需要访问的服务地址。DOMAIN-SUFFIX 可以根据域名匹配,地址类规则则需要结合已知目标 IP;附加 no-resolve 的含义是不为该条地址规则主动触发域名解析,而不是禁止整条连接使用 DNS。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
DNS 返回了地址,也不代表后续一定按预期出站。应分别核对解析结果与规则命中记录;如果域名已命中前面的规则,继续修改后面的 GEOIP 或 FINAL 不会改变这次匹配。也不要仅凭 Global Routing 的名称推断 DNS 查询本身的出站路径,具体还取决于当前 DNS 相关设置及实际记录。
五、解析异常的核对顺序
Connectivity Test 用于观察所选连接的测试结果,不等同于完整验证某个网站的 DNS、TLS 和业务访问。测试结果正常但网页失败时,应把“没有获得地址”和“获得地址后连接失败”分开排查。以下步骤不依赖虚构的速度数据,每一步都要求记录可复现的现象。
- 固定网络与样本。记录 Wi-Fi 或蜂窝网络、目标域名、当前 Config 和 Global Routing。优先选择实际失败的域名,再加一个已知正常的域名作对照。
- 确认配置生效。保存后重新连接,检查是否仍使用刚刚修改的文件。若配置会被远程更新覆盖,应在副本中测试,并在更新后重新核对。
- 区分错误阶段。没有地址、查询超时、返回不存在,与拿到地址后的连接超时不是同一问题。结合可用的连接记录或目标应用错误提示判断,不能仅凭“网页打不开”认定 DNS 故障。
- 恢复系统 DNS 作对照。若恢复后立即可用,而指定解析器持续失败,优先检查该解析器在当前网络是否可达,以及是否需要访问内部域名。
- 单测 DoH 条件。检查端点拼写、HTTPS 路径、设备时间和证书错误。普通 HTTPS 网站能打开,只能说明部分 HTTPS 连接可用,不能证明特定 DoH 端点必然可达。
- 核对 A 与 AAAA。若已经返回地址但访问仍失败,检查是否只在某一种地址族上异常。IPv6 路径问题不能简单归结为解析器错误,也不应先批量删除 IPv6 相关配置。
- 最后处理缓存与自动连接。重新建立连接,并重新打开目标应用;同时核对 Settings → On Demand,避免测试期间自动重连改变连接状态。不要把清缓存当作替代前面核对步骤的固定答案。
结论:得到地址后,转查连接与规则
当同一目标已稳定返回 A 或 AAAA 记录,却仍在连接阶段超时,应检查规则命中、所选连接和目标服务端口。此时继续轮换解析器,通常不能定位真正的失败环节。
六、常见问题:设置后仍异常怎么处理
改成 DoH 后,为什么第一次打开网页更慢?
DoH 连接可能包含端点引导解析、TLS 建连和查询过程。先在同一网络连续测试同一域名,区分首次连接与后续复用;若每次都长时间等待,恢复系统 DNS 作对照,并核对端点可达性,不要只根据一次打开速度下结论。
公共网站能打开,家里的内部域名打不开怎么办?
先把 dns-server 恢复为 system,在原家庭 Wi-Fi 下复测。若恢复后可用,说明内部名称可能依赖本地解析器。需要同时保留公共与内部解析时,应按现有网络设计配置域名对应的解析策略,不要指望公共解析器知道私人网络里的名称。
填了多个 DNS,是不是就会严格按顺序备用?
不要仅根据地址书写顺序推断严格的主备行为,查询选择与回退受实际实现和配置影响。排查时先只保留一个已知可达的解析器,保存并重新连接;单项验证完成后,再按当前设置支持的机制增加其他解析器。
Subscribe 更新成功,为什么 DNS 设置没有变化?
连接信息的 Subscribe 更新与当前 Config 的 DNS 项不是同一个检查点。返回 Config 核对所选文件,再检查 [General] 中的 dns-server。若更新的是远程配置文件,还要核对远程内容是否覆盖了本地修改。
最终应保留一份能复现结果的记录:使用的网络、Config 名称、Global Routing 姿态、DNS 配置值、目标域名以及失败阶段。分享记录前删除订阅地址、认证信息和私人域名。与其一次改动多个选项,逐项测试并能恢复到可用基线,更便于判断问题究竟发生在哪里。