本文适用于已在 Shadowrocket（小火箭）中配置自己的服务、延迟测试有结果但浏览器仍无法访问的情况。按基础网络、Global Routing、DNS、规则与缓存的顺序逐项验证，区分“查不到地址”和“查到地址却连不上”，避免一次修改多项设置后失去判断依据。
延迟正常不等于网页链路正常
延迟测试只说明测试对象在对应测试方式下有响应。它是否包含域名解析、代理认证或目标网页访问，取决于测试方式；一次成功的测试不能证明所有网站都能打开。浏览器加载 HTTPS 页面，还需要域名解析、连接目标、TLS 握手以及服务器响应，其中任何一步失败都会表现为页面无法载入。
上面的链条用于定位故障，不代表内部实现只有这一种顺序：域名规则可以在获得目标 IP 前匹配，IP 规则则可能需要解析结果。还要区分两次解析：代理服务器地址如果填写域名，需要先解析该服务器；目标网站域名的解析位置，则与协议、出站方式和配置有关。
- 所有域名都打不开：先排查基础网络、连接状态和 DNS 可达性，不要立即重建订阅。
- 仅某个域名失败：检查域名拼写、对应 DNS 结果、规则命中与网站本身状态。
- 首页能开、图片或登录失败：这些资源可能来自不同域名，应分别查看请求，不能只检查地址栏中的域名。
- Wi-Fi 失败而蜂窝网络正常：优先比较网络认证、DNS 传输与 IPv6 路径，再判断是否与服务参数有关。
先建立可重复的测试基线
测试前记录失败网址、使用的网络、Home 中所选服务器以及 Global Routing 状态。以两个平时可以访问的网站和一个失败网站作对照，每次只改一项设置，再访问同一组页面。下面的步骤都以已有自己的服务器或订阅为前提；客户端购买不包含连接服务。
-
保存现状
在 Config 确认当前使用的配置，并先保留备份。记录 Home → Global Routing 的当前选项、所选服务器和原有 DNS 值，避免将排错修改误当作长期配置。
-
验证基础网络
暂时关闭连接，访问平时可直接访问的网站。若仍失败，先完成 Wi-Fi 认证或切换可用网络。检查 Settings → On Demand；排查期间暂时停用可能自动重新建立连接的条件，结束后恢复。
-
固定出站
回到 Home，选定自己的可用服务器并开启连接。在 Home → Global Routing 临时选择 Proxy，对同一网址重试。Proxy 用于隔离规则影响，不代表 DNS 请求一定全部通过该服务器。
-
检查解析
打开 Settings → DNS，记录当前设置，并与 Config 中已启用配置的 DNS 项核对。先恢复到一套来源明确的设置，不要同时叠加多个未经验证的解析器。
-
恢复并复测
恢复原来的 Global Routing，再次访问相同页面。若 Proxy 正常而 Config 失败，转查规则；若两者均失败，继续区分 DNS 查询失败、目标连接失败和 TLS 错误。
DNS 设置要看解析器、传输与作用范围
DNS 将域名转换为地址。A 记录提供 IPv4 地址，AAAA 记录提供 IPv6 地址；获得记录只代表查询成功，并不保证这些地址在当前网络和出站路径下可达。设置 DNS 时应分别回答三个问题：向谁查询、怎样传输、该设置作用于哪些请求。
| 检查对象 | 实际含义 | 排查动作 |
|---|---|---|
| Settings → DNS | 检查应用层 DNS 设置及已有覆盖选项，不能仅凭填入地址判断是否生效。 | 记录原值，再与启用配置核对；每次只改变一个来源。 |
dns-server |
配置文件中的 DNS 服务器项；system 表示使用系统提供的解析器。 |
查看当前启用配置的 [General]，不要编辑未启用的副本后直接下结论。 |
| 传统 DNS | 通常使用 UDP 53，也可能使用 TCP 53；端口或传输被限制时可能超时。 | 比较 Wi-Fi 与蜂窝网络，不把查询超时直接归因于网站故障。 |
| DoH / DoT | DoH 通常使用 HTTPS 443，DoT 通常使用 TCP 853；加密不等于必然可达。 | 核对解析服务支持的协议、地址与证书条件，避免只改端口或随意拼接路径。 |
| A / AAAA | 两类记录可能都存在，但其中一条网络路径可能不可用。 | 将解析结果与实际连接失败的地址族对应，再判断 IPv6 路径。 |
如果需要在配置文本中检查系统 DNS 基线，相关语法如下。它只是配置片段，不是完整配置，也不是要求覆盖现有文件；应修改备份副本中已有的对应项，避免重复建立多个 [General] 段。
[General]
dns-server = system使用系统 DNS 便于判断问题是否来自原先自定义的解析器，但不保证所有网络都返回相同结果。若原配置为指定域名安排了单独的解析方式，也要检查相应配置。不要把增加解析器数量当作通用修复：不同来源的记录可能不同，混合后反而更难复现问题。
结论：用网络切换定位传输问题
保持服务器、配置和测试域名不变，只切换 Wi-Fi 与蜂窝网络；若故障随网络变化，再检查该网络下的 DNS 可达性和地址族路径，而不是同时替换协议与整套规则。
把报错按阶段分类
以下是 Apple 网络请求中可能出现的真实错误标识，不保证浏览器或 Shadowrocket 会逐字显示这些字符串。应记录当前实际看到的原文、时间和请求域名，再按失败阶段归类；“超时”本身并不能证明是 DNS 问题。
报错：NSURLErrorCannotFindHost (-1003)
原因与解法：请求无法找到主机，常见于域名拼写错误或解析未得到可用结果。先核对完整域名，再检查 DNS 查询是否有响应；若只涉及一个域名，应同时确认该域名是否仍有效。
报错：NSURLErrorTimedOut (-1001)
原因与解法：请求在限定时间内未完成，可能发生在解析、连接或等待响应阶段。先确认是否已获得目标 IP，再检查后续连接，避免把所有超时都当作解析失败。
报错：NSURLErrorCannotConnectToHost (-1004)
原因与解法：无法连接主机，并不等同于查不到主机。若已得到地址，检查所用出站、目标端口及 IPv4/IPv6 路径，不要只反复更换 DNS。
报错：NSURLErrorSecureConnectionFailed (-1200)
原因与解法：TLS 安全连接未能建立。先核对设备日期与时间，再检查目标证书和相关 TLS 配置；不要通过关闭证书验证来掩盖故障。
DNS 查询结果也需要区分：NXDOMAIN 表示解析器报告该名称不存在；SERVFAIL 表示服务器未能完成查询；查询超时则表示在等待范围内没有收到响应。三者不是同一种故障。对已确认有效的同一域名，用固定解析设置重复测试，比只看浏览器“无法打开页面”更有判断价值。
排除 Global Routing 与规则干扰
解析成功后，网页仍可能因为出站选择不合适而失败。Global Routing 中，Proxy 用于代理出站，Direct 用于直接连接，Config 按启用配置处理，Scene 按所选场景处理。排错时不要只看服务器是否已选中，还要确认当前姿态是否真正使用它。
若 Proxy 能打开同一页面、Config 却不能，检查是否存在提前命中的域名或 IP 规则。规则按顺序匹配；DOMAIN-SUFFIX 检查域名后缀，GEOIP 与 IP-CIDR 涉及 IP 条件，FINAL 作为最终兜底。下面仅展示语法，不应整段替换现有配置。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.com和192.0.2.0/24用于文档示例，不是本文提供的连接服务。no-resolve表示不为了匹配该条 IP 规则而额外触发解析，不是关闭全部 DNS。- 如果规则提前将目标交给
DIRECT，后面的FINAL,PROXY不会将该请求重新改为代理。 - 订阅更新成功只说明订阅内容获取成功，不能证明目标网站的 DNS、规则与连接都正常；更新服务器列表也不等于修复当前 Config。
不要使用“浏览器直接打开目标 IP”作为 HTTPS 的唯一验证方法。HTTPS 还依赖域名对应的证书、SNI 和站点路由，直接输入 IP 可能触发另一种错误。更可靠的证据是：同一域名是否获得地址、命中什么动作、随后连接在哪一步失败。
缓存、IPv6 与常见复测问题
修改 DNS 后，应用、系统或解析服务可能仍保留缓存。保存配置并确认生效后，可断开再重新连接，随后重新发起浏览器请求；这不保证清除所有层级缓存。不要根据一次刷新结果就断定修复完成，应对同一组页面重复验证，并记录网络是否发生变化。
换了 DNS，为什么网页还是打不开？
先确认改的是 Config 中当前启用的文件，或 Settings → DNS 中实际使用的设置，再确认查询是否已经返回地址。若已有地址而连接失败，应转查规则、目标端口和 TLS，不要继续叠加解析器。
只有 Wi-Fi 不能用，需要重填订阅吗？
先保持订阅和所选服务器不变，切换蜂窝网络复测。若蜂窝网络正常，回到 Wi-Fi 检查认证页面、系统 DNS 与当前解析传输是否可达；没有证据表明订阅失效时，不要先删除订阅。
关闭 IPv6 后恢复，能一直关着吗？
这提示需要检查 IPv6 路径，但还不能确定根因。记录失败时是否使用 AAAA 地址，再比较同一网络的 IPv4 连接。临时关闭相关选项可作对照，长期设置应结合网络和自己的服务支持情况决定。
重连后又变成另一个配置怎么办？
检查 Config 的当前启用项、Home → Global Routing 中是否选择 Scene，以及 Settings → On Demand 是否在切换网络后触发连接。固定配置和网络条件后再复测，避免把自动切换造成的差异误判成 DNS 随机失败。
向自己的服务提供方反馈时，保留故障发生时间、网络类型、Global Routing 选项、失败域名、实际错误原文以及是否获得 A/AAAA 结果。隐藏订阅令牌、认证信息和私钥，不要公开整个配置文件。能够说明“解析成功但连接失败”或“仅某网络下 DNS 超时”，比只提交一张延迟截图更有助于定位。
- 恢复测试期间修改的 On Demand 与 Global Routing 设置。
- 保留已验证可复现的单项修改，撤回无效修改。
- 按原来的网络和测试网址复测，确认问题不是仅暂时消失。