VPN安⁠全吗？日志、DNS泄漏与加密自查指⁠南

VPN 是否安全，不能只看客户端界面上是否出现了“已连接”，也不能把“加密”直接等同于“完全匿名”。一次网络连接至少涉及本地设备、客户端内核、代理协议、DNS 解析、出口服务器以及目标网站多个环节。任何一层配置不当，都可能让真实 IP、访问请求或连接元数据暴露在不必要的范围内。

更实际的判断方法，是把安全拆成几个可以核对的问题：服务商是否说明日志政策，客户端使用了什么协议，DNS 请求是否经过预期通道，浏览器是否存在 WebRTC 泄漏，断线后系统是否会自动回落到普通网络，以及公共 Wi-Fi、网银支付和远程办公等场景是否采用了合适的分流策略。本文不承诺“绝对匿名”，而是提供一套可重复的自查顺序。

先看日志政策：无日志不是一句口号

“无日志”通常是用户最先看到的安全承诺，但这四个字本身不够具体。阅读隐私政策时，应当区分内容日志、连接日志、账户信息、支付记录和技术诊断数据。内容日志可能涉及访问过的域名或传输内容；连接日志可能包含连接时间、源 IP、分配到的出口、流量用量或会话状态；账户与支付信息则可能因为注册、退款、风控或法律要求而被保留。

一个更有价值的隐私政策，会说明收集哪些数据、收集目的是什么、保存多久、是否用于分析或广告、哪些第三方可以接触，以及用户如何申请删除或导出。若页面只写“绝不记录任何信息”，却没有解释账户登录、流量统计、故障排查和付款处理如何完成，表述就不够完整。没有日志并不等于服务端完全没有运行所需的临时状态，也不等于支付平台、操作系统或目标网站不会留下记录。

还要留意“为了改善服务而收集匿名数据”这类描述。匿名化、去标识化和完全不收集并不是同一个概念。设备型号、客户端版本、错误时间、网络运营商和地区等字段单独看似普通，组合后仍可能帮助建立使用特征。对隐私要求较高的用户，应确认诊断上报是否可以关闭，并检查客户端是否包含崩溃报告、分析工具或第三方统计模块。

• ✅ 先保存隐私政策的发布日期和关键段落，后续规则变化时便于对照。
• ✅ 区分“不会记录访问内容”和“不会保存任何连接信息”。
• ✅ 关闭不必要的崩溃报告、使用统计和个性化诊断。
• ❌ 不要因为页面出现“无日志”徽章，就跳过账户、付款和第三方处理说明。

看懂加密与协议：连接安全取决于组合

客户端中的协议名称，描述的是建立连接和传输数据的方式，并不单独代表整个隐私方案。Shadowsocks 是较常见的加密代理协议，生态成熟、客户端支持范围较广，但具体保护效果取决于加密方法、密钥管理和实现版本。VMess 常见于 V2Ray 生态，能够与不同传输方式组合，配置字段较多，客户端与服务端参数不一致时可能出现导入成功但握手失败的情况。

Trojan 通常依赖 TLS 传输，证书、域名、服务器时间和客户端校验都会影响安全性与可用性。VLESS 的设计较轻量，本身不提供完整的传输加密，通常需要配合 TLS、REALITY 或其他安全传输方式使用。Hysteria2 和 TUIC 基于 QUIC 与 UDP，在部分丢包或波动环境下可能采用不同于传统 TCP 的传输策略，但如果本地网络限制 UDP，连接就可能失败或频繁切换。

如果使用系统级 VPN 协议，还可能遇到 WireGuard、IKEv2/IPsec 或 OpenVPN 等方案。WireGuard 配置简洁、开销较低，适合移动设备和频繁切换网络的场景；IKEv2/IPsec 通常与系统网络设置结合较紧密，移动网络切换时的体验取决于客户端和服务端实现；OpenVPN 生态成熟，TCP 与 UDP 模式各有适用环境，但配置文件、证书和加密套件需要妥善管理。

自查时不要只问“用了哪一种协议”，还要问四个问题：客户端是否验证服务器身份，是否使用现代 TLS 配置，证书或密钥是否通过安全渠道下发，协议在断线与重连时是否会回落到其他不符合预期的配置。订阅链接本身也是敏感凭据，不能提交给来源不明的在线转换工具，也不应发布在截图、公开文档或共享群组中。

