2026-08-27 · 故障排查 · 约 8 分钟

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

从 DNS 设置项含义讲起，按步骤排查解析失败、延迟正常却无法打开网页的常见原因与对应改法。

本文速览

延迟测试有读数，不代表目标域名已解析，也不代表网页连接成功。本文适用于已安装 Shadowrocket、已有自己的服务商与订阅的用户。先分开检查 DNS、规则与出站连接，再用同一网址、同一网络逐项复测；每次只改一个设置，保留能够恢复的配置副本。

一、先区分延迟、DNS 与网页连接

Shadowrocket（小火箭）的延迟读数只说明本次测试覆盖的目标和方式取得了结果。服务器地址可达、域名解析成功、代理认证通过、目标网站返回内容，是不同环节。不能把一个延迟数字当作整条访问链路的检查结论。

域名解析 规则判断 出站连接 TLS 握手 网页响应

这条流程用于区分排查层次，不表示所有请求都固定在本地先解析。域名规则可以直接匹配域名；部分代理路径会把目标域名交给远端处理。涉及 IP 的规则、服务器自身使用的域名，以及直连请求，仍可能需要相应的解析结果。

在 Home 确认连接开关已开启，并查看 Global Routing 当前值。随后打开一个平时能够访问的 HTTPS 页面，再访问发生故障的页面。记录完整域名、网络类型、测试时间和报错。仅一个域名失败时，应优先检查该域名与对应规则，不要立即替换全部 DNS 设置。

  • 网页提示找不到服务器：先查域名拼写、DNS 响应及 Host 覆盖。
  • 网页长时间等待后超时：可能是解析超时，也可能是连接或出站路径超时，需要结合日志判断。
  • 网页提示证书问题：请求已进入 TLS 检查阶段；还要核对设备时间、证书与目标地址，不能仅归因于 DNS。
  • 网页返回 HTTP 403 或 503：已有 HTTP 响应，优先检查访问限制或网站状态，而不是持续更换 DNS。

二、DNS 设置项与端口分别代表什么

DNS 把域名转换为网络连接所需的地址。A 记录对应 IPv4，AAAA 记录对应 IPv6。收到 AAAA 记录不等于当前网络具有可用的 IPv6 出站路径；反过来，某个域名只有 A 记录，也不等于解析异常。

53
传统 DNS：通常使用 UDP，也可使用 TCP
443
DoH：通过 HTTPS 查询时的常见端口
853
DoT：通过 TLS 查询时的默认端口

端口说明的是传输方式，不是可达性保证。当前网络可能无法访问某个解析器；带域名的加密 DNS 地址还涉及解析器自身域名如何解析。不要把普通 DNS 的 IP 地址直接写成任意 HTTPS 地址，也不要把 DNS 查询端口填入代理服务器端口栏。

检查项作用排查动作
dns-server配置文件中的 DNS 服务器设置。在 Config 中打开当前配置，检查 General 中是否存在此项；同时核对 Settings → DNS 中的设置。
system使用系统提供的解析器。结合当前 Wi-Fi 或蜂窝网络复测；网络切换后解析条件也会变化。
Host可为指定域名提供固定地址映射。检查故障域名是否被映射到旧地址，避免把固定映射误当作实时 DNS 结果。
A / AAAA分别返回 IPv4 / IPv6 地址。将“有解析结果”与“该地址可以连接”分开验证。

Settings 中的全局选项和 Config 中的配置项可能同时影响行为。检查时应以当前启用的配置和实际日志为准，不要仅凭某个页面里保存过的值判断生效状态。界面分组随应用调整时，按 DNS、Config、General 等英文名称定位。

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

先保存当前配置副本，并记录原来的 Global Routing、DNS 和服务器选择。下面的每一步都使用同一故障网址。若页面恢复，重复访问一次并观察日志，再决定是否保留修改。

  1. 检查基础网络。暂时关闭 Shadowrocket 连接，访问平时可正常打开的页面。Wi-Fi 如需登录，先完成网络登录。随后恢复连接；基础网络本身不可用时，修改配置无法解决上游断网。
  2. 确认当前服务器。回到 Home，确认选中的服务器属于自己的有效订阅。延迟正常但认证、传输或远端出站失败时，应向自己的服务商核对连接参数与服务状态。
  3. 核对路由姿态。在 Home → Global Routing 记录当前是 Config、Proxy、Direct 还是 Scene。若使用 Scene，先确认该场景实际采用的设置，避免把场景切换误认为 DNS 改动。
  4. 检查有效 DNS。查看 Settings → DNS，并打开 Config 中当前使用的配置，核对 General 的 DNS 设置与 Host 映射。一次只调整一处，修改后重新连接再复测。
  5. 做网络对照。在允许使用蜂窝数据的情况下，从 Wi-Fi 切换到蜂窝网络，保持配置与网址不变。只在一种网络失败时，优先检查该网络的解析器可达性、网络登录与出站限制。
  6. 检查自动连接。若关闭后连接又自动开启，检查 Settings → On Demand。排查期间记录并暂时调整相应条件，完成后恢复原来的按需连接设置。

四、用 Global Routing 对照规则与 DNS 问题

