本文适用于已在 iPhone 或 iPad 上配置 Shadowrocket、已有自己的服务器或订阅，但遇到延迟测试正常而网页无法加载的情况。按“确认症状 → 对照路由 → 核对 DNS → 检查 IPv6 → 复测”的顺序操作，可以区分解析故障、服务器连接故障与规则分流问题，避免一次改动多个设置后无法判断原因。
一、延迟正常不等于网页请求完整成功
Shadowrocket（小火箭）中的延迟结果，只能说明对应测试方法在当时完成了某个连接步骤。TCP 测试通常侧重服务器端口是否可达；使用 HTTP 类测试时，结果也只对应测试目标及其路径。它不能代替对故障网站的 DNS 查询、TLS 握手和页面资源加载的检查。
打开网页通常需要把域名解析为地址，再通过选定的直连或代理路径建立连接，随后完成 TLS 握手与 HTTP 请求。代理场景中，目标域名也可能交给远端解析。只看到一个延迟数值，不能确定本地 DNS 或远端 DNS 是否都正常，更不能据此认定网站一定可访问。
这些端口描述的是 DNS 传输方式，不是要求把服务器端口改成其中一个。DNS over HTTPS 可以正常建立连接，也不代表目标网站可达；反过来，普通网页能打开，也不能证明网络允许访问每一种 DNS 传输方式。
二、先建立可以重复的故障对照
排查时使用同一个完整网址、同一个浏览器和同一台设备。不要把网站首页、站内跳转与视频播放混成一个测试：主文档可能已经成功，但图片、登录或媒体使用的其他域名仍然失败。每轮只改变一个条件，并记录结果。
- 确定范围。分别访问故障网站与一个此前可正常访问的网站。记录是全部页面失败、仅一个域名失败，还是文字能显示而图片一直加载。
- 确认基础网络。暂时停止 Shadowrocket 连接，检查当前网络是否需要完成网页登录认证。此步骤只用于验证基础网络，不要求故障网站必须能够直连。
- 恢复原连接。回到 Home，选择自己已有的服务器并开启连接，再访问同一网址。不要只重复延迟测试。
- 对照接入网络。保持服务器与配置不变，在 Wi-Fi 和蜂窝网络间切换后复测。只在某个 Wi-Fi 失败时，优先检查该网络的 DNS 可达性、认证状态或访问限制。
- 排除自动重连干扰。如果停止连接后又自动开启，检查 Settings → On Demand。记录原设置，测试期间按需暂停，结束后恢复。
浏览器可能复用原有连接，DNS 也可能存在缓存。更改设置后先停止并重新开启 Shadowrocket 连接，再重新打开故障页面。若现象仍不一致，可以关闭相关浏览器标签页后重试；不要把一次刷新成功直接当作问题已解决。
三、用 Global Routing 区分路由问题与解析问题
在 Home → Global Routing 核对当前选项。Config 表示按当前配置处理流量，并不表示所有请求都走代理；Proxy 主要用于让流量走所选代理进行对照。Direct 则用于直连对照。Scene 会依据场景设置决定行为，排查时还要核对当前生效场景，不能仅凭这个名称判断实际出口。
| 对照结果 | 优先检查 | 下一步 |
|---|---|---|
| Config 失败，Proxy 成功 | 规则命中、策略选择及不同路径的解析差异 | 检查当前 Config 中目标域名对应的规则与策略 |
| Config 与 Proxy 都失败 | 当前服务器、DNS 可达性或目标网站 | 保持配置不变，换用自己已有的另一服务器对照 |
| Direct 成功，Proxy 失败 | 代理出口、远端解析或目标站对出口的限制 | 核对服务器状态，不先改写整份规则 |
| 只在某个接入网络失败 | 该网络的传输限制与 DNS 路径 | 对照 Wi-Fi 与蜂窝网络，并检查 DNS 传输方式 |
结论：Proxy 成功时，先回查 Config
如果相同服务器、相同网络下只有 Config 失败，先查目标域名的匹配规则与实际策略，再调整 DNS；不要把长期停留在 Proxy 当作规则问题已经修复。
这些结果是缩小范围的线索，不是单次测试即可成立的证明。切换 Global Routing 可能同时改变连接路径与解析条件，因此需要结合下一节的 DNS 设置逐项验证。完成对照后，恢复日常使用的选项。
四、核对 DNS 地址、传输方式与配置来源
打开 Settings → DNS，记录当前可见的 DNS 设置。再到 Config 确认实际使用的配置文件是否包含 DNS 相关设置。不要只改某一处地址就认定生效：配置文件、全局设置及对应选项的组合会影响最终行为，应通过重新连接和请求结果验证。
- 检查输入是否属于对应字段。普通 DNS 地址、DNS over HTTPS 的完整地址和 DNS over TLS 的服务器名称不是可以随意互换的文本。按界面支持的格式填写，不要把订阅地址粘贴到 DNS 字段。
- 检查端点是否完整。DNS over HTTPS 通常需要完整的 HTTPS 端点，不能仅凭一个网站首页地址判断它提供 DNS 服务。核对自己正在使用的解析服务说明，不随意拼接路径。
- 检查初始解析依赖。如果 DNS 端点使用域名，连接它之前仍可能需要先解析该域名。基础解析不可用时，单纯换成另一个域名形式的端点未必能解决问题。
- 检查路径是否可达。当前网络可能允许 HTTPS，却限制其他端口；代理服务器本身使用域名时，还要考虑建立代理连接前的解析环节。不要让 DNS 请求与代理建立过程相互依赖。
- 单项替换并复测。先备份现有配置，再使用自己已确认可用的 DNS 设置作对照。保留当前服务器、Global Routing 与测试网址不变，重新连接后记录结果。
如果更改 DNS 后恢复，继续核对它是否在重新连接、切换网络后仍有效。若只有第一次成功，后续再次失败，需要回看缓存、端点可达性或自动切换条件。订阅刷新主要更新服务器信息，并不等于当前 Config 的 DNS 设置一定随之更新。
五、根据错误原文选择检查方向
错误可能来自浏览器、系统网络层或请求日志，不一定是 Shadowrocket 自身显示的提示。以下原文是常见网络错误表述，不保证每台设备都显示相同文字。记录错误对应的是目标网站域名、代理服务器域名，还是 DNS 端点域名，比只记录“打不开”更有用。
报错：The server with the specified hostname could not be found.
原因与解法：主机名解析未得到可用结果，也可能是域名拼写错误或域名本身失效。先核对完整域名，再对照 Settings → DNS 与当前 Config，并在另一接入网络复测同一网址。
报错：NXDOMAIN
原因与解法：解析器返回域名不存在；这与等待超时不同。核对域名拼写、是否误加子域名，再比较另一已确认可用的解析路径；不要用不断增加等待时间处理此类结果。
报错：SERVFAIL
原因与解法：解析器未能完成查询，可能涉及上游故障或域名验证问题。保持其他条件不变，对照另一可用解析路径；若只影响同一域名，记录结果并向自己的服务方反馈。
报错：The request timed out.
原因与解法：某个请求阶段超过等待时间，但文字本身不能确定是 DNS 故障。先判断是否已有解析地址，再检查连接路径；若已解析成功，应继续检查 TCP、TLS 或目标服务响应。
出现证书错误时，应检查设备日期与时间、目标域名以及所配置端点是否正确。它与“找不到域名”不是同一类问题。不要为消除提示而关闭 TLS 验证，也不要在尚未区分失败阶段时同时更换 DNS、服务器和协议。
六、仅个别域名失败：检查规则、AAAA 与页面资源
如果大多数网站正常，只有少数域名失败，应优先检查差异。A 记录提供 IPv4 地址，AAAA 记录提供 IPv6 地址；有 AAAA 记录不代表当前网络的 IPv6 路径一定可用。出现解析成功却连接迟滞时，可以在确认可恢复的前提下，对照 IPv6 相关设置，一次只改变一项，测试后恢复或记录最终选择。
规则按顺序匹配。DOMAIN-SUFFIX 匹配指定域名及其子域名；IP-CIDR 与 GEOIP 针对 IP 信息，某些情况下需要先解析才能判断；FINAL 是前面规则均未命中时的兜底。下面只用于说明顺序与语法，不是要求直接替换现有配置。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 先查域名规则。示例中的
example.com及其子域名会先命中 DIRECT；如果该域名必须经由用户自己的代理访问，就要核对是否存在不合适的早期匹配。 - 理解 no-resolve。它用于避免为了该 IP 规则主动触发域名解析，不是修复 DNS 的通用开关，也不保证请求永远不发生解析。
- 确认策略存在。示例中的
PROXY必须对应实际可用的策略；不要只复制名称，而忽略当前配置中是否有相应定义。 - 检查附属资源。页面文字正常而图片失败时，检查图片、脚本或登录请求使用的域名。只修改主域名的规则，可能覆盖不到独立的资源域名。
结论：有地址但连接失败，应向后检查
若已确认故障域名返回地址，而请求仍卡在连接或 TLS 阶段，优先核对实际出口、IPv4 / IPv6 路径及目标站响应，不再把所有失败归为 DNS 解析问题。
七、常见追问与最终核对
延迟一直正常，为什么换服务器后就能打开？
延迟测试只覆盖测试目标和部分连接环节。另一个服务器可能具有不同的出口、远端解析或目标站可达性。保持 DNS 与 Config 不变对照两者，记录故障网站是否随服务器变化，不要据此直接认定本地 DNS 有问题。
切到 Proxy 能打开，是否可以不管 Config？
可以把这个结果作为定位线索，但仍应回到 Config 检查规则顺序、目标域名命中的策略和 DNS 相关设置。修复后切回日常选项，确认同一网页及其资源都能加载。
只有 Wi-Fi 出错，蜂窝网络正常，要重装吗？
先不用重装。保留相同服务器和配置，检查 Wi-Fi 登录认证与 DNS 传输可达性；如果暂停连接后它又自动开启，再检查 Settings → On Demand，避免测试条件被自动重连改变。
更新订阅之后，DNS 会一起恢复吗？
不一定。服务器订阅与 Config 承担的内容不同。先在 Home 确认当前所选服务器是否变化，再到 Config 核对实际配置，最后检查 Settings → DNS；不要把更新服务器列表当成重置全部网络设置。
完成修改后，至少用原故障网址、一个正常对照网址和一次接入网络切换进行复测。若仍需向自己的服务方反馈，提供失败域名、时间、接入网络、Global Routing 选项、错误原文，以及修改前后的对照结果。订阅令牌、服务器密码和其他凭据应从截图或日志中移除。
- 已区分域名解析失败、连接超时与 TLS 错误，没有仅凭延迟结果下结论。
- 已确认当前 Home 所选服务器、Config 文件和 Global Routing 选项。
- 已核对 DNS 地址格式、端点可达性与可能存在的初始解析依赖。
- 已恢复临时修改的 On Demand、路由及 IPv6 相关选项，或记录需要保留的调整。
- 已验证重新连接后问题仍保持解决，而不是只成功加载过一次。