VPN如何判断IP和DNS是否泄漏？按5步完成检测与修复
简答：判断VPN是否泄漏，不能只看网页显示的公网IP。先关闭VPN记录真实IP和DNS，再开启VPN复测公网IPv4、IPv6、DNS解析器和WebRTC；如果仍出现原运营商IP或运营商DNS，应检查VPN客户端的DNS/IPv6防泄漏、浏览器安全DNS、系统自定义DNS与Kill Switch，并在切换服务器、断线重连和更换网络后再次测试。
定义：VPN泄漏是指VPN连接期间，真实公网IP、IPv6地址、DNS查询路径或浏览器WebRTC候选地址仍绕过VPN隧道暴露给网站或其他网络服务。
先用5步判断：30秒快速检查VPN是否真的生效
- 关闭VPN建立基准。在同一设备、同一浏览器、同一网络下，打开公网IP查询页和DNS泄漏测试页，记录真实公网IPv4、IPv6（如果有）、网络运营商以及DNS解析器所属网络。不要先切换Wi-Fi、移动数据或浏览器。
- 开启VPN并连接一个不同地区的服务器。如果客户端允许选择地区，优先选择与当前网络明显不同的位置，便于发现出口地址是否改变。VPN服务商的官方排查说明也建议在连接VPN前后分别进行DNS测试，并使用标准或扩展测试对照结果。Proton VPN 的 DNS 泄漏说明
- 重新检查公网IP。VPN开启后，网页看到的公网IP通常应变为VPN出口或其基础设施提供商的地址，而不是你关闭VPN时记录的家庭宽带、公司网络或移动运营商地址。IP变化只能证明浏览器出口可能改变，不能单独证明DNS、IPv6和WebRTC没有泄漏。
- 运行DNS标准或扩展测试。DNSLeakTest说明，标准测试会发起一轮查询，扩展测试会发起更多轮查询以发现更多解析服务器；扩展测试更全面，但耗时更长。DNSLeakTest：Standard 与 Extended 的区别
- 复测特殊场景。切换一次VPN服务器、断开后重新连接、从Wi-Fi切到移动数据，分别检查IP和DNS；如果客户端有Kill Switch或始终开启VPN选项，再测试VPN瞬间断开时网页是否还能加载。
最快结论：如果VPN开启后仍出现关闭VPN时记录的真实公网IP，属于明显异常；如果DNS结果仍显示真实宽带或移动运营商，优先排查DNS路径；如果只出现Cloudflare、Google或其他公共DNS，不能仅凭名称认定为泄漏，还要看它是否属于VPN路径、是否与VPN出口地区和客户端说明一致。
IP、DNS、IPv6和WebRTC分别在检查什么
| 检查项目 | 正常情况下重点看什么 | 出现什么结果需要排查 | 常见原因 |
|---|---|---|---|
| 公网IPv4 | 不再显示关闭VPN时的家庭宽带、公司或移动运营商地址 | 仍显示关闭VPN时的真实地址 | VPN未接管浏览器流量、分流规则、客户端连接失败 |
| 公网IPv6 | 应由VPN客户端处理、阻断或明确纳入VPN路径 | 出现关闭VPN时的IPv6前缀或运营商IPv6 | 客户端未处理IPv6、系统优先走IPv6、分流或网络适配器冲突 |
| DNS解析器 | 结果不应直接属于关闭VPN时记录的运营商DNS；应与VPN服务说明或VPN出口网络相符 | 仍显示真实运营商DNS，或结果与客户端保护策略不一致 | 系统自定义DNS、浏览器安全DNS、Android Private DNS、VPN隧道外解析 |
| WebRTC | 测试页不应暴露真实公网地址；局域网私有地址与真实公网IP要分开判断 | 出现关闭VPN时的真实公网地址 | 浏览器WebRTC候选地址、浏览器或扩展设置、VPN未覆盖浏览器流量 |
DNS的作用是把域名转换为IP地址；如果DNS查询绕过VPN，运营商或其他解析服务可能看到你访问的域名请求。VPN服务商的技术说明也提醒，手动指定第三方DNS、浏览器内置加密DNS或VPN连接中断，都可能改变原本的DNS路径。Proton VPN：DNS、第三方DNS与断线场景说明
WebRTC是浏览器用于实时音视频和点对点通信的技术。Mozilla说明，WebRTC在某些情况下可能让网站获得本地IP地址；MDN也指出，ICE候选地址可能暴露设备网络拓扑或地址信息。测试时要区分192.168.x.x、10.x.x.x等私有局域网地址与关闭VPN时的真实公网IP：前者不等于运营商公网IP泄漏，后者才是更需要优先排查的结果。Mozilla：WebRTC与本地IP暴露说明 MDN：RTCIceCandidate 地址与隐私说明
看到Cloudflare、Google或其他公共DNS，算不算泄漏
不一定。DNS测试显示的是解析请求实际到达或被识别到的解析器，不是简单的“名称越知名越安全”或“不是VPN品牌就一定泄漏”。判断时应同时对照四项：一是VPN关闭时的运营商DNS；二是VPN开启后的解析器所属网络；三是VPN客户端是否明确提供DNS防泄漏并说明使用哪类解析器；四是切换VPN服务器后结果是否随VPN路径变化。
- 明确异常：VPN开启后仍出现关闭VPN时的宽带、公司或移动运营商DNS，且IP路径也没有改变。
- 需要核实：显示Cloudflare、Google、OpenDNS等公共DNS，但VPN客户端文档没有说明是否通过隧道转发。此时不要直接宣布“安全”或“泄漏”，应先关闭系统和浏览器自定义DNS，再复测。
- 可能正常：解析器不属于你的真实运营商，且VPN服务商明确说明DNS请求通过VPN隧道处理；但不同客户端、协议和系统版本可能有差异，仍应以实际复测结果为准。
Android的Private DNS只能保护DNS问题本身，不能替代VPN，也不能保护其他网络流量；Google官方说明中还提示，不同Android版本和设备厂商的设置入口可能不同。Google Android帮助：Private DNS设置与作用
按设备排查：Windows、macOS、iPhone和Android怎么修复
- Windows：先打开VPN客户端设置，查找名称类似“DNS leak protection”“IPv6 leak protection”“Kill Switch”或“Block internet without VPN”的选项；具体名称和可用性以当前客户端页面为准。然后检查网络适配器是否手动填写了DNS，浏览器是否启用了独立的Secure DNS。Windows官方文档说明，DNS over HTTPS可以使用自动或手动模板，并且可以设置失败时是否回退到明文DNS；如果浏览器自行解析，VPN客户端的DNS保护可能无法按预期工作。Microsoft：Windows网络与DNS over HTTPS设置
- macOS：在系统网络设置中检查当前Wi-Fi或有线接口的DNS列表，暂时移除不确定来源的自定义DNS，再重新连接VPN测试。若安装过网络过滤、企业管理或其他VPN类软件，也应暂时停用冲突组件后复测。菜单名称可能随macOS版本变化，以系统搜索“DNS”“VPN”或“网络”显示的当前页面为准。
- iPhone：检查是否同时安装了多个VPN、DNS过滤或网络安全配置；iOS通常一次只能由一个VPN类配置实际接管流量。优先在当前VPN客户端内查找DNS防泄漏、IPv6保护和断线阻止网络的选项，不要仅凭状态栏出现VPN图标判断保护完整。若网络配置混乱，可先记录订阅或配置来源，再考虑系统网络设置中的重置选项；Apple提示，重置网络设置会删除已保存的Wi-Fi密码以及VPN和APN设置，因此应作为回退步骤而不是第一步。Apple支持：重置网络设置会清除的内容
- Android：检查系统“Private DNS”、浏览器Secure DNS以及VPN客户端的DNS设置是否同时生效。Google说明，Private DNS只保护DNS问答，不会保护其他网络流量；如果浏览器使用自己的Secure DNS，测试结果可能与系统解析路径不同。优先将不确定的自定义DNS改回自动或按VPN客户端文档设置，再复测。
修复后的验证标准：重新检查公网IPv4、IPv6、DNS和WebRTC四项；再关闭VPN确认基准是否仍能复现。只改一个设置、复测一次并记录结果，比一次同时更改多个选项更容易定位原因。
如何验证Kill Switch、切换服务器和断线保护
VPN泄漏不一定只发生在稳定连接期间，也可能出现在启动、切换服务器、网络切换或隧道短暂中断的瞬间。Kill Switch的目标是VPN断开时阻止网络流量，而不是让VPN永远保持连接；不同客户端的实现和命名可能不同，不能把某个菜单名称当成所有软件的通用功能。
- 先保存一个普通网页或测试页，确认VPN已连接并记录当前公网IP。
- 在客户端内查找并开启Kill Switch、Always-on VPN或类似断线阻止选项；如果没有该选项，不要自行假设客户端支持。
- 使用客户端的断开按钮或切换服务器，观察VPN断开到重新连接期间网页是否还能继续加载。
- 恢复连接后重新进行IP、DNS、IPv6和WebRTC测试。
- 如果断线期间仍能访问互联网且出现真实IP，优先关闭敏感应用，检查客户端是否支持全局阻断、是否存在分流规则，以及系统是否同时运行了其他VPN或代理。
测试网页只能观察浏览器发出的部分请求，不能证明所有应用、后台服务、种子客户端或企业软件都走同一条路径。因此，浏览器测试通过后，仍应在实际使用的应用内验证；如果是跨境办公，还要单独确认办公客户端、视频会议和文件同步工具的连接路径。
结果判定清单：什么情况可以继续用，什么情况要暂停
| 测试结果 | 判断 | 下一步 |
|---|---|---|
| 公网IP变为VPN出口；DNS不再显示真实运营商；无真实IPv6；WebRTC无真实公网IP | 浏览器层面的主要泄漏项目暂未发现 | 再做一次换服务器、断线重连和Wi-Fi/移动数据切换测试 |
| 公网IP已改变，但DNS仍是真实运营商 | 疑似DNS路径绕过VPN | 检查系统自定义DNS、浏览器Secure DNS、Android Private DNS和客户端DNS保护 |
| IPv4已改变，但出现真实运营商IPv6 | 疑似IPv6未纳入VPN或未被阻断 | 检查客户端IPv6保护；没有明确选项时向客户端文档核实，不要直接复制陌生配置 |
| 只出现192.168.x.x等私有地址 | 不能直接等同于真实公网IP泄漏 | 重点确认是否同时出现关闭VPN时的公网IPv4或IPv6 |
| 断线时网页仍可访问并显示真实IP | Kill Switch未启用、未覆盖当前流量或客户端不支持 | 开启可核实的断线阻止功能，或在敏感操作前手动断开网络 |
以上判断是网络排查标准，不是对任何具体VPN产品的安全承诺。客户端版本、系统版本、网络类型和浏览器设置都会影响结果；不能核实的按钮、字段和兼容性，应以当前产品文档及实际测试为准。
常见问题 FAQ
只查公网IP，能证明VPN没有DNS泄漏吗？
不能。公网IP只反映某个网页看到的出口地址，DNS测试观察的是域名解析请求到达了哪些解析器；IPv6和WebRTC也可能走不同路径。至少应同时检查公网IP、DNS解析器和IPv6，浏览器用途还应补做WebRTC测试。
DNS测试显示Cloudflare或Google，是不是一定泄漏？
不是。公共DNS名称本身不能证明泄漏。要对照VPN关闭时的运营商DNS、VPN客户端的技术说明以及开启VPN后的实际路径。如果不确定，先取消系统和浏览器中的自定义DNS，重新连接VPN后复测。
WebRTC测试显示局域网IP，是否说明真实IP已经泄漏？
不一定。192.168.x.x、10.x.x.x等通常是私有局域网地址，和运营商分配的公网地址不同。真正需要优先排查的是测试页是否显示关闭VPN时记录的公网IPv4或IPv6。
VPN连接成功但DNS测试仍显示原运营商，先改DNS还是换服务器？
先检查DNS路径配置，再换服务器。优先排除系统手动DNS、浏览器Secure DNS、Android Private DNS和其他VPN/过滤器冲突；只改一个设置并复测。如果仍显示原运营商，再换服务器观察结果是否变化。
测试通过后，VPN断开几秒还会泄漏吗？
有可能。稳定连接测试不能覆盖断线瞬间。应单独验证Kill Switch或断线阻止功能；如果断线期间仍能访问网页并显示真实IP，敏感操作前应先停止网络，或使用具备可核实断线保护的客户端功能。
DNS泄漏测试能代表所有应用都安全吗？
不能。测试网页主要观察浏览器流量，其他应用可能使用自己的解析器、代理、分流规则或独立网络权限。办公软件、视频会议、同步工具等应在实际场景中单独验证。
常见问题
只查公网IP，能证明VPN没有DNS泄漏吗？
不能。还要检查DNS解析器、IPv6和浏览器WebRTC，因为它们可能走不同的网络路径。
DNS测试显示Cloudflare或Google，是不是一定泄漏？
不是。公共DNS名称本身不能证明泄漏，应结合VPN关闭时的运营商DNS、客户端说明和复测路径判断。
WebRTC显示局域网IP，是否说明真实IP已经泄漏？
不一定。私有局域网IP与运营商公网IP不同，重点看是否出现关闭VPN时记录的真实公网地址。
VPN连接成功但DNS仍显示原运营商，怎么办？
先检查系统自定义DNS、浏览器Secure DNS、Android Private DNS和其他VPN/过滤器，再只改一个设置并复测。
测试通过后，VPN断开几秒还会泄漏吗？
有可能。应单独验证Kill Switch或断线阻止功能，稳定连接测试不能替代断线场景测试。
DNS泄漏测试能代表所有应用都安全吗？
不能。网页测试主要观察浏览器流量，办公、会议、同步等应用还需要在实际使用场景中单独验证。