WebRTC 泄漏检测工具怎么用？检查浏览器是否暴露真实公网 IP 指南

WebRTC 穿透代理的三大核心协议特性#

1. UDP 传输层协议与系统代理的天然脱节：绝大多数操作系统（无论是 Windows 的 Internet 设置、macOS 的系统代理还是各类浏览器的 SwitchyOmega 插件）所建立的“系统代理”，其本质是基于应用层的 HTTP 或 SOCKS 协议。传统的系统代理主要针对 TCP 流量进行监听和重定向；而 WebRTC 为了保障音视频通话的极致超低延迟，其底层的 STUN 探测与媒体流传输默认全部基于无连接的 UDP 协议。当浏览器发起 STUN 请求时，数据包根本不经过操作系统的 HTTP 代理端口，而是直接经由物理网卡的默认路由出海，从而造成真实公网 IP 的彻底裸奔。
2. ICE Candidate 候选者收集的暴力机制：在 RFC 5245 规范中，为了保证位于不同 NAT 路由器背后的两个终端能够成功握手，WebRTC 引擎必须不遗余力地收集本机所有可用的通信候选者（ICE Candidates）。引擎不仅会收集本地主机的私网 IP（如 192.168.1.100），更会通过向外部 STUN 服务器发送绑定请求，强制让对端回传本端在公网网关映射后的真实外网 IP 与端口。这一原本用于促进连通性的合规算法，在代理场景下演变成了天然的嗅探工具。
3. 前端 JavaScript 接口的零权限调用：在绝大多数浏览器中，网页代码无需弹出任何权限授权弹窗（例如不需要像麦克风、摄像头或地理位置那样向用户请求授权），只需在后台执行三行简洁的 JavaScript 代码创建 RTCPeerConnection 对象，即可自由监听并提取底层返回的所有 Candidate 候选者信息，用户在浏览网页时对此完全一无所知。

三大候选者类型的技术内涵与风险等级#

1. 主机候选者（Host Candidate，typ host）：这是浏览器直接从操作系统底层读取的物理网络接口 IP。在家庭环境中，它通常是一个 192.168 或 10 开头的私网 IPv4 地址；但在启用了 IPv6 的现代宽带中，Host Candidate 往往直接包含一个全球唯一的公网 IPv6 地址。如果你的 IPv6 未被代理接管，真实的 IPv6 地址会直接作为 Host Candidate 被上报，造成灾难性的全球唯一物理定位泄漏。
2. 服务器反射候选者（Server Reflexive Candidate，typ srflx）：这是最致命的泄漏类型。它是本地终端向公共 STUN 服务器发送 UDP 探测包后，由 STUN 服务器在公网视角下看到的映射 IP。如果出现 typ srflx 且该 IP 属于中国电信、中国联通或中国移动，说明你的应用层代理软件被完全穿透，真实公网出口已经彻底大白于天下。
3. 中继候选者（Relay Candidate，typ relay）：在某些受限极严的对称型 NAT 环境中，P2P 直连无法建立，双方必须通过合规的 TURN 服务器进行媒体流转发。此时收集到的候选者是远端 TURN 服务器的公网 IP。如果网络环境仅产生 Relay 候选者，说明所有的流量均被强制中继，真实身份得到了完善保护。

两种模式的核心防御分水岭#

1. 系统代理模式的软肋：系统代理仅仅是在操作系统中设置了一个环境变量或注册表开关（如 Windows Internet 选项中的代理服务器）。它依赖应用程序自觉遵循该设置。然而，WebRTC 规范在设计之初就优先追求穿透一切障碍建立直连，其底层的 C++ 原生网络模块会主动绕过这些应用层设置，直接向系统内核请求开启原生的 UDP Socket，导致数据包毫无阻拦地溜出物理网卡。
2. TUN 模式的全局降维打击：TUN 模式是在操作系统的网络驱动层，虚拟出一块拥有最高路由优先级的虚拟物理网卡（如 Windows 下的 Wintun 驱动）。代理客户端修改系统底层路由表，将发往全局的所有流量（包括 0.0.0.0/0 的全部 TCP 与 UDP 报文）强行引导至该虚拟网卡。无论 WebRTC 引擎如何试图绕过应用层，只要其数据包离开操作系统协议栈，就必然被 TUN 虚拟网卡无差别捕获并加密转发至海外落地服务器，从而在网络底层物理截断了泄漏通道。

