VPN 流量包和包月哪个好？按使用量算清楚

VPN 安全并不是打开开关后就自动完成的结果。VPN 通常会在设备与所选节点之间建立加密通道，改变对外可见的网络出口，但它不能替代 HTTPS、密码管理、系统更新和账号安全设置。服务商是否记录连接元数据、客户端是否正确接管 DNS、浏览器是否通过 WebRTC 暴露地址，都会影响实际隐私效果。本文从日志、加密、DNS、WebRTC 和日常使用场景出发，整理一套可以自行执行的检查方法。

判断安全性时，应把“服务商能看到什么”“本地网络能看到什么”“目标网站能识别什么”分开。VPN 可以降低公共 Wi-Fi 或本地网络直接观察访问目标的机会，但节点运营方仍可能处理经过服务器的连接；网站也仍然可以通过账户、Cookie、浏览器存储和用户主动提交的信息识别访问者。只有先明确保护对象，再检查配置和政策，测试结果才有意义。

先分清 VPN 能保护什么

连接 VPN 后，本地网络通常只能看到设备与 VPN 节点之间的连接，而不是直接看到所有目标网站的完整访问关系。对公共 Wi-Fi 来说，加密通道可以降低同一网络中的其他设备直接读取传输内容的风险；对家庭宽带或办公网络来说，网络管理员可能仍能看到设备正在连接某个 VPN 服务，以及连接时间和传输规模。

这并不意味着目标网站完全不知道用户是谁。只要在浏览器中登录账号，网站仍可以把当前访问与账号资料、Cookie、历史会话和设备特征关联起来。支付平台、邮箱和企业系统通常还会结合登录地点、设备变化、验证记录等因素判断风险。更换 VPN 出口只能改变网络层面的地址，不会清除应用层身份。

还要区分 VPN 协议与线路类型。Shadowsocks、VMess、Trojan、Hysteria2 和 WireGuard 主要描述客户端与服务端如何建立连接、认证和传输数据；直连、中转、BGP 或 IEPL 专线则描述网络路径。协议本身不能保证服务商不记录日志，专线也不能自动修复 DNS 配置错误。使用 Clash Verge、sing-box、Shadowrocket 或官方客户端时，都应检查客户端是否真正接管了预期流量。

用观察者模型确定风险

如果主要担心公共 Wi-Fi 中的窃听，重点是确认客户端启用了加密隧道、HTTPS 网站没有证书警告，并且断线时不会悄悄回落到普通网络。如果主要担心服务商保存连接记录，就要阅读隐私政策、服务条款和诊断数据说明。如果主要担心网站建立身份关联，则应检查登录状态、Cookie、浏览器配置和应用权限。不同问题需要不同措施，不能用一个“无日志”标签回答全部问题。

• ✅ 先写清楚要防范的是公共网络、运营商、服务商还是目标网站。
• ✅ 把 VPN 隧道、HTTPS、账号安全和设备安全分别检查。
• ❌ 不要把更换出口地址理解为清除网站账号、Cookie 或浏览器指纹。
• ❌ 不要仅凭节点名称、协议名称或测速结果判断隐私水平。

无日志政策怎么核对才有意义

“无日志”不是一个统一的技术标准。有些服务只承诺不保存访问内容，却可能保留连接时间、节点选择、流量用量、错误信息或客户端版本。有些数据只在内存中用于运行，有些则可能写入持久化日志。阅读政策时，应优先寻找具体的数据类别、使用目的、保存方式、保留期限和删除机制。

活动日志与连接元数据需要分开判断。活动日志可能包含访问目标、DNS 查询或传输内容，能够更直接地描述网络行为。连接元数据则可能包括连接建立时间、断开时间、所选地区、流量统计和故障代码。即使这些数据不包含网页正文，如果它们长期与账户绑定，也可能形成使用轨迹。

审计、透明度报告或公开承诺可以作为参考，但不能替代完整阅读。报告可能只覆盖节点系统，而不包括官网账户、支付流程、客户端崩溃数据或订阅系统。还要留意报告的检查时间、适用范围和是否包含当前版本。若服务商提供无需邮箱地址的注册方式，用户仍需为用户名、密码和订阅链接做好单独保护，信息收集较少不等于凭据泄露后没有影响。

加密、协议与客户端模式要分别检查

加密通常包含两个层面：设备到节点之间的隧道加密，以及浏览器或应用与目标服务器之间的 HTTPS 或其他应用层加密。VPN 隧道可以降低本地网络直接查看传输内容的机会，但当流量离开节点后，目标网站是否继续使用 HTTPS 仍然重要。访问支付、邮箱和工作系统时，应确认地址栏使用 HTTPS，并留意证书错误、异常跳转和浏览器安全警告。

WireGuard 采用现代密码学设计，配置结构相对简洁；Shadowsocks 更接近加密代理，是否覆盖所有应用取决于客户端的系统代理、虚拟网卡或透明代理模式；VMess 和 Trojan 常见于兼容客户端生态，具体安全性还与传输层、认证和服务端配置有关；Hysteria2 使用基于 UDP 的传输思路，遇到网络环境限制时需要检查客户端和服务端是否同时支持。不能因为协议名字听起来更先进，就跳过权限、传输方式和分流检查。

官方客户端一般会把账户、节点和系统隧道整合在一起；Clash Verge、sing-box、Shadowrocket 等兼容客户端则可能需要用户手动导入订阅并选择代理模式。导入订阅只表示客户端读到了配置，不代表系统已经启用代理。全局、规则和直连模式的流量范围不同，规则未命中的域名可能直连，虚拟网卡模式也可能受到系统权限和其他网络工具影响。

