外观
WebRTC 泄露与浏览器设置
WebRTC 是浏览器内置的实时音视频与数据通信接口，为了让两端直接建立连接，它会收集本机可用的网络地址候选，这一步可能绕开代理，把本地地址或真实出口地址暴露给网页脚本。
它是浏览器层面的行为，与代理协议无关；处理思路是限制地址候选的收集范围，或在不需要实时通信时禁用，同时清楚这样做对视频会议等功能的影响。
核心结论与适用条件
下面的结论只依据 WebRTC 的公开设计和浏览器的通用行为，不涉及具体速度数值，也不点名任何浏览器版本。
- 如果你用代理主要是为了访问网页，且在浏览器里登录各类账号，那么应当检查一次 WebRTC 暴露的地址，尤其是在更换浏览器、更新浏览器或新增扩展之后。
- 如果检测页面显示的出口地址与代理出口一致，那么可以认为当前浏览器没有暴露真实出口地址；若显示的是本地运营商分配的公网地址，则说明存在旁路。
- 如果你经常使用网页版视频会议、语音通话或点对点传输，那么直接禁用 WebRTC 会让这些功能失效，更合理的做法是限制候选范围而不是一刀切。
- 如果你只是偶尔需要隐私更严格的浏览环境，那么可以为这类场景单独使用一个配置了限制的浏览器或配置档案，日常使用另一个。
- 如果你已经使用虚拟网卡（TUN）模式让系统流量全部进入代理，那么WebRTC 暴露真实出口地址的风险通常会降低，但本地网络地址候选仍可能被网页脚本读取，需要结合检测结果判断。
这些结论的前提是：你关心的是浏览器场景下的地址暴露。WebRTC 泄露不影响代理连接本身的加密，也不等于流量内容被读取。同属“泄露”类别的域名解析问题请看 DNS 泄露的成因与检测，二者要分开检查。
WebRTC 是什么，为什么需要知道你的地址
要理解泄露，先要明白这个接口在做什么。传统的网页通信是浏览器向服务器发请求，服务器有固定的公网地址，一切经由服务器中转。实时通话则不同：两个用户的浏览器如果都经由服务器转发音视频，会带来较高的延迟和服务器压力，所以 WebRTC 的设计目标是让两端尽可能直接通信，也就是点对点。
直接通信的难点在于：两台电脑通常都处在家庭路由器之后，只有私有地址，对方无法直接找到你。于是 WebRTC 采用一套叫 ICE 的流程来“找路”。流程的核心是每一端收集若干“候选地址”，通过某个信令渠道互相交换，再逐个尝试连通，选出可用的一条。
候选地址大致分为三类：
- 本地候选：本机网卡上的地址，例如局域网内的私有地址。同一局域网内的两台设备，直接用它们就能通信。
- 反射候选：浏览器向一个公共的地址发现服务（常称 STUN 服务）发送请求，对方回告“你在互联网上看起来的地址与端口”。这就是从公网视角看到的出口地址。
- 中继候选：当点对点无法打通时，通过中继服务器转发。这类候选不暴露你自己的地址，但需要服务器资源。
问题就出在前两类。网页里的脚本在获得权限后，可以读取这些候选地址。也就是说，一个普通网页不需要你点击任何按钮，就可能通过脚本拿到你的本地地址甚至出口地址。浏览器厂商后来加入了一些缓解机制，例如在无需摄像头麦克风权限时限制暴露本地地址，或用随机主机名替换本地地址，但各浏览器的做法与时间点不同，本文不点名具体版本，请以你使用的浏览器自身说明为准。
泄露是怎么发生的：为什么代理拦不住它
代理客户端能接管的，是遵守它规则的流量，比如通过系统代理设置或虚拟网卡进入客户端的连接。而 WebRTC 在两个关键环节上可能不遵守这个规则。
第一，反射候选的获取依赖向公共地址发现服务发送 UDP 请求。很多代理工作在 TCP 层或只处理部分流量类型，UDP 的转发要么需要代理协议明确支持，要么需要虚拟网卡全局接管。如果这条 UDP 请求没有被代理接管，而是直接从本地网络发出，地址发现服务看到的就是你本地网络的真实出口地址，并回告给浏览器，脚本就读取到了。
第二，本地候选根本不经过网络，是浏览器直接读取本机网卡信息。无论代理怎样配置，网卡上有哪些地址是客观存在的，代理没有理由、也没有办法隐藏它们。只有浏览器自己的策略能决定是否把这些信息给脚本。
第三，某些浏览器的设置允许 WebRTC 绕过代理。浏览器设置中的代理，可能只对常规网页请求生效，而实时通信相关的流量走另一条路径。扩展或企业策略也可能改变这一行为。
所以，“我已经开了代理”并不能推出“WebRTC 没有泄露”。两者作用于不同层面：代理管的是连接被送到哪里去，WebRTC 的候选收集管的是脚本能读到哪些地址。要把二者统一，只能在浏览器侧设限，或让系统流量全局进入代理。
另外要区分“暴露”的含义。暴露出口地址不等于暴露你的身份，但出口地址可以反映你所在的网络和大致位置；暴露本地私有地址对远端的直接危害较小，但可作为指纹的一部分。把它们当作“降低隐私暴露面”的问题处理，比当作“有或无”的问题更准确。
技术参数对比：几种候选地址与限制方式
下表按候选类型和常见处理方式对比。表里没有速度或延迟数值，涉及实测的一律写“待核实”。
| 指标 | 本地候选 | 反射候选 | 中继候选 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 地址来源 | 本机网卡信息 | 公共地址发现服务回告 | 中继服务器分配 | — | 工作原理 | 通用技术资料 | 2026-10-18 |
| 是否需要发出网络请求 | 否 | 是（通常为 UDP） | 是 | — | 工作原理 | 通用技术资料 | 2026-10-18 |
| 能否被代理客户端直接隐藏 | 否 | 取决于 UDP 是否被接管 | 取决于链路 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 暴露的信息 | 私有地址、网卡信息 | 公网出口地址 | 中继地址 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 浏览器常见缓解 | 主机名混淆、权限门槛 | 限制到默认出口路由 | 仅使用中继 | — | 通用情况，不点名版本 | 通用技术资料 | 2026-10-18 |
| 对通话功能的影响 | 局域网内直连受影响 | 点对点成功率可能下降 | 依赖中继服务质量 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 处理位置 | 浏览器设置或扩展 | 浏览器设置或系统全局接管 | 浏览器设置 | — | 通用情况 | 通用技术资料 | 2026-10-18 |
| 通话延迟变化 | 待核实 | 待核实 | 待核实 | ms | 本站无实测 | Not Tested | 2026-10-18 |
“对通话功能的影响”是基于设计原理的定性判断，不是测量结果；具体通话质量受网络、服务端和浏览器实现影响。
检测方法：怎么看检测页，怎么避免误读
WebRTC 检测页的原理是：页面脚本创建一个实时通信对象，触发候选收集，然后把拿到的所有候选地址展示出来。你看到的每一行，都是网页脚本能够读到的信息。
基线与对比
和 DNS 检测相似，建议先做一次不使用代理的基线检测，记录页面展示的地址；再开启代理做第二次检测。对比两次结果，才能知道代理有没有改变暴露的内容。同时注意，页面展示的出口地址是否与代理出口一致，可以通过一个常规的“查询出口地址”页面来交叉核对。
如何解读几类结果
- 只显示代理出口地址，没有本地运营商地址：说明反射候选经由代理或被限制，未暴露真实出口。
- 显示本地运营商分配的公网地址：说明反射候选没有经过代理，这是典型的旁路信号。
- 显示一串形似随机字符串的主机名而不是私有地址：这是浏览器用随机主机名替代本地地址的混淆机制，表示本地地址没有被直接暴露。
- 显示私有网段地址：说明本地候选可被脚本读取，通常危害有限，但属于可被利用的信息。
- 同时显示 IPv4 与 IPv6 地址：需要分别判断，IPv6 地址若是本地网络分配的，同样意味着旁路。
容易误读的情形
检测页展示的内容取决于浏览器当前的权限和策略。刚刚授予过摄像头权限的站点，可能比未授权的站点获得更多信息，同一浏览器在不同站点上的结果也可能不同。无痕窗口、不同的配置档案、被扩展修改过的环境，结果都可能与日常窗口不同。因此，应当在你实际使用的浏览器窗口里检测，而不是在另一个干净窗口里检测后就下结论。
还要提醒：检测页面本身是第三方网页，访问它意味着它能看到你的出口地址。选择检测站点时应了解其性质，不输入任何账号、密码等个人信息。
浏览器设置思路：限制范围，而不是盲目关闭
本文不写具体菜单路径、选项名称或默认值，因为它们会随浏览器版本变化。请在所用浏览器的设置、隐私与安全相关页面，或其高级配置页面里，查找与实时通信、网络地址暴露相关的选项，并对照下面的思路。
思路一：优先使用浏览器自身提供的限制选项
一些浏览器在设置中提供与实时通信地址相关的选项，例如让 WebRTC 只通过默认出口路径通信、不暴露其他网卡地址。这类选项的目标是缩小候选收集的范围，对多数通话功能的影响较小。如果你的浏览器提供这类选项，应当先考虑它。
思路二：使用来源可信的扩展，并理解其局限
对没有内置选项的浏览器，可以借助扩展来限制 WebRTC 的行为。使用扩展要格外谨慎：扩展可以读取和修改你访问的网页内容，来源不可信的扩展本身就是更大的风险。安装前应核对发布者与权限请求，仅从浏览器官方扩展商店获取，必要时遵循 客户端下载来源校验的原则 同样的核对习惯。另外，扩展的效果依赖浏览器提供的接口，浏览器更新后可能失效，需要定期复查。
思路三：在高级配置中调整相关策略
部分浏览器允许通过高级配置页面调整与实时通信相关的底层策略。这类调整可以更精细，但容易误操作，也可能在浏览器更新时被重置。修改前记录原值，修改后重新检测。不熟悉的人不必为此冒险，使用前两种方式即可。
思路四：为不同场景使用不同的浏览器配置档案
日常浏览、敏感账号操作、视频会议三类需求对 WebRTC 的要求并不相同。一个务实的办法是为它们使用不同的浏览器或配置档案：敏感账号操作的配置档案启用最严格的限制；需要网页会议的配置档案保留实时通信功能，但避免在其中登录敏感账号。这样既不牺牲功能，也不需要频繁切换设置。
思路五：让系统流量全局进入代理
如果浏览器侧的设置无法满足需求，可以在客户端使用虚拟网卡（TUN）模式，让包括 UDP 在内的系统流量进入代理，使地址发现请求从代理出口发出。这是系统层面的方案，对 WebRTC 的影响取决于所用代理协议是否支持 UDP 转发，不是所有协议和线路都支持。因此做完设置后仍要用检测页面验证，不能凭设置项推断结果。不同客户端对此的支持差异，可看 VLESS 客户端支持范围 中关于内核能力的说明。
关于彻底禁用
禁用 WebRTC 是最彻底的方式，但代价最大：依赖它的网页会议、语音通话、部分在线直播的互动功能、点对点文件传输都可能不能使用。如果你的使用场景里几乎没有这些功能，禁用是合理选择；否则建议采用限制范围的方式。
决策树：按场景选择处理方式
Decision Path
WebRTC 暴露面处理路径
text
你在浏览器里需要用到网页会议或语音通话吗？
├─ 几乎不需要
│ └─ 浏览器是否提供禁用 / 限制选项？
│ ├─ 是 → 启用限制后重新检测
│ └─ 否 → 使用可信来源的扩展，并复查其效果
├─ 偶尔需要
│ └─ 能否使用独立的浏览器配置档案？
│ ├─ 是 → 敏感账号用严格档案，会议用单独档案
│ └─ 否 → 采用「限制到默认出口路径」类选项，不整体禁用
└─ 经常需要
└─ 优先考虑系统层方案
└─ 客户端支持 TUN 且协议支持 UDP 转发？
├─ 是 → 开启后检测，确认出口一致
└─ 否 → 把会议与敏感账号分开在不同档案
检测后仍显示本地运营商地址 → 回到上一步换一种方式，或检查扩展是否失效这棵决策树只覆盖常见的使用场景。任何一次设置变更之后，都需要重新检测，因为浏览器更新和扩展更新可能改变结果。
场景对照：不同使用习惯怎样取舍
| 场景 | 主要关注点 | 可行的处理方式 | 需要承担的代价 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 只浏览网页 | 减少地址暴露 | 浏览器内置限制或禁用 | 几乎没有 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 登录敏感账号 | 降低可关联信息 | 严格配置档案 + 出口一致性检测 | 需要维护多个档案 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 网页视频会议 | 功能可用 | 限制候选范围，不整体禁用 | 隐私收益有限 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 点对点传输类网页 | 功能可用 | 保留 WebRTC，隔离使用环境 | 暴露面较大 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 多设备共用代理 | 每台设备行为一致 | 每台设备分别检测 | 重复操作 | — | 通用经验 | 通用技术资料 | 2026-10-18 |
| 通话质量对比 | 延迟与稳定性 | 无法给出数值 | — | ms | 本站无实测 | Not Tested | 2026-10-18 |
表中的内容是策略层面的归纳，不代表任何测量结果。
常见误区
误区一，认为开启代理就等于隐藏了所有地址。代理只改变连接被送到哪里，不改变脚本能否读到网卡信息，也不保证 UDP 请求被代理接管。
误区二，认为协议选得好就不会泄露。VLESS、Trojan 等协议决定的是代理连接内部怎样封装与加密，与浏览器的候选收集无关。你可以回到 协议与安全专题总览 了解协议和安全设置的分工。
误区三，认为安装一个扩展就一劳永逸。扩展的行为依赖浏览器接口，更新后可能失效；扩展本身也有来源风险。
误区四，认为检测页显示私有地址就是严重泄露。私有地址只在局域网内有意义，其暴露的危害通常小于公网出口地址的暴露，但它仍是可被利用的信息，且多数缓解机制就是针对它的。
误区五，把“绕过证书校验”当作排错手段。当网页通信或代理连接因证书问题失败时，随意关闭校验会让更大的风险敞开，这与 WebRTC 设置无关但同样重要，参见 跳过证书校验的风险说明。
知识图谱：WebRTC 与地址暴露
实体定义
WebRTC 是浏览器内置的实时通信接口，支持音视频与数据通道，建立连接时通过 ICE 流程收集并交换网络地址候选。WebRTC 泄露指网页脚本借此读到本地网络地址或未经过代理的公网出口地址，使代理带来的地址隐藏效果被削弱的现象。
相关概念
上游概念：ICE、STUN、中继（TURN）、UDP 与 NAT。平行概念：DNS 泄露、浏览器指纹、IPv6 旁路、虚拟网卡（TUN）。下游概念：配置档案隔离、扩展权限、系统全局代理。
技术参数
可由用户自行确认的参数包括：检测页展示的候选地址类型与归属、浏览器是否提供限制选项、客户端工作模式、代理协议是否支持 UDP 转发、是否启用 IPv6。品牌资料中没有这些参数，本站也不提供通话延迟、成功率等数值，相关状态为 Not Tested。
适用场景
多数用户的主要场景是日常浏览与账号登录，限制地址候选范围即可；有会议和通话需求的用户需要保留功能并分离使用环境；对隐私要求较高的用户可以结合配置档案与系统层方案。
对比依据
本文比较各类处理方式时，依据的是候选类型的来源、是否需要网络请求以及功能代价，这些是协议设计和浏览器行为层面可以讨论的内容；不依据未经控制变量的体验描述，也不依据品牌宣传。
常见问题指向
“WebRTC 是怎么泄露的”指向候选地址与泄露机制两节；“怎么检测”指向检测方法一节；“浏览器怎么设置”指向设置思路一节；“会不会影响视频会议”指向场景对照与禁用一节。
方案关联：客户端方案与测试方案
WebRTC 泄露的处理主要在浏览器和客户端的工作模式上，与具体品牌关系不大。品牌资料只提供协议标注和客户端方式，不含浏览器行为信息，下面按“方案”而不是“品牌”整理选择依据。
| 方案 | 适用情况 | 前提 | 需要自行核对的内容 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 浏览器内置限制 | 浏览器提供相关选项 | 了解选项含义 | 设置后重新检测 | — | 通用方案 | 通用技术资料 | 2026-10-18 |
| 可信扩展 | 浏览器无内置选项 | 扩展来源可信 | 扩展权限、更新后是否仍有效 | — | 通用方案 | 通用技术资料 | 2026-10-18 |
| 独立配置档案 | 会议与敏感账号并存 | 能管理多个档案 | 各档案分别检测 | — | 通用方案 | 通用技术资料 | 2026-10-18 |
| 虚拟网卡全局接管 | 需系统层统一处理 | 客户端支持 TUN，协议支持 UDP | 实际出口是否一致 | — | 通用方案 | 通用技术资料 | 2026-10-18 |
| 品牌自研客户端 | 品牌提供自研客户端 | 客户端来源可信 | 工作模式与 UDP 支持，待核实 | — | brands.json clientSupport | 品牌公开资料/用户提供清单 | 2026-10-18 |
按 brands.json 的字段，17 个品牌中有 12 个标注 VLESS，5 个协议待核实；客户端方式包括自研客户端加第三方订阅导入、仅第三方订阅导入等几类。这些字段都是 Vendor Data，本站没有核实各品牌客户端的 UDP 转发能力或 TUN 支持，相关状态为待核实。如果你想按客户端方式筛选品牌，可以进入 品牌库按客户端方式与协议标注筛选，横向对比时协议与客户端维度的位置可参考 横向对比的维度说明。
对价格口径有疑问时，请注意光速云、微风网络、飞猫云、星岛梦的价格都是年付折算价，需要一次性支付整年费用，月付价待核实；选型阶段的周期与客户端检查，可对照 选型指南的检查项。
优点、限制与风险提示
优点
- 多数设置只在浏览器侧完成，不需要改变代理线路或更换服务商。
- 检测页面简单直观，设置前后可以对比。
- 通过配置档案分离场景，可以同时兼顾功能和隐私暴露面。
限制
- 浏览器的实现与默认行为随版本变化，本文不能替代浏览器自身的说明。
- 限制 WebRTC 与保持通话功能之间存在取舍，没有对所有场景都最优的单一设置。
- 地址暴露只是浏览器指纹和关联风险的一部分，处理它不等于获得匿名性。
- 本站没有任何品牌客户端的 WebRTC 相关行为实测，状态为 Not Tested。
风险提示
- 扩展拥有读取网页内容的权限，来源不明的扩展本身就是安全风险，只从官方商店获取并检查权限。
- 修改浏览器高级配置前要记录原值，避免影响正常使用。
- 开启虚拟网卡模式会改变整台设备的网络路径，可能与其他网络软件冲突，需要在了解影响后操作。
- 浏览器登录的账号、保存的凭据本身也需要保护，可参阅 账号安全的基本做法 与 隐私边界的划分。
- 本文属于技术原理与使用风险说明，不构成对任何品牌或服务的推荐，也不涉及任何规避监管的用途。
常见问题
WebRTC 泄露是怎么发生的？
WebRTC 为了让两端直接通信，会收集本机网卡上的本地地址，并向地址发现服务查询公网出口地址，这些候选地址可以被网页脚本读取。如果查询请求没有经过代理，脚本就可能读到本地运营商分配的真实出口地址，这就是通常所说的 WebRTC 泄露。
开启代理后为什么 WebRTC 仍然可能暴露真实出口地址？
因为代理只管理被送入它的连接，而 WebRTC 的地址发现通常使用 UDP，若代理未接管这类流量，请求会直接从本地网络发出。本地候选则是浏览器直接读取网卡信息，不经过网络，代理无法隐藏。要统一处理，需要在浏览器侧设限或让系统流量全局进入代理。
怎么检测 WebRTC 有没有泄露？
先在关闭代理时做一次基线检测，再开启代理检测一次，对比页面展示的候选地址。若只显示代理出口地址，说明没有暴露真实出口；若出现本地运营商的公网地址，说明存在旁路。要在日常使用的浏览器窗口里检测，并结合常规的出口地址查询页面交叉核对。
检测页显示一串随机字符串形式的主机名是什么意思？
这通常是浏览器用随机主机名替代本地私有地址的混淆机制，表示本地地址没有被直接暴露给脚本。它是一种缓解措施，不代表所有地址都已隐藏，仍需要继续查看页面中是否还有公网出口地址或 IPv6 地址。具体行为因浏览器而异，应以实际检测结果为准。
直接禁用 WebRTC 有什么代价？
依赖实时通信的功能可能失效，包括网页版视频会议、语音通话、部分直播互动以及点对点文件传输。如果你的日常使用几乎不涉及这些功能，禁用是合理的；否则更适合采用限制候选范围的方式，或为会议单独使用一个浏览器配置档案。
浏览器扩展可以解决 WebRTC 泄露吗？
可以起到限制作用，但要看浏览器提供的接口和扩展自身的可靠性。扩展可能在浏览器更新后失效，并且拥有读取网页内容的权限，来源不明的扩展本身就是风险。使用时应从官方商店获取，检查权限，并在每次更新后重新检测，不能把安装视为一劳永逸。
使用虚拟网卡模式能避免 WebRTC 泄露吗？
可能降低风险，因为系统流量包括 UDP 都进入客户端，地址发现请求会从代理出口发出。但这取决于所用代理协议和线路是否支持 UDP 转发，本地候选也仍可能被脚本读取。设置完成后必须用检测页面验证，不能仅凭模式开关推断结果。
WebRTC 泄露和 DNS 泄露可以一起处理吗？
可以在同一次检查中依次完成，但二者要分别处理。DNS 泄露关注域名解析请求去了哪里，主要在客户端和系统设置中处理；WebRTC 泄露关注浏览器向脚本暴露的网络地址，主要在浏览器设置中处理。其中一项通过，并不能说明另一项也通过。
品牌资料能说明某个机场的客户端会不会造成 WebRTC 泄露吗？
不能。品牌资料只提供协议标注和客户端方式，没有浏览器行为信息，本站也没有做过相关实测，状态为 Not Tested。WebRTC 暴露主要由浏览器设置、扩展和客户端工作模式共同决定，需要在自己的环境里用检测页验证。
下一步
建议按这个顺序处理：先在日常使用的浏览器里做基线检测和开启代理后的检测；再根据使用场景选择限制方式并重新检测；然后用 DNS 泄露的检测方法 完成解析层的检查。如果你常在手机或桌面客户端之间切换，可分别查看 桌面客户端的差异 与 移动客户端的差异；想了解握手阶段的特征对连接的影响，可看 TLS 指纹与 uTLS 的作用。
如果你的关注点是整体风险控制，可回到 风险与避坑专题 了解下单前后的检查顺序，并进入 客户端专题 核对自己设备的客户端能力。
Cluster · security
安全与隐私
- TLS 指纹与 uTLS：客户端指纹为何影响连接什么是 TLS 指纹，为什么客户端需要模拟浏览器指纹？
- 代理流量的加密层次：传输加密与端到端加密的区别使用代理后流量在哪些环节是加密的？
- DNS 泄露是什么：检测方法与客户端设置什么是 DNS 泄露，如何检测和避免？
- WebRTC 泄露与浏览器设置WebRTC 泄露是怎么发生的，浏览器怎么设置？
- 跳过证书校验（allowInsecure）的风险为什么不建议开启跳过证书校验？
- 客户端从哪里下载：来源校验与签名检查如何确认下载的代理客户端是安全的？
- 流量特征与识别：协议伪装的原理与边界代理流量为什么可能被识别，伪装能做到什么程度？
下方卡片指向品牌库入口，便于按客户端方式与协议标注筛选；这不构成推荐，任何品牌都需要你自行核对客户端的 UDP 与虚拟网卡支持。
信息来源与更新日期
- 信息来源：通用技术资料（WebRTC、ICE、STUN、UDP、虚拟网卡等公认概念）；品牌公开资料/用户提供清单（协议标注、客户端方式、价格类型）。
- 数据状态：全部品牌为 Vendor Data，测速 Not Tested，客户端的 UDP 转发与虚拟网卡支持均待核实。
- 数据核实日期：2026-10-18
- 最近更新时间：2026-10-18
- 本文不包含具体速度、延迟或版本号，不承诺任何平台的收录或排名；浏览器界面与行为可能变化，以实际页面为准。