Shadowrocket（小火箭）显示延迟正常，并不等于网页请求全过程正常。先区分 DNS 解析失败、规则选错出站与连接握手失败，再检查当前 Config 的 DNS 配置；每次只改一项，用同一域名复测。本文适合已有服务商与订阅、能够连接却无法正常浏览网页的用户，重点说明如何找到失败环节，而不是反复更换设置。
一、延迟正常，为什么网页仍然打不开？
延迟测试的结果取决于测试方式：可能只验证到服务器的连接，也可能访问一个指定测试地址。即使测试成功，也不能证明所有网站的域名都能解析、所有规则都能正确匹配，或目标网站的 TLS 握手一定成功。因此，“有延迟数值”只能作为部分链路可用的证据。
这条流程是排查模型，不是固定的内部执行顺序。域名规则可能在解析前命中；IP 类规则可能需要先取得地址；代理出站也可能由远端完成目标域名解析。若服务器地址本身使用域名，还需要先解析服务器地址，随后才有机会建立代理连接。
- 所有域名都失败：优先检查 DNS 服务是否可达、当前配置是否生效，以及基础网络是否需要完成登录认证。
- 只有个别域名失败：检查对应解析结果与命中规则，不要直接重置全部网络设置。
- 文字出现、图片不加载：页面资源可能来自其他域名，需要分别检查失败资源的请求。
- 已有地址却仍然超时：继续检查出站、IPv6 路径和目标服务，不应直接认定为 DNS 故障。
二、先做最小对照：网络、模式、配置逐项确认
先记下当前网络、Home 中选择的服务器、Global Routing 的取值，以及 Config 中正在使用的配置。保留这份记录，才能在测试结束后回到原来的状态。不要在一次测试里同时更新订阅、切换服务器并修改 DNS，否则无法判断是哪一步产生了变化。
- 检查基础网络。暂时关闭 Shadowrocket 连接，在当前 Wi-Fi 或蜂窝网络下打开平时可直连的网站。公共 Wi-Fi 若弹出认证页面，先完成认证；基础网络本身不可用时，修改 DNS 通常不能解决问题。
- 恢复连接并复现。回到 Home，确认使用的是自己的有效连接配置，再访问同一个失败域名。记录失败时间，便于在请求记录或日志中定位对应条目。
- 核对 Global Routing。日常使用规则配置时选择 Config。临时切换 Proxy 可以帮助判断故障是否与分流有关；Direct 则用于对照当前网络的直连行为。测试结束后恢复原模式。
- 核对实际配置。进入 Config，确认选中的是准备检查的配置，而不是只编辑了另一个未启用的文件。若正在使用 Scene，先核对场景对应的模式与配置，避免场景变化改变测试条件。
- 固定目标复测。分别记录“打开首页”“刷新失败页面”“访问另一个域名”的结果。一个域名恢复不代表全部问题解决。
三、DNS 设置项：先读含义，再修改当前 Config
进入 Config，打开当前使用的配置并进入编辑界面，检查 DNS 相关项目；使用文本配置时，重点核对 [General] 下的 dns-server。界面项目会随实际配置与应用界面有所不同，不要把系统 Wi-Fi 的 DNS、配置内 DNS 和浏览器自己的加密 DNS 当成同一个入口。
| 项目或概念 | 实际用途 | 排查重点 |
|---|---|---|
dns-server | 配置使用的 DNS 服务器来源；支持形式应以应用当前说明为准。 | 核对拼写、地址格式和可达性，不要一次填入大量未经验证的地址。 |
system | 使用系统提供的 DNS 来源。 | 适合作为对照；所在网络的 DNS 若有问题，使用系统来源也可能继续失败。 |
| DNS over HTTPS | 通过 HTTPS 传输 DNS 查询，通常使用 TCP 443。 | 需要完整且正确的服务端点；其主机名解析、TLS 与网络访问都必须正常。 |
| DNS over TLS | 通过 TLS 传输 DNS 查询，标准服务通常使用 TCP 853。 | 检查网络是否允许连接相应端口，以及证书对应的主机名是否正确。 |
| IPv6 与 AAAA | AAAA 记录提供 IPv6 地址；得到地址与能够连通是两个条件。 | 出现 AAAA 结果但 IPv6 路径异常时，网页可能等待超时后才尝试其他地址。 |
| Fallback | 在符合对应条件时使用备用解析来源。 | 先读清触发条件，不要假定所有备用来源都会并行查询或自动返回最快结果。 |
需要建立最小对照时，可先保存原配置副本，再仅将 DNS 来源改为系统来源。以下是文本配置中相关项目的示例，不是完整配置，也不应覆盖现有文件的其他内容：
[General]
dns-server = system保存后确认该配置仍处于启用状态，再断开并重新连接测试。如果系统来源可用而原来的加密 DNS 不可用，应继续核对原端点的访问链路。加密 DNS 的主机名本身可能需要预先解析；不能建立连接时，反复刷新网页并不会绕过这一前提。
四、检查规则命中：解析成功也可能走错出口
在 Home 中将 Global Routing 临时从 Config 改为 Proxy 后，同一网页如果恢复，说明故障可能与规则选择、直连路径或不同出站下的解析行为有关，但这并不能单独证明原 DNS 有问题。应回到 Config，沿着请求实际命中的规则继续检查。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上只用于解释语法：example.com 与 192.0.2.0/24 是文档示例，不代表待访问的服务或应照搬的分流策略。实际规则按配置顺序自上而下匹配，首条匹配后结束，FINAL 放在最后处理剩余请求。
DOMAIN-SUFFIX：匹配域名后缀。检查是否把目标域名或其资源域名提前指向了不适用的出站。IP-CIDR：匹配目标 IP 网段。示例中的no-resolve用于避免仅为匹配这条规则而主动解析域名；它不表示应用访问目标时永远不需要 DNS。GEOIP：按地址所属地区数据库匹配。域名请求是否需要先解析，取决于匹配过程与相关配置，不能只看规则名称下结论。FINAL：处理此前未命中的请求。若最终出站不可用，DNS 已经返回地址也仍会访问失败。
结论：先找到失败请求的命中规则，再决定改 DNS 还是改出站
Proxy 可用、Config 不可用时，先恢复 Config 并查看该域名的请求记录；只有证据指向解析超时或错误答案时，才修改 DNS。若记录已经给出目标地址并进入连接阶段，应优先核对命中规则和出站。
五、从日志区分解析失败、超时与 TLS 错误
在应用的请求记录或日志中，以刚才访问失败的时间和域名查找条目。不同网络层返回的措辞可能不同，下面列出的是可能出现在日志中的错误片段，不是承诺所有界面都会显示相同文字。判断时要同时看错误发生在哪一个地址、哪个阶段。
报错：no such host
原因：解析阶段没有得到可用主机地址；可能是域名错误、记录不存在或上游返回了否定结果。
解法：先核对域名拼写，再用同一网络下的另一解析来源对照；若只有服务商提供的服务器域名失败，向自己的服务商确认地址是否有效。
报错：i/o timeout
原因：某次网络操作在时限内未完成；既可能发生在 DNS 查询，也可能发生在出站连接，不能仅凭这几个词归类。
解法：检查相邻日志指向的是 DNS 服务器还是网站或代理服务器；仅当超时落在 DNS 查询阶段时，才测试其他解析来源。
报错：connection refused
原因：连接目标明确拒绝了请求，通常需要检查目标服务与端口，而不是继续等待解析。
解法：核对实际连接的地址与端口；若被拒绝的是加密 DNS 端点，检查该服务是否监听对应端口。
报错：certificate verify failed
原因：TLS 证书验证没有通过，可能与设备时间、端点主机名或证书链有关。
解法：检查系统日期时间与端点地址，向对应服务方确认配置；不要通过关闭证书验证掩盖问题。
若日志里已经出现解析出的 IP，接下来却是连接或 TLS 错误，应把排查重点移到相应阶段。也不要直接在浏览器地址栏输入网站 IP 来验证 HTTPS：证书名称、SNI 与虚拟主机选择都可能因此改变，这不是与域名访问等价的测试。
六、修改后的验证顺序与常见问题
每次修改后都应保存、确认当前 Config、重新连接，再访问相同域名。浏览器缓存与既有连接可能让旧结果暂时保留，可关闭对应页面后重新打开。先完成这类低影响操作，再考虑更大范围的系统设置调整。
- 先在原网络测试失败域名与一个平时正常的域名，记录各自是否得到解析结果。
- 保持服务器、Global Routing 与 Config 不变，只切换 Wi-Fi 和蜂窝网络做对照；注意蜂窝数据可能产生流量费用。
- 若仅一个网络失败，重点检查该网络的 DNS 可达性、认证状态与端口限制。
- 恢复原本的 Config 模式和 On Demand 条件，确认日常规则、页面资源与其他应用都能正常访问。
延迟有数字，是不是就能排除服务商连接问题？
不能。回到 Home，保持同一服务器访问失败域名，再看请求记录是否在连接阶段报错。测试地址成功与目标网站成功是不同结论；订阅或服务器参数需要核实时，从你的服务商处获取有效信息。
把 DNS 换成加密 DNS，就一定能恢复吗？
不一定。先在 Config 保存原设置，再单独修改 DNS 来源进行对照。DNS over HTTPS 和 DNS over TLS 也需要可达的端点与正常 TLS；如果故障实际发生在规则出站，换解析器并不解决根因。
只有 Wi-Fi 打不开，蜂窝网络正常，该改哪里？
先保持 Shadowrocket 配置不变，检查 Wi-Fi 是否需要认证，以及系统 Wi-Fi 详情中的 DNS 是否被手动设置。若使用加密 DNS，再核对该网络能否访问对应端口，不要同时改动多个配置项。
更新订阅以后仍然打不开，是否要一直刷新？
不需要。订阅更新用于获取连接条目，不等于修复当前 Config 的 DNS 或规则。先确认 Home 中实际选中的条目，再回到 Config 检查配置；订阅更新本身失败时，可查看订阅手册的更新说明。
关掉 IPv6 后恢复，是不是以后都应该关闭？
只能说明地址族或对应路径值得继续检查。记录原设置，对比 A 与 AAAA 结果及连接日志；确认网络的 IPv6 路径是否正常后再决定保留哪种设置，不要把一次对照结果推广到所有网络。
需要进一步定位时，向自己的服务商描述失败域名、发生时间、当前网络、Global Routing 和错误阶段即可。分享日志前先移除订阅地址、token、密码与其他认证信息。更多基础操作见使用说明中的问题排查；订阅更新操作见Subscribe 更新说明。