2026-09-09 · 进阶设置 · 约 10 分钟

Shadowrocket DNS 设置:系统 DNS、自定义 DNS 与 DNS over HTTPS 怎么选

对比系统 DNS、自定义 DNS 与 DoH 三种解析方式的工作路径和适用场景,并说明 DNS 设置与分流规则之间的关系,以及常见的解析失败表现。

本文速览

先保留当前可用的 DNS 作为基线，再按需求选择解析器和传输方式。本文适合已在 Shadowrocket 中使用自己配置的用户：说明系统 DNS、自定义 DNS 与 DoH 的区别，给出设置检查顺序，并把解析失败、规则命中与目标连接失败分开处理。

先区分解析器地址与 DNS 传输方式

DNS 用于把域名解析为地址等记录。系统 DNS 指设备从当前网络或系统配置取得的解析设置；自定义 DNS 指主动指定解析器；DNS over HTTPS，简称 DoH，则描述 DNS 查询通过 HTTPS 传输的方式。因此，“自定义 DNS”和“DoH”不是互斥选项，自定义解析器也可以使用 DoH。

选择时先回答两个问题：请求交给哪个解析器，以及通过什么连接交给它。更换解析器可能改变返回的地址；更换传输方式则改变查询的传输路径与保护方式。两者都不等于修改了网页自身的 HTTPS 设置，也不保证目标网站一定可以连接。

方式工作路径优先核对
系统 DNS使用当前系统取得的解析设置，具体请求路径仍受隧道与配置影响。切换 Wi-Fi 或蜂窝网络后，解析结果与内网域名是否变化。
自定义 DNS将查询交给指定解析器；使用普通 DNS 时通常涉及 UDP 或 TCP 53。地址能否到达、端口是否可用、是否需要访问内网域名。
DNS over HTTPS将 DNS 消息通过 HTTPS 发送到解析端点。完整 URL、证书、端点域名的初始解析与实际出站路径。

判断：先保留可用基线，再更换一个变量

如果当前网络可以正常解析，先记录系统 DNS 下的结果；需要固定解析器时再改自定义 DNS，需要加密查询传输时再验证 DoH。不要同时改解析器、Global Routing 和代理配置，否则无法判断哪一步改变了结果。

DNS 查询与网页连接是两个检查阶段

在典型的域名访问中，应用需要取得目标地址，再建立连接。实际过程可能使用缓存，也可能由应用自身解析或由代理端解析，不能把下面的流程理解成每次访问都一定在本地完成全部步骤。

域名请求 解析处理 地址返回 路由决策 目标连接

排查时分别记录“有没有解析结果”和“拿到结果后是否连接成功”。返回了地址，说明该次查询已经得到应答，但地址是否适用于当前出口、目标端口是否可达、TLS 是否成功，仍需继续核对。浏览器显示打不开网页，不能单凭这一现象认定是 DNS 故障。

53
普通 DNS 常用端口，可使用 UDP 或 TCP
443
HTTPS 默认端口，DoH 端点通常使用此端口

端口可达只是必要检查之一。DoH 还需要正确的 HTTPS 路径和有效的证书；把普通 DNS 地址后面的端口从 53 改为 443，不会自动得到 DoH 服务。反过来，DoH 加密的是到解析端点的查询传输，不会让解析器本身看不到查询，也不会自动将全部业务连接改为代理出站。

设置前备份，并核对当前配置是否参与 DNS 处理

在 Shadowrocket 中先从 Home 确认当前连接状态和 Global Routing，再到 Settings → DNS 核对解析设置。同时到 Config 查看当前使用的配置文件：配置内的 DNS 项也可能参与实际行为，不能只凭 Settings 里填了一个地址就判断最终使用了哪个解析器。具体字段与可选项以当前应用内显示为准。

  1. 保存原值。记录现有 DNS 项、当前配置名称和 Global Routing 选项。修改配置文件前保留一份副本，方便逐项恢复。
  2. 确认基线。在当前网络访问一个已知正常的公网域名；需要内网资源时，另选一个实际使用的内网域名作为对照。
  3. 只改 DNS。使用已有且获准使用的解析器参数，不同时更换服务器、规则和协议参数。
  4. 重新建立连接。保存后断开并重新连接，再重新发起访问。已有连接和缓存可能继续使用旧结果，不应仅靠刷新一次页面下结论。
  5. 按网络复核。分别在实际使用的 Wi-Fi 与蜂窝网络验证；如果设置了 Settings → On Demand，测试期间也要核对是否发生自动重连。

普通 DNS 参数核对

地址形式
解析器 IP 地址
文档示例
192.0.2.53
常用端口
UDP / TCP 53
检查重点
可达性、内网解析需求与实际出站路径

