Shadowrocket（小火箭）的延迟数值不能证明网页访问链路完整。已有服务商与订阅的用户，应先固定网络、目标网址和出站条目，再核对 DNS 解析、Global Routing 全局路由与连接报错。本文按可复现的顺序说明如何区分解析失败、规则选错和出站连接失败，每次只改一项，避免用反复更换 DNS 掩盖真正原因。
一、延迟正常，只说明测试涉及的环节有响应
网页打开需要经过域名解析、连接建立、TLS 握手和内容请求。DNS 的作用是把域名解析为 IP 地址；拿到地址之后，连接仍可能被目标端口、网络路径、证书或服务器状态阻断。延迟测试采用的目标和测试方式不同，覆盖的环节也不同，不能把一个毫秒数直接当成网页可用性结论。
这条流程用于定位故障，不表示所有请求都严格按同一位置解析。域名规则可能在取得 IP 之前命中，部分出站方式也可能把域名交给远端处理。应以当前配置和请求记录为依据，而不是假定所有域名都由同一台 DNS 服务器解析。
- 服务器地址可连接：只能说明测试所触及的地址与端口有响应，不代表访问任意网站都成功。
- 某个测试网址可访问：只能说明该目标当时可用，其他域名可能走不同规则或不同地址族。
- 网页长时间转圈：既可能是 DNS 等待，也可能是连接、握手或某个页面资源超时，必须继续观察报错。
二、先读懂 DNS 设置，不把端口与解析器混为一谈
先在 Config 配置中确认当前选中的配置，再查看其中的 DNS 设置。配置文件的 [General] 段可以包含 dns-server；system 表示使用系统 DNS。若配置中已经填写其他解析器，修改前应保存原值，不要直接覆盖整段配置。
[General]
dns-server = system这段内容仅用于辨认字段，不是一份完整配置，也不是要求所有网络都改成 system。系统 DNS 受当前接入网络影响；自定义 DNS 则需要相应地址与传输路径可达。加密 DNS 保护的是查询传输过程，不等于目标网站一定可以建立连接。
上述数字是协议常用端口，不是需要依次填入 Add Server 添加服务器页面的参数。出站服务器的 Port 端口必须与服务商提供的参数一致。DoH 使用 HTTPS 请求路径，不能把仅有一个 IP 地址的字符串直接当作完整 DoH 地址。
结论：先查解析结果，再决定是否更换 DNS
如果同一次请求已经取得目标 IP，随后才出现连接超时，应先检查出站路径与目标端口；只有查询失败、返回异常地址或地址族差异等证据，才支持继续沿 DNS 方向排查。
三、用五步建立可重复的排查记录
先选一个你平时能访问、当前又能稳定复现故障的网址。记录完整域名、测试时间、接入网络和错误文字。不要同时切换网络、出站条目、DNS 与规则，否则即使页面恢复，也无法判断是哪一项产生了影响。
- 确认网络已完成接入。在可信网络中完成可能存在的网页认证。分别记录关闭连接开关与开启连接开关后的结果；这个对照只用于辨认故障范围，不要求所有目标都在两种状态下可用。
- 核对当前出站。回到 Home 首页，确认连接开关与选中的条目。若条目来自 Subscribe 订阅，链接从你的服务商处获取。确认订阅状态与条目参数，不要把更新成功等同于服务端一定可连接。
- 记录路由姿态。打开 Home 首页 → Global Routing 全局路由，记录当前选择的是 Config 配置、Proxy 代理、Direct 直连还是 Scene 场景。Scene 场景还需要核对其生效条件，不能仅凭名称判断实际路径。
- 在相同条件下发起一次请求。访问同一网址，检查可用的请求记录或日志，寻找域名、解析地址、命中规则、出站策略和错误文字。没有记录到的字段应标记为未知，不能自行推断。
- 只改一项再复测。例如在保留其他条件时对照 Config 配置与 Proxy 代理，或者对照当前 DNS 与已确认可达的解析方式。每轮记录结果；无改善就恢复原值，再验证下一个假设。
四、按报错区分解析失败、连接失败与证书失败
下面列出的是网络日志中常见的错误原文片段，并非保证每个界面都会显示这些字符串。同一故障可能表现为浏览器提示、请求记录中的简短错误或更底层的日志。判断时要结合它对应的域名：报错对象可能是目标网站，也可能是出站服务器或 DNS 端点。
报错：no such host
原因：当前解析过程未能得到所需主机地址，也可能是域名拼写错误。
解法：先核对报错域名，再检查当前 DNS 的可达性；若是出站服务器域名，先解决该域名的解析，而不是修改目标网站规则。
报错：i/o timeout
原因：某次网络读写超过等待时间，既可能发生在 DNS 查询，也可能发生在连接或后续传输。
解法：查看错误前面的地址与操作阶段；查询超时检查解析器路径，连接超时则核对出站地址、Port 端口和当前网络。
报错：connection refused
原因：该连接尝试收到拒绝响应，常见于目标端口没有服务监听或网络设备主动拒绝。
解法：确认被拒绝的是网站还是出站服务器，核对相应端口；若是服务商提供的出站参数，向自己的服务商确认状态。
报错：certificate has expired or is not yet valid
原因：证书有效期与当前时间不符，可能涉及设备时间、网站证书或出站 TLS 端点。
解法：先核对系统日期与时间，再确认错误所属域名；保留证书校验，不用关闭校验来替代修复。
若网站已经返回 HTTP 403 或 HTTP 404，通常说明对应请求已到达一个 HTTP 服务，不能继续把这一条响应当成单纯的 DNS 无结果。此时应检查目标地址是否正确、网站访问条件以及服务端状态；若怀疑解析到了错误服务，再核对 DNS 返回值。
五、解析有结果，继续检查规则与 IPv6 路径
Config 配置姿态下，请求会受当前配置中的规则影响。DOMAIN-SUFFIX 域名后缀规则与 IP-CIDR 地址段规则针对的对象不同；GEOIP 地址归属规则依赖 IP 判断；FINAL 是末尾兜底规则。已有解析结果不代表请求一定经过你预期的出站。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY以上只说明规则顺序：example.com 及其子域名匹配 DIRECT 直连，其余请求由 FINAL 使用 PROXY 代理策略兜底。它不是完整配置，也不是适用于所有用户的推荐规则。若某域名被更前面的 REJECT 拒绝规则命中，更换 DNS 通常不能改变这个匹配结果。
| 对照现象 | 优先检查 | 下一步操作 |
|---|---|---|
| Proxy 可访问，Config 不可访问 | 当前配置的规则、策略与相关覆盖设置 | 查看该域名命中的规则及实际出站，不直接归因于 DNS。 |
| 同一配置在不同网络表现不同 | 网络认证、解析器可达性、UDP 与地址族路径 | 保留网址和出站条目，只切换接入网络并记录差异。 |
| 返回 A 与 AAAA，但部分连接超时 | IPv4 与 IPv6 的实际可达性 | 检查失败连接使用的地址族，再做单变量对照。 |
| 主页面能开，图片或登录失败 | 资源子域名及其规则、解析和出站 | 记录失败资源的域名，逐条检查，不只测试主站域名。 |
A 记录提供 IPv4 地址，AAAA 记录提供 IPv6 地址。DNS 正确返回 AAAA 并不保证当前网络具备可用的 IPv6 路径；同样，出现 IPv6 地址也不等于故障一定由它引起。只有对照结果指向地址族差异时，才检查相关 IPv6 设置，并保留恢复方式。
另一个容易遗漏的环节是缓存。浏览器、系统和中间解析器可能保留结果，修改 DNS 后的一次刷新未必代表发生了新查询。可以先重新建立连接并重新打开页面，再结合新的请求记录判断；不要把清除全部浏览数据作为第一步。
六、常见追问与恢复检查
延迟只有几十毫秒，为什么还要查出站连接？
延迟数字没有覆盖任意网站的完整请求。回到 Home 首页确认选中条目，再记录失败网址的连接阶段；测试目标可达而目标网站的 443 端口不可达，两种现象可以同时出现。
把网址换成 IP 地址，就能确认 DNS 问题吗？
不能直接这样判断。HTTPS 依赖域名进行证书校验和虚拟主机选择，直接访问 IP 可能得到证书错误或其他站点。应查看解析与连接记录，而不是把 IP 访问失败作为 DNS 结论。
换了 DNS 还是打不开，要继续换吗？
先看是否已经取得地址。若取得地址后才超时，恢复原有 DNS，继续核对 Global Routing 全局路由、实际出站与 Port 端口；若是查询本身超时，再检查解析器传输路径。
只有订阅更新失败，网页正常，需要改 DNS 吗？
先区分订阅域名解析失败与 HTTP 状态错误。链接从你的服务商处获取，核对复制完整性与有效状态；网页正常不代表订阅地址正常，但也不足以证明全局 DNS 有问题。
恢复后应回到日常使用的 Config 配置与预期策略，恢复原来的 On Demand 按需连接条件，再复测主页面、图片与登录等必要资源。如果只有临时切换到 Proxy 代理时成功，应继续修正规则，不要把临时对照结果当成已经定位到 DNS。
- 保留一份已验证可用的配置备份，记录最终只改动了哪一项。
- 向服务商说明问题时，提供时间、网络类型、协议、目标域名与错误文字。
- 分享日志前遮盖订阅 token、UUID、密码和完整凭据；无需公开完整订阅链接。