Shadowrocket（小火箭）显示延迟数值，只能说明对应测试在当时完成，不能证明所有域名都能解析、所有网页都能连接。本文面向已经配置好自己已有服务、但遇到网页无法加载的用户，按“确认接管状态、识别失败阶段、检查 DNS、核对规则、恢复验证”的顺序定位问题。操作前保存当前配置，每次只改一个变量，避免把解析故障与代理出站故障混在一起。
一、延迟正常，不等于网页请求完整成功
访问网页至少涉及目标域名处理、路由选择、建立连接和应用层交互。DNS 的作用是取得域名对应的地址等记录；HTTPS 页面还需要与目标完成 TLS 握手。延迟测试可能只检测服务器端口，也可能请求指定测试地址，具体取决于所选测试方式。它并没有逐一访问你正在打开的网页及其图片、脚本和登录接口。
这条流程用于划分排查阶段，不表示所有请求都必须先在本地完成 DNS。域名规则可以在取得目标 IP 前命中；部分代理协议和配置允许把域名交给远端处理，而 IP 类规则可能需要解析结果。因此，要区分“设备本地解析”“代理服务器地址解析”和“目标域名在远端解析”，不能看到一个延迟数值就排除所有 DNS 问题。
- 测试正常，所有网站失败：先检查连接开关、当前选择的服务器和 Global Routing，而不是立即更换 DNS。
- 只有部分域名失败：检查这些域名的解析结果、命中规则与实际出站策略。
- 主页面打开，图片一直转圈：分别记录失败资源的域名；它们未必与主页面使用同一条规则。
- 出现证书错误：检查系统时间、目标地址和网络登录状态，不能直接归因为解析超时。
二、先记录状态，再做一次可重复的对照
先选一个能够稳定复现问题的完整网址，记录网络类型、发生时间和报错原文。不要用“所有页面都不行”替代具体网址，也不要同时更换服务器、配置文件和 DNS。下面以 iPhone / iPad 的 Home、Config、Settings 界面为操作基准，其他平台按对应功能核对；系统 VPN 标识只表示隧道状态，不代表远端服务已经可用。
-
保存现状
在 Config 确认当前生效的配置，备份后再编辑。记录 Home 当前选中的服务器、Global Routing 状态，以及 Settings → On Demand 中已有条件，不先删除原配置。
-
确认接管
回到 Home 检查连接开关。需要手动停用连接做对照时，先检查 Settings → On Demand，避免系统按既有条件重新建立连接，让“关闭后测试”的结果失去意义。
-
核对姿态
检查 Home → Global Routing。Config 用于按配置分流，Proxy 用于对照代理路径，Direct 用于对照直接连接，Scene 按已设场景工作。测试时明确选择一种，不把 Scene 当作固定的代理模式。
-
重复请求
在同一网络、同一服务器下重试相同网址，记录错误是否一致。随后只切换 Wi-Fi 与蜂窝网络再测；如果只有一个网络失败，应优先检查该网络的 DNS 可达性、登录认证或访问限制。
-
恢复设置
完成对照后恢复原来的 Global Routing 和 On Demand 条件。将改动及结果逐项记下，避免临时使用 Proxy 成功后，误以为原 Config 内的分流问题已经修复。
三、DNS 设置需要分清地址、传输与解析位置
检查 DNS 时，要同时问三个问题：查询交给谁、通过什么传输方式、查询流量走哪条路径。填写一个 DNS 地址只回答了第一个问题，并不会自动保证该地址在当前网络可达。加密 DNS 还依赖到解析服务的连接；当解析服务使用域名时，也要考虑首次解析所需的引导路径。
| 检查对象 | 实际含义 | 排查要点 |
|---|---|---|
| System DNS | 使用系统当前提供的解析设置，通常与所连网络有关。 | 同一设备换网络后结果可能变化，不能把 Wi-Fi 下的成功直接套用到蜂窝网络。 |
| 自定义 DNS | 显式指定解析服务器或受支持的解析服务地址。 | 核对格式与可达性；不要把 HTTPS 服务地址填进只接收 IP 的字段。 |
| DNS over HTTPS | 通过 HTTPS 传输 DNS 查询。 | 检查完整服务路径、TLS 连接和解析服务自身域名的可解析性；只有端口可连仍不足以证明可用。 |
| DNS over TLS | 通过 TLS 传输 DNS 查询。 | 检查服务端口、证书验证与当前网络是否允许该连接。 |
| A / AAAA | 分别对应 IPv4 与 IPv6 地址记录。 | 有 AAAA 记录不等于当前 IPv6 路由可用；应结合连接结果判断。 |
如果当前配置使用文本形式的 [General] 段，可以检查其中的 dns-server 设置。例如下面表示使用系统 DNS，并非通用的“最佳参数”。它只适合作为受控对照：先备份，再修改现有字段，不要把重复的同名字段追加到文件末尾，也不要假定这个字段会覆盖浏览器自身的 Secure DNS。
[General]
dns-server = system四、按报错区分解析失败、连接超时与证书问题
报错原文比“打不开”更有定位价值。下面是浏览器或网络工具可能显示的真实错误文本，不是要求在 Shadowrocket 中寻找同名菜单，也不是断言每个平台都会显示相同措辞。看到错误后，应结合发生位置和日志判断，不能只凭一个词就直接改配置。
报错：ERR_NAME_NOT_RESOLVED
原因与解法：浏览器未能取得可用的名称解析结果；先核对域名拼写，再对照系统解析与当前配置的 DNS，检查是否为浏览器自己的 Secure DNS 路径失败。
报错：DNS_PROBE_FINISHED_NXDOMAIN
原因与解法：诊断结果指向域名不存在，但错误配置的解析服务也可能返回异常否定结果；确认完整域名，换可信的已知解析路径复核，不要仅靠反复刷新页面。
报错：ERR_CONNECTION_TIMED_OUT
原因与解法：连接没有在规定时间内完成，并不专指 DNS；检查目标解析地址、命中策略和远端连接，在相同网址下对照 Config 与 Proxy 的结果。
报错：ERR_CERT_DATE_INVALID
原因与解法：证书日期校验失败，可能涉及设备时间或站点证书有效期；先核对系统日期和时区，再确认目标站点状态，不要通过关闭证书验证处理。
如果查询工具明确返回 NXDOMAIN，表示该次回答认定域名不存在；返回 SERVFAIL 则是解析服务未能完成查询，两者与“没有收到回答”的超时不同。保留响应类型、查询域名和所用解析服务器，比只记录“DNS 错误”更便于后续核对。
五、检查规则：解析正确也可能走错出站
在 Global Routing 选择 Config 时，规则通常按从上到下的顺序处理，命中后执行对应策略。DOMAIN-SUFFIX 根据域名后缀匹配，IP-CIDR 根据 IP 网段匹配，GEOIP 根据 IP 地理数据库判断，FINAL 负责没有被前面规则命中的请求。DNS 返回正确地址，只代表解析阶段完成，并不能保证后续策略适合这个请求。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,PROXY这段仅用于阅读语法：example.com 是示例域名，192.0.2.0/24 是文档示例网段，不应直接当作日常规则使用。no-resolve 表示不为这条 IP 规则主动触发域名解析；如果请求已经带有 IP，仍可能匹配。示例中的 PROXY 需要当前环境存在可用的代理选择，不会凭空生成一条可用线路。
- Config 失败、Proxy 成功：优先检查域名是否被较早的 DIRECT 或 REJECT 规则命中，但这仍只是线索，也要比较两次请求的解析路径。
- Direct 成功、Proxy 失败：检查所选服务器和代理出站，不应仅因本地 DNS 能解析就认定远端也能解析。
- 主域名成功、资源域名失败：分别核对资源域名规则，不能用主域名的一次命中代表整个页面。
- 改 FINAL 没有效果：检查请求是否早已命中前面的规则，或当前是否根本没有处于 Config。
如果记录中能看到请求域名、目标地址和策略，将三者一并保存。提交诊断信息前遮盖认证凭据、私有地址和订阅令牌。不要为了排查公开完整配置；本文以用户已有自己的服务商与订阅为前提，本站不提供、不销售、不推荐节点或订阅。
六、IPv6、缓存与浏览器 DNS 的常见疑问
换了 DNS，为什么还是同一个错误？
先确认修改的是 Config 中正在使用的文件，并已保存。重新建立连接，关闭旧页面后发起新请求；浏览器、系统或远端都可能保留缓存，修改 DNS 不保证立即清除所有层的结果。记录新请求时间，避免把旧标签页的错误当成新结果。
关掉 IPv6 就能打开，应该一直关吗？
这只能说明 IPv6 路径或地址选择值得继续检查。记录 AAAA 查询结果，在同一网络分别验证 IPv4 与 IPv6 的可达性，再核对路由和服务端支持。临时停用相关选项可用于对照，但不要将它当作所有 DNS 故障的固定处理。
只有一个浏览器打不开，怎么查？
在同一设备用另一个浏览器访问完全相同的网址。检查故障浏览器的 Secure DNS、自带代理设置和扩展；临时恢复为系统解析做一次对照，并在测试后恢复原设置。无痕窗口可辅助排除部分站点数据，但不保证绕过 DNS 缓存。
用 IP 能开，用域名打不开，就是 DNS 吗？
不一定。HTTPS 站点通常依赖域名提供 SNI 和校验证书，直接访问 IP 可能进入另一站点或出现证书错误。应使用解析查询结果和带正确域名的连接测试共同判断，不要把裸 IP 页面是否打开作为唯一证据。
订阅能更新，为什么网页仍然打不开？
订阅更新只验证订阅地址当时的访问路径，不验证所有服务器与目标网站。回到 Home 确认实际选择的服务器，再检查 Global Routing 和失败域名；不要通过反复更新订阅代替 DNS 与规则排查。
七、以同一网址复测，保留最小改动
排查结束的标准不是“延迟出现了数字”，而是在预期的网络与路由模式下，原来失败的网址能够重复加载，关键资源也能正常请求。某些页面小请求正常、大资源卡住，才需要进一步考虑链路 MTU 或传输层问题；尤其使用 WireGuard 时，不应一看到网页打不开就随意修改 MTU，把另一层故障混入 DNS 排查。
- 恢复日常使用的 Global Routing，重试原网址和原先失败的资源域名。
- 在 Wi-Fi 与蜂窝网络分别验证，记录是否只有单一网络存在问题。
- 恢复 On Demand 原有条件，确认网络切换后连接行为符合预期。
- 只保留经对照证明有效的改动，撤回没有效果的 DNS、IPv6 或规则调整。
- 仍然失败时，整理报错原文、发生时间、网络类型、策略和已做对照，向自己已有服务的维护方核对。