主流浏览器彻底禁用 WebRTC 实操步骤#

1. Mozilla Firefox（火狐浏览器原生彻底关闭）：
   • 在地址栏输入 about:config 并按下回车，接受免责风险提示；
   • 在顶部搜索框中输入 media.peerconnection.enabled；
   • 双击该配置项，将其布尔值由 true 修改为 false；
   • 效果评估：一旦设为 false，Firefox 将在底层彻底剥离所有 WebRTC 相关的 JavaScript API。任何网页调用 RTCPeerConnection 均会直接抛出未定义异常，从根源上 100% 杜绝任何形式的 IP 泄露。
2. Google Chrome / Microsoft Edge（基于策略或扩展程序）：
   • 由于 Chromium 架构为了保障其庞大的会议生态（Google Meet / Webex），在较新版本中移除了直接禁用 WebRTC 的底层标志位，用户可以通过安装权威的安全扩展进行拦截：
   • 推荐使用开源合规的扩展程序：WebRTC Control 或 uBlock Origin；
   • 在 uBlock Origin 设置面板中，勾选【防止 WebRTC 泄露本地 IP 地址】（Prevent WebRTC from leaking local IP addresses）；
   • 在 Chromium 企业策略中，可将 WebRtcUdpPortRange 设为空，或者将网络访问策略配置为强制走中继（disable_non_proxied_udp）。

网页前端 WebRTC 嗅探测试源码#

1
<!DOCTYPE html>
2
<html lang="zh-CN">
3
<head>
4
    <meta charset="UTF-8">
5
    <title>WebRTC IP 深度嗅探测试探针</title>
6
</head>
7
<body>
8
    <h2>当前浏览器 WebRTC 候选者嗅探日志</h2>
9
    <ul id="ip-list"></ul>
10

11
    <script>
12
        const ipList = document.getElementById('ip-list');
13

14
        function appendLog(text, isDanger = false) {
15
            const li = document.createElement('li');
16
            li.textContent = text;
17
            if (isDanger) li.style.color = 'red';
18
            ipList.appendChild(li);
19
        }
20

21
        try {
22
            // 构造包含公共 STUN 服务器的配置对象
23
            const rtcConfig = {
24
                iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
25
            };
26

27
            const pc = new RTCPeerConnection(rtcConfig);
28

29
            // 创建一个虚假的虚假数据通道以触发 ICE 协商
30
            pc.createDataChannel("leak-detector");
31

32
            pc.onicecandidate = function(event) {
33
                if (event.candidate) {
34
                    const candidateStr = event.candidate.candidate;
35
                    console.log("捕获到原始 Candidate:", candidateStr);
36

37
                    // 正则提取候选者中的 IP 地址
38
                    const ipRegex = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/;
39
                    const match = candidateStr.match(ipRegex);
40

41
                    if (match) {
42
                        const leakedIP = match[1];
43
                        if (candidateStr.includes("typ srflx")) {
44
                            appendLog("【致命泄漏】检测到真实公网出口 IP: " + leakedIP, true);
45
                        } else if (candidateStr.includes("typ host")) {
46
                            appendLog("【本地指纹】检测到本地主机私网 IP: " + leakedIP, false);
47
                        }
48
                    }
49
                } else {
50
                    appendLog("ICE 候选者收集完毕。如果上方未出现真实公网 IP，说明防御成功！");
51
                }
52
            };
53

54
            pc.createOffer().then(offer => pc.setLocalDescription(offer));
55

56
        } catch (err) {
57
            appendLog("WebRTC 模块已被浏览器彻底禁用或阻断: " + err.message);
58
        }
59
    </script>
60
</body>
61
</html>

终端使用命令行模拟测试 STUN 穿透#

在 Linux 或 macOS 终端下，可以使用开源的 stun 命令行工具直接向公共 STUN 服务器发送探测，核验当前网关外部映射的真实地址：

1
# 1. 在终端下直接向 Google STUN 服务器发送探测包 (测试当前出口映射)
2
stun stun.l.google.com 19302
3

4
# 2. 检查操作系统当前是否有进程在监听或建立 WebRTC 相关的 UDP 会话
5
netstat -unp | grep -E "3478|19302"
6

7
# 3. 使用 tshark 抓包监听网络接口上的 STUN Binding 请求
8
sudo tshark -i any -f "udp port 19302" -Y "stun"

