延迟数值不能证明目标网站的 DNS、连接与 TLS 全部正常。本文适合已经拥有自己的服务器或订阅、但遇到网页打不开的用户：先固定测试条件，再检查 DNS 回答，最后用 Global Routing 与规则记录区分解析故障和出站故障。每次只调整一项，保留能够恢复的原配置。
01 延迟正常，不等于网站访问链路正常
Shadowrocket（小火箭）的服务器测试与浏览器访问某个域名，并不是同一个请求。不同测试方式覆盖的环节也不同：服务器端口能够建立连接，并不能说明目标域名已经获得正确地址；某个测试目标能够响应，也不能证明另一个网站的所有资源都可访问。
普通网页访问可以按下面几个观察点拆解。实际处理中，规则判断与 DNS 查询可能交错进行，例如域名规则可以先匹配，IP 规则则可能需要解析结果。流程链用于定位问题，不表示应用内部所有请求都严格按同一顺序执行。
- 找不到服务器：先确认域名拼写与 DNS 回答，不能仅凭浏览器提示就认定服务器不可用。
- 一直等待后超时：解析、连接或远端响应都可能超时，需要结合记录区分。
- 证书提示异常：检查设备时间、域名与证书信息，不要通过忽略证书验证来解决。
- 正文出现但图片缺失：页面资源可能来自其他域名，需要逐个检查失败请求，而不是只看地址栏里的域名。
02 先记录现场，再进入 Settings → DNS
打开 Home，记下当前服务器和 Global Routing 的选择，再到 Config 确认使用中的配置。随后进入 Settings → DNS，记录当前 DNS 设置。如果配置文件还包含 DNS 相关内容，也要一起检查；只查看一个页面，可能遗漏配置对解析行为的影响。
本节按设置的作用解释，不把某种配置的默认值当成所有设备的默认值。具体字段与可用选项以当前应用界面为准。检查重点是“向谁查询、怎样到达、查询结果是否被本地指定”，而不是把所有开关同时打开。
| 检查对象 | 作用 | 需要核对的内容 |
|---|---|---|
| DNS 服务器 | 接收域名查询并返回结果 | 地址是否录入正确，当前网络能否到达该服务。 |
| DNS 查询传输 | 决定查询如何发送 | 普通 DNS 与加密 DNS 的地址写法不同，不能只替换端口就认为协议也已改变。 |
| 本地映射 | 为特定域名指定地址 | 是否遗留过期地址，是否把单个网站固定到了已失效的地址。 |
| 配置中的 DNS 内容 | 参与当前配置的解析行为 | 当前启用的 Config 是否就是刚修改的文件，是否存在重复或冲突设置。 |
| IPv4 / IPv6 | 对应不同地址族与网络路径 | 获得 AAAA 回答不等于当前网络的 IPv6 出站一定可用。 |
下面是协议层面的常见端口，不是要求逐项填入 Shadowrocket 的推荐值。服务可能使用非默认端口，仍需以用户已有 DNS 服务的实际参数为准。加密查询也需要先建立可用连接，不会自动修复错误的路由或失效的服务器。
结论：先确认查询能到达，再判断回答是否正确
如果当前 DNS 服务本身无法连接，先恢复到已记录的可用设置；如果已经返回地址，则转查该地址对应的出站路径。不要把“有 DNS 回答”和“网页能够打开”当作同一项检查。
03 用同一域名完成一次可复现测试
选择一个确实打不开的完整网址作为测试目标，记录时间和当时使用的网络。不要一边切换 Wi-Fi，一边更换服务器、DNS 和规则，否则即使恢复访问，也无法知道是哪项修改起了作用。
- 保存原设置：记录 Home 中的服务器、Global Routing、Config 文件与 Settings → DNS 内容。配置文件编辑前保留副本。
- 建立基线：保持原设置，重新请求同一个网址，并查看本次请求对应的连接记录或日志。重点找域名、解析结果、匹配规则、策略与错误信息；可见字段以实际记录为准。
- 区分回答与超时：有明确 DNS 响应码时先解释响应码；只有等待超时而没有回答时，先检查 DNS 服务的可达性，不能把超时直接当作域名不存在。
- 只改 DNS 一项：如有自己已确认可用的 DNS 设置，可暂时替换进行对照。保存后重新建立连接，再请求相同网址，其他条件保持不变。
- 复查缓存影响：重新加载页面可能仍使用已有连接或缓存。必要时关闭相关页面、结束浏览器后重新打开；重新连接也不保证所有应用缓存立即清空。
- 恢复并复测：如果没有改善，恢复原 DNS，继续检查规则和出站。有效修改也应再次测试，避免把网站临时恢复误认为设置已修复。
04 读懂 DNS 错误，不把所有超时归为解析失败
以下是 DNS 响应码与系统网络错误的原文，不是承诺每次都在 Shadowrocket 中显示同样文字。浏览器可能只给出简化提示；只有在诊断结果或日志中实际看到这些内容时，才按对应方向处理。
DNS 响应：NXDOMAIN
原因：该回答表示查询的域名不存在，也可能与错误的查询名称或异常回答有关。
解法：先核对完整域名和拼写，再用自己已确认可用的解析路径对照；如果不同解析路径都得到相同结果，向网站管理方确认域名状态。
DNS 响应：SERVFAIL
原因：DNS 服务器未能完成这次查询，可能涉及上游解析、权威服务器或验证环节。
解法：记录域名与发生时间，使用另一条已知可用的解析路径复测；不要把该响应等同于域名不存在，也不要据此关闭 TLS 验证。
系统错误：The request timed out.
原因：请求未在限定时间内完成，这句话本身不能指明超时发生在 DNS、连接还是网页响应阶段。
解法：检查超时前是否已有解析地址和连接记录；没有回答时检查查询路径，已有地址时转查策略、服务器与目标站点连接。
如果记录已经出现有效地址，后面又显示连接失败，排查重点应向出站路径移动。反过来，如果一直没有解析结果，频繁切换网页协议或修改 FINAL 也未必触及真正的断点。
05 用 Global Routing 对照，检查 Config 的规则命中
在 Home → Global Routing 中，Proxy、Direct、Config、Scene 对应不同的路由选择方式。排查时先记录当前选择；若使用 Scene，还需要确认当前场景实际采用的行为。不要仅凭连接开关已经打开，就认定网站一定走了所选服务器。
可以在同一网络、同一服务器与同一目标网址下，短暂对照 Config 和 Proxy。如果 Proxy 可访问而 Config 不可访问，优先检查规则命中和配置差异。但这只是缩小范围：路由改变可能同时改变 DNS 查询的可达路径，因此仍需结合记录确认。
| 对照现象 | 下一步检查 |
|---|---|
| Proxy 可访问，Config 失败 | 检查目标域名是否命中 DIRECT、REJECT 或错误的策略；同时比较解析结果。 |
| Direct 可访问，Proxy 失败 | 检查所选服务器的实际访问能力、远端解析与目标连接，不要只看延迟数值。 |
| 多种路由选择都失败 | 检查域名状态、DNS 回答、当前网络与网站本身，不能直接认定是 Config 规则问题。 |
| 换网络后恢复 | 对照两种网络的 DNS 可达性、IPv6 路径与连接限制，暂时保留其余设置不变。 |
下面只演示规则语法与顺序，使用保留示例域名，不是可直接解决所有网站问题的配置。应在现有规则段中核对对应条目，而不是用这两行覆盖整份 Config。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX用于域名后缀匹配；示例会匹配example.com及其子域名。IP-CIDR与GEOIP按 IP 条件参与判断，需要注意实际解析地址与配置中的解析控制选项。- 规则按顺序匹配，命中后采用相应策略。若前面已有更早命中的条目，把新规则加在后面可能不会改变结果。
FINAL是前面规则均未命中时的兜底。改成PROXY会影响所有落到兜底的请求，不应把它作为单个域名解析失败的默认修复。
完成对照后恢复日常使用的 Global Routing。如果问题由配置修改引起，先回退对应修改，再逐条核对。用户已有订阅的更新主要用于刷新服务器信息，不等于修复当前 Config 中的 DNS 或规则内容；两者应分开检查。
06 常见追问与提交诊断信息
延迟很低，为什么只有部分网页打不开？
延迟测试没有覆盖每个网站及其资源域名。先记录失败网址，在 Config 下查实际命中策略，再对照 Proxy；如果只有图片或登录步骤失败，继续找相应资源域名，而不是反复测试同一个服务器端口。
换了 DNS 就恢复，需要一直保留吗？
先在同一网络复测，并核对原 DNS 是否超时或返回异常结果。若新设置确实稳定且符合自己已有服务的参数，可以保留；同时记录原值。一次成功不足以排除缓存、网站短暂故障或网络切换的影响。
Wi-Fi 不行，移动网络正常，要关 IPv6 吗？
先比较解析出的 A、AAAA 地址及实际连接情况。存在 AAAA 回答不代表 IPv6 路径可用，但也不说明必须永久关闭 IPv6。若要调整相关设置，只把它作为一次单变量对照，并在测试后记录结果或恢复原值。
关闭后又自动连接，怎么做断开对照？
到 Settings → On Demand 核对是否启用了按需连接，记录原状态后暂时停用，再做断开对照。测试结束按原需要恢复。On Demand 控制连接触发，不负责修复 DNS 回答或规则内容。
需要进一步协助时，提交可复现条件比只提交一个延迟数字更有效。记录中若含订阅地址、服务器凭据或个人请求信息，应先遮盖敏感内容，只保留定位问题所需的字段。
- 设备类型、当前网络类型，以及故障是否只出现在某一种网络。
- 失败域名、发生时间、Global Routing 选择与使用中的 Config。
- DNS 是否有回答、实际响应码，以及后续连接是否建立。
- 规则命中的策略、Config 与 Proxy 对照结果，以及已经恢复的修改。