2026-10-14 · 故障排查 · 约 8 分钟

Shadowrocket DNS 设置详解:延迟测试正常但网页打不开怎么办

延迟测试有数值、网页却打不开,多半是解析环节出了问题。本文解释配置文件中 DNS 相关设置项的含义,并给出解析失败时的检查顺序。

本文速览

本文适用于已经在 Shadowrocket（小火箭）中配置好自己的服务商与连接信息，但遇到延迟测试有结果、网页仍无法打开的情况。先区分服务器连接、DNS 解析与网页访问三个环节，再核对 Config 中的 DNS 设置、Global Routing 和规则。每次只改一项，用同一域名复测，避免把规则拦截或出站失败误判为 DNS 故障。

一、延迟有数值，为什么仍可能解析失败

Home → Connectivity Test 的结果取决于当前采用的测试方式。测试可能只覆盖到服务器的连接，也可能访问一个测试目标。无论采用哪一种，它都不能证明所有网站的 DNS、TLS 与页面资源都正常。某个服务器地址已经缓存时，测试甚至不必重新解析这个地址。

打开一个新域名时，通常先查询地址，再按照实际策略建立连接，最后进行 TLS 握手与 HTTP 请求。下面是便于排查的简化流程；实际是否在本地解析、何时解析，还取决于规则类型与出站协议。

域名请求 地址解析 策略选择 出站连接 网页响应

因此，“延迟正常”只是一个局部证据。DNS 返回了地址但连接超时，应继续查出站；DNS 根本没有返回地址，才优先查解析。网页文字能显示、图片却加载失败，也可能是图片使用的另一个域名没有解析成功，不能只检查地址栏里的主域名。

53
传统 DNS 常用 UDP/TCP 端口
443
DNS over HTTPS 通常使用的端口
853
DNS over TLS 通常使用的端口

判断：先确认有没有解析结果

获得 A 或 AAAA 记录后仍打不开页面，不要继续反复更换 DNS。先记录返回地址，再检查该连接命中的策略与出站结果；端口可达也不等于整个解析服务正常。

二、在 Config 中核对正在使用的 DNS 设置

先打开 Config，确认当前选中的配置文件。编辑另一个未启用的文件，不会改变当前连接的行为。修改前保留副本；如果配置来自用户自己的远程配置来源，还要注意后续更新可能覆盖本地修改。

在 Config 中打开当前文件的编辑入口，查看 [General] 下的 dns-server。它用于指定解析服务器。下面只展示一个最小语法片段，不是一份可以替换原配置的完整文件。

[General]
dns-server = system

system 表示使用系统提供的 DNS，通常受当前 Wi-Fi 或蜂窝网络影响，并不表示固定使用某个公共解析服务。若这里填写的是一个地址或多个地址，应逐项核对来源与可达性；不要为了“备用”而不断追加未经验证的解析端点。

三、按固定顺序复测，避免同时改变多个变量

选一个自己平时能够正常访问的完整域名作为测试对象，并另选一个不同站点作对照。测试期间固定服务器与网络；不要一边切 Wi-Fi、一边切换服务器、又同时改 DNS，否则即使恢复，也无法知道是哪项起作用。

  1. 记录现场

    在 Home 记录选中的 SERVER、Global Routing 当前值和 Connectivity Test 结果。记下故障域名、网络类型，以及浏览器显示的具体错误；截图分享前遮住账号与服务器信息。

  2. 核对模式

    打开 Home → Global Routing，确认是 Config、Proxy、Direct 还是 Scene。若使用 Scene，先确认实际生效的场景。记录原值后再作对照，不把切换模式当作最终修复。

  3. 核对配置

    进入 Config，打开当前选中的文件，检查 dns-server 与 [Host]。只修改一项，保存后回 Home 重新连接，再打开同一个域名。

  4. 检查自动连接

    进入 Settings → On Demand，记录是否启用及相关条件。若测试中连接自动恢复，可临时关闭 On Demand 后重复对照，结束后恢复原设置。On Demand 控制连接触发，不是 DNS 服务器设置。

  5. 更换网络

    保持配置和 SERVER 不变，再分别用 Wi-Fi 与蜂窝网络复测。若只有某个网络失败，优先检查该网络的 DNS 可达性、登录认证状态及网络限制。

  6. 恢复并确认

    恢复不必要的临时改动，重新连接后测试两个站点。成功标准是能获得预期解析结果并完成网页加载，而不仅是 Connectivity Test 再次显示数值。

