这个问题问得非常到位——我之前也纠结过为什么明明VPN路由表都改了，WebRTC还能泄露真实IP，后来查了相关协议和浏览器实现才搞明白，核心原因是WebRTC的设计目标和系统路由逻辑不一样，再加上ICE/STUN/TURN的工作机制，具体拆解如下：

一、WebRTC不严格遵循系统默认路由的核心原因 #

VPN的核心是修改系统路由表，让普通网络流量默认走虚拟VPN接口，但WebRTC的设计目标是尽可能建立高效的P2P连接，所以它会主动绕过系统路由的限制：

• 浏览器会直接枚举操作系统中所有活跃的网络接口（包括你的物理网卡、VPN虚拟网卡，甚至蓝牙共享的网卡等），获取每个接口对应的本地IP地址。
• 更关键的是，WebRTC允许直接绑定特定网卡发送网络请求，不需要遵循系统默认的路由规则——也就是说，它可以跳过VPN接口，直接用物理网卡发送数据包，哪怕系统路由表显示所有流量都该走VPN。

二、STUN/TURN/ICE如何协同获取真实IP #

这三个协议是WebRTC实现P2P连接的核心，它们的工作逻辑直接导致了真实IP的泄露：

1. ICE：收集所有可能的连接候选 #

ICE（Interactive Connectivity Establishment）是一套寻找最优P2P路径的框架，它的第一步就是收集所有可用的IP地址候选：

• 它会把物理网卡的本地IP、通过STUN获取的物理网卡公网IP，以及VPN接口的本地IP、VPN的公网IP，全部加入候选列表。
• 哪怕VPN的IP是系统默认路由的出口，真实IP依然会被作为候选之一，后续会和对方交换这些候选地址，尝试建立连接。

2. STUN：主动探测公网真实IP #

STUN（Session Traversal Utilities for NAT）的作用是获取设备的公网IP地址：

• WebRTC会向STUN服务器发送请求，STUN服务器会返回请求数据包的来源公网IP。
• 如果WebRTC选择用物理网卡发送这个STUN请求（而不是VPN接口），那STUN服务器返回的就是你的真实公网IP，这个IP会被加入ICE候选列表。
• 为什么会用物理网卡？因为WebRTC会尝试所有可用接口，而有些操作系统允许程序直接指定网卡发送请求，完全绕过系统路由。

3. TURN：中继过程中也可能泄露 #

TURN（Traversal Using Relays around NAT）本来是作为P2P连接失败时的中继服务器，但它也可能泄露真实IP：

• 如果WebRTC用物理网卡连接TURN服务器，TURN服务器会记录下你的真实公网IP。
• 即使后续用TURN中继流量，对方也可能通过TURN服务器的日志或者连接信息，间接获取到你的真实IP。

三、验证方式 #

你可以直接在浏览器里查看WebRTC收集的候选地址：

• Chrome浏览器：访问chrome://webrtc-internals/，找到ICE Candidate相关的日志，里面会列出所有WebRTC收集到的IP地址，包括真实IP和VPN IP。
• Firefox浏览器：访问about:webrtc，在连接详情里查看候选地址列表。

内容的提问来源于stack exchange，提问作者Gradient