2026-09-30 · 故障排查 · 约 10 分钟

Shadowrocket 延迟正常但网页打不开:DNS 解析失败排查与 DNS 设置项含义

节点延迟正常、网页却打不开,多半出在 DNS。本文给出解析失败的判断方法,讲解 DNS 相关设置项的作用,并按顺序列出排查步骤。

本文速览

本文适用于已在 Shadowrocket（小火箭）中导入自己服务商参数、连接后仍无法打开网页的用户。先区分延迟测试与域名解析，再检查 Global Routing、当前配置中的 DNS 和本地网络；每次只修改一项，用同一网址复测，最后根据错误类型决定是修正 DNS、规则还是连接参数。

一、延迟正常不等于网页请求完整成功

打开网页通常涉及域名解析、建立连接、TLS 握手和 HTTP 请求。Home 中的延迟结果只反映该次测试使用的目标与测试方式，不代表所有网站都能解析，也不代表服务器认证、传输设置和网页返回都正常。即使测试成功，浏览器仍可能停在域名解析阶段；反过来，网页打不开也可能是连接或 TLS 问题，不能只凭延迟读数确定 DNS 故障。

首先记录失败网址的完整域名、发生时间、当前服务器、Global Routing 姿态和网络类型。用一个此前能访问的网页作对照，不要连续更换网站、服务器和 DNS，否则无法判断是哪一项改变了结果。以下现象只是定位线索，需要结合后面的复测验证。

可观察现象优先检查不能直接推出
多个域名均提示找不到服务器DNS 查询是否超时，当前解析器是否可达不能仅凭提示认定服务器失效
只有一个域名打不开域名拼写、该域名的 DNS 记录和命中规则不能直接认定全部 DNS 配置错误
已得到目标 IP，随后连接超时出站路径、端口与服务商参数不能把连接超时当成解析超时
出现证书或安全连接提示设备时间、TLS 主机名和目标站点不能靠更换 DNS 保证修复

二、DNS 设置项分别控制什么

DNS 把域名转换成可连接的地址。系统 DNS 通常来自当前 Wi-Fi 或蜂窝网络；配置中的 dns-server 用于指定 Shadowrocket 的解析器。两者不是同一个层面的开关：浏览器自己的加密 DNS、配置规则及连接方式也可能改变实际查询路径，因此填写了某个解析器地址，不等于所有请求都必然经过它。

设置或概念作用排查要点
dns-server在配置的 [General] 中指定 DNS 解析器核对拼写、格式和解析器可达性；先确认当前配置确实在使用
system使用系统提供的 DNS 来源切换 Wi-Fi 与蜂窝网络后，系统来源可能改变
DNS over HTTPS通过 HTTPS 传送 DNS 查询解析器域名自身也可能需要先解析；HTTPS 可达性同样重要
A / AAAA分别返回 IPv4 / IPv6 地址记录有 AAAA 记录不代表当前 IPv6 出站路径一定可用
缓存与 TTL在一定时间内复用解析结果修改后短时间仍看到旧结果，不一定表示设置未生效
53
传统 DNS 常用 UDP / TCP 端口
443
DNS over HTTPS 通常使用的 HTTPS 端口
2 类
地址记录：A 对应 IPv4，AAAA 对应 IPv6

判断：先验证可达性，再更换解析器

如果传统 DNS 查询超时而 HTTPS 可正常连接，可测试已有可信来源提供的 DNS over HTTPS 配置；如果 HTTPS 本身也不通，先排查网络与连接路径，不要只把解析器列表越填越长。

端口号是协议常见值，不是需要在服务器配置里统一改填的数值。DNS 的端口与用户已有服务器的连接端口相互独立；不要为了排查解析，把 Home 中服务器的 Port 改成 53。

三、按顺序完成一次可回退的排查

