2026-10-15 · 故障排查 · 约 10 分钟

Shadowrocket 网页打不开但延迟正常：DNS 解析失败的排查与设置项说明

延迟测试有数值、网页却打不开时，从 DNS 角度逐项排查：dns-server 设置项的含义、系统 DNS 与自定义 DNS 的差别，以及按步骤恢复的检查顺序。

本文速览

本文适合已经在 Shadowrocket（小火箭）导入自己的订阅、连接后仍无法打开网页的用户。先区分服务器可达、域名解析与网页连接三个环节，再核对 Global Routing 和当前 Config，最后只改一项 DNS 设置做对照。目标是找出故障发生的位置，而不是把所有打不开的问题都归因于 DNS。

一、延迟正常为什么不代表网页能打开

Home 中服务器条目的延迟值，只说明当前测试方法所覆盖的链路有响应。不同测试方法检查的目标和过程不同：端口能够建立连接，不等于目标域名已经解析成功；即便某个测试网址可访问，也不能证明另一个网站的 DNS、TLS 和 HTTP 请求都正常。

打开一个 HTTPS 页面通常先取得域名对应的地址，再按策略建立连接，完成 TLS 握手后请求页面。任一环节失败，都可能在浏览器里表现为“无法打开网页”。如果是 Proxy 策略，还需要考虑目标域名是否交给远端解析，不能仅凭设备本地的 DNS 测试判断整条链路。

53
传统 DNS 常用 UDP / TCP 端口
443
HTTPS 与 DoH 通常使用的端口
853
DoT 的默认端口

结论：用同一网址做对照

保留一个持续失败的网址，在同一网络、同一服务器和同一 Global Routing 状态下比较修改前后结果。不要一边换服务器一边换 DNS，否则即使恢复，也无法确认是哪项改动起效。

二、先确认故障范围，再修改 dns-server

先记录失败网址、当前 Wi-Fi 或蜂窝网络、选中的服务器、Global Routing 状态，以及浏览器显示的完整错误。记录只需保留域名和现象，不要附带订阅 token、账户信息或完整配置密钥。订阅链接从你的服务商处获取，不应作为排错截图的一部分公开。

  1. 固定测试条件

    在 Home 记录当前服务器，再进入 Home → Global Routing 核对选项。若当前使用 Scene，先确认其实际采用的场景与策略，不要默认它等同于 Config。

  2. 比较两个域名

    用 Safari 分别打开失败网址和另一个平时可用的网址。只有一个域名失败时，优先检查拼写、该域名的解析记录和命中的规则；所有网址失败时，再检查公共链路。

  3. 比较网络环境

    保持服务器和配置不变，在 Wi-Fi 与蜂窝网络间切换后重试同一网址。若只有某个 Wi-Fi 失败，还应确认该网络是否需要先完成网页认证。

  4. 控制自动连接

    需要做断开连接的对照时，进入 Settings → On Demand 记录现有状态，必要时临时关闭。否则按需连接可能重新建立连接，使“断开后测试”的条件失效；结束后恢复原设置。

  5. 保留原配置

    在 Config 中先保留当前配置副本或导出备份，记录当前选中的文件。后续只修改该文件的一项参数，保存并重新连接后复测，不要同时更新订阅或导入另一份完整配置。

如果系统能够解析并访问同一网址，而连接后失败，重点检查配置内 DNS、规则命中和远端路径；如果断开后也失败，系统网络或网站自身同样需要排查。两种情况都不是单凭一次测试即可定论。

三、dns-server、系统 DNS 与自定义 DNS 的区别

dns-server 是配置文件 [General] 内的 DNS 上游设置。进入 Config，打开当前文件的操作菜单并选择 Edit Config，检查现有 [General] 段；菜单以当前界面显示为准。不要把参数写进 [Rule]，也不要在同一文件里重复堆叠多个同名设置。

设置方式含义排查重点
dns-server = system使用系统提供的 DNS 上游。切换网络后，上游可能变化；不等于固定使用某个公共 DNS。
dns-server = 1.1.1.1指定一个普通 DNS 上游地址，作为对照示例。当前网络是否允许访问其 DNS 服务；地址可达不等于查询一定成功。
加密 DNS 上游按所用配置支持的语法，通过 DoH 或 DoT 传送查询。除解析服务外，还依赖端点连通性、证书及可能的引导解析。

