很多用户在使用快连电脑版时会有一种错觉：客户端显示已连接，IP 检测网站也显示的是节点地址，于是就认为流量已经全部被接管。但在 IPv4/IPv6 双栈网络逐渐普及的今天，这种判断并不总是成立。一个典型场景是：应用优先走 IPv6 直连，而快连只接管了 IPv4 流量，结果就是 IPv4 走了代理、IPv6 却从本地网络直接出去。对普通浏览来说，这可能只是“时快时慢”；对需要隐藏真实网络环境的场景来说，这就是一次实打实的地址泄漏。本文从泄漏成因讲起，给出可操作的检测方法、双栈优先级调整思路与分流规则配置方式，帮助你把这条容易被忽略的缝隙补上。
一、IPv6 泄漏是怎么发生的
要理解泄漏，先要理解双栈的“选择权”在谁手里。当一台设备同时拥有 IPv4 和 IPv6 地址，访问一个同时支持两种协议的目标时，操作系统和应用程序会按照自己的优先级策略选择其中一条路径。现代操作系统普遍优先 IPv6，这是设计上的进步，但在代理场景下就带来了一个新问题：如果代理客户端只接管了 IPv4 的路由，IPv6 的流量就会绕过代理，从物理网卡直接发出。
泄漏通常发生在三种情况下。第一种是客户端工作模式只处理 IPv4，虚拟网卡或系统代理没有覆盖 IPv6 路由。第二种是分流规则把某些域名或网段排除在外，而这些目标恰好支持 IPv6，排除规则同时放行了两种协议。第三种是浏览器或应用自身的行为，例如某些浏览器会并行发起 IPv4 与 IPv6 连接，哪条先返回用哪条，代理只拦住了其中一条。三种情况的共同点是：表面上看连接正常，实际上有一部分流量没有经过节点。
二、先确认你的网络是不是双栈
在排查泄漏之前，先确认本地网络是否真的具备 IPv6 能力。如果运营商或路由器根本没有下发 IPv6 地址，那么泄漏无从谈起，问题应该回到 IPv4 层去查。
Windows 上可以在“设置 → 网络和 Internet → 属性”中查看是否分配了 IPv6 地址，也可以用命令行确认：
REM 查看本机 IPv4 / IPv6 地址分配情况
ipconfig /all
REM 测试 IPv6 连通性（示例地址，可替换为任意双栈站点）
ping -6 ipv6.google.com
REM 查看 IPv6 路由表
netsh interface ipv6 show routemacOS 与 Linux 上对应的命令是 ifconfig 或 ip -6 addr，以及 ping6 或 ping -6。如果本机确实拿到了全球单播 IPv6 地址，并且能连通外部 IPv6 站点，就说明你的环境是双栈，接下来才需要关心“有没有被代理接管”。
三、检测：三种由浅入深的方法
方法一：双栈 IP 检测站点对比
最直接的方式是分别用只查 IPv4 和只查 IPv6 的检测页面各看一次。如果 IPv4 显示的是节点地址，而 IPv6 显示的是你本地运营商分配的地址，基本可以确认存在泄漏。注意要在连接快连的状态下检测，并且检测前清一次浏览器缓存，避免看到旧结果。
方法二：系统路由表核对
路由表是最客观的证据。连接快连后，查看 IPv6 默认路由指向哪块网卡。如果默认路由仍然指向物理网卡而不是快连的虚拟网卡，说明 IPv6 没有被接管。
REM 查看 IPv6 默认路由
netsh interface ipv6 show route
REM 查看所有网卡的接口列表，便于对照接口索引
netsh interface ipv6 show interfacesmacOS 上可以用 netstat -rn -f inet6 查看 IPv6 路由表，重点看 default 一行对应的网关与接口。
方法三：抓包观察实际出口
如果前两种方法的结果互相矛盾，可以用抓包做最终确认。在物理网卡上过滤 IPv6 流量，连接快连后访问一个双栈站点，观察是否有发往外部 IPv6 地址的包没有经过虚拟网卡。这一步对普通用户略重，但在排查“到底哪条路径漏了”时非常有效。
四、处理思路：优先“接管”，其次“禁用”，最后“分流”
发现泄漏后，处理方式并不是只有一种。按对使用体验的影响从小到大，可以分成三层。
第一层：让快连接管 IPv6
如果客户端当前版本支持 IPv6 接管，优先在设置中确认相关选项已开启，并检查工作模式是否覆盖双栈。接管的好处是体验最完整，IPv4 与 IPv6 都经过节点，不需要额外维护排除列表。开启后重新连接，再用前面的检测方法复核一次。
第二层：在不需要 IPv6 时临时禁用
如果当前网络环境并不依赖 IPv6，而客户端版本又不支持接管，那么临时在物理网卡上禁用 IPv6 是最省事的做法。Windows 可在“网络适配器 → 属性”中取消勾选“Internet 协议版本 6 (TCP/IPv6)”，macOS 可在网络设置中把 IPv6 配置改为“仅本地链接”。这样做会让所有流量回到 IPv4，代理覆盖完整，代价是失去 IPv6 直连带来的部分速度优势。
第三层：用分流规则精确控制
如果既需要保留 IPv6 的本地能力，又不想让特定流量绕过代理，就需要用分流规则把“哪些目标走代理、哪些直连”写清楚。这里的关键不是把所有 IPv6 都排除，而是明确哪些网段必须经过节点。规则写好后，建议用检测站点与路由表双重验证，确认规则实际生效。关于规则写法与优先级的更多细节，可以参考快连技术博客中关于自定义代理规则的专题文章。
五、双栈优先级：理解系统的“先选谁”
即使代理已经接管了双栈，仍然可能出现“某次访问走了 IPv6 直连”的偶发现象，这往往与系统的地址选择策略有关。操作系统在同时拥有多种地址时，会按照前缀策略表决定优先使用哪一个源地址和哪条路径。理解这一点，有助于解释为什么同样的设置下，不同应用的表现会不一样。
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| IPv4 检测为节点地址，IPv6 为本地地址 | IPv6 未被接管，走了物理网卡 | 开启 IPv6 接管，或临时禁用物理网卡 IPv6 |
| 部分应用泄漏，部分正常 | 应用自身优先 IPv6，且分流规则未覆盖 | 检查分流规则是否同时覆盖 IPv4 与 IPv6 目标 |
| 刚连接时正常，一段时间后泄漏 | 路由或前缀策略被其他软件改写 | 核对路由表，排查是否有其他网络软件同时运行 |
| 禁用 IPv6 后某些站点变慢 | 目标站点 IPv6 路径更优，禁用后回落到 IPv4 | 按需启用，仅对必须隐藏的场景禁用 |
| 检测结果时好时坏 | 浏览器并行连接，先返回者胜出 | 以路由表与抓包结果为准，不只看单次检测 |
需要强调的是，调整优先级属于系统层操作，改动前应记录原始配置，改动后逐一验证。对于大多数用户，第一层的“接管”与第二层的“临时禁用”已经足够；只有在经常于多个网络环境之间切换、或对 IPv6 有明确依赖时，才需要深入到优先级与策略表这一层。
六、浏览器与应用层的补充防护
系统层处理完之后，还有两个容易遗漏的地方。第一是浏览器自身的并行连接行为，部分浏览器会同时发起 IPv4 与 IPv6 请求，代理只拦住了其中一条时，另一条仍可能从本地出去。可以在浏览器中关闭“预连接”或“并行连接”相关选项做对比测试。第二是应用层的独立网络栈，某些应用不遵循系统代理设置，需要单独配置或依赖 TUN 模式接管。关于 TUN 模式与虚拟网卡的排查方法，本站已有专门文章，这里不再展开。
此外，检测时建议使用多个来源交叉验证，而不是只信一个页面的结果。不同检测站点的查询逻辑不同，有的只查 IPv4，有的会同时返回 IPv6，有的还会检测 DNS 与 WebRTC。把多个结果放在一起看，才能判断是“真的泄漏”还是“检测口径不同”。
七、一套可复用的自查清单
- 确认双栈：本机是否分配了全球单播 IPv6 地址，是否能连通外部 IPv6 站点。
- 连接后核对路由：IPv6 默认路由是否指向快连虚拟网卡，而不是物理网卡。
- 双栈检测对比：分别查看 IPv4 与 IPv6 的出口地址，判断是否一致指向节点。
- 检查分流规则：排除规则是否只写了 IPv4 网段，而放行了对应的 IPv6 目标。
- 排查并行软件：是否有其他网络软件在连接后改写路由或前缀策略。
- 按需处置：优先接管，其次临时禁用，最后才用分流规则做精细控制。
IPv6 泄漏之所以容易被忽略，是因为它不会让网络“断掉”，只会让一部分流量悄悄走另一条路。正因如此，判断依据不能只看“能不能上网”，而要看“路由指向哪里、出口地址是谁”。把本文的检测方法与处理顺序走一遍，大多数双栈环境下的泄漏都能被定位并解决。如果你希望系统性地了解快连的工作模式与接管范围，可以从快连下载页面获取最新客户端，并在快连官网查阅对应的功能说明。