2026-08-23 · 问题排查 · 约 9 分钟

Shadowrocket 延迟正常但网页打不开:DNS 解析失败的排查顺序

测速有数值、网页却一直转圈,多半出在解析环节。本文逐项解释 DNS 相关设置项的含义,并给出从配置到网络环境的排查顺序。

本文速览

Shadowrocket（小火箭）显示延迟，只能说明对应测试获得了响应，不能证明浏览器的 DNS、规则和 HTTPS 请求全部正常。本文面向已经持有自己的服务商配置与订阅的用户，按“网络基线 → 路由姿态 → DNS 配置 → 规则与地址族 → 复测”排查，每次只改一个变量，区分解析失败、连接超时与 TLS 错误。

一、延迟正常不等于网页链路正常

先确认延迟来自哪一种测试。连接到服务器端口的测试，与请求某个网页地址的测试，覆盖的链路不同。服务器地址若本身是 IP，测试甚至不需要解析该服务器的域名；浏览器访问网站时，却仍需要取得目标域名的地址，再建立连接。因此，Home 中出现延迟数值，不能单独排除 DNS 故障。

网页持续转圈也不是 DNS 失败的唯一表现。解析已经成功，但后续连接被阻断、目标服务器没有响应、TLS 握手失败，都会导致页面打不开。排查时先记录错误文字和发生阶段，再决定是否调整 DNS，避免把所有访问异常都归到同一个设置项。

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

端口号用于理解传输差异，不代表当前网络一定允许这些连接，也不代表应该把服务器端口改成这些数值。代理服务器端口与 DNS 服务端口是两类参数，前者必须与用户已有服务端配置一致。

二、先建立可以重复的排查基线

不要一开始就同时更换服务器、DNS 和规则。先固定一个出现问题的网址，记录当前网络、所选服务器、Global Routing 和启用的配置。对照时使用完整域名，不要把 HTTPS 网址中的域名替换成 IP 来“验证 DNS”：这样会改变证书校验、SNI 和网站的虚拟主机选择，结果不能直接比较。

  1. 记录现状

    在 Home 记录所选服务器与连接状态，打开 Home → Global Routing，记下当前选项；在 Config 记录正在使用的配置，修改前保留可恢复的副本。

  2. 核对基础网络

    暂时断开连接，访问一个当前网络本来允许访问的网站。公共 Wi-Fi 如需网页认证，先完成认证。若断开后仍打不开该网站，优先检查 Wi-Fi 或蜂窝网络本身。

  3. 固定测试姿态

    重新连接，在 Home → Global Routing 暂时选择 Proxy，保持同一服务器，重试目标域名。这一步用于与 Config 作对照，不是最终配置建议。

  4. 切换网络复测

    保持服务器与配置不变，在 Wi-Fi 和蜂窝网络之间做一次对照。如果仅一种网络失败，记录该网络下的 DNS 请求与连接错误，不要立即覆盖配置。

  5. 恢复原有设置

    完成对照后恢复原来的 Global Routing。若断开后连接自动恢复，检查 Settings → On Demand 中已启用的条件，临时停用相关条件后再进行断开测试。

三、检查实际生效的 DNS 配置

进入 Config，确认当前启用的是哪份配置，再查看其中的 DNS 设置。修改未启用的文件不会改变当前连接；远程配置更新还可能覆盖本地改动。因此先保存副本，并在修改后重新连接，再对同一个域名复测。只更新 Home 中的服务器订阅，也不能据此认定 Config 中的 DNS 设置已经同步改变。

核对对象含义排查重点
dns-server配置中指定的 DNS 解析服务。地址格式是否正确，当前网络是否能到达该服务，是否误用了失效地址。
system使用系统提供的 DNS 解析来源。更换 Wi-Fi 后系统 DNS 可能变化，不能把上一个网络的测试结果直接套用。
DoH 地址通过 HTTPS 发送 DNS 查询。核对完整 URL 与服务路径；只有主机名、缺少路径时未必是有效端点。
服务器域名建立代理连接前也可能需要解析。区分代理服务器域名解析失败与目标网站域名解析失败。
静态域名映射把指定域名对应到固定地址。旧地址可能绕过正常查询，尤其要检查曾经手动添加的映射。

下面只是配置语法示例，不是通用修复方案。它表示使用系统解析来源，适合作为受控对照的一项变量；若当前网络的系统 DNS 本身异常，该设置同样可能失败。只调整已有配置中的对应字段，不要为了测试而删除其余规则、策略或服务端参数。

[General]
dns-server = system