按场景选择协议与模式

• 日常网页和应用：优先使用官方客户端或经过验证的兼容客户端，保持协议与订阅配置自动更新，避免手动复制容易出错的长参数。
• 移动网络切换：关注 WireGuard、IKEv2 或客户端对网络变化的处理方式。切换 Wi-Fi 与蜂窝网络后，应确认隧道是否重新建立。
• 高波动网络：可以测试基于 QUIC 的 Hysteria2 或 TUIC，但先确认网络允许 UDP，并观察断线后是否自动恢复。
• 复杂分流：使用 Clash Verge、sing-box 或 Shadowrocket 时，必须确认规则、DNS 模式与代理模式彼此匹配，不能只导入节点而忽略全局设置。

DNS 与 WebRTC 泄漏：连接成功不代表信息没有外露

DNS 负责把域名转换为 IP 地址。启用代理后，如果浏览器或操作系统仍把 DNS 请求发送给本地运营商提供的解析服务器，访问过的域名可能暴露在代理通道之外，这就是常说的 DNS 泄漏。它不一定会让网页立即失效，却会让隐私保护出现缺口，也可能导致地区判断、内容分流或证书验证结果不符合预期。

DNS 泄漏的来源比较多：客户端采用了错误的 DNS 模式，系统的“安全 DNS”设置覆盖了代理规则，浏览器启用了独立的 DoH，IPv6 请求没有纳入隧道路由，或者分流规则把 DNS 查询发送到了本地网络。不同客户端对“远程 DNS”“Fake-IP”“真实 IP”“劫持 DNS”等术语的定义也不完全相同，因此不能只看一个开关的名称。

WebRTC 是浏览器用于音视频通信和实时连接的技术。为了建立点对点连接，浏览器可能收集本地网络接口、候选地址或映射后的地址。在特定浏览器、扩展和网络配置组合下，WebRTC 检测页面可能显示不希望公开的本地或公网地址。它与 DNS 泄漏不是同一个问题，解决其中一个并不会自动解决另一个。

测试时应使用可信的 IP 检测和 DNS 泄漏检测页面，并分别记录代理关闭、代理开启、切换线路、切换 DNS 模式四种结果。不要只看页面显示的出口国家，还要查看 DNS 服务器归属、IPv4 与 IPv6 结果，以及浏览器是否报告候选地址。测试页面本身可能更新检测方法，因此一次结果不能替代配置复核。

1. 关闭客户端，记录当前网络的出口 IP 与 DNS 服务器。
2. 开启客户端，等待连接稳定后重新检测出口与 DNS。
3. 切换到规则模式和全局模式分别测试，确认规则不会意外绕过 DNS。
4. 在浏览器中检查 WebRTC 候选地址，并确认 IPv6 是否被纳入预期路径。
5. 更换 Wi-Fi 或移动网络后再次检查，排除网络环境差异造成的误判。

配置 Kill Switch：重点防止断线回落

Kill Switch 通常译为网络阻断或断网保护。它的作用不是提升速度，而是在 VPN 隧道中断、客户端退出、线路切换或系统网络变化时，阻止指定流量直接回落到普通网络。对于需要避免短暂暴露真实出口的场景，这项功能比界面上的连接动画更重要。

不同平台的实现方式并不一致。Windows 和 macOS 客户端可能通过系统防火墙、网络扩展或路由规则实现；Android 通常可以在系统的 VPN 设置中找到“始终开启 VPN”与“阻止未使用 VPN 的连接”等选项；iOS 受系统网络扩展和应用权限限制，用户应优先使用支持断线保护的可信客户端；Linux 则可能需要 NetworkManager、WireGuard、OpenVPN 或 sing-box 等组件配合防火墙规则。

开启后不要立刻用于重要业务，先做可控测试。连接 VPN 后暂时停止客户端进程、切换网络或手动断开隧道，观察浏览器、终端和后台应用是否还能访问网络。若网页无法访问但本地局域网仍可用，可能是符合预期的阻断；若浏览器继续访问且检测到本地出口，则 Kill Switch 可能只覆盖了部分应用或只在全局模式下生效。

