Shadowrocket DNS leak 怎么查？DNS 泄漏、IPv6 绕过与修复步骤

更新于 2026-10-26 · acaisbest.shop

简答：先固定网络和 Global Routing，断开旧连接后做一次 DNS leak test，再分别检查系统 DNS、配置 DNS、IPv6 和应用绕过；修复后用同一条件复测，才能确认结果是否改善。

定义：Shadowrocket DNS leak 指设备或应用的域名查询没有按预期经过当前配置的 DNS 或代理路径，而是被系统、网络、IPv6 或应用自身解析路径处理。

先做这一步：固定条件并记录结果

本文是第三方使用指南，不代表 Shadowrocket 官方。Shadowrocket 在 App Store 的产品说明中列出 DNS 请求记录、IPv6、DNS over HTTPS、DNS over TLS 和 DNS over QUIC 等能力，但具体选项会随客户端版本和系统环境变化；当前能否使用某个功能，应以 App Store 产品页和设备内实际显示为准。

先记录当前网络：Wi-Fi 名称或蜂窝网络、是否开启系统级其他网络工具、当前时间。
打开 Shadowrocket 的 Home，记下连接状态、当前服务器和 Global Routing；如果使用 Config，再记下当前启用的配置文件。
暂时关闭 On Demand 或其他会自动重连的功能，避免断开后马上恢复旧连接。
断开 Shadowrocket，关闭需要测试的网页或应用，再重新打开一个新的 DNS leak test 页面。不要直接使用浏览器已经打开的旧标签页。
在同一网络、同一设备上先测试关闭状态，再开启 Shadowrocket 后重新测试。每次只改变一个条件，并记录检测到的解析服务商、国家或地区、IPv4/IPv6 项目。

测试结果快速判读

检测结果	更可能说明什么	下一步
检测到本地网络或运营商 DNS	查询可能仍走系统 DNS、普通 UDP/TCP 53，或配置没有真正生效	检查 active Config、DNS 来源和 Global Routing
只出现 IPv6 DNS，IPv4 正常	IPv6 查询或双栈路径可能绕过了预期配置	在 Wi-Fi 与蜂窝网络分别复测，并单独观察 AAAA 请求
检测到 DoH/DoT 服务商	不一定是泄漏，可能是当前配置使用的加密 DNS	核对该服务商是否就是你配置的 DNS，不要只看名称就判定异常
没有检测到泄漏，但网页仍打不开	可能是解析失败、规则错误、连接超时或 TLS 问题	查看 Shadowrocket 的请求记录或日志，不要继续盲目更换 DNS

DNS 泄漏测试只能观察测试页面触发的查询，不能证明所有应用、后台服务或其他协议都绝对不会使用独立解析路径。因此，复测时还要结合应用访问记录、IPv4/IPv6 和实际网页请求。

Shadowrocket DNS leak 与其他连接问题怎么区分

DNS 泄漏关注的是“域名由谁解析”；DNS 解析失败关注的是“域名有没有得到有效地址”；代理出口或 IP 暴露关注的是“连接最终从哪个地址出去”。三者可能同时出现，但不是同一个问题。

如果 DNS leak test 显示了未配置的运营商解析服务，但网页仍能打开，优先按 DNS 路径排查。
如果检测不到 DNS 泄漏，但某个域名返回 NXDOMAIN、SERVFAIL 或长时间超时，优先检查解析结果、规则匹配和连接日志。
如果域名已经解析成功，但连接仍失败，DNS 可能不是根因，还要检查服务器地址、端口、协议参数、TLS 和网络丢包。
如果只有部分应用表现异常，检查该应用是否使用自己的解析机制、系统隐私功能或独立网络扩展；不要只根据浏览器测试结果下结论。

从协议角度看，DoH 是把 DNS 查询和响应放进 HTTPS 交换中，RFC 8484 说明它可以减少链路上的明文 DNS 观察，但它不会自动替所有应用选择同一条连接路径。Apple 的 Network Extension 文档也区分了系统级 DNS 配置、VPN 与 DNS proxy 能力，因此“启用了加密 DNS”不等于“所有查询都由同一个组件处理”。

可参考 IETF 的 DNS over HTTPS 标准说明和 Apple Network Extension 文档理解这些边界。

按路径排查：DNS、Global Routing、配置和 IPv6