为什么 STUN 协议采用异或映射（XOR-MAPPED-ADDRESS）#

1. 规避传统 NAT 网关的 ALG 深度包检测：在早期的 RFC 3489 规范中，STUN 服务器直接在报文载荷中明文填充客户端的映射 IP（MAPPED-ADDRESS）。然而，很多家用或企业路由器内置了应用层网关（ALG，Application Level Gateway）功能。当 ALG 检测到报文载荷中含有 IP 字符串时，会擅自修改该字段，从而破坏了真实公网映射的判定。RFC 5389 强制引入了异或映射算法，将 IP 与固定的 Magic Cookie 执行数学异或，使得经过中间网关时呈现为无规律的二进制伪随机数，成功避开了中间网络设备的篡改。
2. Wireshark 与终端抓包实战取证：

1
# 1. 使用 tcpdump 捕获发往 Google STUN 端口的交互报文并保存为 pcap 文件
2
sudo tcpdump -i any "udp and (port 3478 or port 19302)" -w stun_leak.pcap -c 20
3

4
# 2. 在终端使用 tshark 深度解析 STUN 响应中的 XOR-MAPPED-ADDRESS 真实 IP 字段
5
tshark -r stun_leak.pcap -Y "stun" -T fields -e ip.src -e ip.dst -e stun.att.ipv4
6

7
# 3. Windows PowerShell 快速检测当前系统是否成功加载了 Wintun 虚拟网卡驱动
8
Get-NetAdapter | Where-Object { $_.InterfaceDescription -match "Wintun|Clash|WireGuard" } | Format-Table Name, Status, LinkSpeed

WebRtcIPHandlingPolicy 策略属性深度配置#

通过在操作系统注册表或 Linux 系统的 /etc/opt/chrome/policies/managed/ 目录下下发策略，管理员可以强制浏览器约束 WebRTC 的网络行为：

1. default（默认模式）：允许 WebRTC 使用所有可用的网络接口（包括物理网卡、WiFi 与虚拟网卡），这是导致应用层系统代理发生泄漏的元凶。
2. default_public_interface_only：仅允许使用默认的公网接口，但在没有 TUN 网卡的环境中依然会暴露物理公网 IP。
3. disable_non_proxied_udp（强烈推荐的安全模式）：此策略会强制 WebRTC 仅使用通过代理隧道中转的连接，或者强制所有的媒体流走合规的 TURN 中继服务，完全禁止浏览器直接向物理网卡开启原始的 UDP Socket。在此策略下，外部 STUN 探测由于无法直连出网而自动失效，既保障了企业内网的安全合规，又彻底消除了无意识的公网 IP 泄漏风险。

【排查案例一】跨境电商卖家使用指纹浏览器未禁用 WebRTC 遭遇关联封店#

某跨境电商品牌在亚马逊北美站运营着 15 个品牌矩阵店铺。为了防止账号之间相互关联，团队为每个店铺采购了昂贵的独享静态美国住宅 IP，并在电脑上统一使用某知名商业指纹浏览器。然而在某次例行更新后，系统在 48 小时内接连收到了 6 个店铺的停权邮件，提示“检测到该账户与已被封禁的违规账户存在多重强关联网络指纹”。

企业安全工程师介入全面排查，在模拟真实的店铺管理操作时，使用抓包工具对指纹浏览器的网络请求进行了底层审计：

原来，该指纹浏览器在最新版本的默认模板中，为了兼容海外视频客服功能，将 WebRTC 设置由原先的“完全禁用”（Disabled）悄然修改为了“网络真实替身模式”（Replaced）。但由于该功能存在底层驱动兼容性 Bug，当网页向某些特定的第三方 STUN 服务器发送 UDP 包时，底层的替换逻辑未能生效，真实的中国电信宽带公网 IP 与本地 192.168.1.58 的私网地址被直接写入了 Candidate 字符串并发送给了亚马逊的前端风控脚本。

亚马逊的大数据关联引擎在后台比对发现：这 6 个原本拥有不同海外 IP 的店铺，在同一周内全部上报了完全相同的中国电信真实 IP 与相同的局域网网卡 MAC 衍生指纹。这种铁证如山的关联事实瞬间触发了矩阵团灭机制。