分流与阻断要一起检查

规则分流并不天然不安全。它可以让本地银行、打印机、公司内网或局域网设备保持直连，也可以避免所有流量都经过远程线路。但分流规则如果写得过宽，可能把需要保护的浏览器、同步工具或 DNS 请求排除在隧道之外。Kill Switch 如果只保护代理列表，同样可能无法覆盖被分流到直连的应用。

网银支付场景下，应优先使用银行官方应用或确认地址栏为 HTTPS 的网页，检查账户安全设置和多因素认证，不要把 VPN 当作支付安全的唯一措施。公共 Wi-Fi 场景下，开启自动连接保护和 Kill Switch，避免设备在隧道重建期间发送敏感请求。远程办公场景下，应先确认公司要求的 VPN、零信任客户端或证书认证，不要用个人代理配置替代组织规定的访问方式。

• ✅ 开启系统级断线保护，并确认它覆盖浏览器、终端和后台应用。
• ✅ 在 Wi-Fi、蜂窝网络和睡眠唤醒后分别测试自动重连。
• ✅ 规则分流只保留必要的直连范围，DNS 规则与路由规则保持一致。
• ✅ 为重要账户启用多因素认证，并在支付前检查网站域名。
• ❌ 不要同时运行两个会修改系统代理或默认路由的客户端。
• ❌ 不要为了恢复网页访问而直接关闭 Kill Switch，却忘记重新打开。

按使用场景完成一轮安全自查

安全设置需要与使用场景对应，而不是所有设备都固定采用全局模式。家庭设备数量较多时，可以在官方客户端中使用订阅链接一键导入，并为不同平台分别确认 DNS、IPv6 和断线保护选项。Windows、macOS、Android、iOS 与 Linux 的权限模型不同，同一份订阅在各平台的默认行为也可能不同，导入成功不代表所有安全选项已经启用。

公共 Wi-Fi 的主要风险是网络环境不可控。连接咖啡店、机场或酒店网络后，先确认网络名称，避免在未验证的门户页面输入敏感凭据；再开启可信客户端和 Kill Switch，最后检查出口与 DNS。完成网银操作或远程登录后，应主动断开会话，不要让浏览器长期保留开放的管理页面。

网银支付更重要的是端到端的账户保护。VPN 可以减少本地网络观察到的内容，但目标银行仍能看到登录设备、账户行为和风险特征。不要在公共设备上保存密码，也不要接受来源不明的证书或浏览器扩展。若银行系统因为出口地区变化触发验证，应按照银行的安全流程处理，不要反复切换线路绕过风控。

远程办公则要重点检查应用是否继承系统代理。部分桌面应用只读取系统代理，部分终端程序需要单独设置 HTTP、HTTPS 或 SOCKS5 代理，还有一些软件完全忽略系统代理。开启 Kill Switch 后，应测试会议、代码仓库、内部系统、邮件和文件同步是否都符合组织的访问策略。涉及公司数据时，优先遵守管理员提供的配置和日志要求。

最终检查清单：把“安全”变成可验证步骤

完成配置后，可以把自查结果记录下来：使用的客户端版本、导入的订阅来源、当前协议、DNS 模式、IPv4 与 IPv6 状态、WebRTC 检测结果，以及 Kill Switch 的断线测试表现。记录不需要包含订阅链接本身，尤其不要把完整链接、密码或私钥写入公开笔记。

如果检测发现 DNS 泄漏，先检查客户端 DNS 模式、浏览器 DoH、IPv6 路由和系统网络适配器；如果 WebRTC 暴露地址，检查浏览器设置与扩展；如果 Kill Switch 无效，确认客户端是否获得系统网络权限、防火墙规则是否被其他安全软件覆盖，以及当前使用的是全局模式还是规则模式。每次只修改一个变量，再重新测试，通常比同时更换协议、客户端和 DNS 更容易定位问题。

当服务商更新订阅或调整线路时，也应重新检查安全边界。配置文件新增协议、DNS 地址或规则后，旧的测试结果不一定继续成立。对于 Clash Verge、sing-box、Shadowrocket 等兼容客户端，导入后应查看实际生效的 DNS、路由和代理模式；不要仅凭节点列表存在，就认为所有应用已经经过预期通道。