确认当前配置真的在用。在 Home 查看 Global Routing；如果选择 Config，进入 Config 确认编辑的是当前启用文件，而不是仅导入但未启用的旧文件。规则配置只在实际被选中时才会影响请求。
先用同一模式做基线。不要同时切换 DNS、服务器和规则。先保持当前 Global Routing 不变，访问同一个域名，打开请求记录或 Log，观察是否出现 DNS 失败、连接超时、规则命中或直连策略。
核对 DNS 来源。检查 Settings 中的 DNS 相关选项，以及当前配置文件里的 DNS 参数。System DNS 适合作为基线，因为它使用当前网络提供的解析器；自定义 DNS 适合做对照；DoH/DoT 则要确认对应服务可达。修改后必须断开并重新连接，再发起新的域名请求。
检查规则顺序。在 Config 中查看 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、IP-CIDR6 和 FINAL 等规则。更具体的规则应放在更宽泛的规则前，FINAL 应作为未匹配请求的兜底。若 IP 规则带有 no-resolve，它通常表示该规则匹配时不要额外触发域名解析，不代表全局关闭 DNS。
单独测试 IPv6。先在 Wi-Fi 测试，再在蜂窝网络测试；对同一个域名分别观察 A 与 AAAA 结果。若只有 IPv6 条目显示异常，先记录网络是否提供 IPv6，再核对配置是否覆盖 IPv6，而不是立即更换全部 DNS。
查看日志位置。复现一次问题后，回到 Shadowrocket 的 Log 或请求记录页面，按刚才的时间查找目标域名。分享日志前删除订阅地址、密码、UUID、Cookie、token、服务器完整地址等敏感信息。

Shadowrocket 的 App Store 说明明确列出 DNS 请求记录、规则匹配、IPv6 和多种加密 DNS 传输支持；但这些能力不等于默认会以某一种方式工作，必须结合当前配置和实际日志判断。

修复建议：从最小改动开始

不同修复方式的适用场景

做法	适合解决	注意事项
恢复 System DNS	需要先建立可重复的基础对照	切换 Wi-Fi、蜂窝网络后，系统解析器可能不同
设置已确认可达的自定义 DNS	需要比较不同解析结果或避开当前网络解析异常	只填写与当前配置格式相符的地址，先保存原配置
使用 DoH 或 DoT	希望减少普通 DNS 在链路上的明文传输	加密 DNS 服务本身仍能看到查询，并且不保证所有应用都使用它
修正 Config 规则和 FINAL	DNS 没有泄漏，但请求被错误 DIRECT 或规则未命中	规则按顺序匹配，修改前备份并一次只改一条
核对 IPv6 或暂时做对照测试	只有 IPv6、AAAA 或某个网络环境出现异常	不要把临时对照结果当成长期通用结论

建议顺序是：保存原配置 → 只改一个 DNS 变量 → 断开并重新连接 → 用同一域名复测 → 查看 Log → 再决定是否进入规则或 IPv6 排查。DoH 只保护到 DoH 服务端之间的 DNS 传输，不能替代代理路由、应用权限和系统网络配置。

如果你需要稳定处理跨境办公中的 DNS、MTU、丢包和客户端连接问题，可在完成本文自检后了解边界云加速的办公网络方案；它与本文的技术排查内容是两个不同模块，具体服务范围以官网说明为准。

最后核对：修复是否真正生效

使用同一台设备、同一网络和同一个 DNS leak test 页面重新测试。
保持与首次测试相同的 Global Routing 和服务器，避免把多变量变化误判为修复成功。
同时对比 Wi-Fi 与蜂窝网络；如果只有一个网络异常，优先记录该网络的 DNS、IPv6 和登录认证状态。
访问一个此前失败的域名，并在 Log 中确认是否出现新的 DNS 查询、命中的规则和最终策略。
若结果仍不一致，恢复原配置后再做下一轮单变量测试。不要为了“没有泄漏”而关闭所有 IPv6、规则或验证功能。

最后核对：2026-10-26。Shadowrocket 的版本记录、系统支持和 DNS 能力可能继续变化，具体菜单与字段应以设备当前安装版本和 App Store 产品页为准。

常见问题

Shadowrocket DNS leak 测试发现运营商 DNS，就一定是客户端失效吗？

不一定。先确认当前 Global Routing、启用的 Config、DNS 来源和测试时是否存在旧连接；如果检测结果只在某个网络出现，还要比较 Wi-Fi 与蜂窝网络。

Shadowrocket 使用 DoH 后还会 DNS leak 吗？

DoH 可以加密客户端到 DoH 服务端之间的 DNS 传输，但不代表所有应用、IPv6 查询或系统服务都会自动使用同一路径。复测时要结合 DNS leak test、Log、A/AAAA 和实际访问结果。

检测不到 DNS 泄漏，但网页仍然打不开怎么办？

先把问题从 DNS 泄漏改为连接排查：查看目标域名是否解析成功、Config 是否命中错误规则、FINAL 是否走了 DIRECT，再检查连接超时、TLS 和服务器参数。

为什么 Wi-Fi 正常，蜂窝网络却出现 DNS leak？

System DNS 会随网络变化，蜂窝网络可能提供不同的解析器；IPv6、网络策略或 DoH 服务可达性也可能不同。保持服务器和 Global Routing 不变，分别记录两种网络的 DNS 与 IPv6 结果。

DNS leak test 显示多个服务商，是否一定代表泄漏？

不一定。可能是多个解析器、IPv4/IPv6 双栈、缓存或测试页面触发了不同查询。重点看是否包含未配置的网络解析器，并用断开、重连和同条件复测确认。