团队随后在所有指纹浏览器环境中，将 WebRTC 策略强制锁定为硬编码的“Disable WebRTC”，并在软路由网关全面阻断了所有外部 STUN 请求，后续重新入驻的店铺彻底告别了关联危机。

【排查案例二】海外社交媒体账号因 WebRTC 暴露出真实私网与公网 IP 被批量限流#

某短视频海外运营团队在电脑端使用安卓模拟器批量运营海外账号，虽然模拟器上配置了海外代理客户端且地理定位显示在美国洛杉矶，但发布的视频播放量连续两周全网卡在 0 播放（俗称死号限流）。

团队技术负责人调取了模拟器环境内部的 BrowserLeaks 测试结果，发现了令人触目惊心的泄漏现象：

由于该代理客户端仅在应用层注入了常规的 HTTP 代理，安卓系统底层的 Chrome 浏览器内核在调用 WebRTC 协议时，直接将模拟器桥接的电脑宿主机真实公网 IP（中国联通）探测了出来，并且将其作为 typ srflx 优先候选者展示在页面上。

海外短视频平台的反作弊算法对“设备网络分裂”拥有极高敏感度：应用层上报的是美国洛杉矶时区与美国机房 IP，而底层 WebRTC 探针却静默回传了中国联通的真实网络出口。这种底层网络协议的极度矛盾，瞬间将该批账号判定为恶意的跨国群控灰产脚本，直接施加了隐形降权与流量冷冻。

团队将模拟器的网络架构重构为基于软路由网关级 TUN 强劫持，并在浏览器底层彻底停用 WebRTC 接口，新账号发布视频后播放量秒级破万，恢复了正常的推流机制。

【排查案例三】金融支付结算网关通过 WebRTC 探测到跨国物理位置冲突触发风控拒付#

某跨国贸易公司的财务人员在远程处理海外 Stripe 账户向海外供应商的供应商大额打款时，支付页面在点击最终确认后，连续五次弹出拒付错误代码 Transaction_Failed_High_Risk，随后企业账户被 Stripe 风险控制委员会施加了长达 7 天的资金冻结。

技术团队与 Stripe 技术支持取得联系后，安全人员调取了发起支付那一秒的风控日志。明细日志中记录了一项致命的欺诈特征：WEBRTC_IP_LOCATION_MISMATCH。

财务人员所使用的笔记本电脑虽然挂载了美国的住宅代理节点，但其 Edge 浏览器并未配置防 WebRTC 泄露策略。Stripe 的前端安全脚本在后台静默触发了一次轻量级的 STUN 探测。STUN 服务器在一瞬间捕获到了财务人员真实的中国大陆公网出口 IP。Stripe 的机器学习模型在比对时，发现 HTTP 业务出口在美国、而 WebRTC 底层源 IP 位于一万公里之外的大陆，两者在物理时空上完全不可能由同一个人在同一秒钟完成操作，从而判定该网银会话正在遭受严重的海外中间人跨国会话劫持（Session Hijacking），立即执行了最高级别的熔断保护。

【排查案例四】自建节点使用普通 SOCKS5 代理导致 STUN UDP 探测逃逸出网#

某网络技术爱好者在海外购买了高性能 VPS 搭建自建出海节点，客户端使用的是传统的 SOCKS5 本地代理监听端口（127.0.0.1:10808）。在浏览器中使用代理扩展插件连接该节点后，访问 Google 和 YouTube 速度飞快，但在打开 IPleak.net 测试时，页面下方的 WebRTC 检测框中赫然显示出该爱好者本地光猫的真实公网 IP。

该爱好者感到非常困惑：明明配置了全局代理，为什么数据包还会泄露？

深入抓包分析表明，该爱好者所使用的客户端软件默认仅开启了 SOCKS5 的 TCP 代理功能，并未支持或开启 UDP ASSOCIATE（UDP 代理转发功能）。当网页向 STUN 服务器发起 UDP 报文探测时，浏览器向本地 10808 端口发送 UDP 握手失败，浏览器网络协议栈根据其内置的回退机制，自动退回到直连模式，直接调用物理网卡将该 UDP 报文从家庭路由器的公网出口发送了出去。

这一复盘充分表明：仅靠普通的应用层代理根本无法约束 WebRTC 的穿透行为，唯有开启全局 TUN 模式或者直接在客户端规则中全局 REJECT 阻断 STUN 协议，才能实现滴水不漏的安全防护。

