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

一、延迟正常为什么不能证明 DNS 正常

Shadowrocket（小火箭）的 Connectivity Test 用于检查所选测试方式对应的连通性。结果中的时间，只反映该次测试涉及的目标和路径；即使测试成功，也不能推导出所有网站的域名都能解析、所有出站都能访问，或者 HTTPS 握手一定成功。先看测试方式和目标，再解释结果，不能只看一个延迟数字。

打开网页还需要取得域名对应的地址、选择访问策略、建立连接并完成 TLS 握手。以下是定位问题时的逻辑分解，不代表客户端内部各环节始终严格串行；例如，域名规则可以在取得 IP 前完成匹配，而 IP 类规则可能需要解析结果。

判断 DNS 故障应寻找解析失败的证据。浏览器明确提示找不到服务器，或系统查询工具无法取得地址，比“网页转圈”更有指向性。如果已经得到地址，却在连接或证书验证阶段失败，应转查出站、规则、系统时间或网站本身。

• 所有域名失败：先查解析器是否可达、当前网络是否需要网页登录认证，以及 VPN 是否真正保持连接。
• 少数域名失败：先查域名拼写、域名专用 DNS、规则命中和目标站点状态。
• 页面文字出现但图片不加载：记录失败资源的域名。主站与图片、接口可能使用不同域名和规则。
• 直接访问 IP 也失败：不能立即排除 DNS，也不能立即确认线路故障。HTTPS 网站通常依赖正确的域名、SNI 和证书，裸 IP 访问不是可靠对照。

二、先记录原状，再做三组对照

开始修改前，记录 Home → Global Routing 当前选项、正在使用的服务器、Config 中启用的配置，以及 Settings → DNS 的现有值。复制配置作为排查副本，不在唯一一份配置上连续试改。订阅内容可能在更新时被重新写入，因此还应区分手动设置与服务商配置中的设置。

1. 同网络对照：在当前 Wi-Fi 下，分别测试一个原本可以直接访问的网站和出现故障的网站。记录完整报错，不只记录“打不开”。需要断开连接作对照时，仅测试允许直接访问的站点，并留意 Settings → On Demand 是否会按条件重新连接。
2. 换网络对照：保持服务器、Config 和 DNS 不变，将 Wi-Fi 换成移动网络，或换到另一条已知可用的网络。如果只有某个 Wi-Fi 失败，优先检查该网络的认证页、DNS 限制或路由器设置。
3. 换姿态对照：记录原选项后，在 Home → Global Routing 临时比较 Config 与 Proxy。Proxy 用于比较一般网页流量经代理出站后的表现，不等于所有 DNS 请求都会自动走代理；测完恢复原选项。

三、Settings → DNS：地址、默认值与推荐取值

进入 Settings → DNS，先确认当前显示的是系统解析方式还是自定义解析器。这里不能给所有设备写死一个统一“默认地址”：平台、现有设置及导入配置都可能影响生效值。以本机当前页面和启用的 Config 为准；如果自定义过，先保存原值，再做单项对照。

解析器地址决定向谁查询；传输方式决定查询如何发送；域名专用设置决定某个域名是否使用另外的解析路径。这三件事应分开检查。更换解析器不会自动修复错误的 PROXY 策略，也不会让不可达的代理服务器恢复连接。

添加多个 DNS 地址不等于自动修复。不同实现可能有不同的查询与回退逻辑，不能假定列表中的第二个地址一定会在第一个超时后接管。先用单一解析器确认可达性，再按实际需要恢复配置。

如果加密 DNS 的服务端使用域名，而解析该域名又依赖这个尚未连通的服务，就可能产生启动阶段的依赖问题。此时应核对配置提供方要求的启动解析与路由设置，而不是关闭证书验证。不要用随意替换成 IP 的方式修改加密 DNS 地址，这可能破坏证书名称匹配。

