连接状态显示正常，浏览器里却检测出本地网络地址被外部读取——这类状况往往不是连不上，而是 WebRTC 这条实时通信通道绕过了代理路径，把硬件的本地地址暴露了出去。WebRTC 本身是浏览器做到音视频通话的标准能力，它为了建立点对点连接，会主动收集候选网络地址；假如客户端或浏览器没有对这条通道做限制，收集到的本地地址就也许被网页读到。快连在客户端中给予了防泄露相关设定，配合浏览器侧的一两项调整，可把这条通道收回到可控范围内。假如客户端还没安装客户端，可先到 快连下载 页面取得对应平台的版本。
一、WebRTC泄露是什么，为什么值得关注
WebRTC 是浏览器内置的实时通信能力，视频会议、在线客服、部分网页游戏都依赖它。为了让两个硬件立刻建立连接，浏览器会收集一系列候选地址，包括经由本地网络接口取得的地址、经由解析服务取得的地址，与经由中继服务分配的地址。正常状况下，这些地址只在通信双方之间交换；但假如网页脚本主动读取这些候选地址，本地网络信息就也许被记录下来。
故障在于，WebRTC 的地址收集过程并不总是走代理通道。部分浏览器做到会立刻读取本地网络接口，绕过系统平台代理设定。也就是说，即使快连处于已连接状态，浏览器仍也许经由 WebRTC 拿到你所在网络的本地地址。这个地址不肯定能立刻定位到明确位置，但它能反映你使用的联网环境，与代理出口地址不一致时，就也许被用来做关联分析。
值得关注的成因有三个。第一是地址不一致带来的识别风险：网页一并拿到代理出口地址和本地地址，两者不一致本身就是一种特征。第二是本地地址暴露：局域网地址虽然不能立刻从外部浏览，但它能反映网络结构，配合其他信息可缩小识别范围。第三是行为关联：同一硬件在各类站点上暴露相同的本地地址特征，也许被用于跨站关联。这些风险并不等于“肯定被追踪”，但属于可主动收敛的暴露面。
有一点需注意，防泄露设定并不改变快连的加密途径。快连的传输始终运用 AES-256-GCM 高强度加密算法，配合 KTP 极速协议，连接建立时间约为 3 秒。WebRTC 泄露是浏览器层面的地址收集故障，加密保护的是传输内容，两者化解的是各类层面的故障，需分别处理。
二、快连的防泄露设定能做什么
快连客户端给予的防泄露相关设定，核心目的是让浏览器的实时通信请求也走代理路径，要不至少不让本地地址被立刻读取。各类版本的客户端在特性命名与包含范围上略有差异，但大多包含以下几类能力。
第一类是代理转发规则。客户端可在系统平台层面把 WebRTC 使用的网络请求纳入代理路径，使候选地址的收集过程经过加速通道。这样一来，网页读到的地址与代理出口地址保持一致，不会出现本地地址与出口地址并存的状况。
第二类是地址过滤。部分版本会在本地网络接口层面过滤掉内网地址，使浏览器无法收集到局域网地址。此种途径对浏览器兼容性较好，不依赖浏览器自身的设定项。
第三类是浏览器配合选项。客户端也许给予“与浏览器配合”的提示或开关，引导用户端在浏览器中关掉 WebRTC 的本地地址收集。这类选项大多需用户端在浏览器侧人工完成，客户端只负责提示。
需留意的是，防泄露设定与分流规则、代理模式是各类层面的配置。分流规则决定哪些流量走加速通道，防泄露设定决定实时通信请求是否也受这条路径约束。两者可一并打开，互不冲突。假如你希望进一步了解分流模式与规则的关系，可浏览 快连官方站点 的知识库入口，那里有更完整的设定说明。
三、各类平台打开防泄露设定的路径
快连在 Windows、macOS、Android、iOS 四个平台都给予客户端，防泄露相关设定的位置都在“设定”分类下，但入口名称与层级略有差异。假如你在客户端里找不到对应选项，可先查明当前版本，旧版本也许没有独立的防泄露入口，换新到最新版后路径会更统一。
- Android 基础版：进入客户端后单击右下角“我的”，选用“设定”，在“隐私保护”区域查找防泄露选项。移动端浏览器对 WebRTC 的处理途径与桌面端各类，可用范围以实际显示为准。
- iOS 基础版：在客户端首页单击左上角菜单，进入“设定”，选用“隐私保护”。iOS 系统平台对浏览器的管控较严格，WebRTC 地址收集本身受到肯定限制，防泄露设定更多是补充作用。
- Windows 专业版：运行客户端主页面，单击左侧“设定”，在“隐私”或“高级”区域查找“WebRTC 防护”“防泄露设定”或类似名称的选项。打开后客户端会接管实时通信请求的地址收集过程。
- macOS 专业版：单击顶部菜单栏的快连图标进入主窗口，选用“偏好设定”，在“隐私”标签页中找到防泄露相关开关。macOS 端也许一并给予“地址过滤”与“代理转发”两种途径，按需选用其一便能。
各平台的设定在保存后即时生效，不需重启客户端。打开后不妨先用浏览器做一次验证，查明地址收集结果符合预期，再决定是否长期保持打开。假如发现某些网页应用无法正常建立连接，回到设定页面调整防护途径，而不是立刻关掉全部防护。
四、打开WebRTC防护的完整操作步骤
下面以桌面端为例，完整走一遍打开防护的流程。移动端的页面布局各类，但判断逻辑一致，可对照操作。
整个流程大多几分钟就能完成。验证经由后，不妨把验证结果截图保存，后续更换浏览器或换新客户端时可对照，快捷判断防护是否仍旧有效。
五、浏览器侧还需做哪些配合设定
客户端的防泄露设定负责代理路径与地址过滤，浏览器自身的设定同样重要。两者配合才能把暴露面收敛到位，只靠一侧往往不够。
第一项是排查浏览器的 WebRTC 策略。主流浏览器在设定或实验性特性中给予了 WebRTC 相关选项，可限制本地地址收集。各类浏览器的入口名称各类，有的叫“WebRTC 连接策略”，有的叫“禁止非代理 UDP 连接”。把策略设定为仅使用代理或禁用非代理连接，可减少本地地址被收集的机会。
第二项是关掉不必要的实时通信权限。浏览器在网页请求摄像头、麦克风权限时会一并触发更完整的地址收集。关于不需音视频特性的站点，保持权限关掉便能减少这类触发。权限管理在浏览器的站点设定中逐项查明，不要一次性全部放行。
第三项是注意扩展与插件的影响。部分浏览器扩展会注入脚本或修改网络请求，也许影响 WebRTC 的行为。假如验证时发现地址异常，可临时禁用扩展再测一次，判断故障是否来自扩展。
第四项是保持浏览器换新。WebRTC 的做到细节随版本变化，旧版本也许存在已知的地址收集行为差异。换新到较新的稳定版本本，可减少因做到差异带来的意外暴露。
六、怎么验证WebRTC是否还在泄露
防护打开后需实际验证一次，不能只看开关状态。验证分两步：先查明代理出口地址正常，再查明没有本地地址混入结果。
第一步，打开浏览器浏览一个显示当前出口地址的页面，记录返回的地址。这个地址应当与快连客户端显示的节点出口一致。假如出口地址与客户端显示不符，说明代理路径本身有故障，先化解连接故障再谈防泄露。
第二步，浏览 WebRTC 检测页面，翻阅返回的候选地址列表。正常状况下，列表中应当只出现与代理出口一致的地址，要不只出现中继地址，不应出现 192.168、10、172.16 等本地网段地址。假如检测结果中仍旧出现本地地址，说明防护没有全然生效，按下面的顺序排查。
- 排查浏览器策略：浏览器自身的 WebRTC 策略也许包含了客户端设定，逐项核对策略项是否与客户端防护途径匹配。
- 排查扩展干扰：临时禁用一切扩展再测一次，排除扩展注入脚本导致的行为变化。
- 排查分流规则：分流模式下，某条直连规则也许把实时通信请求提前放行。把相关域名的规则调整为走加速通道，并上移到直连规则先前。
- 查明客户端版本：旧版本的防护包含范围也许有限，换新到最新版后重新打开并验证。
- 查明防护开关已打开：回到客户端隐私设定，查明 WebRTC 防护处于打开状态，而不是仅打开了页面没有保存。
- 查明浏览器已重启：浏览器在启动时读取网络策略，设定变更后需全然退出再打开，仅刷新页面不够。
假如以上都排查过仍旧检测到本地地址，可换一个浏览器交叉验证。换浏览器后正常，说明故障在原浏览器的策略或扩展；换浏览器后仍异常，说明故障在客户端防护或系统平台网络层面，需按连接路径继续排查。
七、防泄露设定与套餐、多端的配合使用
防泄露设定属于客户端本地配置，不会改变套餐权益。快连当前共有三档套餐：移动基础版 ¥20/月，服务 iOS 与 Android 用户端；电脑专业版 ¥32/月，服务于 Windows 与 macOS 用户端；全平台旗舰版 ¥55/月，通吃一切平台，并允许 5 台硬件并行在线使用。无论选用哪一档，防泄露设定的操作途径都相同。
多端用户端需注意，防护设定是每台硬件独立生效的，不会自行同步。全平台旗舰版的 5 台硬件额度下，A 硬件打开防护不会影响 B 硬件的设定，B 硬件仍需单独打开并验证。假如希望多台硬件保持一致，可先在一台硬件上调好防护途径与浏览器策略，再对照着在其他硬件上复现，验证步骤也可复用同一套检测页面。
关于经常使用公共网络的硬件，防泄露设定的价值更突出。公共网络下本地地址暴露带来的关联风险更高，打开防护并配合浏览器策略，可减少不必要的地址收集。一切硬件上的加速流量同样运用 AES-256-GCM 高强度加密算法，配合 KTP 极速协议，连接建立时间约为 3 秒，防护设定只影响地址收集路径，不会改变加密与连接特性。
首次使用不妨先利用 72 小时免费体验期期把防护开关、浏览器策略与验证流程走一遍，查明常用网页应用不受影响随后再决定订阅哪一档。试用期间的防护设定保存在本地，试用结束后不会丢失，订阅后继续沿用便能。假如配置过程中发现客户端里没有防泄露入口，最省事的做法是重新下载一次最新安装包：进入 快连下载 页面选用对应平台，安装完成后按本文第三节的路径进入隐私设定，再照着第四节的六步流程打开防护，最后用第六节的做法验证一次。防护调好随后，日常使用大体不需再改动，只在更换浏览器或换新客户端时重新验证一次便能。