192.0.2.53 是文档示例地址，不能直接用作实际解析器。

DoH 参数核对

地址形式
完整 HTTPS URL
文档示例
https://dns.example.com/dns-query
常用端口
HTTPS 443
检查重点
路径、证书、端点初始解析与可达性

示例端点不提供解析服务；实际 URL 应采用你已有解析服务给出的完整参数。

DoH 端点如果使用域名，建立 HTTPS 连接前还需要取得该域名的地址，这通常称为初始解析或 bootstrap。不能让端点的唯一解析来源依赖尚未建立的同一个 DoH 连接。若当前配置涉及这类依赖，应检查其初始解析安排，而不是反复重填同一个 URL。也不要随意把端点域名替换成 IP，这可能破坏证书名称校验。

DNS 与分流规则的关系：返回地址不等于命中策略

Home → Global Routing 中的 Config 用于按当前配置规则处理流量；Proxy 与 Direct 是不同的全局路由选择，不能拿它们的测试结果直接替代 Config 下的规则验证。使用 Scene 时，还需先核对场景中实际生效的路由设置。DNS 查询走哪条路径、目标连接命中什么策略，应分别检查。

域名规则依据可用的域名信息匹配，IP 规则依据目标地址匹配。对需要 IP 判断的流量，解析结果可能影响后续命中；但这不表示所有规则都必须先完成一次本地 DNS 查询。例如，应用直接请求 IP 时，未必存在可以匹配的原始域名。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

以上只是语法说明，示例域名与网段均用于文档，不是可直接套用的完整配置。若某次访问在换 DNS 后命中了不同的 IP 规则，应先对比返回地址，再看规则顺序；不要为了修复一个域名而直接删掉全部规则。若解析器请求也需要经过代理，还要检查是否产生“连接代理前必须解析，而解析又依赖该代理”的循环依赖。

解析失败按现象分类，不把所有超时归给 DNS

每次复测建议记录四项：当前网络、查询域名、返回结果或错误、随后连接是否成功。对比时保持配置与目标一致，并注意缓存。Home 的 Connectivity Test 可作为连通性线索，但单次延迟结果不是下载带宽，也不能独立证明所有域名解析正常。

换成 DoH 后，所有域名都超时怎么办？

先恢复原来的 DNS，确认基线能否恢复。然后核对 Settings → DNS 中的完整 URL、端点域名是否可解析、设备时间是否正确，以及端点连接是否被当前路由阻断。普通网页能打开，不代表指定的 DoH 路径一定可用。

公网网页正常，但家里的内网域名打不开？

先确认设备仍连接到对应内网，再对比系统 DNS 与自定义 DNS 的结果。公共解析器通常不掌握局域网私有记录；应保留相应内网解析路径，而不是继续更换公网解析器。还要区分普通 DNS 名称与使用 .local 的 mDNS 名称。

已经返回 IP，网页还是一直转圈，是 DNS 错了吗？

先看该次连接命中的规则与策略，再检查目标连接超时或 TLS 错误。若同时返回 A 与 AAAA 记录，还应核对 IPv4、IPv6 路径是否都可用。只有其中一条地址路径失败时，不宜直接判断解析器整体失效。

为什么改完设置，看起来还是原来的结果？

先保存设置并重新建立连接，再关闭旧页面重新访问；同时核对 Config 是否仍有相关 DNS 配置。应用内置 DoH、系统或应用缓存、已有长连接，都可能让一次刷新无法反映新设置，应结合对应请求记录判断。

如果结果显示 NXDOMAIN，含义是解析器报告域名不存在；它与“没有收到应答”的超时不同。SERVFAIL 则表示解析器未能完成处理，可能涉及上游、DNSSEC 验证或其他解析故障。先检查域名拼写，再比较相同域名在基线解析路径中的结果，不要把不同错误统一记为“网络慢”。

完成验证后，保留可回退的配置记录

最终选择应由实际访问需求决定。系统 DNS 适合作为当前网络的对照；固定解析器适合需要明确控制解析来源的配置；DoH 适合需要 HTTPS 查询传输且端点可正常到达的环境。是否保留某种方式，要同时检查公网域名、内网域名和当前分流，而不只是看一次查询耗时。

Shadowrocket 是 Apple 平台的闭源商业应用，以 iPhone、iPad 使用为主；其他设备兼容性与系统要求以 App Store 页面标注为准。客户端采用一次性买断，客户端购买与线路服务分开。本文以用户已有自己的配置为前提，本站不提供、不销售、不推荐任何节点或订阅。

App Store 正版核对查看获取与购买说明