开始前保存当前配置副本，记录原有 DNS 行。若配置由用户已有订阅管理，后续更新可能覆盖本地改动；用于排查的副本应与原配置区分。不要公开上传包含密码、UUID、订阅令牌或完整服务器地址的配置。

  1. 记录基线

    在 Home 记录当前服务器与连接状态，打开 Home → Global Routing 记录当前选项；用 Safari 访问同一个失败网址，保留实际提示及测试时间。

  2. 检查网络

    暂时断开连接，确认当前 Wi-Fi 是否需要先完成网络登录。需要比较网络时，分别在 Wi-Fi 与蜂窝网络测试同一网址，注意蜂窝网络可能产生流量费用。

  3. 对照姿态

    在 Home → Global Routing 中，记录 Config 下的失败结果，再临时切换 Proxy 测试。若结果改变，优先查看规则和出站路径；不要据此认定 DNS 已被全面修复。

  4. 核对配置

    回到 Config，确认当前启用的文件，进入该文件的编辑入口，检查 [General] 中的 dns-server。只在副本中调整这一项，不同时改动服务器认证或传输参数。

  5. 重新复测

    保存并确认使用修改后的配置，断开后重新连接，再访问同一网址。重新连接不保证清除所有应用缓存；必要时关闭并重开浏览器，记录结果是否稳定改变。

  6. 恢复设置

    将 Global Routing 恢复原值。若测试期间连接自动恢复，检查 Settings → On Demand，记录其原设置；临时关闭后再做手动连接测试，结束后按原需求恢复。

下面是使用系统 DNS 的最小配置片段，仅用于理解字段位置，不是完整可连接配置。编辑时应修改已有的对应行，不要为了测试追加重复的 [General] 段，也不要覆盖原配置的其他必要设置。系统 DNS 本身也可能不可达，因此这一片段不能作为通用修复方案。

[General]
dns-server = system

四、按错误原文区分解析失败类型

下面列出 DNS 工具或诊断记录中常见的响应码与错误文本，不表示 Shadowrocket 的每个页面都会原样显示这些词。浏览器的“找不到服务器”提示无法单独区分 NXDOMAIN 与超时；只有看到具体查询结果时，才按对应分支处理。

报错：NXDOMAIN

原因与解法：解析器返回域名不存在——先检查域名拼写和子域名，再用相同域名向另一个已知可达的解析器复查；若多个解析器均返回相同结果，应联系目标网站维护方确认记录。

报错：SERVFAIL

原因与解法：解析器未能完成查询，可能涉及上游异常或 DNSSEC 验证问题——保留域名、解析器和时间，换一个可达解析器对照，不能把它当作“域名一定不存在”。

报错：REFUSED

原因与解法：解析器拒绝这次查询，可能限制了递归查询来源——确认该解析器是否允许当前网络使用，改回系统 DNS 或使用已有授权的解析器后复测。

报错：DNS query timed out

原因与解法：查询在等待时间内没有得到响应——检查解析器地址、查询路径及当前网络对 UDP / TCP 53 的可达性；换网络测试时保留其他设置，避免同时引入多个变量。

五、DNS 正常后继续检查规则与地址族

Global Routing 的 Proxy、Direct、Config、Scene 用于选择请求处理姿态。Proxy 与 Direct 可作为对照，Config 按当前配置处理，Scene 按所设场景决定实际方式。它们不能简单理解成四个 DNS 开关；切换姿态改变结果时，还要核对具体请求的规则命中与出站路径。

DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址网段匹配，GEOIP 按 IP 地理库匹配，FINAL 处理未命中前序规则的请求。域名规则本身不要求先取得目标 IP 才能比较域名；IP 类规则可能涉及解析，具体还取决于规则选项。下面仅示意语法，不应直接覆盖现有规则。

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

六、常见追问与排查结束条件

为什么换了 DNS，网页还是打不开？

先到 Config 确认正在使用修改后的文件，再检查查询是否确实返回地址。如果已得到地址而连接仍超时，回到 Home 核对服务器参数与 Global Routing，不要继续重复修改 DNS。

只有 Wi-Fi 出问题，蜂窝网络正常怎么办？

保持服务器、配置和网址不变，先完成 Wi-Fi 的网络登录，再检查该网络提供的系统 DNS。若仅该网络无法连接指定解析器，保存对照结果后联系网络管理员确认限制。

是不是多填几个 DNS 就更稳？

不一定。多个地址不会自动保证每个查询都得到理想结果。先保留一个来源明确且当前网络可达的解析方式，验证失败域名；恢复后再按实际需求决定是否增加其他解析器。

订阅更新后又恢复故障，怎么处理？

在 Config 比较更新前后的 DNS 与规则，确认更新是否覆盖本地修改。向自己的服务商反馈具体字段和失败时间，不发送完整订阅令牌；测试副本也应保留原始文件便于回退。

排查结束应满足三个条件：同一失败网址能够重复打开；Global Routing 已恢复日常使用姿态；重新连接后结果仍一致。建议保留一条简短记录，例如“Wi-Fi 下系统 DNS 查询超时，修改测试副本后恢复，Config 姿态复测通过”，而不是只记“换 DNS 好了”。这样的记录能帮助区分再次发生的网络问题和配置覆盖问题。

App Store 正版核验