Shadowrocket（小火箭）的测试结果有延迟数值，不等于目标网页的域名已经成功解析。本文以用户已有自己的服务商与订阅、能够查看当前配置为前提，依次检查网络、Global Routing、DNS、规则与连接日志。每次只改一个设置，用同一个失败网址复测，最后区分解析故障、连接超时和 TLS 错误。
一、延迟测试正常，不代表网页请求全程正常
网页打开需要完成多个阶段。客户端先取得目标域名对应的地址，再根据配置决定连接路径，随后建立传输连接与 TLS 会话，最后请求页面内容。实际解析位置可能在本机，也可能在远端；流程中的任何一个环节失败，都可能表现为浏览器持续等待。
Home 中的 Connectivity Test 只说明所选测试方式对应的探测结果。探测目标、探测协议和网页使用的目标不一定相同。即使测试返回数值，也不能据此认定所有域名、所有端口和所有请求都可用。
例如，假设一次测试显示 80 ms，而浏览器报告找不到服务器。这个数字只能作为该次测试的记录，不能替代失败域名的解析结果。排查时应记录具体网址的域名部分、错误文字和发生时间，而不是反复比较延迟数字。
- 只有一个网站失败：先检查域名拼写、该站点的解析结果及其命中规则。
- 多个不同网站都失败：先检查基础网络、连接状态和公共配置。
- 页面框架出现但图片不显示：继续记录图片或脚本实际请求的域名，不能只检查地址栏中的域名。
- 直接出现 HTTP
403或502：已有某个 HTTP 服务返回响应，应沿响应来源继续查，不应直接归因为 DNS。
二、先核对 Home 与 Global Routing，再动 DNS
先确认设备本身能够访问当前网络。需要网页登录的 Wi-Fi 应先完成网络认证。然后回到 Home，核对连接开关、当前所选服务器与 Global Routing。选中了服务器和连接已经建立，是两个不同状态。
- 记录当前网络是 Wi-Fi 还是蜂窝网络，并保留一个可重复失败的网址。
- 在 Home 查看连接状态。若仍显示
Not Connected，先处理连接建立问题，不要把此时的失败当作配置内 DNS 故障。 - 进入 Home → Global Routing，记下当前选择，尤其确认是否停在
Direct。 - 运行一次 Connectivity Test，记录测试方式与结果，再打开同一个失败网址。
- 需要对照时，在记录原值后临时切换姿态；完成一次复测后恢复，不同时改 DNS、服务器和规则。
| 姿态 | 排查时关注什么 |
|---|---|
Proxy | 用于观察走代理路径时的表现；它并不等于所有 DNS 请求必然采用同一种解析路径。 |
Direct | 流量直接连接。若原本期望通过代理访问，需要先纠正姿态。 |
Config | 按当前配置的规则分流，需要核对失败域名命中的规则与策略。 |
Scene | 按已设置的场景决定路由行为；应核对当前场景，而不是只看所选服务器。 |
判断：先用姿态对照缩小范围
若同一网络、同一服务器下，Proxy 能打开而 Config 失败，下一步优先检查规则与配置相关的解析路径，不要立刻替换整套连接信息。
三、DNS 设置分别控制什么
DNS 把域名转换为地址。A 记录提供 IPv4 地址，AAAA 记录提供 IPv6 地址。收到地址只说明解析有结果，不说明设备到该地址的路径可达。特别是获得 AAAA 记录后仍连接失败时，需要区分“返回了 IPv6 地址”和“IPv6 连接可用”。
检查 Settings → DNS 中的相关设置，同时检查 Config 中正在使用的配置文件。全局设置与配置文件可能共同影响实际行为；不要只看编辑器中某个文件就认定它已经生效。以下表格解释概念，不要求把每一项都手动改成自定义值。
| 项目 | 作用 | 排查要点 |
|---|---|---|
| 系统 DNS | 使用当前系统网络提供的解析设置。 | 切换 Wi-Fi 与蜂窝网络时，解析环境可能随之改变。 |
| 自定义 DNS | 指定解析服务器。 | 服务器地址正确不等于当前网络能够访问它。 |
| DNS over HTTPS | 通过 HTTPS 传输 DNS 查询。 | 通常涉及 TCP 443；服务地址、TLS 和到服务端的路径都要可用。 |
| DNS over TLS | 通过 TLS 传输 DNS 查询。 | 通常使用 TCP 853，网络限制可能与普通 DNS 不同。 |
[Host] | 在配置中指定域名与地址的映射。 | 旧地址可能仍被使用；应检查失败域名是否存在手动映射。 |
传统 DNS 通常使用 UDP 53，某些场景也使用 TCP 53。加密传输改变的是查询通道，不会自动修复目标网站停机、错误规则或不可达地址。不要为了“加密”同时填入多组来源不明的解析地址。
如果需要用系统 DNS 做一次对照，可以先备份已有配置，再在 Config 中编辑用于测试的副本，核对已有 [General] 段的 dns-server。下面仅展示相关字段，不是完整配置，也不应覆盖原文件中的其他段。
[General]
dns-server = system已有 [General] 段时应修改对应字段，不要反复追加重复段落。保存后确认测试副本处于使用状态，再重新建立连接并复测。若当前还有手动 DNS 设置，应一并记录，以免误把两个变量的变化当成一个结果。
四、按固定顺序做单变量排查
排查的目标是确定“哪一层改变后结果发生变化”。先保存原始配置与设置记录，再按下面顺序操作。每一步都使用同一个失败域名，避免更换测试目标导致结论失去可比性。
- 核对失败范围。分别打开两个平时能够访问的网站，再打开失败网站。记录是全部失败、单站失败，还是只有静态资源失败。
- 更换接入网络。在条件允许时，用相同配置对照 Wi-Fi 与蜂窝网络。只在一个网络失败时，检查该网络的认证状态、DNS 可达性和访问限制。
- 核对配置生效状态。在 Config 确认正在使用的文件；在 Home → Global Routing 确认姿态。不要把“编辑了文件”当成“已经使用该文件”。
- 对照解析来源。保留原值，临时比较系统 DNS 与原有自定义 DNS。若结果不同，继续查看解析服务器是否可达、返回地址是否不同。
- 排除本地映射与规则。在当前配置搜索失败域名及其父域名，同时检查
[Host]和[Rule]。域名可能被更宽泛的规则提前命中。 - 重新建立连接后复测。保存设置后关闭并重新打开连接，再重新请求页面。应用可能保留旧连接或缓存，必要时退出相关应用再打开。
- 恢复无效修改。某一步没有改善现象，就恢复其原值，避免最后留下多项无法解释的改动。
不要用“直接在浏览器输入网站 IP”作为唯一的 DNS 对照。HTTPS 依赖域名参与证书校验和站点选择，直接访问 IP 可能出现证书错误或进入另一个站点，即使原来的 DNS 并没有故障。
若连接会在后台自动重新建立，还应查看 Settings → On Demand。On Demand 管理连接触发条件，不负责把域名解析成地址。做断开状态的对照时，应记录它是否启用，避免把自动重连后的请求误认为直接连接结果。
五、区分解析报错、超时与规则命中
错误原文比“打不开”更有定位价值。下面是 Apple 网络框架可能提供的英文错误描述，不保证浏览器或 Shadowrocket 在每个界面逐字显示。若日志包含错误域与代码，应连同原文一起记录。
报错：A server with the specified hostname could not be found.
原因与解法：NSURLErrorDomain -1003 表示无法找到指定主机；先核对域名拼写，再检查该域名的解析结果、DNS 可达性与本地映射。
报错：The request timed out.
原因与解法：NSURLErrorDomain -1001 表示请求超时，但不能单独证明 DNS 失败；按时间顺序核对解析、连接建立与服务器响应停在哪一步。
报错：A server with the specified hostname could not be found.
原因与解法：若错误对应的是自定义加密 DNS 服务的主机名，失败点可能是解析服务本身的初始解析；记录该服务地址，并用系统 DNS 做一次对照，而不是修改目标网站规则。
报错：An SSL error has occurred and a secure connection to the server cannot be made.
原因与解法：NSURLErrorDomain -1200 指向安全连接建立失败；核对设备日期时间、目标主机与证书相关信息，不要通过关闭证书校验来掩盖问题。
在 Config 姿态下，规则也会改变现象。规则通常自上而下检查，命中后采用对应策略。下面用保留示例域名说明顺序；内容只用于阅读，不是可直接替换的完整配置。
[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匹配example.com及其子域名；它位于前面时，后面的 FINAL 不会再决定这些请求的策略。IP-CIDR匹配地址网段。示例中的192.0.2.0/24是文档用网段，不是要添加的目标服务。no-resolve表示不为匹配该条 IP 规则主动触发域名解析，不表示整个请求此后完全不需要 DNS。GEOIP依据 IP 地理数据匹配；它不是按网站所用语言判断，也不是按域名后缀判断。FINAL,PROXY是前面规则均未命中时的兜底；排查时还要确认 PROXY 对应的实际出站。
判断：有地址后仍失败，继续检查连接阶段
若日志已显示目标地址，并在随后出现连接超时，应优先核对命中策略、目标端口与出站路径。不要仅凭网页失败就继续更换 DNS。
六、常见追问与提交排查记录
Connectivity Test 有数值，为什么 Safari 还是打不开？
先在 Home 记录测试方式，再核对 Home → Global Routing。测试与网页可能访问不同目标；用同一失败网址分别检查解析结果和命中策略，不能把一个延迟数值当成全站访问证明。
换成蜂窝网络就好了，需要改所有 DNS 吗？
先保持配置不变复现一次网络差异。检查 Wi-Fi 是否需要认证，以及当前 DNS 服务在该网络是否可达。只有对照确认解析来源影响结果后，再修改对应设置。
改了 DNS 还是显示旧结果怎么办？
先确认 Config 中使用的是已修改的配置，再重新建立连接并重开请求页面。检查 Settings → DNS 与配置的 [Host] 是否还有手动设置；不要连续追加多个 dns-server 字段。
只有订阅更新失败，也能判断是 DNS 吗？
不能。订阅请求还可能受链接有效性、鉴权和服务器响应影响。记录更新时的错误原文，并向自己的服务商确认已有订阅仍有效；不要在排查记录中公开完整订阅地址。
如果需要进一步协助，整理下面这些信息即可。清晰的复现条件比整份未脱敏配置更有用；订阅凭据、密码、私钥与完整访问令牌都应隐藏。
- 失败域名、发生时间，以及网页显示的错误原文。
- 设备使用 Wi-Fi 还是蜂窝网络，换网络后现象是否变化。
- Home 的连接状态、Global Routing 选择和 Connectivity Test 的方式与结果。
- 正在使用的配置名称、相关 DNS 字段、是否有对应 [Host] 映射。
- 相关规则及其顺序，以及日志中可确认的目标地址、命中策略或连接错误。
- 已经尝试的单项修改、每次结果，以及哪些设置已经恢复。
Shadowrocket 是闭源商业应用，主要用于 iPhone 与 iPad，唯一获取入口是 App Store。应用购买与连接服务是两件事，一次性买断不包含用户自己的连接服务。系统要求以 App Store 页面标注为准。