外观
DNS 泄露是什么：检测方法与客户端设置
DNS 泄露指代理已经连接，但把域名换成 IP 地址的解析请求仍然直接发往本地网络提供的 DNS 服务器，没有走代理通道，于是你访问过哪些域名在代理之外是可见的。
判断方法是开启代理后访问解析检测页面，看返回的解析服务器归属；避免方法是让客户端接管解析，使用远程解析或代理侧 DNS，并核对系统层和应用层有没有各自的旁路。
核心结论与适用条件
下面的结论只依据 DNS 与代理客户端的公认工作方式，不依赖任何品牌宣传，也不涉及具体速度或延迟数值。
- 如果你只是想确认“我的域名查询有没有暴露在代理之外”，那么最直接的办法是开启代理后做解析检测，并在不同浏览器、不同应用里各做一次，因为系统层和应用层的解析路径可能不同。
- 如果检测结果里出现了本地运营商或家庭路由器的解析服务器，那么这属于泄露的典型信号，需要回到客户端设置里检查 DNS 模式，而不是更换协议。协议本身不决定解析走哪里，这一点在 协议与安全专题总览 里已有概述。
- 如果你使用系统代理模式，那么只有尊重系统代理设置的程序才会被转发，其余程序的解析与连接都可能绕开代理；这时需要考虑虚拟网卡（TUN）模式，或逐个应用配置。
- 如果你的客户端开启了“假 IP”之类的解析映射机制，那么检测页面的结果可能与直觉不同，需要先理解它的原理再判读，详见后文。
- 如果你无法确认自己的客户端内核支持哪些 DNS 选项，那么先查阅客户端自己的文档，再对照 桌面与移动客户端专题 中的兼容说明，不要凭记忆照搬别人的配置。
这些结论的适用前提是：你使用的是常见的代理客户端，且已经正确导入订阅。若连接本身失败，应先排查连接问题，再谈 DNS 泄露。
先搞清楚：一次访问里 DNS 在哪个环节发生
要理解泄露，必须先把“访问一个网站”拆成几步。很多人以为代理开启之后，浏览器发出的一切都经过代理，但解析域名发生在建立连接之前，并且可能由不同的组件负责。
第一步，应用拿到一个域名，例如某个网站的主机名。应用并不能直接用域名发包，需要先得到对应的 IP 地址。第二步，解析动作由谁执行取决于应用：普通程序调用操作系统提供的解析接口，系统再向它配置的 DNS 服务器发起查询；有些浏览器内置了自己的解析器，甚至可以通过加密的 DNS 查询协议（例如 DoH）直接向某个公共解析服务发起请求，绕开系统设置。第三步，拿到 IP 后应用才发起 TCP 或 UDP 连接，这个连接才可能被代理客户端接管。
注意顺序：如果代理客户端只在第三步介入，那么第二步发生的查询并没有经过代理。这就是泄露的结构性来源。查询的内容是域名本身，哪怕后续的数据传输完全加密，域名也已经以明文或可被识别的形式交给了本地的解析服务器。本地网络的运营商可以看到你查询了哪些域名，也可能对解析结果做缓存、重定向或过滤。
再看代理客户端的做法：若应用把域名交给代理，由远端解析，这叫远程解析；若应用先自行解析出 IP 再交给代理，解析在本地完成，容易形成泄露。
最后还有一个常被忽视的环节：解析结果会被缓存。操作系统、浏览器、路由器都可能缓存最近的解析结果。开启代理之前已经缓存的记录，在代理开启后仍可能被直接使用，这会让“泄露”判断变得混乱。检测前宜先清理缓存或重启浏览器，让结果更接近真实状态。
把这条链路记住，后面的检测、设置与排错，都是在回答同一个问题：这一步的查询到底发给了谁。
DNS 泄露的几种常见形态
“DNS 泄露”不是单一问题，不同形态的成因与处理方式不同。把它们区分开，能避免把所有异常都归结为一个设置项。
第一种是系统代理模式下的旁路。系统代理只是在系统里登记了一个代理地址，是否使用由各个程序自行决定。尊重该设置的浏览器会把请求交给代理，但没有读取该设置的程序则直接联网，它们的解析与连接都不经过代理。
第二种是应用先本地解析。有些客户端或应用使用的是只能传递 IP 的代理类型，解析必须在代理之前完成。这种情况下，即使后续连接确实走了代理，域名查询仍是本地发出的。
第三种是浏览器自带的加密解析。浏览器可以配置为使用 DoH 向某个公共解析服务发起查询。这类查询不走系统 DNS 设置，是否经过代理取决于浏览器是否被代理客户端接管。它的结果既可能出现“泄露”，也可能因为加密而无法被本地网络读取，需要看具体配置，不能一概而论。
第四种是 IPv6 带来的旁路。如果代理只处理了 IPv4，而网络同时提供 IPv6，解析和连接可能通过 IPv6 路径走出去。检测时看到的解析服务器如果来自 IPv6 地址，需要留意这一点。
第五种是路由器层的拦截：部分路由器会把局域网内的 DNS 查询转给自己配置的上游，特征是无论客户端填什么解析服务器，检测结果都显示同一个归属。
下表把这些形态与排查方向放在一起，方便对号入座。
| 形态 | 典型表现 | 主要成因 | 优先排查位置 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 系统代理旁路 | 部分程序检测结果显示本地解析 | 程序不读取系统代理设置 | 客户端工作模式、程序自身代理设置 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 应用先本地解析 | 连接已走代理，解析仍在本地 | 代理类型只传 IP | 客户端的远程解析选项 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 浏览器加密解析 | 浏览器与系统结果不一致 | 浏览器单独配置了解析服务 | 浏览器隐私与安全设置 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| IPv6 旁路 | 出现 IPv6 解析服务器 | 代理未覆盖 IPv6 | 客户端的 IPv6 处理选项 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 路由器劫持 | 改任何解析服务器结果都不变 | 网关拦截 DNS 查询 | 路由器 DNS 与重定向设置 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
这张表不含任何测量数值。表里的“典型表现”是通用经验归纳，具体到你的环境，仍要以检测结果为准。
检测方法：一步一步做，并学会判读
检测的目标是回答一个问题：在代理开启状态下，向外发出的域名查询，最终是由谁的解析服务器接收的。检测站点的原理大体一致：页面让你的浏览器访问一批随机生成的唯一域名，这些域名的权威解析由检测站点控制，于是它能看到是哪些递归解析服务器来问了这些域名，并把结果展示给你。
检测前的准备
先关闭代理，做一次基线检测并记录结果，这样你知道自己的“本地解析服务器归属”大致是什么样。然后清理浏览器缓存或重启浏览器，再开启代理，保持常用的工作模式不变，做第二次检测。两次结果对比，比孤立看一次结果可靠得多。
如果你同时使用多个浏览器或有其他需要代理的应用，应各自做一次。浏览器内置解析器、扩展、独立配置的应用都可能得到不同结果。只在一个浏览器里通过检测，不代表所有应用都没有泄露。
如何判读结果
判读主要看三件事。第一，检测页展示的解析服务器归属，是否与基线检测中的本地运营商一致。如果一致，说明查询仍然走了本地路径。第二，展示的服务器数量与分布，是否出现多个不同归属并存。并存可能意味着多路径，也可能是递归解析服务器的正常负载分担。第三，结果在多次刷新之间是否稳定。
特别需要说明的几种“看起来像泄露但不是”的情况：
- 展示的是你代理服务端所在网络的解析服务器，这是预期结果，因为查询由远端发出，说明走了代理侧 DNS。
- 展示的是某个公共解析服务，而你的客户端恰好配置了它作为远端上游，同样是预期结果。
- 使用了假 IP 机制时，应用拿到的是本地分配的占位地址，真正的解析在远端完成，检测页展示的是远端解析结果。
因此，检测不能只做一次、也不要把单个站点的结论当成最终答案。可以交叉使用不同的检测站点，并结合客户端自己的连接日志，看域名是被代理处理还是直连。
技术参数对比：不同 DNS 处理方式的差异
下表比较几种常见的 DNS 处理方式，只描述设计层面的差异，不包含速度或延迟数值。凡是需要实测才能给出的内容，一律写“待核实”或“Not Tested”。
| 指标 | 本地直接解析 | 远程解析（代理侧） | 假 IP 映射 | 客户端内置加密解析 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|---|
| 解析发生位置 | 本机或本地网络 | 代理服务端一侧 | 客户端本地占位、服务端真实解析 | 客户端向指定上游发起 | — | 工作原理 | 通用技术资料 | 2026-10-18 |
| 域名是否暴露给本地网络 | 是 | 否（连接前已交给代理） | 否（占位地址不对外查询） | 取决于是否加密及是否走代理 | — | 工作原理 | 通用技术资料 | 2026-10-18 |
| 对应用的要求 | 无 | 应用需传递域名而非 IP | 应用需接受占位地址 | 无 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 常见副作用 | 泄露域名列表 | 个别程序因拿不到 IP 而异常 | 部分程序缓存占位地址后行为异常 | 上游不可达时解析失败 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 对规则分流的影响 | 可按 IP 规则匹配 | 域名规则更直接 | 域名规则最直接 | 取决于实现 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 解析延迟 | 待核实 | 待核实 | 待核实 | 待核实 | ms | 本站无实测 | Not Tested | 2026-10-18 |
| 设置复杂度 | 低 | 中 | 中到高 | 中 | 相对等级 | 通用经验 | 通用技术资料 | 2026-10-18 |
| 适合的工作模式 | 无代理时 | 系统代理或 TUN | 通常搭配 TUN | 浏览器等独立应用 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
“相对等级”只是通用经验排序，不是测量结果。不同客户端对同一名词的实现细节可能不同，应以所用客户端的文档为准。
客户端设置思路：让解析跟着代理走
下面不给出具体菜单路径、默认值或版本相关的细节，只讲设置的思路。你需要在自己客户端的设置中找到与 DNS、解析、虚拟网卡相关的选项，对照思路逐项核对。
思路一：确认工作模式覆盖了你关心的应用
系统代理模式适合只依赖浏览器、且浏览器遵守系统代理设置的场景。如果你还有其他需要代理的程序，而它们不遵守系统代理，要么在各自的设置里指定代理，要么改用 TUN 模式。TUN 模式由客户端创建一块虚拟网卡，把系统的网络流量接入客户端，让不遵守系统代理的程序也被覆盖。这种模式通常也更容易接管解析请求，但需要更高的系统权限，并可能与其他虚拟网卡软件冲突。
思路二：开启远程解析或代理侧 DNS
在规则分流的客户端里，通常有一个与 DNS 相关的设置区，用来决定哪些域名由哪个上游解析。核心原则是：需要走代理的域名，其解析也应通过代理通道发出，并由远端完成，或者使用一个只能通过代理访问到的上游。直连的域名可以使用国内常见的本地解析，以保证访问速度和就近调度，但这是有意的分流，而不是泄露。
思路三：理解假 IP 与真实 IP 两种解析策略
一些客户端提供两种内部解析策略：一种是尽量返回真实 IP，让应用拿到真实地址后再连接；另一种是对需要走代理的域名返回一个本地分配的占位地址，应用连接该占位地址时，客户端识别出对应的域名，把域名交给远端解析。后一种的优点是域名在本地一侧不需要再被查询；代价是需要处理占位地址与真实世界的差异，例如某些程序会校验或缓存地址。
思路四：处理浏览器自己的加密解析
如果浏览器启用了自己的 DoH，系统层面的 DNS 设置对它不生效。此时应在浏览器的隐私与安全设置中找到安全 DNS 相关的选项，选择与你的代理配置一致的方式：要么关闭浏览器独立的加密解析、让它走系统，由代理客户端统一处理；要么明确指定一个经由代理可达的服务。关键是让解析路径是你知道并可控的，而不是各个软件各行其是。
决策树：发现解析异常时按什么顺序排查
Decision Path
DNS 泄露排查顺序
text
开启代理后做解析检测，结果是否出现本地运营商？
├─ 否
│ └─ 换一个浏览器 / 应用再测一次，结果一致？
│ ├─ 是 → 暂未发现泄露，保留检测记录
│ └─ 否 → 按「应用级差异」逐个排查
├─ 是
│ └─ 当前是系统代理模式吗？
│ ├─ 是 → 该应用是否遵守系统代理？
│ │ ├─ 否 → 为应用单独配置代理，或改用 TUN 模式
│ │ └─ 是 → 检查客户端是否开启远程解析
│ └─ 否（TUN 模式）
│ └─ 客户端 DNS 设置是否只写了本地上游？
│ ├─ 是 → 为需走代理的域名指定代理侧解析
│ └─ 否 → 检查浏览器独立加密解析与 IPv6
└─ 改了解析设置后结果始终不变
└─ 怀疑路由器或网关拦截 → 换网络对比，或检查路由器 DNS 设置这棵树只给出排查顺序，不替代你的判断。任何一步修改设置后，都应清理缓存并重新检测。
常见误区
误区一，认为协议不同泄露风险就不同。DNS 查询在建立代理连接之前或之外发生，与 VLESS、Trojan 等协议的选择没有直接关系。协议决定的是连接建立后的数据怎样封装，见 加密发生在哪几层的说明。流控方案如 XTLS Vision 作用于数据传输阶段，同样不改变解析发生的位置，相关原理可看 XTLS Vision 工作方式。
误区三，把 DNS 泄露和 WebRTC 泄露混为一谈。前者是域名解析的去向，后者是浏览器实时通信接口对网络地址的收集，二者成因、检测页面与处理方式都不同。后者可参阅 浏览器 WebRTC 的泄露机制与设置。
误区四，认为把 DNS 服务器改成某个知名公共服务就等于安全。更换上游只是换了对象，如果查询仍然从本地网络发出，本地网络依旧能看到你在查询，只是看不到应答内容之外的部分。关键是查询要不要经过代理通道，而不只是上游是谁。
误区六，一旦发现泄露就频繁更换客户端。多数情况下问题出在模式选择与设置上，更换客户端不一定解决问题，反而可能引入新的来源风险。需要下载新客户端时，应遵守 客户端下载来源校验的原则。
知识图谱：DNS 解析与泄露
实体定义
**DNS（域名系统）**把易读的域名映射为 IP 地址。DNS 泄露指在代理使用期间，域名解析请求没有经过代理通道，而是直接发往本地网络提供的解析服务器，使域名查询对本地网络可见的现象。它是解析路径问题，不是加密强度问题。
相关概念
上游概念：递归解析与权威解析、解析缓存、操作系统解析接口。平行概念：远程解析、假 IP 映射、规则分流、虚拟网卡（TUN）。下游概念：隐私暴露面、浏览器加密解析（DoH）、IPv6 旁路。同层的其他泄露类型：WebRTC 地址泄露。
技术参数
可由用户自行确认的参数包括：检测页展示的解析服务器归属、客户端的工作模式、DNS 设置中的上游与分流策略、浏览器是否启用独立加密解析、系统是否启用 IPv6、客户端日志里域名是否被代理处理。品牌资料无法提供这些参数，需要用户在自己的环境中测得；本站不提供解析延迟、成功率等数值，相关内容为 Not Tested。
适用场景
敏感操作较多的用户，如登录账号、处理工作文件，需要重视解析路径；仅偶尔浏览公开网页的用户，也应了解基本原理；使用多设备的用户，需要在每台设备上分别确认；使用路由器统一接入代理的用户，需要在网关层面统一处理 DNS。
对比依据
本文比较各种 DNS 处理方式，只依据解析发生位置、对应用的要求与已知副作用，这些是协议与客户端设计层面可以讨论的内容。不依据未经控制变量的速度测试，也不依据品牌宣传。
常见问题指向
“怎么检测”指向本文检测方法一节；“怎么设置”指向客户端设置思路一节；“为什么检测结果不一致”指向常见形态与误区两节；“和 WebRTC 泄露有什么区别”指向误区三与 WebRTC 文章。
方案关联：协议标注与客户端方式
DNS 泄露与协议无关，但与客户端方式有关：客户端内核提供的 DNS 选项决定了你能做哪些设置。品牌资料只提供协议标注和客户端方式两个字段，且本站不核实客户端内部的 DNS 选项。以光速云为例，资料标注协议为 VLESS，客户端方式为自研客户端加第三方订阅导入；这只说明“有自研客户端可用，也可导入第三方客户端”，不说明其解析设置如何。
Infrastructure Service Snapshot
光速云 /guangsuyun
本站排名第二本站推荐排名，非测速或可用性测试结果
- 入门价格
- 7.5 元/月
- 价格类型
- 年付折算 年付折算价
- 入门流量
- 59GB
- 线路
- IEPL专线、企业级内网专线
- 协议
- VLESS
- 运营年份
- 2020
- 客户端
- 自研客户端+第三方订阅导入
- 支付方式
- 支付宝 / 微信 / USDT
如果你使用品牌自研客户端，建议查阅该品牌官方教程中关于 DNS 或虚拟网卡的说明，再按本文方法检测；如果使用第三方客户端导入订阅，则以第三方客户端的设置为准。品牌库中可按客户端方式筛选，路径见 在品牌库按协议与客户端方式筛选。不同品牌横向比较时，协议维度在对照中的位置可参考 横向对比里的维度说明。
微风网络、飞猫云等协议待核实的品牌，在资料中没有写明协议，这不影响 DNS 检测方法本身，但提示你在下单前先确认协议与客户端支持。价格方面，光速云的入门价格为年付折算 7.5 元/月，月付价待核实；这类年付折算价需要一次性支付整年费用，选型时的周期锁定风险可在 选型清单里的价格口径与周期 一节对照。
优点、限制与风险提示
优点
- 检测门槛低，只需浏览器与检测页面即可初步判断。
- 排查思路通用，不依赖具体品牌或协议。
限制
- 单个检测站点只能反映当次、当前浏览器的结果，不能代表所有应用与所有时刻。
- 不同客户端对相同概念的命名与实现不同，本文只能给出通用思路，不能替代客户端文档。
- 假 IP、TUN、加密解析等机制各有兼容性取舍，部分应用可能出现异常，需要例外处理。
- 本站没有任何品牌的解析行为实测数据，相关状态均为 Not Tested。
风险提示
- 修改系统网络、虚拟网卡或路由器设置可能影响其他设备和软件的正常联网，操作前应记录原设置，便于恢复。
- 为了“通过检测”而随意关闭系统组件、安装来历不明的工具，可能引入更大的安全风险。
- 检测页面本身也是第三方站点，访问它会让该站点看到你的出口地址，使用时应了解这一点。
- 不要因为检测通过就放松其他安全习惯，例如证书校验和下载来源，参见 为什么不应跳过证书校验。
- 本文属于技术原理与使用风险说明，不构成对任何品牌或服务的推荐，也不涉及任何规避监管的用途。
常见问题
什么是 DNS 泄露？
DNS 泄露指代理已经连接，但域名解析请求仍然直接发给本地网络的 DNS 服务器，没有经过代理通道，于是本地网络可以看到你查询过哪些域名。它说的是解析路径，而不是数据内容是否被读取，与所用的代理协议没有直接关系。
怎么检测有没有 DNS 泄露？
先在关闭代理时做一次基线检测，再清理缓存并开启代理做第二次检测，对比返回的解析服务器归属。如果仍是本地运营商，说明查询走了本地路径。建议在不同浏览器和应用里各测一次，并结合客户端连接日志交叉确认，不要只依赖单个检测站点。
DNS 泄露和 WebRTC 泄露是一回事吗？
不是。DNS 泄露是域名解析请求的去向问题，WebRTC 泄露是浏览器实时通信接口在收集网络地址候选时暴露本地或真实出口地址的问题。两者成因不同、检测页面不同、处理位置也不同，前者主要在客户端和系统设置，后者主要在浏览器设置。
检测页显示的是代理服务端所在网络的解析服务器，算泄露吗？
不算。这通常说明域名查询经由代理通道由远端发出，是预期结果。需要警惕的是检测页出现你本地运营商或家庭路由器的解析服务器，尤其是在代理开启之后仍然如此。判断时要以基线检测结果作对照，而不是只看单次展示的名称。
系统代理模式和 TUN 模式在 DNS 上有什么区别？
系统代理模式只对遵守系统代理设置的程序生效，其他程序的解析和连接可能直接走本地网络。TUN 模式通过虚拟网卡接管系统流量，覆盖面更广，也更容易让客户端统一处理解析。代价是需要更高权限，并可能与其他虚拟网卡软件冲突，需要按自己的环境取舍。
什么是假 IP 映射，会不会让检测结果看起来不对？
假 IP 映射是客户端对需要走代理的域名返回本地分配的占位地址，应用连接该地址时，客户端再把对应域名交给远端解析。检测页展示的是远端解析结果，因此与不使用该机制时的预期可能不同。个别应用若缓存或校验占位地址，可能出现异常，可将其加入例外。
把 DNS 服务器改成公共解析服务就够了吗？
不够。更换上游只是换了接收查询的对象，如果查询仍从本地网络发出，本地网络依旧能看到你在查询。关键在于需要走代理的域名，其解析是否经过代理通道并由远端完成，或者使用只能通过代理访问的上游。只改服务器地址而不改解析路径，泄露并不会消失。
浏览器的安全 DNS 功能会影响泄露检测吗？
会。浏览器启用独立的加密解析后，系统层面的 DNS 设置对它不生效，浏览器与其他应用的检测结果可能不一致。处理方式是在浏览器的隐私与安全设置中找到相关选项，选择与代理配置一致的方式，让解析路径统一、可控，然后重新检测。
路由器会不会造成检测结果一直显示本地解析？
可能。部分路由器会拦截局域网内的 DNS 查询并转给自己配置的上游，这时无论客户端填写什么解析服务器，检测结果可能始终显示同一个归属。可以把设备换到另一个网络对比检测，或检查路由器的 DNS 与重定向相关设置，修改前先了解其作用。
品牌资料能说明某个机场有没有 DNS 泄露吗？
不能。品牌资料只提供协议标注和客户端方式，没有解析行为信息，本站也没有做过相关实测，状态为 Not Tested。DNS 泄露主要由你的客户端模式、系统与浏览器设置共同决定，需要在自己的环境里按本文方法检测，而不是看品牌介绍。
下一步
建议按下面的顺序行动：先在自己的主要设备上做一次基线检测和代理开启后的检测；再检查客户端的工作模式和 DNS 设置；之后回头核对浏览器层面的 WebRTC 与安全 DNS。需要理解加密在哪些环节发生，可阅读 代理流量的加密层次说明；需要核对不同客户端的 DNS 选项，可进入 客户端专题查看桌面与移动端差异；需要在选型阶段把客户端方式纳入考虑，可回到 选型指南的客户端与设备数检查项。
如果你在 VLESS 节点上做排查，也可以继续了解 VLESS 客户端支持范围，确认所用内核是否具备你需要的 DNS 选项；若检测通过后仍想系统性检查账户与订阅安全，可看 账号安全的基本做法。
Cluster · security
安全与隐私
- TLS 指纹与 uTLS：客户端指纹为何影响连接什么是 TLS 指纹，为什么客户端需要模拟浏览器指纹？
- 代理流量的加密层次：传输加密与端到端加密的区别使用代理后流量在哪些环节是加密的？
- DNS 泄露是什么：检测方法与客户端设置什么是 DNS 泄露，如何检测和避免？
- WebRTC 泄露与浏览器设置WebRTC 泄露是怎么发生的，浏览器怎么设置？
- 跳过证书校验（allowInsecure）的风险为什么不建议开启跳过证书校验？
- 客户端从哪里下载：来源校验与签名检查如何确认下载的代理客户端是安全的？
- 流量特征与识别：协议伪装的原理与边界代理流量为什么可能被识别，伪装能做到什么程度？
下方卡片指向品牌库入口，方便按客户端方式与协议标注筛选；这不构成推荐，任何品牌都需要你自行核对协议与客户端支持。
信息来源与更新日期
- 信息来源：通用技术资料（DNS 解析流程、远程解析、虚拟网卡、DoH 等公认概念）；品牌公开资料/用户提供清单（协议标注、客户端方式、价格类型）。
- 数据状态：全部品牌为 Vendor Data，测速 Not Tested，解析行为与客户端 DNS 选项均待核实。
- 数据核实日期：2026-10-18
- 最近更新时间：2026-10-18
- 本文不包含具体速度、延迟或版本号，不承诺任何平台的收录或排名；检测站点与客户端界面可能变化，以实际页面为准。