本文适合 Shadowrocket（小火箭）已经能够连接、节点延迟测试也有结果，但网页提示找不到服务器、部分域名长期转圈或订阅刷新失败的情况。排查顺序是先区分连接与解析，再核对 Settings → DNS、Global Routing 和当前 config，最后利用 Log 判断请求停在 DNS、规则匹配还是代理出站。
延迟正常不等于 DNS 已经可用
Shadowrocket 对节点执行延迟测试时，测试目标、连接方式和网页访问过程并不完全相同。延迟数值只能说明客户端在当时能够向已有服务器地址发起一次连接或探测，不能证明任意域名都能被正确解析。网页访问还要经历域名查询、规则匹配、建立 TCP 或 QUIC 连接、TLS 握手与内容传输，其中任意一步失败都可能表现为页面空白或持续加载。
DNS 的任务是把域名转换成 IP 地址。若域名没有得到结果，后续的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 规则可能无法按预期完成整条处理链。若得到错误地址，客户端也可能成功匹配规则，却连接到不可用的目标。因此，“节点显示 80 ms，但网页打不开”不能直接归因于节点速度。
端口数字只用于理解查询路径，并不表示需要手动开放或逐项填写。用户已有的 config、服务商说明或当前网络可能指定了不同的解析方式。排错时应先记录原设置，再一次只改一个项目；同时改 DNS、节点、Global Routing 和 config，会使结果失去可比性。
Settings → DNS 各项应该怎样理解
进入 Shadowrocket 的 Settings，再打开 DNS 相关页面。界面中实际出现的项目会受到当前设置与 config 影响，应以设备上显示的英文标签为准。常见的 DNS Server 用于主要查询，Fallback DNS Server 用于主要解析路径失败后的备用处理，Bootstrap DNS 用于先解析加密 DNS 服务自身的域名。Bootstrap DNS 不能代替所有常规查询，它解决的是“要访问 DNS 服务，先要知道该服务地址”的起始问题。
System 或 system 表示采用系统提供的解析路径。未主动填写自定义地址、也未由 config 覆盖时，应保留客户端当前显示的初始状态，不要仅凭其他设备截图照抄。导入 config 后，[General] 中的 dns-server、fallback-dns-server 与 ipv6 等字段可能改变实际行为，所以 Settings 页面和当前 config 必须一起核对。
| 项目 | 作用 | 排查时的判断 |
|---|---|---|
| DNS Server | 承担主要域名查询 | 全部域名均无结果时先检查此项是否可达、格式是否完整 |
| Fallback DNS Server | 主要查询失败时提供备用结果 | 主解析偶发超时时，可暂时核对备用路径是否也被当前网络阻断 |
| Bootstrap DNS | 解析 DoH 或 DoT 服务自身的主机名 | 加密 DNS 地址是域名且启动阶段失败时重点检查 |
| IPv6 | 控制或影响 AAAA 查询与 IPv6 连接 | 网络仅部分支持 IPv6 时，可能出现先返回 AAAA、连接却超时的现象 |
如果当前 config 明确写有 DNS 字段，以该 config 的处理逻辑为重点。下面是用于识别语法的示例，不是要求照抄的公共设置；地址采用文档示例网段，不能作为实际 DNS 服务使用。
[General]
dns-server = system, 192.0.2.53
fallback-dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT
FINAL,PROXY结论:先确认谁在控制 DNS
Settings 与当前 config 同时存在 DNS 设置时，不要只盯住一个页面。先记录当前启用的 config，再检查其中的 [General]，可以避免反复切换 DNS Server 却看不到变化。
按固定顺序排查全部域名打不开
全部网页都提示找不到服务器时，先保持当前节点和 config 不变。这样可以确认修改 DNS 前后的差异。排查过程中每完成一步，选择同一个常用域名重新测试，并完全关闭先前失败的页面后再打开，避免浏览器继续展示旧错误。
确认连接状态
返回 Home，确认顶部连接开关处于启用状态，当前节点名称与 config 均为预期项目。若开关立即回落，先处理连接问题，不进入 DNS 调整。
切换 Routing
在 Home 检查 Global Routing。短时改为 Proxy 测试一次，再改为 Direct 测试一次，最后恢复原来的 Config 或 Scene。只有 Config 失败时，应检查规则与 config；多种姿态都失败时，再集中检查 DNS 或本地网络。
核对 DNS
打开 Settings → DNS，记录 DNS Server、Fallback DNS Server、Bootstrap DNS 与 IPv6 当前值。删除刚刚手动加入且来源不明的重复项目，保留应用原先状态或用户自己确认可用的设置。
重建连接
回到 Home，关闭连接，等待数秒后重新开启。DNS 设置变化后应重建隧道，单纯刷新网页可能仍使用之前的会话或缓存结果。
更换网络
在 Wi-Fi 与蜂窝网络之间切换后重复同一测试。仅某个网络失败，说明排查重点应转向该网络的解析可达性、IPv6 支持或访问限制，而不是持续更换 Shadowrocket 节点。
查看 Log
进入 Data 或 Settings 中可用的 Log 入口，重新打开一个失败域名，观察是否出现 resolve、DNS、timeout、hostname 等相关记录，并记录发生时间。
Global Routing 的四种常见姿态用于缩小范围。Proxy 让受支持的请求统一走代理策略，Direct 让请求直接连接，Config 按规则逐条匹配，Scene 根据设置的使用场景选择行为。短时切换只用于定位，测试完成后应恢复原设置。若 Proxy 能打开而 Config 不能打开，优先核对 DOMAIN-SUFFIX、GEOIP、IP-CIDR 和 FINAL 的顺序，而不是继续修改 DNS 地址。
报错:A server with the specified hostname could not be found.
原因与解法:系统没有取得该主机名的可用地址，或结果无法用于当前连接——先核对 Settings → DNS，再重建 Shadowrocket 连接并查看 Log 中是否有查询超时。
报错:The Internet connection appears to be offline.
原因与解法:连接链中的 DNS、路由或网络接口没有完成请求——先确认 Home 开关稳定，再分别使用 Proxy 与 Direct 测试，判断问题是否只出现在某个姿态。
报错:Failed to load subscription
原因与解法:订阅域名解析失败、链接失效或用户自己的服务商限制了访问——使用原订阅链接核对格式与有效性，例如 https://example.com/sub?token=xxxx 仅是格式示例，确认后再在 Home 下拉刷新。
只有部分域名失败时检查规则与 IPv6
部分网站正常、少数域名失败，通常说明主要 DNS 路径并未完全中断。此时需要判断失败域名是否被某条规则提前匹配。例如 DOMAIN-SUFFIX,example.com,DIRECT 会让该后缀走 Direct；如果目标只在代理路径下可达，就会表现为其他网站正常、该域名超时。规则采用从上到下匹配的方式，较具体规则应放在宽泛规则之前，FINAL 负责承接前面未匹配的请求。
GEOIP 依据已解析出的目标 IP 判断策略，IP-CIDR 直接按地址段匹配。如果 DNS 返回了与预期不同的地址，GEOIP 的结果也可能变化。排查时可以在 Log 中找到失败域名对应的解析结果、命中的规则关键字与最终策略，再回到 Config 检查相关行，而不是仅凭域名所属地区推测。
- DOMAIN-SUFFIX：检查后缀是否写完整，是否有更靠前的 DOMAIN 或 DOMAIN-KEYWORD 规则先命中。
- GEOIP：检查 DNS 是否先返回了可用 IP，以及规则所选策略是否符合当前 config 的设计。
- IP-CIDR：检查地址段和掩码长度，例如 /24 与 /32 的匹配范围明显不同。
- FINAL：检查未命中前面规则的请求最终进入 PROXY、DIRECT 还是其他策略组。
- IPv6：若 Log 显示 AAAA 结果后长时间等待，可在记录原值后测试当前网络的 IPv6 可用性，并恢复与 config 一致的设置。
On Demand 也可能造成“换到某个网络才失败”。打开 Settings → On Demand，检查是否按 Wi-Fi SSID、接口类型或域名条件启用了不同连接动作。若离开一个 Wi-Fi 后 Shadowrocket 没有按预期连接，网页错误看起来像 DNS 问题，实际原因可能是 On Demand 条件未触发。测试时可先记录规则，再暂时停用 On Demand，手动连接并重复同一域名测试。
切换 DNS 后仍然失败怎样继续定位
切换 DNS Server 后没有变化，不代表故障一定与 DNS 无关。旧查询结果可能仍在应用、系统或网页进程中保留；加密 DNS 自身的域名也可能因为 Bootstrap DNS 不可达而无法启动。正确做法是重建 Shadowrocket 连接、重新打开测试页面，并在同一时间查看 Log，而不是连续填写多个解析地址。
协议层也要与 DNS 层分开判断。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的连接参数由用户已有的服务配置决定。若 Log 已经显示域名成功解析并命中预期策略，但随后出现连接超时或握手失败，排查重点应从 DNS 转向当前节点、协议参数、网络丢包或服务端状态。DNS 只负责取得地址，不能修复后续传输问题。
报错:DNS request timed out
原因与解法:查询已发出但在限定时间内没有返回——更换 Wi-Fi 与蜂窝网络做对照，检查传统 DNS 的 53 端口或加密 DNS 使用的 443、853 路径是否在当前网络可达。
报错:Could not connect to the server.
原因与解法:如果前面的 Log 已经记录解析结果，这通常属于解析之后的连接阶段——核对命中策略、当前节点状态与协议参数，不再反复切换 DNS。
- 记录失败时间、网络类型、Global Routing 姿态、当前 config 和节点名称。
- 在 Log 中确认是否出现域名查询，以及查询有没有返回 A 或 AAAA 地址。
- 有地址时继续确认命中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL 规则。
- 规则正确但连接超时，再检查节点连接、协议参数与用户自己的服务状态。
- 订阅刷新单独失败时，核对订阅域名、链接有效性和服务商给出的更新要求。
结论:以 Log 中最后成功的一步划分责任层
没有解析结果就处理 DNS；已有 IP 但策略不对就处理 Config；策略正确但握手失败就处理节点与协议。按最后成功步骤向后排查，比反复替换 DNS Server 更快。
恢复稳定设置与保留排查记录
定位完成后，应把临时使用的 Global Routing 恢复为原来的 Config、Proxy、Direct 或 Scene，把 On Demand 恢复到测试前状态，并删除仅为排错加入的重复 DNS 项目。若问题来自 config 中的规则，只修改已确认有误的行；若问题来自当前网络，则保留另一网络的对照结果，便于之后复现。
向用户自己的服务商反馈时，提供故障发生时间、使用的网络类型、失败域名、Shadowrocket Log 中与该请求相邻的几行，以及是否能在 Direct 和 Proxy 下复现。订阅内容与访问凭据属于敏感信息，截图前应遮盖 token、服务器地址中的认证信息和 WireGuard 私钥。
Shadowrocket 是 Apple 平台的付费商业应用，iPhone 与 iPad 是主要使用设备，Mac、Apple TV 和 Apple Vision 的兼容性及系统要求以 App Store 页面标注为准。唯一获取入口是 App Store，开发者应显示为 Shadow Launch Technology Limited，应用 ID 为 932747118。客户端一次性买断与线路服务是两项独立内容，购买客户端不等于获得节点或订阅。