mDNS 匿名化的技术边界#

1. 仅保护局域网私网 IP：mDNS 技术的诞生，是为了防止恶意网站通过读取类似 192.168.1.x 的私有地址来推测用户的内网设备拓扑或绘制唯一的设备指纹。开启 mDNS 后，浏览器会将本地私网 IP 替换为一个随机生成的 .local 伪域名（例如 uuid.local），使得前端 JS 无法直接读出私网数字。
2. 对公网 STUN 穿透彻底无能为力：必须清醒认识到，mDNS 机制完全没有、也绝不可能阻止 WebRTC 向公网 STUN 服务器发起 UDP 探测。只要客户端的 UDP 数据包溜出物理网卡到达了外部 STUN 服务器，STUN 服务器回传的 Server Reflexive 候选者中必然包含你真实的公网 IP。许多用户误以为看到了 .local 就代表安全，这种认知盲区往往是导致出海风控翻车的致命诱因。

在企业级数字化出海运营的复杂攻防场景中，WebRTC 安全防护绝非单一维度的开关操作，而是涵盖浏览器环境配置、底层操作系统虚拟网卡调度以及边界防火墙策略的多层次防御体系。只有在每一个微小网络环节建立闭环，才能彻底杜绝真实网络身份的外泄风险。

问题一 为什么我的测试页面只显示了一个 .local 后缀的地址而没有显示公网 IP#

如果在 BrowserLeaks 或 IPleak 的 WebRTC 检测栏中，仅看到形如 xxxx-xxxx.local 的条目，而其下方标有“No Public IP detected”或“No Leak”，这表明你的环境处于高度安全的受控状态。出现这种现象通常有两种原因：第一，当前浏览器成功激活了 mDNS 局域网掩码机制，且系统代理客户端处于开启状态但未对外开放直连 STUN 通道；第二，代理客户端开启了全局 TUN 模式或者直接在防火墙上阻断了 3478 和 19302 端口，导致外部 STUN 探测全部超时失败。只要没有捕获到任何真实的公网 IP，你的网络环境就是绝对合规的。

问题二 彻底禁用 WebRTC 会不会导致网页上的正常功能无法使用#

在绝大多数常规的互联网使用场景中，彻底禁用 WebRTC 完全不会产生任何负面影响。无论是普通的网页浏览、视频播放（如观看 YouTube、Netflix、Bilibili，它们使用的是标准的 HTML5 Video 与 HLS/DASH 协议流）、在线电商购物、社交发帖还是常规文件下载，全部依赖标准的 HTTP/HTTPS 协议，与 WebRTC 毫无关系。唯一会受到影响的场景是：基于浏览器网页端直接运行的实时双向音视频通话（例如直接在网页版 Google Meet、网页版 Zoom、网页版 Discord 或网页端网页客服中开启麦克风通话）。如果你的业务需要使用这些特定会议工具，应当采用“全局 TUN 模式强力代理接管”而非粗暴禁用。

问题三 开启代理软件的系统代理后为什么在检测网站依然能看到本地真实公网 IP#

这是因为系统代理默认只能接管应用程序的 TCP 流量（主要是 HTTP/HTTPS 请求），而 WebRTC 的 STUN 穿透探测报文是基于无连接的 UDP 协议发送的。当检测网页的前端脚本启动 RTCPeerConnection 时，浏览器底层直接绕过了操作系统的 TCP 代理通道，调用物理网卡直接将 UDP 数据包发送给了目标 STUN 服务器。STUN 服务器捕获到的是直接来自你家庭宽带网关的数据包，随后将该真实 IP 回传给网页，从而造成系统代理下的彻底穿透泄漏。

问题四 移动端手机在开启代理后是否同样面临 WebRTC 泄漏的风险#

完全面临相同的严重风险。无论是 iOS 平台的 Safari 浏览器还是 Android 平台的各大手机浏览器，其内核均完整内置了 WebRTC 通信引擎。如果用户在手机上使用的代理软件未开启全接管的 VPN 虚拟网卡模式（VpnService / NetworkExtension），或者手机应用在后台私自调用了原生的 WebRTC SDK，应用便能在毫秒内获取到当前手机插入的真实 SIM 卡移动网络 IP（中国移动/联通/电信蜂窝出口），造成严重的地理伪装破功。

问题五 使用商业指纹浏览器能否彻底消除 WebRTC 泄漏风险#

