快喵VPN防泄漏屏蔽强度：只去私网
去掉 192.168 与 10 开头地址，公网候选保留。影响最小，仍可能暴露出口。
v6.8.2 · 逐条判断依据 · 含六端差异
泄漏不是一种故障，而是三条互不相干的路径。DNS 决定谁替你查域名，WebRTC 决定谁看得到你的本机地址，IPv6 决定有没有第二条路由。三条都收口，出口才只剩一条。
| 通道数量 | 3 条：DNS、WebRTC、IPv6（另有分流导致的第四类误判） |
|---|---|
| 判断依据 | 检测页的解析服务器、候选地址列表、本机 v6 地址 |
| 对应返回码 | 103（DNS）、105（WebRTC）、104（IPv6） |
| 收口层次 | DNS 在应用层，WebRTC 在应用层，IPv6 在系统与路由层 |
| 复现要求 | 同一检测页连开三次，结果一致才算稳定泄漏 |
| 当前版本 | v6.8.2（2026-11-12 发布） |
三条泄漏通道各管什么DNS 管解析，WebRTC 管候选，IPv6 管路由
隧道只规定「流量往哪走」。谁解析域名、谁收集候选地址、系统是否还有第二条路由，这三件事在隧道之外决定。
三条通道互不替代。把 DNS 收口了，WebRTC 仍可能报出私网地址；把候选收敛了，v6 仍可能直连。
- DNS 泄漏最隐蔽：页面照样打开，只有解析服务器暴露位置。
- WebRTC 泄漏最直接：候选列表里能读到内网网段。
- IPv6 泄漏最容易被忽略：v4 走隧道，v6 走直连，两条路并行。
- 分流不是泄漏：规则明确放行的域名走直连，属于设计行为。
- 三者可以叠加：同一次访问可能同时暴露解析地与内网地址。
- 判断要同一页：三项在同一检测页读取，避免条件不一致。
- 三次一致才成立：单次异常多为缓存，重复三次再看。
- 先修 DNS 再修 v6：解析收口后，v6 的表现才看得清。
| 通道 | 泄漏原理 | 典型表现 | 收口层 |
|---|---|---|---|
| DNS | 解析请求发给本地运营商或公共 DNS | 解析服务器落在本地城市 | 应用层接管 |
| WebRTC | 浏览器收集本机与内网地址并上报 | 候选列表出现 192.168 或 10 开头 | 应用层屏蔽 |
| IPv6 | 双栈下 v6 走独立路由，不经过隧道 | 本机持有 2408 或 240e 开头地址 | 系统与路由层 |
| 分流 | 规则放行的域名走直连 | 只有特定站点显示本地解析 | 规则层 |
DNS 泄漏怎么查解析走了谁看解析服务器地区与解析商名称
域名要先变成地址，请求才发得出去。这一步由解析服务器完成。解析服务器在本地，查询内容就落在本地，即使网页内容走的是隧道。
客户端的做法是接管解析：把系统解析指到隧道内的 DoT 服务，由节点侧完成查询。接管失败时会静默回落，页面照常打开。
- 解析服务器在节点侧检测页显示的解析地区与出口地区一致，误差不超过一个地区。
- 解析商不是本地运营商显示运营商名称即未接管，返回码 103。
- 系统 DNS 为自动手动设过 8.8.8.8 一类地址的设备，接管会被绕过。
- 私有 DNS 已关闭Android 的私人 DNS、iOS 的加密 DNS 会抢先接管。
- 浏览器未自带 DoH部分浏览器内置安全 DNS，会覆盖系统设置。
- 三次结果一致无痕窗口连开三次，解析地区不变才算稳定。
| 位置 | 做法 | 影响面 | 适用 |
|---|---|---|---|
| 客户端内 | 接通管内的 DoT，端口 853 | 单机 | 默认推荐 |
| 系统层 | 改系统解析为隧道地址 | 整机含命令行 | 桌面端排障 |
| 路由器 | DHCP 下发隧道内 DNS | 整网设备 | 电视与主机 |
三个位置只需一个生效。同时改两处容易互相覆盖，排查时更难定位。
WebRTC 泄漏怎么收敛候选候选来自本机网卡、NAT 映射与中继三处
WebRTC 建立连接前要先收集候选地址：本机网卡地址、内网地址、公网出口。这些候选会被写进会话描述，对端与检测页都能读到。
屏蔽的目标不是关掉 WebRTC，而是让候选只剩隧道出口。三档强度对应三种取舍，强度越高，点对点通话越依赖中继。
- 候选来源一：本机网卡地址，包含 192.168 与 10 开头网段。
- 候选来源二：NAT 映射后的公网地址，由 STUN 服务返回。
- 候选来源三：中继地址，走 TURN 服务，通常是隧道出口。
- mDNS 混淆：部分浏览器用随机主机名替代内网地址，属缓解不是根治。
- 屏蔽方式：限制非代理 UDP，让候选只能经隧道收集。
- 验证方式：检测页候选列表只剩一条出口地址。
- 副作用：点对点通话改走中继，延迟增加约 20–40ms。
- 页面要重载：改完开关不重载，读到的还是上一次候选。
屏蔽强度：只留中继
候选只剩 TURN 中继，点对点通话改走中继。默认档，兼顾可用与收敛。
屏蔽强度：禁用 UDP
浏览器内 WebRTC 基本不可用，网页会议需回落到 TCP。最严，排障时临时用。
候选条数的正常值
正常只剩一条。多于一条说明还有网卡在收集，需复查虚拟网卡。
虚拟网卡残留检查
多张虚拟网卡并存时，候选会增多，先清理残留网卡。
候选数量写进基线
把数量记进基线，换网络后对比，异常会立刻显现。
IPv6 泄漏为什么断开后还在漏v4 走隧道，v6 按系统路由表直连
双栈网络下，v4 与 v6 是两条独立路由。隧道通常只接管 v4，v6 仍按系统路由表直连。站点若同时有 v6 入口，浏览器会优先走 v6。
表现是：出口检测显示节点地区，但部分站点仍识别出真实地区。原因是那部分请求走了 v6，没进隧道。
- 先确认有没有：本机地址列表里出现 2408、240e 开头，说明 v6 已下发。
- 再看走不走：纯 v6 站点能打开，说明 v6 路由通。
- 阻断要彻底：只拦部分前缀，换一个前缀仍会漏。
- 路由侧优先：整网设备多时，在路由侧关闭下发更省事。
- 移动网络注意：运营商 v6 下发策略与家宽不同，换网要复查。
- 隧道内不做 v6：当前版本隧道只承载 v4，v6 一律阻断。
- 阻断可回退：需要纯 v6 站点时临时放行，用完恢复。
- 看返回码：104 表示仍持有公网 v6 地址。
| 做法 | 位置 | 代价 | 适用 |
|---|---|---|---|
| 阻断 v6 出站 | 客户端 | 纯 v6 站点不可达 | 默认推荐 |
| 关闭路由 v6 下发 | 路由器 | 整网失去 v6 | 家庭整网 |
| 仅保留链路本地 | 系统 | 局域网 v6 发现失效 | 桌面端排障 |
| 放行并观察 | 不改 | 真实地区可能暴露 | 临时对照 |
检测页上先看哪一个判据解析地区、候选条数、v6 地址三项
三项判据在同一页读取：解析服务器地区、候选地址条数、本机 v6 地址。三项都通过，说明请求只走一条出口。
读取顺序建议固定：先解析，再候选，最后 v6。解析没接管时，v6 的表现常被误读。
- 解析地区等于出口地区两者误差不超过一个地区，视为通过。
- 候选只剩一条列表内只有隧道出口地址，无私网网段。
- 本机无公网 v6地址列表内没有 2408、240e 开头地址。
- 页面为无痕窗口避免读到上一次的缓存结果。
- 连接未在切换中选路切换期间结果不稳定，等 15 秒再读。
- 结果可重复连开三次结果一致，才作为判断依据。
六端的 DNS 与 IPv6 泄漏收口实现位置不同，三条判据一致
桌面端能做系统层接管，移动端受系统策略限制，路由器端只能整网处理。差异在实现位置，不在目标。
判断依据六端一致：解析在节点侧、候选只剩出口、本机无公网 v6。
桌面端的系统解析接管
Windows 与 macOS 都能改系统解析并写入出站规则，三条通道可在单机内全部收口。
- Windows 通过防火墙规则阻断 v6 出站。
- macOS 通过网络扩展过滤，规则随扩展加载。
- 两端都能改系统解析，接管失败会回落到应用层。
- Linux 用 nftables 链，重启后需确认脚本执行。
移动端的私有 DNS 优先级
移动端的解析由系统统一管理，客户端只能申请接管，不能强制改写。
- Android 的私人 DNS 优先级高于应用设置。
- iOS 的加密 DNS 配置会覆盖应用层接管。
- 后台被清理时，VPN 服务挂起，三条通道同时恢复原状。
- 移动端 v6 由运营商下发，阻断需在应用内完成。
路由器 DHCP 下发 DNS
路由器端不做逐台接管，而是让整网流量都经过转发链，解析与 v6 由面板统一设置。
- DHCP 下发的 DNS 必须是隧道内地址。
- 面板内关闭 v6 下发，整网即失去 v6。
- 单机开关在整网转发时不再单独起作用。
- 固件升级后需确认开机脚本仍在。
整网转发会让局域网投屏与设备发现失效，需要时用分流放行内网网段。
三条泄漏通道与分流的当前状态四行全绿，出口才只剩一条
前三行是通道，第四行是规则。规则导致的「看起来泄漏」不属于故障，但会干扰判断，所以要单独列出。
第四行显示为需授权，是因为分流默认关闭。开启后按规则组逐条确认放行范围，不放行的域名自然走隧道。
DNS已开启解析在节点侧，返回码 0
WebRTC已开启候选只剩出口，返回码 0
IPv6已开启无公网 v6 地址，返回码 0
分流需授权规则放行的域名走直连，需逐条确认
DNS、WebRTC、IPv6 修复顺序解析没接管时，后两项读数不可靠
- 别同时改三处：三项一起改，出问题无法定位是哪一处引起。
- 每改一处重连：规则在连接时加载，改完不重连等于没改。
- 改完用无痕窗口：普通窗口缓存会让结果滞后。
- 失败先看码：103、105、104 分别对应三项，码比现象准。
- 稳定后再优化：三项通过后再调分流，避免交叉影响。
- 换网络要重来：换网后路由侧策略变化，三项都要复查。
返回码 103：先修 DNS
解析没接管时，后面两项的读数都不可靠。返回码 103。
返回码 105：再修候选
候选收敛后重载页面再读，避免读到旧候选。返回码 105。
返回码 104：最后修 v6
前两项稳定后，v6 是否直连才看得清。返回码 104。
分流规则组逐条复查
逐条看规则组，确认放行范围与预期一致。
六步自检重走一遍
六步自检从头走一遍，确认没有回退。
三项基线写进记录表
三项结果写进基线表，下次对比用。
被当成泄漏的缓存与分流缓存、分流、系统私有 DNS 三类
检测页缓存与旧结果
普通窗口会复用上次的检测结果，尤其在同一标签内刷新时。
- 用无痕窗口重新打开检测页。
- 关闭标签后重开，而不是刷新。
- 换一个检测页交叉验证。
分流规则组的放行范围
被规则放行的域名走直连，解析自然在本地，这不是泄漏。
- 逐条核对规则组内的域名前缀。
- 临时关闭分流，看结果是否变化。
- 确认放行范围与预期一致后再启用。
私有 DNS 与浏览器 DoH
系统私有 DNS 与浏览器内置 DoH 都可能绕过客户端。
- 关闭 Android 私人 DNS 与 iOS 加密 DNS。
- 关闭浏览器内置安全 DNS。
- 检查是否有代理类扩展在接管流量。
三类都排除后仍复现，才按返回码表逐项处理。
WebRTC 泄漏的候选条数口径条件写在括号内，可直接引用
- 通道数量（版本）：3 条主通道 + 1 类分流误判，v6.8.2 起固定。
- 返回码（版本）：103 对应 DNS、105 对应 WebRTC、104 对应 IPv6。
- 候选条数（实测）：正常 1 条，出现 2 条及以上需复查虚拟网卡。
- 中继延迟（实测）：点对点改中继后增加 20–40ms，20 次采样。
- 解析判据（方法）：解析地区与出口地区误差不超过一个地区。
- 复现要求（方法）：同一检测页连开三次结果一致，才计为稳定泄漏。
DNS 与 IPv6 泄漏的六个问题分流、缓存与路由器 v6 三类
三条通道要不要全部关闭？
不是关闭，是收口。DNS 与 WebRTC 改为经隧道，IPv6 阻断直连。目标是让请求只剩一条出口，而不是把功能停掉。
为什么关了 WebRTC 还能看到候选？
多半是页面没重载。候选在页面加载时收集，改完开关不重载，读到的仍是上一次结果。用无痕窗口重开即可。
路由器关了 v6，手机为什么还有 v6 地址？
手机可能同时连着移动网络，运营商下发的 v6 不受路由影响。断开移动网络或用飞行模式复位后再看。
解析显示在节点地区，但站点仍识别真实地区，为什么？
常见原因是 v6 直连或浏览器扩展接管。先看本机是否有公网 v6 地址，再逐个关掉扩展排查。
分流开着算不算泄漏？
不算。分流是明确放行，规则写清就走直连。判断标准是放行范围是否与预期一致，而不是有没有走直连。
移动端息屏后检测结果变了，正常吗？
正常。系统清理后台会挂起 VPN 服务，三条通道同时恢复原状。唤醒客户端后重新检测即可。
本页数据口径每条都带采样条件，可按同一方法复算
- 防护项（版本）：4 项默认开，v6.8.2 起不提供默认关闭。
- 切断间隔（实测）：Windows 1.1–1.5 秒、macOS 0.8–1.2 秒，各 20 次取区间。
- 返回码（版本）：7 个，覆盖授权、解析、候选、v6 与隧道五类问题。
- 自检耗时（实测）：4 分 40 秒至 5 分 30 秒，六步全走，普通家宽条件。
- 安装包体积（版本）：Windows 28.4 MB、macOS 31.2 MB，v6.8.2 公示值。
先解析，再候选，最后 v6；每步都有返回码可对照。