Shadowrocket（小火箭）显示延迟，不代表目标网页已经完成 DNS 解析。本文面向已经拥有自己的服务商与配置的用户：先固定测试条件，再核对当前 Config、DNS 上游与规则命中，最后区分解析失败、连接失败和网站自身故障。每次只改一项，并保留可恢复的原配置。
一、先区分延迟测试与网页访问
延迟测试只能说明相应测试方式覆盖的链路在当时得到响应。它不一定访问正在报错的网站，也不一定使用浏览器这次请求所经历的全部解析和连接步骤。因此，出现延迟数值后，仍然可能在域名解析、策略选择、TLS 握手或网页资源加载阶段失败。
先记录一个具体失败域名、发生时间、当前网络以及 Home 中的 Global Routing。不要用“所有网页都打不开”代替测试记录：同一页面可能同时访问主站、图片域名和登录接口，主页面正常而部分资源失败，与主域名完全无法解析是两类问题。
结论：先定位失败阶段
若已经取得目标 IP，随后才出现连接超时，应先检查目标连接与策略；若同一域名持续没有解析结果，再检查 DNS。端口号仅说明协议惯例，不代表当前网络一定允许相应请求通过。
二、固定 Home、Config 与 On Demand 的测试条件
排查之前先保存当前配置副本或导出备份，并记录原来的 Global Routing。本文以 Config 姿态为主要排查环境，因为需要观察配置中的规则。Proxy 与 Direct 可用于短时间对照，但它们不能单独证明 DNS 正常或异常；Scene 也不适合作为未记录条件的对照组，应先核对当前场景对应的行为。
-
记录当前状态
进入 Home → Global Routing，记录当前为 Config、Proxy、Direct 还是 Scene，同时记下当前选中的已有服务器。测试期间不要同时更换服务器和 DNS。
-
确认活动配置
进入 Config，确认当前选中的配置文件。打开该文件右侧的信息按钮，进入 Edit Plain Text，核对实际保存的
[General]和[Rule]内容，而不是只查看一个尚未选用的文件。 -
核对自动连接
进入 Settings → On Demand，记录是否启用以及已有条件。若关闭连接后又自动连接，先检查这里；需要临时停用时记下原状态，测试结束后恢复。
-
只改一个变量
固定同一个 Wi-Fi 或蜂窝网络，在 Home → Global Routing → Config 下重复访问同一域名。每次修改保存后重新连接，再发起新的请求，并记录结果。
如果问题只在某个 Wi-Fi 出现，还应先检查该网络是否需要网页认证。认证未完成时，DNS 请求和 HTTPS 连接都可能受到限制；此时反复编辑规则不会完成网络认证。若切换网络进行对照，应把它作为独立测试，不与其他设置改动混在一起。
三、DNS 设置应核对哪些内容
DNS 上游负责回答域名对应哪些地址；规则负责选择请求使用的策略，两者不能混为一项设置。在当前配置的 [General] 中，dns-server 用于指定 DNS 服务器。先核对实际值、地址格式和可达性，再考虑替换；不要因为地址看起来熟悉就默认它在当前网络可用。
| 核对对象 | 含义 | 排查重点 |
|---|---|---|
dns-server |
配置中的 DNS 上游列表 | 是否存在拼写错误、过期地址，或与当前网络不兼容的上游。 |
system |
使用系统提供的 DNS 服务器 | 切换 Wi-Fi 与蜂窝网络后，系统提供的解析条件可能改变。 |
| DNS over HTTPS | 通过 HTTPS 传送 DNS 查询 | 核对完整 URL、路径、证书与上游连接；仅有主机名不等于有效查询端点。 |
| A / AAAA | 分别返回 IPv4 / IPv6 地址 | 得到 AAAA 记录不代表当前网络具备可用的 IPv6 出口。 |
| 服务器域名 | 已有服务器地址本身也可能需要解析 | 区分服务器域名解析失败与目标网站域名解析失败。 |
下面是用于理解字段位置的最小片段，不是可覆盖整份配置的模板。它将 DNS 上游设为系统提供的服务器，适合作为明确的对照条件，但不保证适合每个网络。编辑时应修改现有字段，保留其他配置，不要重复添加多个同名项。
[General]
dns-server = system使用带域名的加密 DNS 端点时，还要考虑上游域名如何先被解析，以及端点连接是否可达。加密只改变查询的传输方式，不保证解析结果正确，也不保证网站可连接。若上游连接本身失败，应先处理上游可达性，而不是继续添加更多地址掩盖问题。
- 只在当前使用的配置内修改；远程配置重新更新后，检查本地修改是否仍被保留。
- 不要把网站 URL、订阅链接或服务器连接参数填进
dns-server。 - IPv6 问题应通过同一网络下的对照定位，不要把永久关闭 IPv6 当成所有解析问题的统一解法。
四、用规则命中区分 DNS 与分流问题
在 Global Routing 为 Config 时，规则顺序会影响最终策略。一般应先核对更具体的域名规则，再检查地址规则和末尾的 FINAL。域名可以得到正确解析结果，但请求被分到不可用的出口；这种情况下，修改 DNS 不会直接修复策略错误。
以下片段只展示规则语法，示例域名与文档保留地址不代表任何服务。不要整段粘贴替换已有规则；应在自己的配置里寻找同类条目，结合连接记录确认命中情况。特别是 FINAL,DIRECT，只表示此示例中的最终策略，不是通用推荐值。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT| 关键字 | 匹配依据 | 与排查的关系 |
|---|---|---|
DOMAIN-SUFFIX |
域名后缀 | 检查目标域名是否被较早的条目分配到了意外策略。 |
IP-CIDR |
IP 地址段 | 目标只有域名时，地址匹配可能涉及解析；no-resolve 用于避免为该条地址规则主动触发解析。 |
GEOIP |
IP 所属地区数据库 | 这是地址分类，不是对网站域名或实际服务位置的保证。 |
FINAL |
前面的规则均未命中 | 核对最后采用的策略，不要把兜底策略写在具体规则前面。 |
结论：先对照策略，再改解析
若同一目标在 Proxy 下可访问、在 Config 下失败，应优先对照命中规则与所用出口；这只是缩小范围的线索，不足以单独认定 DNS 故障。恢复 Config 后，再逐项核对相关规则。
五、按实际错误选择下一步
报错必须结合产生它的环节阅读。下面列出的是 DNS 响应或网络日志中可能出现的原文，不是 Shadowrocket 在每次故障时都会显示的固定提示。只在实际记录出现相应文本时使用对应判断；浏览器笼统的“无法打开网页”不能直接等同于 NXDOMAIN。
报错：NXDOMAIN
原因与解法：DNS 返回所查询名称不存在——先核对完整域名与拼写，再用同一域名进行上游对照；若不同上游结果不一致，记录响应来源后继续调查。
报错：SERVFAIL
原因与解法：DNS 服务器未能完成查询，可能涉及上游故障或验证失败——确认是否仅一个域名受影响，再使用已确认可达的上游对照，不要直接判定目标网站已关闭。
报错：connection timed out
原因与解法：某次连接未在等待时间内完成，单凭该文本不能确定是 DNS——查看超时对象是 DNS 上游、已有服务器还是网站地址，再检查对应链路。
若出现证书错误，重点应转向设备时间、访问域名、证书名称和 HTTPS 连接环境。不要通过忽略证书验证来“修复 DNS”。如果网页能显示正文但图片失败，应分别检查资源域名的规则与解析，不要只重复测试主站。
- 仅一个域名失败：核对拼写、该域名的解析响应与独立规则；再确认是否为网站自身故障。
- 同一网络普遍失败：核对认证状态、系统 DNS 和上游可达性；切换网络时保持其他条件不变。
- 解析有结果但连接失败：检查地址可达性、IPv4 / IPv6 路径、策略与 TLS，而不是持续更换解析地址。
- 修改后偶尔恢复：区分缓存过期、重新连接与设置变更的影响；一次成功不足以证明根因。
六、复测、恢复与提交排查记录
修改 DNS 后，已有连接不一定立即重新解析，浏览器与系统也可能保留缓存。保存配置并重新连接后，再发起新的访问；必要时关闭原页面重新打开。不要用不断刷新旧页面代替独立复测，也不要假定重新连接会清除所有应用的缓存。
恢复访问后，应把临时改动逐项收回，只保留经过重复对照确认有效的部分。尤其要恢复原先的 On Demand 状态与 Global Routing，避免排查结束后长期停留在临时的 Proxy 或 Direct 姿态。若配置随后更新，再核对活动文件与相关字段是否发生变化。
| 记录项 | 应写清的内容 |
|---|---|
| 网络与时间 | 发生时间、Wi-Fi 或蜂窝网络、切换网络后是否复现。 |
| 活动配置 | 当前配置名称、Global Routing、DNS 上游类型及相关规则。 |
| 请求结果 | 失败域名、DNS 响应或错误原文、是否已经得到 IP、最终使用的策略。 |
| 单项对照 | 只改了什么、重新连接后的结果、恢复原值后是否再次出现问题。 |
向自己的服务商或支持渠道提供记录前，隐藏订阅完整链接、token、UUID、密码及其他凭据。不要直接公开整份配置。本文仅说明客户端排查方法，不提供、不销售、不推荐节点或订阅；客户端买断 ≠ 线路套餐。