本文速览

适用于 Shadowrocket（小火箭）已能显示测试延迟、但 Safari 或其他应用仍无法打开网页的情况。先区分 DNS、连接超时与 TLS 错误，再核对 Home → Global Routing 和 Config 中的 dns-server，用同一目标、单项修改、切换网络的方式定位。本文以用户已有自己的服务商与订阅为前提，不涉及服务来源选择。

一、延迟正常不等于域名解析正常

一次网页访问通常要经历域名解析、建立连接、TLS 握手和接收内容。Home 中的测试数值只反映所选测试方法覆盖的环节；TCP 连通或某个测试地址可达，不能证明目标网站的域名一定能解析，也不能证明该网站的 HTTPS 请求一定成功。先记录 Connectivity Test 使用的测试方式，避免把不同测试的结果直接比较。

DNS 的作用是把域名转换为 IP 地址。即便代理服务器本身可达，设备使用的解析器不可达、返回空答案，或域名的解析结果不适合当前出口，仍可能打不开网页。反过来，已经取得 IP 后发生的连接超时，也不能简单归类为 DNS 故障。

53
传统 DNS 通常使用 UDP 或 TCP 端口 53
853
DoT 通常通过 TCP 端口 853 传输
443
DoH 通常通过 HTTPS 端口 443 传输

判断：先定位失败阶段，再修改解析器

如果错误已明确指向证书或 TLS 握手，先核对设备时间、目标域名和连接出口；只有出现名称解析错误、DNS 超时或异常答案时，才优先沿 DNS 路径排查。端口能连通本身不代表解析服务能正常回答。

二、先固定 Home 中的测试条件

排查时保留同一个目标域名和同一条已有配置。不要同时更换服务器、改规则、更新订阅和替换 DNS，否则恢复后无法确定是哪项修改起了作用。优先选择自己经常访问、能够确认地址拼写正确的网站，再增加一个不同域名作为对照。

  1. 记录原状。在 Home 记下连接开关状态、当前选中的服务器、Global Routing 姿态，以及 Connectivity Test 的测试方式与结果。不要把凭据写入记录。
  2. 确认路由姿态。Global Routing 中的 Config 按当前配置规则处理流量；Proxy 将一般流量交给所选代理；Direct 用于直接连接对照；Scene 按已设场景工作。Scene 不能仅凭名称推断当前实际策略，应核对场景内容。
  3. 做一次短时对照。在当前网络允许访问的前提下，对同一域名比较 Direct 与 Proxy。某个姿态失败仅提示路径存在差异，不能单独证明是 DNS。完成后恢复原来的姿态。
  4. 确认没有自动干预。检查 Settings → On Demand。为进行手动对照，可先记录并暂时停用相关触发条件，避免手动断开后又被按需连接重新接通；测试完成后恢复。
  5. 切换网络复测。在 Wi-Fi 与蜂窝网络之间切换后，用相同配置重新测试。只有一个网络失败时，应重点检查该网络的 DNS 可达性、登录认证或访问限制。

如果 Wi-Fi 需要先完成网页登录认证，应先完成认证再测试。若所有网站都失败，而当前服务器的域名也无法解析，需要先解决连接入口的解析问题；此时反复切换网站规则通常没有帮助。

三、dns-server 的含义与最小修改

Config 管理的是配置文件，不是订阅服务器列表本身。修改前先保存当前文件副本，确认正在使用哪个配置，再进入该文件的编辑界面。下面是用于说明字段位置的最小片段，只替换现有文件的对应字段，不要用它覆盖整份配置。

[General]
dns-server = system
字段或取值实际含义排查时注意
[General]配置的一般设置段落修改已有段落，避免重复添加同名设置造成理解混乱。
dns-server指定配置使用的 DNS 解析器填写受当前版本支持的取值；它不是代理服务器地址，也不是订阅地址。
system使用当前系统网络提供的 DNS适合做基线对照，但结果可能随 Wi-Fi、蜂窝网络或网络描述文件而变化。
解析器 IP 地址直接指定传统 DNS 服务器需确认地址和服务可达，不能把网站 IP 或代理端口当作 DNS 服务填写。
DoH 地址通过 HTTPS 请求取得 DNS 答案使用当前版本支持的格式与完整端点；普通网站首页不能代替 DoH 端点。

先使用 dns-server = system 建立对照。如果原配置指定了解析器，而改为 system 后恢复，检查原解析器的可达性、地址格式和路径，再决定是否保留修改。system 仍失败时，也不能直接断定应用异常：系统下发的 DNS 本身可能无法访问，或目标域名在该解析器处没有有效答案。

四、按错误原文区分处理方向