四、检查 Config 中的 DNS 覆盖与规则顺序

只修改 Settings → DNS 后现象不变，需要回到 Config，查看启用配置中的 [General]、[Host] 和 [Rule]。其中 DNS 相关选项、域名映射和规则可能共同改变实际访问路径。不要假定设置页里看见的地址就是该域名最终使用的解析器；应结合配置和可用的请求记录确认。

规则从上到下匹配，命中后使用对应策略。下面只演示顺序，不是可直接替换现有配置的完整文件；PROXY 必须对应当前配置中可用的策略或策略组，示例域名也需要替换为实际排查对象。

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

• DOMAIN-SUFFIX,example.com,PROXY：匹配该域名及其子域名。若更靠前已有相关规则，后面的新增规则可能没有机会生效。
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：为这个私有地址段指定 DIRECT；no-resolve 表示不为了匹配该条 IP 规则而主动触发域名解析，不是关闭整个客户端的 DNS。
• GEOIP,CN,DIRECT：按 IP 地理数据库判断。结果受地址与数据库影响，应以实际解析到的 IP 核对规则命中结果。
• FINAL,PROXY：前面的规则均未匹配时使用的兜底策略。它不能替代 DNS 配置，也不能修复错误的域名映射。

如果某个域名命中 REJECT，应确认是否来自有意启用的过滤规则。若命中 DIRECT 后无法访问，而经代理出站可以访问，应调整对应域名的策略，不必先改全部 DNS。对于公司内网域名，则往往需要内网 DNS 与 DIRECT 配合，公共解析器无法替代内部域名服务。

五、按报错原文区分解析、连接与证书问题

以下是浏览器或命令行工具可能显示的原文，不是 Shadowrocket 所有平台都固定使用的提示。记录报错所在应用、目标域名和发生时间，再与客户端请求记录对照。不要把浏览器的所有错误都归为 DNS 失败。

Mac、Windows 或 Linux 上可用系统自带的 nslookup 作补充对照。下面的 example.com 是示例域名，应替换为实际失败的域名。第一条查询当前工具采用的默认解析器，第二条指定一个公共解析器：

nslookup example.com
nslookup example.com 1.1.1.1

查看回答中的查询服务器、是否返回地址，以及是否出现超时或 NXDOMAIN。这个工具不一定复现浏览器自带的加密 DNS 或 Shadowrocket 的全部域名策略，所以它是对照证据，不是客户端内部查询结果的替代品。若浏览器单独启用了安全 DNS，也应记录该状态，在可控条件下比较使用系统解析时的表现。

六、修改后的复测与恢复顺序

DNS 回答可能被客户端、系统和浏览器分别缓存。改完设置后，旧连接或旧回答可能继续影响结果，因此不能只刷新一次网页就认定修改无效。也不要通过反复更新订阅来清缓存，订阅更新可能同时改变服务器和配置，使对照失去意义。

1. 保存一项修改：确认当前启用的 Config 没有切换，记录修改前后的 DNS 或规则值。
2. 重建连接：在允许短暂中断的情况下，关闭再打开 Home 的连接开关；留意 Settings → On Demand 是否自动重连。
3. 重新发起请求：关闭故障页面后重新打开，必要时退出再启动浏览器。无痕窗口有助于排除部分站点数据影响，但不保证清除系统 DNS 缓存。
4. 复测同一对象：使用相同域名、相同网络和相同 Global Routing 选项，对比错误类型是否变化，再测试原本正常的站点是否仍然正常。
5. 保留或回退：只有结果可重复时才保留修改。无改善就恢复原值，继续检查下一项，不把多个未经验证的修改叠加。

七、DNS 排查中的常见问题

进一步查阅可进入规则手册核对匹配顺序，或到连接问题说明继续区分解析与出站故障。本站不提供、不销售、不推荐节点或订阅；涉及账号状态和服务端配置的问题，应由用户向自己的服务商确认。