本文适用于已经在 Shadowrocket（小火箭）中导入自己已有服务、连接开关正常，但访问域名失败的情况。按服务器连通性、Global Routing、DNS、规则与网络环境的顺序检查，并通过单变量测试区分解析失败、连接失败与网站自身故障。文中的配置片段只解释排查方法，不提供节点或订阅。
一、延迟正常为什么不能证明网页可以打开
延迟测试只反映测试方法所覆盖的链路。若测试仅检查服务器端口是否能够建立连接，它不能证明目标域名能够解析，也不能证明服务器到目标网站的连接正常。即使采用 HTTP 测试，结果也只对应测试地址及当时的路径，不能替代对实际失败网站的检查。
浏览器打开 HTTPS 网页时，通常需要完成域名解析、连接目标地址、TLS 协商和 HTTP 请求。DNS 的作用是提供域名对应的地址；它不会修复已过期的服务器凭据，也不会消除网站返回的访问限制。看到“连接正常”后，仍要确定请求停在哪一层。
| 观察到的现象 | 可以说明什么 | 下一项检查 |
|---|---|---|
| 服务器延迟有结果 | 测试覆盖的路径能够响应 | 目标域名解析与实际请求 |
| 域名查询返回 A 或 AAAA | 获得了 IPv4 或 IPv6 地址 | 地址是否可达、TLS 是否成功 |
| 网页返回 HTTP 403 | 请求已到达能够响应的 HTTP 服务 | 网站访问策略与出口限制 |
| 只有一个网站失败 | 故障范围可能局限于该域名或路径 | 对应规则、解析结果与网站状态 |
结论：先确认失败发生在哪一层
保留失败域名和原始提示；已有 HTTP 状态码时，先检查网站响应，不要把更换 DNS 当作第一步。
二、先建立可重复的排查基线
开始前，在 Config 中备份当前配置，记录 Home 当前选中的服务器及 Global Routing 状态。若刚更新过自己已有的订阅，也要记录更新后服务器地址、端口与认证信息是否变化。订阅能刷新，只说明获取订阅内容的请求成功，不代表其中每一项服务都可以使用。
-
记录失败样本
选择一个失败域名和一个平时可以访问的域名，记录完整错误文字、发生时间与当前使用的 Wi-Fi 或蜂窝网络。后续每轮都访问相同页面，避免更换测试对象造成误判。
-
确认服务器
在 Home 核对选中的服务器，执行当前可用的延迟或连通性测试。若服务器本身连接失败，先按自己已有服务的资料核对地址、端口及凭据，不进入 DNS 参数试错。
-
记录路由模式
打开 Home → Global Routing，记录当前是 Proxy、Direct、Config 还是 Scene。排查期间固定模式；若使用 Scene，先确认实际生效的场景，避免网络切换同时改变路由行为。
-
排除自动重连
检查 Settings → On Demand。需要比较连接关闭与开启的差别时，先记录原设置，再临时停用自动触发，防止刚关闭连接就被重新建立；排查结束后恢复原状态。
-
单项修改复测
每次只修改一个设置，保存后重新建立连接，再访问同一组域名。记录结果后决定保留或撤销，不要同时更换服务器、DNS 和整份配置。
三、DNS 设置要区分系统解析与配置覆盖
在 Config 中打开当前正在使用的配置，进入编辑界面，检查 [General] 内是否设置了 dns-server。不要只查看另一份未启用的配置。若还使用了其他 DNS 相关设置，应一并记录，避免修改的字段被其他生效设置覆盖。
system 表示使用系统提供的 DNS。它适合用于建立对照，但不表示所有网络都会得到相同答案：Wi-Fi、蜂窝网络及设备上的 DNS 配置都可能影响系统解析。手动指定解析器时，则需要确认当前网络能够到达该解析器，而不是只确认地址填写正确。
# 仅展示相关字段；不要用此片段覆盖整份配置。
[General]
dns-server = system上面的片段用于说明字段位置。实际测试时，应在现有 [General] 中修改对应行，保留其他设置，避免重复添加多个同名段落或字段。记录旧值后再保存，重新建立连接并复测；若没有改善，恢复旧值再检查下一层。
| 项目 | 含义 | 排查重点 |
|---|---|---|
| A | 域名对应的 IPv4 地址记录 | 有结果后检查该 IPv4 路径是否可达 |
| AAAA | 域名对应的 IPv6 地址记录 | 区分获得地址与 IPv6 路径真正可用 |
| 传统 DNS | 通常使用 UDP 53，必要时使用 TCP 53 | 当前网络是否限制查询或返回异常结果 |
| DNS over HTTPS | 通过 HTTPS 传输 DNS 查询，通常使用 TCP 443 | 解析端点能否连接、端点域名如何完成初始解析 |
| 解析缓存 | 在有效期内复用此前的结果 | 修改配置后是否仍在观察旧连接或旧答案 |
加密 DNS 解决的是查询传输方式，不等于自动修复所有解析问题。解析端点本身不可达，或者端点域名的初始解析失败时，同样可能超时。浏览器或其他应用若独立使用自己的解析方式，也可能与 Shadowrocket 配置中的结果不同，测试时应固定使用同一个应用。
四、根据报错区分无记录、服务器失败与超时
以下是 DNS 诊断中常见的原始状态或错误字符串，不代表 Shadowrocket 在所有界面都会原样显示。浏览器可能只显示概括性错误；应结合当前可见的日志、请求记录或查询结果判断，不要仅凭“无法打开网页”推断原因。
报错：NXDOMAIN
原因：响应方表示所查询的域名不存在；拼写错误、过期域名或异常解析响应都可能造成这一结果。
解法：先核对完整域名，再用另一网络作对照；若只在一个解析路径出现，记录两边结果，检查当前 DNS 来源及本地覆盖。
报错：SERVFAIL
原因：解析器未能完成查询，可能涉及上游查询失败、域名权威服务异常或验证问题，不等同于域名不存在。
解法：用其他已知正常的域名判断是否为单域名故障，再在保持路由不变的情况下切换到已确认可达的解析方式复测。
报错：connection timed out
原因：指定操作未在期限内完成；只有明确发生在 DNS 查询阶段时，才能归入解析超时。
解法：先看超时对象是解析器、服务器还是目标网站，再检查对应端口与网络路径，避免把目标网站的 TCP 超时误当作 DNS 故障。
没有 AAAA 记录不一定是错误：有些域名只提供 A 记录。同样，查询成功但没有所请求类型的记录，也不同于 NXDOMAIN。应同时记录查询的名称、记录类型和返回状态，而不是只记录“没有 IP”。
五、解析成功后检查 Global Routing 与规则
Global Routing 的 Proxy、Direct、Config、Scene 是路由工作方式，不是 DNS 服务器选项。Proxy 用于代理路由，Direct 用于直接连接，Config 按当前配置处理，Scene 按当前场景设置工作。切换它们可以形成对照，但不能据此认定某一种模式必然在本地或远端完成全部解析。
若同一域名在 Proxy 可以访问、在 Config 失败，下一步应检查 Config 下的实际规则命中。若 Direct 可以访问而 Proxy 失败，则还要核对服务器到目标站点的路径。两种现象都不足以单独证明 DNS 有问题。
# 仅说明规则语法与顺序，不是可直接替换的完整配置。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECT匹配该域名及其子域名。检查失败域名是否提前命中了不符合预期的策略。IP-CIDR匹配地址范围；示例中的192.0.2.0/24是文档示例网段，不是实际服务地址。no-resolve用于避免为匹配该条 IP 规则而主动进行域名解析，不表示整个配置停用 DNS，也不阻止请求在其他阶段获得地址。GEOIP根据 IP 所属地区匹配；对域名请求是否需要解析，要结合已有地址与规则参数理解。FINAL放在末尾，处理前面都未命中的请求。确认兜底策略指向预期路径，不能只检查单条域名规则。
结论：有地址仍失败时，转查实际命中策略
保持 DNS 不变，只比较 Proxy 与 Config 的访问结果；若差异稳定出现，优先定位规则及其选定的出口，不继续叠加 DNS 修改。
六、Wi-Fi、蜂窝网络与 IPv6 的对照方法
同一配置在 Wi-Fi 失败、蜂窝网络成功，说明网络环境是重要变量，但不能直接断言 Wi-Fi 的 DNS 出错。网络还可能限制服务器端口、影响 IPv6 路由，或要求先完成登录认证。切换网络后应重新建立连接，并确认 Global Routing 和服务器选择没有随场景改变。
- 先完成网络认证：公共 Wi-Fi 若要求登录，应先完成其认证流程，再测试 Shadowrocket。认证前的重定向或连接阻断可能表现为多个网站同时失败。
- 比较同一域名：在两种网络下访问相同页面，记录 DNS 是否有结果、连接是否超时、是否出现 HTTP 状态码，不能只比较延迟数值。
- 核对 IPv6 路径：若域名返回 AAAA，但当前网络的 IPv6 连接不可用，可能表现为等待或部分资源失败。先确认失败请求实际使用的地址族，再做临时对照，不把停用 IPv6 当作通用修复。
- 处理缓存影响：重新建立连接并重新打开测试页面。应用可能保留自己的 DNS 缓存或连接池，必要时退出并重新打开该应用；重连本身不保证所有应用缓存都被清除。
七、常见追问与排查结束条件
延迟一直正常，是否只需要换 DNS？
先在 Home 确认服务器和 Global Routing，再检查失败域名有没有获得地址。若已经返回 HTTP 错误或 TLS 错误，应转查对应层；只有解析阶段失败时，才把 DNS 作为主要变量。
改了 dns-server，为什么结果没变化？
在 Config 确认修改的是当前启用配置，检查是否有重复字段或其他生效设置。保存后重建连接、重新打开测试应用，并使用同一域名复测；同时留意应用自身的 DNS 和缓存。
只有一个网站打不开，还需要重做配置吗？
先核对域名拼写、该域名的解析结果和 Config 下的规则命中，再比较 Proxy 与 Direct 的结果。保留其他正常网站作为对照，不要为了一个域名直接替换整份配置。
订阅刷新成功，为什么网页还是打不开？
订阅刷新与网页访问是不同请求。回到 Home 确认当前实际选中的服务器，按自己已有服务的资料核对参数，再按本文顺序检查目标域名、路由与 DNS；刷新成功不能替代连接验证。
结束排查前，使用原先失败域名和正常对照域名各复测一次，再恢复临时停用的 On Demand 及原有场景设置。保留能够解释改善原因的最少修改，撤销没有效果的试验项。若仍需向自己已有服务的支持渠道反馈，提供失败时间、网络类型、相关错误和脱敏后的配置片段，移除订阅令牌、密码及其他认证信息。