Shadowrocket（小火箭）的延迟结果只能证明测试目标在当时可达，不能证明网页域名已经解析成功。本文以用户已有自己的服务信息与订阅为前提，按基础网络、DNS 应答、Global Routing、IPv6 和配置覆盖逐项排查；先保留原配置，每次只修改一个变量，再用同一域名复测。
一、延迟正常为什么仍然打不开网页
网页访问不是一次延迟测试。浏览器通常需要先把域名解析为 IP 地址，再建立连接、完成 TLS 握手，最后请求页面内容。测试若只探测服务器地址或特定测试目标，就没有覆盖目标网页使用的 DNS、分流规则与证书验证过程。即使测试显示一个较小的毫秒数，也不能据此排除解析故障。
这条流程用于定位阶段，不代表 DNS 查询与网页请求必然采用同一出站路径。配置可能单独安排 DNS 的发送方式，部分连接也可能由远端处理域名。因此，“节点延迟正常”和“本地 DNS 正常”是两个不同结论。
- 所有网站都失败：先查基础网络、隧道状态和 DNS 上游是否可达，不要立即修改单个网站规则。
- 只有一个域名失败：查域名拼写、该域名的 DNS 应答以及命中的规则；也可能是网站自身故障。
- 首页能开，图片或登录失败：记录失败资源实际使用的域名，不要只测试地址栏中的主域名。
- 显示证书警告或 HTTP 403：已经进入其他故障阶段，不能单凭“页面没打开”判定 DNS 失败。
二、先建立可复现的排查基线
开始前，在 Home 记录当前选择的连接，在 Config 记录正在使用的配置，并保存一份副本。后续每次测试都使用同一个完整网址，记录网络类型、时间、Global Routing 姿态与错误表现。不要同时更新订阅、更换连接、改 DNS 和改规则，否则无法判断是哪一项产生了影响。
- 检查基础网络：暂时断开 Shadowrocket，访问平时能正常访问的网站。公共 Wi-Fi 若需要网页认证，先完成网络认证；基础网络不通时，优先处理 Wi-Fi 或蜂窝网络。
- 控制自动重连：在 Settings → On Demand 检查是否启用了自动触发。为完成断开对照，可暂时停用相关触发条件，并在排查后恢复，避免误把自动重连当成手动断开测试。
- 复现一次失败：重新连接，访问故障网址，记录是长时间等待、域名错误、连接超时还是 TLS 错误。浏览器概括性的失败提示不能替代 DNS 查询结果。
- 更换网络复测：在条件允许时，将同一设备从 Wi-Fi 切到蜂窝网络，保持连接和配置不变。只有某张网络失败，才重点检查该网络对 DNS 传输或目标地址的可达性。
- 查看对应记录：结合 Shadowrocket 的连接记录、DNS 查询结果或当前可用的诊断工具，核对失败域名、返回地址和实际策略；具体入口以当前界面为准。
不要用“直接打开网站 IP”作为通用验证方法。HTTPS 网站可能依赖域名对应的 SNI、证书和虚拟主机；直接访问 IP 失败，并不能证明网络不通。
三、区分 DNS 返回错误与查询没有返回
DNS 故障首先分为两类：服务器返回了明确错误，或者查询一直没有得到有效回应。两者处理方式不同。以下是 DNS 协议中的真实状态名称，并非保证 Shadowrocket 或浏览器一定逐字显示的界面提示；有些日志只显示笼统的解析失败或超时。
报错：NXDOMAIN
原因：应答表示查询名称不存在，也可能涉及错误的本地映射或上游异常应答。解法：先核对完整域名，再用另一条已知可用的解析路径查询同名记录；不要靠增加等待时间处理名称不存在。
报错：SERVFAIL
原因：解析器未能完成查询，可能与上游权威服务器、验证过程或临时服务故障有关。解法：用同一解析器查询另一个正常域名，再对故障域名作交叉查询，以区分解析器整体故障与单域名故障。
报错：REFUSED
原因：服务器拒绝处理该查询，常见于访问控制或不允许当前来源进行递归查询。解法：核对该 DNS 服务的使用范围，恢复为当前网络或已有配置中允许使用的解析器。
如果没有任何应答，重点检查 DNS 服务器地址、传输方式与出站路径。注意，NOERROR 也不等于一定取得可用地址：查询成功但对应记录类型不存在时，答案区可以为空。只查不到 AAAA，而 A 记录正常，并不表示整个域名解析失败。
- A：返回 IPv4 地址，用于观察 IPv4 解析是否正常。
- AAAA：返回 IPv6 地址；取得地址之后，还要确认当前网络具备可用的 IPv6 路径。
- CNAME：表示别名，后续仍需解析指向的名称；主域名有应答不等于完整别名链都正常。
四、DNS 设置项分别解决什么问题
Shadowrocket 的有效 DNS 行为需要结合当前配置判断。检查 Config 中当前启用的配置及其 General 设置；以文本查看时，对应的是 [General] 等相关配置段。不要仅凭另一份未启用配置中的数值判断当前状态，也不要把服务信息里的服务器地址误填成 DNS 服务器。
| 设置或概念 | 作用 | 修改时机与边界 |
|---|---|---|
dns-server |
指定 DNS 上游；支持的地址写法与传输方式应按当前应用配置说明填写。 | 确认现用上游不可达或应答异常时再调整。填写多个地址不应被理解为固定逐项串行尝试。 |
system |
在支持该值的 DNS 配置中，使用当前系统网络提供的解析器。 | 可用于恢复对照；其实际服务器可能随 Wi-Fi、蜂窝网络或网络管理设置改变。 |
fallback-dns-server |
配置备用解析上游，作为主解析过程之外的补充。 | 具体启用条件以当前配置机制为准，不能理解为所有失败请求都会自动得到修复。 |
ipv6 |
影响 IPv6 相关处理；需结合系统、隧道与实际网络能力判断。 | 当 AAAA 正常返回但 IPv6 连接失败时作单变量对照，不能把关闭它当作所有 DNS 故障的通用答案。 |
[Host] |
配置本地域名映射，可能影响特定域名最终使用的地址。 | 只有个别域名异常时检查旧映射。网站地址会变化，不宜长期用临时 IP 替代正常解析。 |
如果使用带域名的加密 DNS 端点，还需要先解决端点自身的名称解析与连接问题。端点无法建立连接时，单纯把普通 DNS 换成加密 DNS 不会自动恢复访问；应同时检查证书验证、设备时间和端点所走的路径。
结论：先验证上游可达，再更改解析方式
端口号只能帮助辨认传输类型，不能证明端点可用。若同一上游在当前网络上无法连接，先恢复到已验证可用的配置，再分别测试普通 DNS 与加密 DNS，保留实际能返回正确答案的方案。
五、用 Global Routing 对照区分解析与分流问题
在 Home → Global Routing 核对当前姿态。日常使用规则配置时通常需要关注 Config；临时切换 Proxy 或 Direct 可以提供对照，但它们不能保证覆盖 DNS 的所有独立设置。Scene 涉及场景选择，不应当作一个固定的直连或代理策略来解释。
| 姿态 | 排查用途 | 结果如何解读 |
|---|---|---|
| Config | 按当前配置检查请求命中的规则和策略。 | 只在此姿态失败时，重点检查规则顺序、策略组选择及配置内 DNS 设置。 |
| Proxy | 临时对照代理路径下目标网站的可达性。 | 恢复访问说明出站路径值得检查，但不能单独证明 DNS 已被修复。 |
| Direct | 临时观察直接连接目标的结果。 | 只有在目标本身允许且能够直接访问时，才有有效的对照意义。 |
| Scene | 检查当前场景实际选择了什么配置与行为。 | 先确认场景内容，避免把场景切换引起的差异误判为 DNS 随机故障。 |
如果已经取得正确 IP，但连接仍然超时，应继续检查出站策略。域名规则与 IP 规则并不等价：DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址网段，GEOIP 依赖地址归属数据库，FINAL 处理前面未匹配的请求。需要目标 IP 的匹配过程可能涉及解析，而使用 no-resolve 时不应期待规则为了匹配主动发起解析。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上仅是规则语法示例，不是建议直接替换当前配置。example.com 是示例域名，PROXY 也必须在当前配置中具备可用的策略含义。诊断时先看实际命中记录：上方较宽的规则若已命中，后面的修正规则不会再得到机会；FINAL 应留在末尾。
六、解析成功后仍失败：检查 IPv6、缓存与配置覆盖
DNS 返回地址只是完成了第一步。若 A 与 AAAA 都有结果，但某张网络仅 IPv6 路径异常，浏览器可能先等待失败路径，再尝试另一条路径，表现为长时间转圈或时好时坏。此时需要对照连接使用的地址族，而不是继续反复更换 DNS。
- 对照地址族：记录失败连接使用 IPv4 还是 IPv6。必要时在配置副本中调整 IPv6 相关选项作测试；保留原值，测试后根据结果决定是否恢复。
- 排除缓存影响：改完配置后重新建立连接，并重新发起网页请求。浏览器、系统与解析器可能分别保留缓存，单次刷新未必会触发新的 DNS 查询。
- 确认有效配置：回到 Config，检查启用的仍是刚修改的那一份。编辑副本但没有启用，常会造成“修改没有效果”的错觉。
- 区分两种更新：Home 中已有 Subscribe 的更新主要用于刷新相应服务信息；远程 Config 的更新则可能覆盖配置内容。不要把刷新订阅当作修复 DNS 参数的必需步骤。
- 检查变更是否被覆盖：如果每次远程配置更新后故障重现，对照更新前后的 DNS、Host 和 Rule 内容，确认本地修改是否被替换。
不要把完整订阅链接、认证信息或未经处理的日志发给他人。求助时保留错误类型、目标域名、网络类型和策略名称即可；涉及账户与令牌的部分先删除。
七、按证据收尾：什么时候可以停止修改 DNS
完成排查后，应能指出问题发生在“查询无回应”“明确错误应答”“返回错误地址”还是“地址正确但连接失败”中的哪一类。如果每次查询都能返回预期地址，而日志显示失败发生在建立连接或 TLS 握手阶段，就应停止修改 DNS，转向检查已有服务的连接状态、目标网站、设备时间与策略路径。
- 可以确认 DNS 方向：同一域名在原上游失败，在另一条经过验证的解析路径成功，且保持其他条件不变后网页恢复。
- 更像分流问题：DNS 结果一致，只有 Config 失败；调整实际命中的规则后恢复。
- 更像网络路径问题：配置不变，Wi-Fi 失败而蜂窝网络成功，或仅某个地址族连接失败。
- 更像目标端问题：仅一个站点异常，解析正常，其他站点在同一连接与策略下可以访问。
向自己的服务方反馈时，提供发生时间、Wi-Fi 或蜂窝网络、故障域名、DNS 应答状态、返回的地址族，以及 Config 与临时对照姿态的差异。报告“域名查询返回 SERVFAIL”比只说“延迟正常但不能用”更有助于定位。完成后恢复临时关闭的 On Demand，并保留最终可用配置的副本。