系统 DNS 随当前网络环境取得，适合用来恢复一个接近系统默认的对照。自定义 DNS 明确指定上游，但不保证在所有 Wi-Fi 或蜂窝网络中都可达，也不能自动修复错误规则、服务器故障或网站证书问题。企业内网的专用域名还可能只能由其内部 DNS 解析。

[General]
dns-server = system

上面只展示参数位置，不是一份完整配置。若原文件已经有 [General]，在原段落内替换对应行即可，不要用这两行覆盖整份文件。需要比较自定义上游时，再把该行单独改为 dns-server = 1.1.1.1，保存、重新连接，并复测相同域名。此地址仅用于解释语法，不代表适用于所有网络。

四、根据错误区分无记录、服务失败与超时

浏览器的概括提示通常不足以判断原因。若诊断记录提供 DNS 响应码或错误文本，可以按下面三类定位。这里的英文是 DNS 响应码和常见网络错误文本，并非保证 Shadowrocket 的每个界面都会逐字显示这些内容。

报错：NXDOMAIN

原因：本次 DNS 响应表示查询的域名不存在，也可能与上游返回结果有关。

解法：先核对域名拼写，再用同一域名比较系统 DNS 与一个可达的自定义上游；若均返回此响应，向域名或服务维护方确认记录状态。

报错：SERVFAIL

原因：解析服务未能完成查询，可能涉及上游递归查询或验证失败，并不等同于域名不存在。

解法：保持连接策略不变，换一个已确认可达的解析上游复测，并记录是否只影响单个域名，避免直接删除现有规则。

报错：timed out

原因：某一步在等待时间内没有收到响应；若未标明查询阶段，也可能是连接或握手超时，而不只是 DNS。

解法：先确认错误发生在 DNS 查询还是目标连接，再比较网络环境；只有 DNS 查询超时，才优先检查解析上游的连通性。

收到 NOERROR 也不一定表示拿到了可用地址：响应可能没有对应的 A 或 AAAA 记录。如果已经获得地址，随后才出现 TLS 证书错误或 HTTP 错误，应转向检查设备时间、目标站点、连接路径和规则，不要继续把问题当成纯 DNS 故障。

五、解析成功后，检查 Global Routing 与规则命中

在 Home → Global Routing 中，Config 按当前配置规则决定策略，Proxy 将流量交给代理策略，Direct 使用直连策略；Scene 则需要结合当前场景设置理解。这里的模式控制与 DNS 上游选择不是同一件事，切换为 Proxy 并不能保证某个 DNS 服务就会可达。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

这段只演示规则含义，不应直接替换现有规则：DOMAIN-SUFFIX 会匹配 example.com 及其子域名；FINAL 是前面规则都未命中时的兜底。规则按顺序匹配，前面更宽的匹配可能已经决定策略。IP-CIDR 和 GEOIP 涉及目标 IP，排查时也要留意取得地址后的匹配结果；它们不是 DNS 服务器设置。

六、恢复后的确认与常见问题

找到有效修改后，保留最终配置和一条简单记录：原现象、改动行、使用网络、复测网址与结果。将临时改变的 Global Routing 和 On Demand 恢复到日常状态，再测试一次。如果回到 Config 后故障重现，应继续检查规则，不要长期依赖一次临时切换掩盖问题。

改完 DNS 怎么还是原来的结果？

先确认修改的是 Config 当前选中的文件，并且保存成功；重新连接后退出并重开测试应用再试。缓存可能暂时保留旧结果，不建议在首次复测无变化时就连续叠加多项修改。

直接输入网站 IP 能不能证明 DNS 有问题？

不能作为可靠结论。HTTPS 依赖域名参与证书校验和站点选择，直接访问 IP 可能进入其他站点或触发证书错误。应比较同一域名的解析响应与后续连接结果，而不是用 IP 替代网址。

为什么换到蜂窝网络就好了？

保持服务器和配置不变再复测。若差异稳定存在，检查 Wi-Fi 的认证状态、系统 DNS 和对所用 DNS 传输的限制；恢复 dns-server = system 做一次对照，再决定是否保留自定义设置。

网页恢复了，订阅更新仍然失败怎么办？

订阅更新是另一条请求链路。先确认已有订阅链接仍有效，再向自己的服务商核对是否存在访问限制或账户状态问题。不要因网页已恢复就认定订阅域名、验证参数和服务端响应都正常。

App Store 下载先核对正版信息