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

Shadowrocket DNS 解析失败排查:延迟测试正常但网页打不开怎么办

从 dns-server 设置、系统 DNS 与配置文件 DNS 的关系入手,按步骤排查解析失败、个别域名打不开等情况,并解释相关设置项的含义。

本文速览

Shadowrocket（小火箭）的延迟测试成功，不等于目标网站的 DNS、规则和 HTTPS 连接都正常。本文面向已有服务商与订阅的用户，按“记录现象、确认配置、对照 DNS、核对规则、检查 IPv6”的顺序定位问题；每轮只改变一个变量，最后用同一域名复测，区分解析失败与解析之后的连接失败。

一、延迟测试正常，为什么网页仍然打不开

Home 中的延迟结果只反映所选测试方式对应的目标与路径。即使某项测试能完成，也不能证明浏览器访问的每个域名都能解析，更不能证明网站的 TCP、TLS 或后续资源请求能够完成。先记录具体打不开的域名、出现时间，以及当时使用 Wi-Fi 还是蜂窝网络，不要只记录“网络不通”。

网页访问通常需要把域名转换为地址，再建立连接并完成 TLS 协商。配置可能让部分域名交给代理端解析，也可能需要本地先取得地址；不能把所有请求都理解为固定的一条路径。下面是用于排查的逻辑顺序，不代表每个协议的实际数据包顺序。

域名请求 解析与分流 地址连接 TLS 协商 页面资源
  • 域名没有取得地址：重点检查 DNS 响应、解析器可达性以及本地映射。
  • 取得地址但连接超时：继续检查命中的策略、目标端口与地址族，不能直接认定为 DNS 故障。
  • 页面出现 HTTP 403 或 503：至少该次请求已到达能返回 HTTP 响应的服务；检查站点访问限制或服务状态。
  • 首页显示但图片不加载：记录图片或脚本使用的域名，主站域名正常不代表资源域名使用同一条规则。

二、先做一轮单变量排查

开始前保存当前配置副本，记下 Home → Global Routing 的状态与当前选择的服务器。本文以 Config 为日常规则分流基线；Proxy、Direct 与 Scene 的行为需要结合各自设置判断，不能把姿态切换当作 DNS 修复本身。

  1. 记录基线

    在 Home 记录当前服务器和 Global Routing 状态。用浏览器重新打开同一目标域名，记下错误文字；不要同时更新订阅、换服务器和修改 DNS。

  2. 确认配置

    进入 Config，确认当前实际启用的配置文件，再查看其 [General] 与 [Rule]。备份后在本地副本中测试，避免直接改动唯一的一份配置。

  3. 切换网络

    保持服务器与配置不变，在 Wi-Fi 和蜂窝网络间做一次对照。若仅 Wi-Fi 失败，先核对该网络是否需要网页认证，再检查其 DNS 与网络限制。

  4. 对照解析

    在测试副本中只更改 dns-server，保存并使该副本生效，再断开并重新连接。复测同一域名，记录是否得到地址以及页面是否恢复。

  5. 恢复验证

    若修改无效，恢复原值再测试。涉及断开连接时，可先检查 Settings → On Demand，必要时暂时关闭自动连接条件，测试后恢复，避免自动重连干扰观察。

三、dns-server、系统 DNS 与配置文件的关系

dns-server 位于配置文件的 [General] 段，用于指定解析器。system 表示使用系统提供的 DNS；系统 DNS 可能来自当前 Wi-Fi 的自动配置或手动设置，并不等同于固定的公共解析器。切换网络后，系统所用的解析条件也可能改变。

先在当前生效配置中搜索 dns-server，确认有没有重复定义或遗留的测试值。随后分别在两个本地测试副本中使用下面两种写法，不要把两个 [General] 段直接拼到同一份文件里。这里的公共地址仅用于可达性对照，不保证在所有网络中可用。

对照 A：使用系统提供的 DNS

[General]
dns-server = system

对照 B：指定一个普通 DNS 地址

[General]
dns-server = 1.1.1.1

测试时先只保留一个候选解析器，便于判断变量。多个解析器同时存在时，请求调度、缓存与不同响应可能让结果难以归因。若指定地址无响应，而 system 正常，应优先判断该网络到指定解析器的路径，而不是反复导入订阅。

53
普通 DNS 常用端口，涉及 UDP 与 TCP
443
DoH 通常使用的 HTTPS 端口
2 类
分别观察 A 与 AAAA 地址记录

端口可达不等于协议可用。普通 DNS 可能在 UDP 响应被截断时需要 TCP；DoH 则需要完成 HTTPS 连接。不要把一个普通 DNS 地址简单改写为 HTTPS 地址就当作 DoH 使用，DoH 需要真实有效的服务端点；如果端点使用域名，还要考虑首次连接前如何解析该域名。

结论：用单个解析器做对照

若同一网络、同一服务器下只有更换 dns-server 后恢复，保留这组对照结果，再判断原解析器的可达性；先不要同时修改规则或协议。

四、按 DNS 错误原文区分原因

以下是 DNS 响应码与网络诊断中常见的错误文本，不保证每个 Shadowrocket 界面都会原样显示。若日志或诊断结果出现这些文字，应同时记录查询域名、记录类型、解析器地址和时间；只截取一行错误，通常不足以确定故障发生在哪一段。

