Shadowrocket（小火箭）的延迟数值只反映对应测试路径，不能证明网页域名已经解析成功。已有自己的服务商与订阅、且连接后网页打不开的用户，可依次检查本地网络、当前 Config 的 DNS、Global Routing 与请求记录；每次只改一项，以解析结果和连接阶段判断故障位置。
一、延迟正常不等于网页请求成功
先区分两件事：连接到所选服务器，与访问目标网站。延迟测试可能只覆盖服务器连接或指定测试地址；Safari 打开网页则还需要解析目标域名、选择出站策略、建立连接并完成 TLS 握手。前一步有响应，后面的任一步仍可能失败。因此，延迟有数值时，应把 DNS 列为优先检查项，而不是直接判定服务器或整个网络正常。
这条流程用于划分排查阶段，并非所有连接的固定内部执行顺序：域名规则可能先参与匹配，部分 IP 规则则需要取得地址。实际检查时，要分别记录“是否得到 IP 地址”“最终使用什么策略”“连接失败发生在哪一步”。网站出现证书错误或 HTTP 状态码，通常说明问题已经不只是单纯的 DNS 无响应。
端口说明的是服务常用方式，不是要求在路由器上开放入站端口。得到 A 或 AAAA 记录也只说明解析返回了地址；返回错误地址、IPv6 路径不可达或后续端口受限，同样会表现为网页打不开。
二、先建立本地网络与当前配置的基线
开始修改前，保存当前配置副本，并记下出问题的完整域名、所用 Wi-Fi 或蜂窝网络、Global Routing 当前选项与报错时间。测试应使用同一网页，并额外准备一个在当前网络原本可以访问的网页作对照。只观察单个网站，容易把目标网站自身故障误认为所有 DNS 请求失败。
-
暂停自动连接
进入 Settings → On Demand，记录当前启用状态和条件，排查期间暂时停用。随后在 Home 断开连接，避免刚断开就因按需条件重新接通。
-
检查原始网络
断开后用 Safari 访问对照网页。公共 Wi-Fi 若要求认证，先完成网络登录；原始网络也无法访问时，先处理 Wi-Fi、蜂窝数据或网络认证。
-
确认当前配置
进入 Config，核对实际选中的配置文件，再打开对应文件检查内容。只编辑另一个未启用的文件，不会改变当前请求的处理结果。
-
连接后复测
返回 Home，连接用户已有的服务器，再在 Safari 重试相同网页。记录断开与连接两种状态下的差异，不同时切换服务器、DNS 和规则。
-
切换网络验证
保持配置和服务器不变，在 Wi-Fi 与蜂窝网络间切换后重试。只有一个网络失败时，优先检查该网络的 DNS 可达性、认证及访问限制。
若用户已有的服务器地址本身是域名，建立连接前也可能需要解析它。这意味着“目标网页的 DNS”与“服务器域名的初始解析”是两个检查对象。前者出错时连接可能仍保持；后者出错时，连接本身就可能建立失败。不要仅凭状态栏中的连接标识判断这两项都已完成。
三、核对 [General] 中的 dns-server
在 Config 中检查当前文件的 [General] 段，找到 dns-server。先确认是否使用系统解析、显式 DNS 地址或 DNS over HTTPS，再检查拼写及当前网络能否到达所填服务。不要把多个来源的设置直接拼接，也不要把服务商提供的其他字段误填为 DNS 地址。
[General]
dns-server = system上面是使用系统 DNS 的最小片段，用于说明字段语法，不是完整配置。若决定做对照测试，应在备份后替换原有的同名配置项，而不是重复添加 [General] 或堆叠多个 dns-server。保存后重新连接并发起新请求；恢复正常只能说明解析路径变化有效，还需要对照原设置查明原因。
- 系统 DNS：
system使用系统提供的解析设置。切换 Wi-Fi 或蜂窝网络后，其实际解析环境可能随之改变，适合建立当前网络的对照基线。 - 显式 DNS 地址：核对地址是否正确，以及当前网络是否允许到达该解析器。设置了地址不代表请求一定可达，单看服务器延迟无法验证这一点。
- DNS over HTTPS：检查完整 HTTPS 端点路径、主机名及 TLS 连接条件。解析器主机名的初始解析也可能影响连接，不能把“使用 HTTPS”当作可用性的保证。
- 局域网域名：公司或家庭内部名称可能只由本地 DNS 提供答案。改成外部解析器后，公网网页可能恢复，而内部名称反而无法解析。
四、用 Global Routing 区分规则与解析问题
进入 Home → Global Routing，先记录当前选项。Config 按当前配置中的规则处理请求；Proxy 与 Direct 可用于对照出站路径。不要把切换到 Proxy 后网页恢复直接解释为“DNS 修好了”：目标域名可能一直有解析结果，只是原规则把连接交给了不合适的出站策略。
| 测试状态 | 观察结果 | 下一项检查 |
|---|---|---|
| Config 失败，Proxy 正常 | 所选出站路径能够完成该网页请求 | 核对规则命中、策略指向及 DNS 相关配置 |
| Direct 正常，Proxy 失败 | 直接路径可访问，代理路径存在差异 | 检查所选服务器、出站连接和解析路径 |
| 多种状态均失败 | 问题不只关联某一条分流规则 | 检查本地网络、解析器可达性和目标网站 |
| 仅一个域名失败 | 故障范围集中于特定目标 | 检查该域名解析结果、专用规则和网站状态 |
规则按顺序匹配，命中后使用对应策略。检查 DOMAIN-SUFFIX 是否覆盖了目标域名，GEOIP 或 IP-CIDR 是否把解析所得地址送往其他路径，以及 FINAL 是否位于规则段最后。以下片段仅展示语法和顺序，example.com 是文档示例域名，不是网页连通性测试目标。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYno-resolve 表示该 IP 规则不为匹配目的主动触发域名解析，并不是关闭所有 DNS。是否已经掌握目标 IP、前面是否命中域名规则，都影响后续匹配。若现有配置使用命名策略，还应检查策略最终指向，不能只看到规则行里的名称就认定使用了预期服务器。
结论：先保留能复现差异的对照
当 Config 与 Proxy 表现不同时，先记录同一域名的命中规则和最终出站，再修改对应条目；不要同时更换 DNS 和服务器，否则无法判断是哪项修改生效。
五、按报错阶段辨认 DNS、连接与 TLS
Safari 的提示可能因系统语言而不同。若错误详情或诊断记录提供系统错误标识，可用下面的原文区分阶段；这些是 Apple URL Loading System 的错误名称，不表示 Shadowrocket 一定逐字显示它们。查看与本次访问时间一致的请求记录，优先寻找解析失败、目标 IP、命中策略和后续连接结果。
报错：NSURLErrorCannotFindHost（-1003）
原因：请求无法找到指定主机，可能涉及域名拼写或名称解析。解法：先核对完整主机名，再比较系统 DNS 与当前 DNS 设置下能否取得地址。
报错：NSURLErrorDNSLookupFailed（-1006）
原因：DNS 查询失败，解析器不可达或解析过程异常均可能导致此类结果。解法：检查当前解析器与网络路径，保持其他条件不变，切换网络或用系统 DNS 做一次对照。
报错：NSURLErrorTimedOut（-1001）
原因：请求超时，可能发生在解析、连接或等待响应阶段。解法：先确认记录中是否已有目标 IP，再检查对应出站与连接结果，不凭超时字样单独判断 DNS。
报错：NSURLErrorSecureConnectionFailed（-1200）
原因：安全连接建立失败，问题可能涉及 TLS、证书或网络中的连接干预。解法：核对设备日期时间与目标主机名，查看 TLS 相关记录，不通过关闭证书验证来代替排查。
如果记录里已经有目标 IP，随后连接该 IP 超时，应继续检查服务器出口、目标端口及 IPv4 / IPv6 路径，而不是反复修改 DNS。若只看到 DNS 查询发出却长期没有响应，才应重点核对解析器可达性。若只有旧网页正常、新域名失败，缓存可能掩盖了问题，也需要用新请求复测。
六、确认恢复后再还原按需连接
修改后应保存当前配置，断开再连接，并重新打开目标网页。Safari 或应用可能保留已有连接与缓存，因此一次刷新成功并不足以证明原因已经消除；同样，旧连接继续失败也不代表新设置没有生效。用原故障网页、对照网页以及另一网络重复检查，记录结果是否一致。
- 确认解析：目标域名能够得到合理地址，且不再出现本次复现时的解析失败记录。
- 确认分流：恢复日常使用的 Global Routing 状态，检查目标请求是否命中预期规则和策略。
- 确认网络切换：分别在常用 Wi-Fi 与蜂窝网络验证，特别留意切换后才出现的解析器不可达现象。
- 恢复自动条件：回到 Settings → On Demand，恢复此前记录的条件，再检查连接是否按预期触发。
- 保存有效配置：保留修改前后的副本。如果远程配置后续更新会覆盖本地编辑，应核对更新内容，不把临时修正当成永久结果。
如果仍然失败，向用户自己的服务商或网络管理员提供最小必要信息：发生时间、网络类型、目标域名、Global Routing 状态、命中策略和脱敏后的错误片段。不要发送完整订阅链接、认证密码或带访问令牌的配置。能明确说明“解析无响应”还是“取得地址后连接失败”，通常比单独提供一张延迟测试结果更有助于定位。