网络能正常解析时先保留系统 DNS；需要固定解析器时再使用自定义 DNS；需要加密到解析器之间的查询传输时考虑 DNS over HTTPS。本文以 iPhone / iPad 的 Shadowrocket 设置操作为例，说明检查入口、端口、规则依赖与故障定位；Mac、Windows、安卓、Linux 可沿用判断方法，但界面位置以各平台实际显示为准。
先区分 DNS 解析与代理连接
DNS 把域名转换为地址，例如查询 A 记录得到 IPv4 地址、查询 AAAA 记录得到 IPv6 地址。解析成功只说明获得了答案，不代表目标端口可达，也不代表代理连接已经建立。反过来，Home 中服务器测试有响应，也不能证明所有网站的域名都能正确解析。
这条流程用于理解依赖关系，不表示所有请求都必须先在本地完成解析。DOMAIN-SUFFIX 可以依据域名匹配；IP-CIDR、GEOIP 等规则在需要地址信息时可能触发解析。对于交给代理处理的域名请求，是否由远端解析，还取决于协议、配置和实际连接路径。
三种 DNS 方式的路径与取舍
“自定义 DNS”表示手动指定解析器，不等同于某一种加密协议。这里将传统 IP 地址形式的 DNS 与 DNS over HTTPS 分开比较，便于判断地址该填在哪里、失败时先检查哪条网络路径。
| 方式 | 解析路径 | 适用条件 | 先检查什么 |
|---|---|---|---|
| 系统 DNS | 沿用系统当前网络提供的解析配置 | 家庭、办公网络正常，或需要访问内部域名 | 切换 Wi-Fi 后解析器是否变化，内部域名是否可用 |
| 自定义 DNS | 指定传统 DNS 解析器，通常使用 UDP 53，必要时使用 TCP 53 | 已有明确可达、允许使用的解析器 | 地址是否正确，53 端口是否受限，是否影响内部域名 |
| DNS over HTTPS | 通过 HTTPS 请求解析端点，通常使用 443 端口 | 需要加密查询传输，且端点和证书可正常访问 | 端点 URL、初始域名解析、TLS 与路由是否正常 |
系统 DNS 往往适合有内部域名的网络。办公系统、打印设备或家庭存储可能依赖路由器下发的解析器；直接替换为外部解析器后，公共网站仍能打开，但内部名称可能返回不存在或错误地址。这不是代理协议失效，而是解析器不掌握相应的内部记录。
DNS over HTTPS 也不保证更快。首次连接可能涉及端点域名解析、TCP 连接与 TLS 握手，后续请求可以复用连接和缓存。应在相同网络、相同目标域名下观察解析错误和访问结果，而不是仅凭端口是 443 就判断其稳定性。
结论：先保留能工作的解析路径
公共网站和内部域名都正常时，不必为了更换方式而改 DNS；需要调整时，一次只换一个解析器，并保留原配置以便恢复。
Settings 与 Config：先确认生效位置再修改
在 iPhone / iPad 上，先到 Home 查看 Global Routing，按规则测试时选择 Config；再到 Config 确认当前启用的是哪份配置。进入 Settings → DNS 检查全局 DNS 设置，同时检查当前配置的 DNS 项。配置可能带有自己的解析设置，因此不能只看 Settings 里的单个地址就断定最终行为。
- 记录基线。记下当前网络、Global Routing、启用的 Config、原 DNS 取值，以及出问题的域名。先确认原设置下能否重现问题。
- 备份当前配置。在 Config 中保留原配置副本。检查配置文本的
[General]区域是否已有dns-server，避免新增重复项。 - 只修改一个位置。要验证系统 DNS 就恢复相应的系统解析选择；要验证自定义方式，就填写自己已有的解析器地址或完整 DNS over HTTPS 端点。
- 重新建立连接。保存并确认配置仍处于选中状态，然后关闭、重新打开 Home 的连接开关。重新请求目标域名，结合日志和访问结果判断是否生效。
- 最后再恢复自动连接。测试期间检查 Settings → On Demand，避免自动连接改变测试状态；确认结果后恢复原来的按需连接安排。
下面两张卡仅说明字段结构。192.0.2.53 属于文档示例地址，resolver.example 是示例域名，均不是可用解析服务，不能直接用于联网。实际值应来自你已获准使用的网络配置；本文不推荐任何解析服务或线路服务。
传统 DNS 示例结构
- 配置区域
[General]- 配置键
dns-server- 地址形式
192.0.2.53，仅作示例- 常用端口
- UDP / TCP 53
普通 IP 地址形式不提供 DNS 传输加密；不要把文档地址当成可用服务。
DNS over HTTPS 示例结构
- 配置区域
[General]- 配置键
dns-server- 端点形式
https://resolver.example/dns-query- 常用端口
- HTTPS 443
需要完整的服务端点；路径以解析服务实际提供的值为准，并非所有服务都使用相同路径。
如果配置由用户已有的订阅或远程文件维护，更新可能覆盖本地修改。更新前保留差异，更新后重新检查当前选中的 Config 与 DNS 项。服务器订阅更新和配置文件更新也不是同一件事：前者更新服务器条目，不应被当成 DNS 设置已经更改的证据。
DNS 与 Global Routing、规则顺序怎样配合
Global Routing 的 Proxy、Direct、Config、Scene 决定不同的路由姿态。排查规则时使用 Config；Proxy 与 Direct 适合做路径对照，但切换后不能再用同一组现象证明原规则命中了哪一条。使用 Scene 时还要核对场景内实际生效的设置。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这段规则用于解释语法，不是通用分流配置。example.com 和 192.0.2.0/24 都是文档示例；在当前配置已正确使用相应策略的前提下，规则按顺序检查。不要为了套用示例而覆盖现有完整规则。
- DOMAIN-SUFFIX：按域名后缀匹配，适合明确知道目标域名的场景；该条在前面命中后，不需要继续依靠后面的 GEOIP 来决定策略。
- IP-CIDR：按地址网段匹配。示例中的
no-resolve表示不为匹配该条规则额外触发域名解析，不表示整条连接永远不会使用 DNS。 - GEOIP：依据目标 IP 的地理数据库分类。解析返回的地址不同，后续分类结果可能随之变化；数据库分类也不等于实际网络时延。
- FINAL：在前面的规则都未命中时选择最终策略，不能修复已经失败的 DNS 查询，也不能纠正不可达的服务器地址。
另外，代理服务器本身若使用域名，也需要一条可用的初始解析路径。如果 DNS over HTTPS 端点被安排走代理，而该代理服务器域名又依赖这个尚未可达的端点，就可能形成启动依赖。应分别确认服务器域名与解析端点能否在连接建立前得到解析，不能靠反复切换协议解决。
按网络与错误阶段定位 DNS 故障
测试时先固定服务器和 Config，只更改 DNS 方式。分别记录 Wi-Fi 与蜂窝网络下的结果，不要同时更换服务器、规则和解析器。网页打不开并不一定发生在 DNS 阶段：获得地址之后，仍可能在目标连接、TLS 或应用层失败。
| 可观察现象 | 优先排查 | 下一步操作 |
|---|---|---|
| 只有内部域名无法解析 | 自定义解析器是否缺少内部记录 | 恢复系统 DNS，在同一 Wi-Fi 重试内部域名 |
| 传统 DNS 超时，HTTPS 网站仍可访问 | 所选解析器与 53 端口路径 | 先对照系统 DNS，再验证已有 DNS over HTTPS 端点是否可达 |
| DNS over HTTPS 提示 TLS 错误 | 系统时间、证书名称、端点域名 | 核对完整 URL 与设备时间，保持证书验证开启 |
| 已返回 A / AAAA，但连接超时 | 目标地址路由、IPv6 可达性、服务器连接 | 检查实际出站策略，不要直接判定 DNS 失败 |
| 改完配置后结果暂时不变 | 应用缓存、系统缓存、连接复用 | 重新建立连接并重启目标应用，再与新的查询结果对照 |
NXDOMAIN 表示解析器回答该名称不存在；超时表示没有在等待期限内得到可用响应，两者不能混为一谈。若只在某个网络出现超时，先检查该网络到解析器的路径；若公共域名正常而内部名称持续返回 NXDOMAIN，先检查解析器是否选错。
也不要用“直接在浏览器输入 IP”作为唯一验证。很多 HTTPS 站点依赖域名完成证书验证和虚拟主机选择，直接访问 IP 失败并不能证明路由不可达。应结合请求日志中的解析结果、目标地址与连接阶段，区分 DNS 错误和 TLS 错误。
结论：以错误阶段决定下一步
没有解析答案时检查 DNS 路径；已经得到地址时检查规则、出站和目标连接。只有更换 DNS 后错误阶段确实变化，才继续比较解析方式。
DNS 设置常见问题与恢复方法
换成 DNS over HTTPS 后，为什么连接反而更慢？
先恢复原 DNS 做同网络对照，再检查端点域名解析、HTTPS 443 可达性以及端点请求是否绕远路。首次握手较慢与每次查询都超时不是同一问题；不要一次填入多个端点来掩盖单个端点不可达的原因。
家里能用，切到公司 Wi-Fi 后内部系统打不开怎么办？
先在 Settings → DNS 恢复系统解析，并检查 Config 是否仍指定了自定义解析器。在同一 Wi-Fi 重试内部域名；若恢复后正常，说明需要保留内部解析路径，而不是继续更换代理服务器。
已经打开 DNS over HTTPS，为什么还会看到 DNS 流量？
先核对流量来自哪个应用和哪个阶段。端点域名的初始解析、未进入当前隧道的请求，以及应用自身的解析机制，都可能与所选 DNS 设置不同。仅开启一个端点，不能证明设备全部查询都经过该端点。
订阅更新以后 DNS 又变了，应该从哪里恢复？
进入 Config 检查当前选中的文件，对照备份中的 [General] 与 dns-server。确认更新的是服务器订阅还是远程配置；恢复经过验证的 DNS 项后，重新建立连接，并检查 Settings → On Demand 是否恢复了预期状态。
最后保留一份最小排障记录：网络类型、Global Routing、当前 Config、DNS 方式、目标域名、错误阶段和恢复操作即可。需要提供记录时，移除用户已有订阅中的令牌、认证信息及内部域名。本站不提供、不销售、不推荐节点或订阅；本文只说明如何检查用户已有配置。
- 公共网站与内部域名均正常：保留当前设置，不必追求统一改为某一种 DNS。
- 需要固定解析器：先确认地址可达、使用权限与内部域名需求，再修改。
- 需要加密查询传输：验证完整 DNS over HTTPS 端点、TLS 和初始解析路径。
- 修改后异常：恢复备份，重新连接，再逐项测试，而不是叠加更多设置。
获取 Shadowrocket 与基础配置教程
iPhone / iPad 版在 App Store $2.99 一次性付费，系统要求以 App Store 页面标注为准；Mac（Apple 芯片 / Intel）、Windows、安卓、Linux 版免费。通过下载页选择对应平台；iPhone / iPad 产品页可核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118。
客户端买断与线路套餐是两回事。Shadowrocket 为闭源商业应用，配置连接时使用用户已有的服务器或订阅；DNS 设置不会自动提供线路。