什么是 WebRTC 泄漏？
WebRTC（Web Real-Time Communication）是 IETF RFC 8825 标准化的浏览器原生 API，让浏览器之间能够直接建立点对点的音频、视频与数据通道——无需独立插件或服务器中继。要建立这些连接，浏览器必须收集并交换 ICE 候选：RFC 8839 所定义的 IP 地址与端口的结构化清单。问题在于，ICE 候选收集会在 VPN 隧道或 SOCKS 代理有机会拦截流量之前暴露设备的真实本地与公网 IP 地址。
当浏览器经由 VPN 上网时，所有 HTTP/HTTPS 请求都通过隧道路由，并携带 VPN 出口 IP。然而，WebRTC 走 UDP，并在执行局域网（STUN/TURN）发现时绕开系统默认路由表。如果浏览器的 WebRTC 栈未被显式限制，远端页面只需对一台公开 STUN 服务器（例如 stun:stun.l.google.com:19302）调用 RTCPeerConnection，便能在 candidate 事件中收到设备的真实公网 IP——即便此时 VPN 仍处于启用状态。这就是 WebRTC 泄漏。
为何对竞赛投票反欺诈检测至关重要
依赖按 IP 限投票的在线竞赛在一定程度上靠普通 VPN 检测得以保护——但 WebRTC 泄漏开辟出第二条检测通道，更可靠而非更弱。一位轮换 VPN 出口、却使用未打补丁 WebRTC 栈的浏览器的投票者，会在每次比赛页面发起对端协商或我们的反欺诈 JavaScript 静默调用 RTCPeerConnection 时，无意中广播自己的真实 IP。
实践中，竞赛平台可以采用服务端 STUN 关联：页面加载一次隐式的对端连接握手，真实 IP 出现在 candidate 字符串里，后端评分引擎再把它与该投票声称的来源 IP 比对。出现差值即提示存在代理或 VPN 使用——这是有组织刷票的强烈信号。
从我们平台的视角来看，理解 WebRTC 泄漏有两层意涵：
- 检测准确度：我们的反欺诈评分层会把 WebRTC 暴露出的 IP 与提交投票的 IP 进行交叉比对。不一致会拉高该提交的风险评分。当多次不一致共同指向同一底层 IP 时，可把投票集群归因到同一行为者。
- 客户隐私文档：我们的服务买家所处司法辖区中 VPN 使用合法且常见。我们的知识库必须坦率说明 WebRTC 泄漏可能让他们以为代理栈所提供的匿名性化为乌有，让他们带着准确预期来选择我们的服务。
泄漏的技术解剖
一段触发候选收集的极简 JavaScript 代码大致如下（取自 MDN Web Docs）：
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.createOffer().then(o => pc.setLocalDescription(o));
pc.onicecandidate = e => {
if (e.candidate) console.log(e.candidate.candidate);
};RFC 8839 §5.1 规定的 candidate 字符串格式（a=candidate:...）以明文形式包含 IP 地址、端口与传输类型。无需任何用户操作；整个交换对用户而言不可见。
各浏览器在缓解上有所差异：
- Firefox 自 42 版本起便提供
media.peerconnection.enabled = false这一用户可控开关。 - Chrome 与 Edge（Chromium）支持
chrome://flags/#enable-webrtc-hide-local-ips-with-mdns，启用后会用 mDNS.local主机名替换真实 IP。 - Brave 在其”指纹保护”模式下默认禁用 WebRTC。
与我们 SEO 策略的关联
“WebRTC 泄漏”这一术语承载着两类信息搜索意图：注重隐私的 VPN 用户，以及构建反欺诈系统的开发者。两类受众都与竞赛投票话题相互交叉。一篇结构良好的词条有助于在”竞赛反欺诈”主题集群中确立主题权威性，通过展现第一手技术深度来支撑我们的 E-E-A-T 信号——这是纯商业服务页面无法企及的。
三句话小结： WebRTC 泄漏会通过浏览器的 ICE 候选过程暴露设备真实 IP，绕开 VPN。竞赛平台借此把代理伪装下的投票关联回同一来源 IP。准确记录这一机制既支撑我们的反欺诈可信度，也覆盖了相应的信息类 SEO。