使用 DoH 时还要检查“先解析服务地址”的依赖：如果 DoH 端点使用域名，建立 HTTPS 连接之前需要先取得端点地址。端点自身不可达、证书校验失败，或其域名无法解析，都可能让目标网站的查询停住。加密传输改变的是查询承载方式，并不自动保证端点可达，也不能替代对当前网络的检查。

四、把规则命中与解析结果分开核对

Global Routing 下的 Direct、Proxy、Config、Scene 不是四种 DNS 协议。Direct 与 Proxy 用于不同的流量处理姿态；Config 按所用配置处理；Scene 则需要核对所选场景的具体设置。排查期间不要让场景变化与 DNS 修改同时发生，否则同一个网址前后可能使用了不同路径。

Config 下还应检查规则顺序。域名规则与 IP 规则判断的对象不同，基于 IP 的匹配可能涉及目标域名的解析。若日志已经有地址，但请求落到不合适的策略，继续更换 DNS 不一定解决问题。下面的保留域名与文档地址仅用于解释语法，不是可连接服务。

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

还要区分 A 与 AAAA 记录：前者返回 IPv4 地址，后者返回 IPv6 地址。解析成功但只在使用某个地址族时连接失败，属于地址可达性线索。保留 DNS 应答与后续连接结果再处理，不要把“出现 AAAA 记录”本身当作故障，也不要同时修改 IPv6、DNS 和规则三个变量。

五、根据错误原文确定下一步

以下是 Apple 网络错误域中的错误标识，用于在错误详情或诊断信息出现相应原文时辅助判断，并不是声称 Shadowrocket 每次都会展示这些文本。浏览器也可能只显示中文提示。记录实际看到的完整内容，不要仅凭“打不开”三个字归因。

报错: NSURLErrorDomain Code=-1003

原因与解法:对应找不到主机，优先检查域名拼写与解析结果；确认失败的是服务器域名还是网页域名，再核对当前生效的 DNS 来源与静态映射。

报错: NSURLErrorDomain Code=-1001

原因与解法:对应请求超时，不能单凭此项认定 DNS 失败；先确认是否已取得目标 IP，再检查该请求的规则策略、所选服务器与当前网络的连接能力。

报错: NSURLErrorDomain Code=-1200

原因与解法:对应安全连接失败，应检查设备日期时间、目标证书及 TLS 连接情况；不要通过关闭证书校验掩盖问题，继续核对目标地址与网络认证状态。

如果只有某一个网站失败，而其他域名可以稳定访问，应把该域名及其相关资源域名单独记录。网页主文档、图片和脚本可能来自不同域名，主页面已经显示但图片一直加载，并不意味着主域名还没解析成功。结合失败资源的域名检查规则，比整体替换 DNS 更容易定位。

六、常见追问与修复验收

延迟一直有数值，还需要换服务器吗？

先保持当前服务器不变，完成 Global Routing 与 DNS 的单变量对照。若已经取得目标 IP，但相同请求经当前服务器持续超时，再用用户已有的另一台服务器复测，区分服务端路径与解析问题。

改完 DNS，为什么浏览器还是原来的结果？

先确认修改的是 Config 中正在使用的配置，并重新连接。浏览器可能复用连接或缓存结果，可关闭对应页面后重开，也可用另一个正常域名交叉检查；不要连续快速改动多个解析来源。

Proxy 能打开，Config 打不开，该改哪里？

恢复 Config 后检查目标域名命中的规则，特别是前置的 DOMAIN-SUFFIX、IP-CIDR、GEOIP 与最终的 FINAL。同时比较两次测试的解析结果，不能只把所有规则都改成 PROXY 后就视为完成修复。

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

先完成 Wi-Fi 的网页认证，并核对该网络提供的系统 DNS。保持同一服务器和配置重测；若指定解析端点只在此 Wi-Fi 下不可达，记录端点与错误，交由该网络的管理方核查。

修复验收应回到原来的使用姿态，而不是停留在临时 Proxy 测试状态。恢复所需的 Global Routing 与 On Demand 条件，重新连接，再访问最初失败的网站及一个对照网站。确认页面主体和必要资源都能加载，并确认没有依赖临时切换网络才恢复。

  1. 保留最终采用的 DNS 来源和配置副本，撤销没有证据支持的临时改动。
  2. 在日常使用的网络下复测；如涉及 Wi-Fi 与蜂窝网络切换，分别记录结果。
  3. 若故障仍可重复，携带脱敏后的错误原文、目标域名及规则命中信息继续排查，而不是反复导入同一份订阅。
App Store 正版核对