随着“IPv6 规模部署”持续推进，多数家庭光纤与移动网络已默认开启 IPv4/IPv6 双栈接入。在日常冲浪中，双栈网络能提供公网 IP 并降低部分国内 P2P 穿透难度。然而在开启代理或 VPN 后，双栈网络易演化为严重的安全盲区——“IPv6 泄漏”。许多用户误以为开启代理后流量万无一失，却不知道操作系统正通过“Happy Eyeballs 竞速算法”，把敏感访问流量通过本地 IPv6 物理网络直接发送到公网。本文将系统解构 IPv6 泄漏根因与加固之道。
一、双栈网络下的隐形后门：IPv6 泄漏成因
要理解 IPv6 泄漏为何如此普遍，必须看清操作系统网络协议栈在双栈环境下的默认行为。
当一个网站（例如海外某知名资讯平台或代码托管平台）同时配置了 IPv4 的 A 记录与 IPv6 的 AAAA 记录时，用户设备在访问该网站前，操作系统会向 DNS 解析器同时发起这两个记录的查询。
在传统的单栈代理配置中，绝大多数入门级代理客户端或简易分流规则在设计时，其底层往往只考虑了 IPv4 流量的接管：
- 代理客户端在系统上创建了一个只绑定了私有 IPv4 地址（如
198.18.0.1）的 TUN 虚拟网卡，或者只配置了基于 IPv4 的分流规则库。 - 然而，用户的物理网卡（以太网卡或 Wi-Fi）通过路由器无状态地址自动配置（SLAAC）或 DHCPv6，被运营商直接下发了一个全球唯一的公网 IPv6 地址（以
240e:、2408:或2409:开头）。 - 当应用程序发起网络连接时，操作系统的默认路由表中实际上存在着两套平行的默认网关：一套是通往代理虚拟网卡的 IPv4 默认路由，另一套则是通往运营商物理光猫的 IPv6 默认路由（
::/0）。
如果客户端程序决定走 IPv6 发起连接，或者代理内核没有对 IPv6 流量进行严格的强制劫持，内核协议栈就会毫不犹豫地直接选用物理网卡上的原生 IPv6 默认路由。此时，用户的数据包直接带着自己家庭宽带分配的真实公网 IPv6 地址，完全绕过代理加密隧道，直接从本地运营商网络飞向海外目标服务器！
这种现象带来的后果是灾难性的：一方面，目标服务器能够清晰无误地记录下用户的真实国内家庭公网 IPv6 身份；另一方面，由于这些跨境 IPv6 流量直接暴露在公网骨干网出口上，极易遭遇骨干网针对特定协议或端口的直接阻断，导致连接瞬间断开或超时。
二、Happy Eyeballs 竞速算法对分流的破坏
更为微妙的是，现代浏览器与应用协议栈内置的“Happy Eyeballs 算法”（RFC 8305）在客观上加速了这种泄漏与错乱。
在没有 Happy Eyeballs 的早期时代，双栈系统通常遵循“IPv6 优先”的死板规则。如果目标服务器的 IPv6 路由不可达或延迟极高，用户必须忍受长达数秒乃至十几秒的 TCP 握手超时，系统才会慢吞吞地回退（Fallback）到 IPv4。为了消除这种糟糕的用户等待体验，IETF 推出了 Happy Eyeballs（快乐眼球）算法。
Happy Eyeballs 的核心逻辑是“激进的双向并行竞速”：
- 客户端在解析出 A 记录与 AAAA 记录后，首先向目标服务器的 IPv6 地址发起 TCP SYN 握手。
- 算法启动一个极其短暂的倒计时器（通常仅为 200 到 250 毫秒，被称为连接尝试延迟 Resolution Delay）。
- 如果在 250 毫秒内 IPv6 握手没有完成，客户端绝不等候，立即并行向 IPv4 地址也发送一个 TCP SYN 握手！
- 谁先完成三次握手（即谁返回 SYN+ACK 的网络延迟更低），客户端就立即采纳谁作为本次会话的传输载体，并瞬间掐死另一个连接。
在复杂的代理环境中，这套算法经常引发戏剧性的非对称表现：假设用户的代理节点位于长往返时延的欧美机房（IPv4 往返耗时 180 毫秒），而本地运营商直连海外某些服务器的物理 IPv6 链路碰巧在此时较为通畅（直连延迟 120 毫秒）。由于本地直连 IPv6 握手抢先返回，Happy Eyeballs 算法会自动判定“IPv6 获胜”，从而将后续所有的传输流量强行拖入未经代理保护的本地直连物理链路中。
三、全面排查 IPv6 泄漏的操作流程
要验证自己的双栈环境是否存在安全死角，推荐遵循以下诊断步骤：
第一步是访问专业的双栈泄露检测站点。打开提供纯 IPv6 与双栈交叉审计的测试平台（如 ipv6leak.com 或 test-ipv6.com）。在开启代理的状态下观察系统输出：如果页面显示“检测到你的公网 IPv6 地址”，且该地址的运营商归属为你本地的真实宽带提供商（如中国电信某省分公司），则充分确认为存在严重的 IPv6 泄漏。
第二步是检查操作系统活跃路由表。在 Windows 终端运行 route print -6，在 Linux 运行 ip -6 route show。重点审查路由表顶部是否存在指向物理网卡网关的 ::/0 默认路由。若该路由依然具有较高优先级且未被代理虚拟网卡接管，说明操作系统的三层 IPv6 流量完全处于失控状态。
第三步是抓取特定应用的 AAAA 查询行为。在终端利用网络抓包工具或客户端内置的 DNS 日志，观察访问海外域名时，系统是否在向本地 DNS 发送 AAAA 解析请求。
四、根绝 IPv6 泄漏的四级加固策略
根据用户对 IPv6 的实际业务依赖程度，推荐采用以下四级防御加固方案：
第一级（最彻底也是最推荐的方案）：代理客户端全局丢弃 AAAA 查询。对于绝大多数只需要正常访问海外 Web、AI 工具与流媒体的普通用户而言，海外业务完全由成熟的 IPv4 网络承载。最干净、零副作用的加固方法是在代理客户端中开启 ipv6: false，或者配置 DNS 模块直接对所有海外域名的 AAAA（IPv6）查询返回空记录（NODATA）。没有了 IPv6 解析地址，操作系统应用层会被迫百分之百使用 IPv4 发起连接，从根源上直接消灭了 IPv6 泄漏的物理可能。
第二级：启用严格的双栈 TUN 接管（Strict-Route）。如果确实需要通过代理使用 IPv6（例如访问某些纯 IPv6 的海外科研服务器），必须在客户端中配置真正的双栈 TUN 虚拟网卡。不仅要分配私有 IPv4 地址，还必须为 TUN 网卡分配全局唯一的 ULA（唯一本地 IPv6 地址，如 fdfe:dcba::1/64），并在系统路由表中添加覆盖全球 IPv6 地址空间的更长前缀路由（例如 ::/1 和 8000::/1），将物理网卡的 ::/0 彻底压制。
第三级：在分流规则中实施端到端 IPv6 审计。参考分流规则匹配顺序与短路求值原则：避免代理规则被前置直连覆盖中确立的规范，确保规则集覆盖双栈 IP 段，防止针对境内 IP 的规则误将未标记的 IPv6 流量打回物理接口。
第四级：结合系统防火墙阻断出站泄漏。在路由器或本机防火墙（如 Windows Defender 防火墙或 Linux nftables）上配置出站规则：除了代理客户端自身进程外，严禁任何其他本地进程通过物理网卡向境外公网 IPv6 地址发起直接连接，构建最后一道硬核防线。
在配置双栈分流时，建议对照IPv6双栈分流怎么核验：分别检查地址族与出口逐项验证出口策略，并参考DNS泄漏测试如何解读：区分解析出口与流量出口核查解析器状态。