以下是网络诊断中可能见到的标准错误文本或系统错误代码，并非保证 Shadowrocket 在所有界面显示相同提示。记录时应同时保留错误来源、目标域名和失败阶段。应用内提示、Safari 提示与远端服务器日志的措辞可能不同，不能仅凭“打不开”三个字归因。

报错：NSURLErrorDomain Code=-1003

原因：Apple URL 加载系统未能找到指定主机，常见于名称解析失败或域名拼写错误。

解法：先检查域名拼写，再用同一域名对照 system 与原解析器，并检查是否仅在某个网络下发生。

报错：NXDOMAIN

原因：DNS 响应表示查询的名称不存在；这与“解析器没有回应”不同，也可能涉及所用解析器的策略。

解法：核对完整主机名，用另一个已有且可信的解析器复查；若结果一致，向域名管理方确认记录。

报错：SERVFAIL

原因：解析器未能完成查询，可能涉及上游故障、权威服务器异常或 DNSSEC 验证失败。

解法：比较不同网络和解析器的答案，记录发生时间；不要把它当作永久不存在而直接改写 Host。

报错：NSURLErrorDomain Code=-1001

原因：请求超时，可能出现在解析、连接或等待响应阶段，代码本身不能证明是 DNS 故障。

解法：结合诊断记录确认是否已经取得目标 IP；已取得 IP 时继续检查路由、连接和目标服务响应。

不要把“没有 AAAA 记录”直接解释为整个域名无法解析：域名仍可能有可用的 A 记录。反过来，收到 AAAA 答案也不代表当前网络的 IPv6 路径正常。如果只有部分域名失败，应分别检查解析答案和实际连接使用的地址族，而不是一次性修改所有 IPv6 设置。

五、解析成功后检查规则与覆盖项

DNS 成功仅说明取得了答案，网站请求仍需要走正确的策略。Global Routing 处于 Config 时，规则通常按顺序匹配，先命中的规则决定该请求的处理方式。把规则顺序、策略名称或兜底改错，可能让已有答案的请求走到不可用路径。

检查对象作用具体排查动作
DOMAIN-SUFFIX匹配指定域名及其子域名核对填写的是域名而非带路径的 URL，检查前面是否已有更早命中的规则。
IP-CIDR按 IP 网段匹配检查目标 IP 是否被较早的网段规则接管；带 no-resolve 时还需理解该修饰符的影响。
GEOIP按 IP 地理数据库分类匹配不要把数据库分类等同于网站所属地区；查看实际命中的策略。
FINAL处理前面没有命中的请求核对最后落到 DIRECT、代理或已定义策略组中的哪一个。
[Host]为指定主机提供配置中的解析映射检查是否残留旧地址；先备份再移除单条可疑映射进行对照。

例如 DOMAIN-SUFFIX,example.com,DIRECT 会把示例域名及其子域名交给 DIRECT；如果该请求只有通过用户现有的代理路径才能正常连接，解析器即使返回正确答案，页面也仍可能失败。这里的 example.com 仅演示规则语法，不代表实际测试目标。

判断：已有目标 IP，就沿实际命中策略继续查

当诊断已显示解析答案，先核对该域名的命中规则、最终策略和所选出口。不要通过连续替换 DNS 来修复路由错误，也不要为了临时可用把长期变化的网站地址固定写入 Host。

六、常见追问与恢复验收

换了 DNS，为什么还是显示同一个错误？

先在 Config 确认改动保存到当前使用的文件，再断开并重新连接。关闭失败页面后重新发起请求，给缓存更新留出时间；若仍失败，记录新请求的错误，不要只看浏览器保留的旧页面。

Wi-Fi 打不开，蜂窝网络能打开，要改哪里？

保持服务器与 Config 不变，先比较两种网络下 system DNS 的表现，并检查 Wi-Fi 是否需要网页登录认证。若只在该 Wi-Fi 失败，优先确认网络侧解析和传输限制，再调整客户端字段。

网页恢复了，但订阅更新仍然失败怎么办？

订阅更新访问的是另一条 URL，不等于网页访问测试。检查自己已有订阅的域名、有效期和返回错误；分享记录前删除 token 等凭据。不要把订阅 URL 填入 dns-server，也不要用重复更新代替 DNS 对照。

能直接输入网站 IP 来证明 DNS 有问题吗？

不能作为决定性证据。HTTPS 依赖域名进行证书校验和站点选择，同一 IP 也可能承载多个站点。应保留原域名，通过解析答案与连接阶段记录定位，而不是把 IP 页面打开与否当作唯一依据。

恢复后不要只打开一次首页就结束。按照下面的验收清单检查，确认结果能重复，再保留最终修改。若仍需向自己的服务商或网络管理员反馈，提供经过脱敏的证据即可，避免发送整份配置。