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

延迟正常，只能说明测试目标有响应

Shadowrocket 的延迟测试与浏览器打开网页不是同一项操作。测试方式不同，验证范围也不同：连接端口得到响应，不代表代理认证、目标域名解析、TLS 握手和网页资源加载都已成功。即使测试包含 HTTP 请求，也只能证明该测试目标当时可达，不能代替对实际失败网站的检查。

这条流程表示一次访问所需的主要环节，不代表所有协议都严格按此顺序执行。代理服务器地址若使用域名，它本身还需要先被解析；目标网站域名也可能交给远端解析。因此，要先分清出问题的是“服务器地址”还是“网页地址”，再决定修改哪里。

• 所有网站都打不开：先检查连接是否建立、代理服务器地址是否可解析，以及当前网络是否需要网页登录认证。
• 只有一个域名打不开：记录完整主机名，检查拼写、DNS 返回状态和该域名命中的规则。
• 页面文字出现、图片不出现：检查图片等资源所用的其他域名，不能只检查地址栏里的域名。

先记录现场，再做一次最小对照

排查期间保留原有配置，不同时更换服务器、DNS 和规则。以下步骤以 iPhone 为例，iPad 可按同样逻辑操作。测试应使用用户已有的服务器与订阅；订阅更新成功只说明订阅地址可以读取，不代表其中每个服务器或所有目标网站都可访问。

1. 在 Home 记录当前选中的服务器、连接开关状态和 Global Routing 的选择；在 Config 记录当前启用的配置文件。
2. 记录失败网址的主机名、发生时间、使用 Wi-Fi 还是蜂窝网络，以及浏览器实际提示。分享记录前遮去订阅地址、密码和令牌。
3. 关闭连接，测试一个在当前本地网络中通常可直接访问的网站。如果仍打不开，先检查本地网络或网页登录认证。
4. 重新连接，保持同一服务器和同一网站，重复访问。每次改动后关闭旧网页标签，再新开标签测试，减少旧连接影响。
5. 必要时在 Wi-Fi 与蜂窝网络间做一次对照，但不要同时改 DNS。网络切换后的差异可以帮助定位本地路由器或运营网络的影响。

DNS 设置分别控制什么

从 Settings → DNS 检查应用提供的 DNS 设置，再到 Config 查看当前配置中的 [General]。不同配置可能同时涉及 DNS 服务器、解析策略和按域名指定的结果。排查时要核对当前实际启用的配置，不能只看到某个输入框已有地址，就认定所有请求都走该地址。

例如，配置中的以下一行表示使用系统 DNS。它只是语法示意，不是建议覆盖现有配置的完整文件。修改前保存原值；若配置来自用户自己的服务商，先确认其中的 DNS 约定，再做局部测试。

[General]
dns-server = system

根据返回状态区分三类解析失败

浏览器的“找不到服务器”提示通常不足以定位原因。检查可用的连接记录或诊断输出时，要看有没有 DNS 返回状态、查询域名和超时信息。以下是通用 DNS 状态或诊断用语，并非承诺 Shadowrocket 的每个界面都会逐字显示这些文本。

还要区分“没有 AAAA 记录”和“域名不存在”。AAAA 对应 IPv6 地址，A 对应 IPv4 地址；某个域名只有 A 记录不一定是故障。若已有地址返回，但后续连接卡住，应继续检查地址族可达性、路由和 TLS，而不是反复替换 DNS。

• 记录查询的是 A、AAAA 还是其他类型，避免把不同查询结果直接比较。
• 返回私有地址或与预期不符的地址时，先核对本地网络用途及静态映射，不凭地址外观直接下结论。
• 不要用“把 HTTPS 网址换成 IP 地址”作为唯一验证：证书、SNI 和虚拟主机可能依赖原域名。

用 Global Routing 区分 DNS 与规则问题

Home → Global Routing 中，Config 按当前配置处理流量，Proxy 让适用的流量走代理，Direct 让适用的流量直接连接。切换姿态可以帮助定位，但它不是纯粹的 DNS 开关：目标连接路径、远端解析机会等因素也可能随之变化。

1. 先在 Config 下重现失败，记录域名及其命中的规则或策略。
2. 保持同一服务器，短暂切换到 Proxy，重新访问同一域名。如果恢复，优先检查 Config 中的分流规则与所选策略，但不要据此断言 DNS 一定正常。
3. 对当前本地网络通常可直达的目标，可短暂用 Direct 对照。目标本身在本地网络不可达时，Direct 失败不能证明 DNS 设置有误。
4. 完成对照后恢复原来的姿态；若使用 Scene，先确认当前场景实际选择了什么连接行为，避免场景变化干扰比较。

下面是规则语法示意，example.com 为示例域名，不是诊断服务。DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址网段，GEOIP 按 IP 地理归属匹配，FINAL 处理前序未命中的请求。规则按顺序检查；地址类规则还可能涉及解析结果，不能只盯着最后一行。

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

no-resolve 用于避免为了匹配相应地址规则而额外触发域名解析，不是“修复所有 DNS”的选项。若某域名被前面的规则送往不可用路径，单纯更换 DNS 可能不会改变结果。应先核对命中项，再修改该项的策略或位置。

常见追问：缓存、订阅与连接恢复

恢复后按同一条件复测

一次打开网页只能说明当次成功。恢复后，应在最初失败的网络、原目标域名和日常使用姿态下再测一次，并检查页面附属资源是否加载完整。排查记录的重点是“哪一个变量改变后恢复”，而不是累计改过多少设置。

• 恢复运行设置：还原临时切换的 Global Routing，按原需求恢复 Settings → On Demand。
• 核对配置：确认 Config 中启用的文件正确，删除仅为测试加入且已不需要的静态映射或临时规则。
• 保留证据：记录网络类型、失败域名、DNS 返回状态、修改项和复测结果；提供给自己的服务商时遮去凭据。
• 明确下一层：已有正确地址且 DNS 响应正常，仍无法建立连接时，继续检查服务器可用性、目标端口及 TLS，不再把所有失败归因于解析。