连接状态显示正常，浏览器里却检测出本地网络地址被外部读取——这类情形往往不是连接不上，而是 WebRTC 这条实时通信通道绕过了代理路径，把终端的本地地址暴露了出去。WebRTC 本身是浏览器达成音视频通话的标准能力，它为了建立点对点连接，会主动收集候选网络地址；若客户端或浏览器没有对这条通道做限制，收集到的本地地址就或许被网页读到。快连在客户端中带来了防泄露相关配置，配合浏览器侧的一两项调整，能够把这条通道收回到可控范围内。若你尚未安装客户端，能够先到 快连下载 页面拿到对应平台的版本。
一、WebRTC泄露是什么，为什么值得关注
WebRTC 是浏览器内置的实时通信能力，视频会议、在线客服、部分网页游戏都依赖它。为了让两个终端马上建立连接，浏览器会收集一系列候选地址，包括借助本地网络接口拿到的地址、借助解析服务拿到的地址，和借助中继服务分配的地址。正常情形下，这些地址只在通信双方之间交换；但若网页脚本主动读取这些候选地址，本地网络信息就或许被记录下来。
状况在于，WebRTC 的地址收集过程并不总是走代理通道。部分浏览器达成会马上读取本地网络接口，绕过操作系统代理配置。也就是说，即使快连处于已连接状态，浏览器仍或许借助 WebRTC 拿到你所在网络的本地地址。这个地址不必定能马上定位到详细位置，但它能反映你使用的网络状况，与代理出口地址不一致时，就或许被用来做关联分析。
值得关注的缘由有三个。第一是地址不一致带来的识别风险：网页与此同时拿到代理出口地址和本地地址，两者不一致本身就是一种特征。第二是本地地址暴露：局域网地址虽然不能马上从外部打开，但它能反映网络结构，配合其他信息能够缩小识别范围。第三是行为关联：同一终端在各异站点上暴露相同的本地地址特征，或许被用于跨站关联。这些风险并不等于“必定被追踪”，但属于能够主动收敛的暴露面。
这里要补充一点，防泄露配置并不改变快连的加密办法。快连的传输始终使用 AES-256-GCM 强加密保护，配合 KTP 极速协议，连接建立时间约为 3 秒。WebRTC 泄露是浏览器层面的地址收集状况，加密保护的是传输内容，两者处理的是各异层面的状况，须分别处理。
二、快连的防泄露配置能做什么
快连客户端带来的防泄露相关配置，核心目的是让浏览器的实时通信请求也走代理路径，或是至少不让本地地址被马上读取。各异版本的客户端在能力命名与涵盖范围上略有差异，但通常包含以下几类能力。
第一类是代理转发规则。客户端能够在操作系统层面把 WebRTC 使用的网络请求纳入代理路径，使候选地址的收集过程经过加速通道。这样一来，网页读到的地址与代理出口地址保持一致，不会出现本地地址与出口地址并存的情形。
第二类是地址过滤。部分版本会在本地网络接口层面过滤掉内网地址，使浏览器无法收集到局域网地址。这类办法对浏览器兼容性较好，不依赖浏览器自身的配置项。
第三类是浏览器配合选项。客户端或许带来“与浏览器配合”的提示或开关，引导使用者在浏览器中停用 WebRTC 的本地地址收集。这类选项通常须使用者在浏览器侧手工完成，客户端只负责提示。
须留意的是，防泄露配置与分流规则、代理模式是各异层面的配置。分流规则决定哪些流量走加速通道，防泄露配置决定实时通信请求是否也受这条路径约束。两者能够与此同时启用，互不冲突。若你希望进一步了解分流模式与规则的关系，能够打开 快连官方网站 的知识库入口，那里有更完整的配置说明。
三、各异平台打开防泄露配置的路径
快连在 Windows、macOS、Android、iOS 四个平台都带来客户端，防泄露相关配置的位置都在“配置”分类下，但入口名称与层级略有差异。若你在客户端里找不到对应选项，能够先核实当前版本，旧版本或许没有独立的防泄露入口，升级到最新版后路径会更统一。
- macOS 专业版：点选顶部菜单栏的快连图标进入主窗口，挑选“偏好配置”，在“隐私”标签页中找到防泄露相关开关。macOS 端或许与此同时带来“地址过滤”与“代理转发”两种办法，按需挑选其一就能。
- Android 基础版：进入客户端后点选右下角“我的”，挑选“配置”，在“隐私保护”区域查找防泄露选项。移动端浏览器对 WebRTC 的处理办法与桌面端各异，可用范围以实际显示为准。
- iOS 基础版：在客户端首页点选左上角菜单，进入“配置”，挑选“隐私保护”。iOS 操作系统对浏览器的管控较严格，WebRTC 地址收集本身受到必定限制，防泄露配置更多是补充作用。
- Windows 专业版：启动客户端主面板，点选左侧“配置”，在“隐私”或“高级”区域查找“WebRTC 防护”“防泄露配置”或类似名称的选项。启用后客户端会接管实时通信请求的地址收集过程。
各平台的配置在保存后即时生效，不须重启客户端。启用后推荐先用浏览器做一次验证，核实地址收集结果符合预期，再决定是否长期保持启用。若发现某些网页应用无法正常建立连接，回到配置页面调整防护办法，而不是马上停用全部防护。
四、启用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 小时免费体验期把防护开关、浏览器策略与验证流程走一遍，核实常用网页应用不受影响以后再决定订阅哪一档。试用期间的防护配置保存在本地，试用结束后不会丢失，订阅后继续沿用就能。若配置过程中发现客户端里没有防泄露入口，最省事的做法是重新下载一次最新安装包：打开 快连下载 页面挑选对应平台，安装完成后按本文第三节的路径进入隐私配置，再照着第四节的六步流程启用防护，最后用第六节的办法验证一次。防护调好以后，日常使用大致不须再改动，只在更换浏览器或升级客户端时重新验证一次就能。