浏览器、系统与解析服务器可能各有缓存。重新连接有助于建立明确的测试边界，但不保证清除所有缓存。对照时应记录是否重复使用同一结果；不要通过访问任意 HTTPS 数字地址来替代域名测试，这会引入证书和虚拟主机差异。

四、把真实错误分成三类处理

以下是 DNS 协议或诊断输出中可能出现的原文，不表示 Shadowrocket 每一屏都会逐字显示这些内容。浏览器可能只给出概括性提示。应以实际记录为准，不要把所有“打不开”都归到同一类。

NXDOMAIN

原因：解析服务器回答域名不存在；域名拼写错误、记录已撤销或解析侧策略都可能产生此结果。

解法：先核对完整域名，再使用另一个已确认可用的解析来源对照；只有单个域名持续如此时，向该域名的维护方确认记录。

SERVFAIL

原因：解析服务器未能完成查询，可能涉及上游异常、权威服务器不可用或 DNSSEC 验证失败，并不等于域名不存在。

解法：保持网络与出站不变，换用已有的可用解析配置复测；若仅此域名异常，保留发生时间和返回状态交给相关维护方。

timeout

原因：在等待期限内没有得到响应，可能是解析端点不可达、数据包被丢弃，也可能是加密解析连接未能建立。

解法：先确认配置中的地址、协议与端口一致，再对照另一网络；不要单纯延长等待时间来掩盖持续不可达。

查询完成但没有所请求类型的记录，也不一定是故障。例如域名只有 A 记录，查询 AAAA 时可能得到成功响应但没有对应答案。应同时看响应状态和记录类型，不能只凭“没有 IPv6 地址”判断解析服务失效。

五、解析正常后，检查 Global Routing 与规则

Global Routing 的 Config 使用当前配置中的规则决定连接去向；Proxy 与 Direct 用于相应的全局路由姿态；Scene 按已配置场景工作。它们不是四个 DNS 服务器选项。切换姿态后网页恢复，只能说明路径变化影响了结果，还需要找出具体规则或出站差异。

在 Config 中检查当前文件的 [Rule]。下面是语法说明片段，使用文档示例域名和保留地址段，不应直接加入实际配置作为修复方案。FINAL,DIRECT 只表示此片段的兜底策略，并不是通用推荐。

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

对同一连接，规则通常按顺序匹配，因此前面的拦截或策略选择可能让后面的规则没有机会生效。若使用规则集，还要检查其实际内容和更新状态。不要只在主文件里搜索域名，没找到就认定没有相关规则。

六、怎样确认修复，并保留可复核的记录

有效修复应能重复验证：在固定网络、固定 SERVER、固定配置下，故障域名能够解析，连接走向符合预期，页面和必要资源都能加载。随后恢复原本需要的 On Demand 设置，再观察网络切换后是否仍然正常。

如果两个解析来源都能正常返回地址，但同一服务器上的网页连接仍失败，应转向服务器可用性、TLS、出站限制与规则检查。继续堆叠 DNS 地址会增加变量，不会自动修复这些问题。需要继续定位时，可查看本站故障排查和概念速查。

Shadowrocket 是 Apple 平台的闭源商业应用，主要用于 iPhone 与 iPad，唯一获取入口是 App Store。开发者为 Shadow Launch Technology Limited，客户端采用一次性买断；客户端买断 ≠ 线路套餐。本文以用户已有自己的服务商与配置为前提，系统要求以 App Store 页面标注为准。

App Store 正版核对