Config 按当前配置的规则分流，Proxy 与 Direct 用于整体路由姿态对照，Scene 则按已设置的场景工作。临时切换姿态不是最终修复方法；它的作用是缩小问题范围，完成复测后应恢复日常配置。

对照现象可以推断什么下一步
Config 失败，Proxy 成功规则指定的路径或相关 DNS 行为值得检查；不能直接断定解析器故障。查故障域名命中的规则与策略，确认是否走了 Direct 或其他指定路径。
Direct 成功，Proxy 失败代理路径可能有认证、连接或远端解析问题。核对当前服务器参数，并查看失败发生在解析还是连接阶段。
三种姿态均失败共同因素可能是基础网络、域名本身或共同使用的解析设置。换网络作对照，同时检查域名与 Host 映射。
只有某个域名失败故障范围较小，不足以说明全部 DNS 请求失败。核对该域名的规则、解析响应及网站状态。

DOMAIN-SUFFIX 按域名后缀匹配；IP-CIDR 按地址网段匹配；GEOIP 按 IP 地理分类匹配；FINAL 是兜底规则。规则按排列顺序判断，命中后使用对应策略。下面只展示语法，不是可直接覆盖日常配置的规则方案。

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

example.com 与 192.0.2.0/24 仅用于说明语法。示例中的 no-resolve 表示不要为了匹配该条 IP 规则主动触发域名解析，不表示后续连接永远不需要解析。删除某条 IP 规则或改为全局 Proxy，可能改变路径，但不会自动修复损坏的域名记录。

结论：先定位命中的路径，再决定是否改 DNS

若同一域名在 Proxy 成功、Config 失败，先检查 Config 中的规则与策略。只有观察到解析超时、无有效地址或错误映射后，再调整相应 DNS 设置，避免用路由变化掩盖原来的问题。

五、按报错原文区分解析与连接失败

浏览器提示、应用日志与系统错误可能使用不同文字。下面列出的是可能在浏览器或 Apple 网络错误记录中遇到的原文与代码，不是 Shadowrocket 固定输出模板。记录报错所属位置，并查看同一时间附近是否已有解析地址。

报错：ERR_NAME_NOT_RESOLVED

原因：浏览器没有取得目标域名的可用解析结果。

解法：先核对域名拼写，再检查当前 DNS 与 Host 映射；保持路由不变，换网络复测同一域名。

报错：NSURLErrorDomain Code=-1003

原因：Apple URL 加载错误中的 cannot find host，表示无法找到指定主机。

解法：区分失败的是目标网站域名还是服务器域名，检查相应解析配置；若多次出现明确的 NXDOMAIN，核对域名有效性，而不是单纯延长等待。

报错：NSURLErrorDomain Code=-1001

原因：请求超时，单独这一代码不能确定超时发生在 DNS 阶段。

解法：查看超时前是否已有地址和连接记录；已有地址时优先检查出站可达性，没有解析结果时再检查解析器路径。

NXDOMAIN 表示解析器返回“该名称不存在”；没有响应则是另一类现象，可能与丢包、解析器不可达或等待超时有关。不要把两者都写成“DNS 被阻断”。若已有地址但连接失败，还应检查 IPv6 路径、代理参数与目标端口。HTTPS 常见端口是 443，但服务器自己的端口必须以用户已有服务的参数为准。

六、常见追问与修复后的验证

延迟一直正常，为什么还是打不开网页？

延迟测试与网页请求覆盖的环节不同。在 Home 记录所选服务器与 Global Routing，再用浏览器请求实际故障域名。分别检查解析结果、命中策略和连接错误，不能只重复测试延迟。

换了 DNS 后还是失败，要继续换吗？

先确认修改的是当前有效设置。检查 Config → 当前配置 → General，并核对 Settings → DNS；重新连接后再试。若日志已有地址却在连接阶段失败，停止盲目更换解析器，转查出站路径。

只有 Wi-Fi 失败，蜂窝网络正常怎么办？

保持同一配置与同一服务器，检查 Wi-Fi 是否完成网络登录，以及所用解析器在该网络是否可达。若使用 system，系统 DNS 随网络变化，两个网络的解析条件并不相同。

更新订阅能修复 DNS 吗？

订阅更新通常用于刷新服务器条目，不能据此认定本地 DNS 设置已修复。只有自己的服务商确认服务器地址或连接参数发生变化时，才按其说明更新已有订阅，并重新核对当前选中条目。

页面恢复后，回到原来的 Global Routing 姿态，恢复需要的 On Demand 条件，再测试故障页面和一个常用页面。对照修改前后的日志，确认恢复不是因为临时切换了网络或规则。若需要重建浏览器请求，可关闭故障标签页再重新打开；这不等于清除了所有系统 DNS 缓存。

  • 记录最终保留的改动：具体设置项、旧值、新值与验证网址。
  • 确认当前 Config 是预期配置，Host 中没有为了测试遗留的固定映射。
  • 确认日常规则仍按预期分流，而不是长期停留在临时对照姿态。
  • 仍未解决时，带着脱敏日志与网络对照结果向自己的服务商核对；更多排查步骤见疑难解答。
App Store 正版核验 →