连接后应执行的客户端自查

1. 确认客户端来自服务商正式下载入口或官方应用商店，并检查应用名称和开发者信息。
2. 连接后查看系统代理、VPN 配置或虚拟网卡状态，确认不是只有客户端界面显示“已连接”。
3. 分别检查浏览器、桌面应用和需要特殊网络权限的应用，确认分流规则符合预期。
4. 断开 VPN 后重新访问测试页面，确认系统代理、DNS 设置和虚拟网卡能够恢复。
5. 更换 Wi-Fi 或移动网络后重新连接，观察是否出现旧线路残留、重复代理或异常权限提示。

不要同时运行两个系统级 VPN、两个虚拟网卡客户端或多个会接管 DNS 的工具。它们可能互相覆盖系统代理、路由表和解析器配置，造成“浏览器能访问、其他应用失败”或“断开后仍然无法联网”。排错时一次只改变一个变量：先固定客户端和协议，再更换线路；先确认隧道，再检查分流。

DNS 与 WebRTC 泄漏的检测和修复

DNS 泄漏指设备的域名查询没有按照预期经过 VPN 保护路径，而是交给了本地运营商、公共 Wi-Fi 或系统中其他解析器。即使网页内容通过 VPN 传输，DNS 查询仍可能暴露访问过的域名类别。出现泄漏的原因可能包括系统 DNS 优先级、客户端分流规则、浏览器安全 DNS、IPv6 配置或其他网络软件残留。

检测时应在未连接和已连接两种状态下分别记录 DNS 解析结果，再在更换线路后重复检查。不要只看网页显示的出口地址，还要查看 DNS 服务商或解析位置是否符合当前连接预期。检测网站的结果只能作为线索，无法证明所有应用都没有泄漏；某个浏览器通过自己的 DNS 机制解析，不代表系统中的邮件、游戏或同步应用也使用同一路径。

WebRTC 是浏览器用于实时音视频通信的技术。为了建立点对点连接，浏览器可能收集网络接口和候选地址信息。在某些浏览器、系统和客户端组合中，页面脚本可能看到与 VPN 出口不同的地址。WebRTC 地址暴露与 DNS 泄漏不是同一问题，修复其中一个并不会自动修复另一个。

• ✅ 连接前后分别检查出口地址和 DNS 解析来源，保存结果用于对比。
• ✅ 在浏览器设置中查看安全 DNS、WebRTC 和站点权限选项。
• ✅ 检查 IPv6 是否被客户端完整支持；若不支持，按客户端说明处理，而不是随意修改系统网络。
• ❌ 不要把陌生的在线“修复工具”当作安全方案，更不要向其提交订阅链接。
• ❌ 不要在检测页面中登录敏感账号或复制真实支付信息。

修复 DNS 问题时，优先使用客户端提供的 DNS 防泄漏、隧道 DNS 或阻止直连选项，并在修改后清理系统 DNS 缓存、重新连接再测试。修复 WebRTC 时，应采用浏览器自身提供的隐私设置或受信任的企业策略；如果只是为了临时测试，不要安装来源不明的扩展。启用浏览器安全 DNS 也不等于 VPN DNS，仍需确认它会不会绕过系统隧道。

公共 Wi-Fi、支付与账号登录的防护清单

公共 Wi-Fi 场景中，首先确认网络名称和登录页面没有明显仿冒迹象。连接后再启动可信客户端，避免在 VPN 尚未建立时打开邮箱、支付或企业后台。客户端若提供网络锁、断线保护或阻止无隧道流量的选项，应先了解它的触发范围，并用断开连接的方式验证，而不是只看设置名称。

支付时，VPN 不能替代支付平台的风控和设备安全。应直接从官方应用或手动输入已确认的地址进入支付页面，检查 HTTPS、收款方和金额。不要在公共电脑上保存银行卡信息，也不要把支付验证码、恢复代码或客户端订阅链接发送给客服以外的陌生人。若支付平台因为出口变化要求额外验证，应按照平台流程处理，不要连续切换多个地区来规避验证。

登录邮箱、云盘和企业账号时，应使用独立且不重复的密码，并优先开启多因素认证。首次在新设备或新出口登录，平台可能触发安全提醒，这是正常的风险控制表现。完成登录后检查活跃会话和已授权应用，撤销不再使用的令牌。浏览器隐私模式只能减少本地历史记录，不能隐藏登录身份，也不能阻止目标网站处理账户数据。

常见问题

VPN 写着无日志，就完全不会留下记录吗？

不能这样理解。应继续查看连接元数据、故障诊断、账户系统、支付服务和第三方分析工具的说明。“无日志”需要结合具体定义和适用范围判断，不能只看宣传标题。

VPN 加密后还需要 HTTPS 吗？

需要。VPN 主要保护设备到节点这一段路径，节点离开隧道后仍要依靠目标网站的 HTTPS 保护应用层通信。尤其是支付、邮箱和企业系统，不应因为已连接 VPN 就忽略浏览器的证书和地址检查。

DNS 泄漏一定代表 VPN 不安全吗？

它说明当前 DNS 请求路径可能没有按预期进入隧道，但原因可能来自客户端模式、系统配置、IPv6、浏览器安全 DNS 或其他网络工具。先确认泄漏范围，再按客户端说明修复，不能只更换节点。

关闭 WebRTC 就能解决所有隐私问题吗？

不能。WebRTC 只涉及浏览器实时通信可能暴露的网络候选地址。DNS、Cookie、登录账号、应用遥测和服务端日志属于其他观察面，需要分别检查和管理。