只要指纹浏览器的配置参数设置正确，商业指纹浏览器是防范 WebRTC 泄漏的强力武器之一。在各大合规指纹浏览器（如 AdsPower、比特浏览器等）中，WebRTC 设置通常提供三种模式：【开启真实】、【完全替换/伪装】以及【彻底禁用】。为了获得绝对的安全性，在进行跨境电商与敏感社交运营时，最稳妥的策略是直接选择“彻底禁用”（Disabled）。如果选择“替换”，一旦某次软件内核升级出现 Hook 拦截失效，真实的物理 IP 仍有可能瞬间逃逸。

问题六 为什么在代理客户端中直接阻断 3478 和 19302 端口能够防泄漏#

STUN 协议在全球有着标准化的端口规范。绝大多数公开的公共 STUN 服务器均监听在 UDP 3478 端口（标准 STUN 端口）或 UDP 19302 端口（Google 运营的全球最大公共 STUN 端口）。网页端发起的绝大多数穿透探测，其目标地址必然指向这两个端口。当代理客户端在规则集最顶端配置针对这两个端口的 REJECT 丢弃规则后，任何试图发起 STUN 握手的数据包在进入网卡的一瞬间被直接就地丢弃，客户端因收不到任何外部回包而超时放弃，从而无法组装出任何包含真实公网 IP 的 Candidate 候选者。

问题七 局域网私网 IP（如 192.168.x.x）泄漏到底有多大危害#

很多用户认为局域网 IP 是私有地址、公网无法直接访问，泄露了也无所谓。这种看法是极具风险的。在现代反欺诈风控体系中，局域网 IP 虽然不能直接寻址，但它构成了**设备指纹关联（Browser Fingerprinting）**的核心拼图。例如，如果一个卖家在同一台电脑上使用不同代理管理三个亚马逊店铺，虽然三个店铺的外网 IP 不同，但如果三个店铺的浏览器环境在底层同时上报了完全相同的本地私网 IP 192.168.1.188 以及相同的内部网络接口标识，亚马逊的风控引擎会将该私网 IP 作为关键特征纳入关联判定图谱，最终导致账号被批量认定为同一物理设备操作。

问题八 开启 TUN 模式后为什么在某些 WebRTC 测试网站上显示的仍然是代理节点 IP#

这正是 TUN 模式所追求的最完美防护效果。在 TUN 模式下，发往 STUN 服务器的 UDP 探测包并没有被粗暴阻断，而是被完整虚拟网卡捕获、加密后送达海外落地服务器，最后由海外落地服务器代为发起 STUN 探测。因此，STUN 服务器捕获到的自然是海外落地服务器的公网 IP。检测网站看到的 WebRTC IP 与常规网页浏览的出口 IP 呈现出完美的一致性（例如全部显示为日本东京某机房 IP），没有任何国内真实信息外泄，这是在兼顾音视频通话需求下的终极防护形态。

问题九 什么是 WebRTC 的 IPv6 穿透泄漏，为什么它比 IPv4 更隐蔽#

在当今全球全面普及 IPv6 双栈的网络环境下，绝大多数国内家庭宽带分配到的都是拥有全球唯一公网路由能力的 IPv6 地址。当 WebRTC 引擎在本地物理网卡上扫描主机候选者（Host Candidate）时，能够直接读取到物理网卡上绑定的真实公网 IPv6。如果用户的代理软件只支持或者只配置了 IPv4 代理，该真实的公网 IPv6 会直接被作为 Host Candidate 打包上传给测试页面。目标平台只需解析出该 IPv6，就能以极高的精度直接定位到你家所在的城市甚至具体小区，其隐蔽性与危险度远超 IPv4。

问题十 如何建立一套标准化的 WebRTC 防泄漏日常巡检机制#

对于从事出海高敏业务的技术团队，建议建立标准化的“开机三步验收机制”：第一步，开启代理客户端并确认已激活全局 TUN 模式；第二步，使用无痕窗口打开 BrowserLeaks.com/webrtc，严格核验【Public IP Address】栏位：必须为“No Leak”或者显示的 IP 必须与当前海外节点的落地出口 IP 100% 严格一致；第三步，检查【Local IP Address】栏位，确认其显示为 uuid.local 或已被彻底阻断。只有当三个指标全部满足时，才被允许登录核心海外业务平台开展操作。