报错：NXDOMAIN

原因：解析器返回该名称不存在，不等同于查询超时。

解法：先核对域名拼写，再用另一解析器查询同一名称；如果结果持续一致，向域名或服务维护方确认记录。

报错：SERVFAIL

原因：解析器未能完成查询，可能涉及上游、权威服务器或 DNSSEC 验证等环节。

解法：使用另一解析器对照，记录是否仅某个域名失败；不能仅凭此码判定服务器失效。

报错：connection timed out

原因：操作在限定时间内没有完成；只有确认它对应 DNS 查询时，才属于解析超时证据。

解法：核对错误对应的目标与端口，若确为 DNS 查询，再检查解析器路径、当前网络与 UDP/TCP 通信。

还要区分“没有某类记录”和“整个域名不存在”：查询 AAAA 没有得到地址，但 A 返回正常，可能只是该域名没有提供 IPv6 地址。如果已得到可用地址，后续却出现 TLS 证书错误，应转查系统时间、证书名称和连接目标，而不是继续更换 DNS。

五、个别域名打不开：核对规则与 Host 映射

只有部分网站失败时，先查看该请求实际命中的规则和策略。DOMAIN-SUFFIX 可直接按域名后缀匹配；IP-CIDR 与 GEOIP 按地址判断时可能涉及解析。规则从上往下匹配，前面的命中结果会影响后续路径，FINAL 才处理此前没有匹配的请求。

下面的片段只说明语法，不应整体替换现有配置。example.com 和 192.0.2.0/24 为文档示例值；PROXY 必须在实际配置中对应可用的策略引用。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
检查项具体含义排查动作
DOMAIN-SUFFIX匹配指定域名及其子域名。核对失败域名是否被更靠前的规则分到另一策略。
IP-CIDR匹配 IP 地址范围。检查地址是否落入意外的直连范围。
no-resolve避免仅为匹配该 IP 规则而触发域名解析。不要把它理解为关闭整个配置的 DNS。
[Host]提供本地名称映射。检查是否遗留旧地址；在测试副本中移除可疑映射后对照。
FINAL处理此前未命中的请求。确认最终策略实际可用，而不是只看规则存在。

如果临时改为 Home → Global Routing → Proxy 后恢复，而 Config 下失败，只能说明两种路由条件存在差异，不能直接证明一定是某条 DNS 设置错误。记录两次的命中策略、连接地址和失败阶段，再回到 Config 缩小范围。测试完成后恢复原姿态，避免将临时对照设置留作日常配置。

六、解析已有结果，继续检查 IPv6、缓存与网络条件

A 记录提供 IPv4 地址，AAAA 记录提供 IPv6 地址。收到 AAAA 响应，只证明解析器返回了地址，不证明当前网络到该地址的连接可用。若域名同时具有两类地址，需要区分“没有记录”“取得记录但连接超时”和“应用选择了哪类地址”这三个问题。

  • IPv4 能连接，IPv6 超时：保留 DNS 响应作为证据，检查当前网络的 IPv6 连通性；需要调整相关选项时先记录原值，只做临时对照，不要同时改 DNS 和分流规则。
  • 改完配置仍像旧结果：确认新配置确已启用，断开并重新连接，再退出浏览器后重试。浏览器、应用和解析器都可能缓存结果，重连不保证清空所有缓存。
  • 仅酒店或公共 Wi-Fi 失败：先完成网络要求的网页认证。网络尚未授权时，DNS 返回或 HTTPS 连接都可能受影响。
  • 仅某个浏览器失败：比较另一个应用对同一域名的结果，检查是否存在应用自己的解析、缓存或连接设置，不要立即改动全局配置。
  • 服务器地址本身是域名：还要检查服务器域名能否在建立连接前完成解析；不能依赖尚未建立的连接来解决自身启动所需的所有解析。

结论：有地址后，转查连接阶段

当同一域名已稳定返回 A 或 AAAA，而失败发生在连接或 TLS 阶段，暂停更换解析器，改查实际使用的地址、命中策略与目标端口。

七、恢复配置并整理可复现记录

修复完成后，恢复测试期间临时关闭的 On Demand 条件，核对 Global Routing 与当前配置，再分别复测主站和资源域名。不要仅以某个页面第一次打开为结论：缓存可能掩盖问题，至少在重新连接后再做一轮相同操作。

订阅负责提供和更新服务器信息，不等于替你修复当前网络的 DNS。订阅从你的服务商处获取；刷新后服务器列表正常，也不能证明目标网站解析正常。如果仅修改了本地配置，还要确认后续配置更新是否会覆盖这项修改。

  1. 记录失败域名和错误原文，明确是全部站点还是个别域名。
  2. 记录 Wi-Fi 或蜂窝网络、Global Routing 状态、当前配置及服务器；对外反馈时隐去敏感地址和凭据。
  3. 记录 dns-server 修改前后的值，以及 A、AAAA 是否取得地址。
  4. 记录请求命中的规则、策略与最终失败阶段，区分 DNS、连接、TLS 和 HTTP 响应。
  5. 说明哪一个单独修改使现象改变，不提交订阅完整链接、token 或密码。

需要继续定位连接问题，可查看问题诊断；不确定关键字含义时，可查阅术语表。保留这一轮单变量记录，比连续更换多组设置更便于复现和判断。

前往 App Store