连接咖啡店、酒店、机场或会议场所的公共 WiFi 时，VPN 可以降低部分网络窥探风险，但它不是“打开后所有数据自动安全”的开关。公共网络的风险不仅来自同一热点下的其他用户，还可能来自名称相似的仿冒热点、被篡改的 DNS、浏览器 WebRTC 暴露的真实网络信息，以及设备本身已经存在的恶意应用。
更准确的理解是：VPN 客户端会在设备与远端服务器之间建立加密通道，使公共 WiFi 运营者通常难以直接读取通道内的网页请求和应用流量；但连接建立前、连接中断时、VPN 未覆盖的流量，以及设备主动提交给网站或应用的数据，仍然需要单独检查。本文从识别公共网络隐患开始，逐步说明 VPN、DNS、WebRTC 与 Kill Switch 应该怎样验证。
公共 WiFi有哪些实际风险
公共热点最容易被忽略的问题，是用户往往只根据 WiFi 名称判断网络是否可信。机场、酒店和咖啡店可能同时存在官方热点、旧热点、员工网络与访客网络，攻击者也可能创建一个名称相近的热点，等待设备自动连接。名称中出现“Free”“Guest”或场所名称，并不能证明它一定属于运营方。
连接到错误的热点后，攻击者可能观察连接元数据、诱导用户访问仿冒登录页，或通过本地网络发现尝试寻找暴露的共享服务。现代网站普遍使用 HTTPS，这能降低网页内容被直接读取的风险，但它不会阻止用户主动打开钓鱼网站，也不能保证每个应用都正确验证证书。
另一类风险来自网络侧的 DNS。设备访问网站时，通常先把域名交给 DNS 服务解析。如果 DNS 请求仍然通过公共 WiFi 提供的解析服务器发送，网络运营者可能知道设备正在查询哪些域名，即使后续网页内容通过 HTTPS 加密。VPN 客户端通常可以把 DNS 请求一并送入隧道，但具体效果取决于客户端模式、系统权限和分流规则。
还要留意设备自身的网络设置。开启文件共享、网络发现、远程管理或自动连接未知热点，会扩大公共环境中的暴露面。办公电脑还可能安装企业安全策略、代理软件或证书管理工具；个人设备则可能同时运行多个代理客户端。多个程序争夺系统代理、路由或 DNS，常常会造成连接看似成功、实际流量绕行的情况。
| 风险来源 | 可能出现的现象 | 应对重点 |
|---|---|---|
| 仿冒热点 | 名称与场所相似，登录页要求输入额外信息 | 向工作人员确认名称，关闭自动加入未知网络 |
| 本地网络窥探 | 同一热点下出现异常设备发现或连接提示 | 关闭共享与网络发现，优先使用 HTTPS 和 VPN |
| DNS 泄漏 | VPN 已连接，但解析请求仍由公共网络处理 | 检查 DNS 服务器来源与客户端的 DNS 接管设置 |
| WebRTC 泄漏 | 浏览器测试页显示本地或公网地址信息 | 检查浏览器权限、扩展和客户端的 WebRTC 处理方式 |
| 隧道中断 | VPN 断开后网页仍可继续访问 | 开启 Kill Switch，并验证断线时是否阻断流量 |
VPN 保护了什么，没保护什么
VPN 连接成功后，客户端通常会创建虚拟网络接口，并把符合规则的流量封装后发送至远端服务器。公共 WiFi 看到的主要是设备与远端服务器之间的加密连接，而不是完整的目标网站请求内容。对于需要在陌生网络中访问普通网页、同步文件或使用应用的场景，这能减少本地链路上的直接窥探机会。
不过“已连接”不等于“所有流量都经过 VPN”。有些客户端默认使用规则分流，只有匹配特定域名或地址的请求进入隧道；有些应用使用自己的网络栈，可能不遵守系统代理；还有些系统服务会在 VPN 连接建立前进行联网。分流本身并非错误，它可以让本地服务保持正常，但使用公共 WiFi 时应清楚哪些流量被排除在外。
HTTPS 与 VPN 解决的是不同层面的问题。HTTPS 主要保护浏览器或应用与目标网站之间的连接，VPN 主要保护设备到 VPN 服务器之间的路径。两者可以同时使用，也不应互相替代。若网站本身是恶意页面，VPN 不会把它变成可信页面；若用户主动把密码输入仿冒页面，加密通道也不会阻止数据被提交给该页面。
协议名称也不能直接等同于安全等级。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 WireGuard 可能出现在不同客户端或订阅中，但最终安全性还取决于客户端来源、配置是否匹配、系统是否及时更新、证书验证是否正常，以及客户端是否正确接管 DNS 和断线策略。不要因为某条线路使用熟悉的协议名称，就跳过实际验证。
- ✅ 连接公共热点后，先确认 VPN 客户端状态确实为已连接。
- ✅ 查看当前模式是全局、规则分流还是系统代理，并确认重要应用属于哪一类。
- ✅ 保持浏览器地址栏的 HTTPS 与证书警告检查，不忽略“连接不安全”提示。
- ✅ 关闭局域网共享、网络发现和不需要的远程管理功能。
- ❌ 不要把 VPN 当作防病毒软件，也不要用它替代账户多因素认证。
- ❌ 不要在公共热点中公开复制订阅链接、密码或恢复代码。
连接与自查的实际操作步骤
下面的操作适用于 Windows、macOS、Android、iOS 和 Linux 上的常见 VPN 客户端。不同系统的按钮名称可能略有差异，但检查逻辑相同：先确认网络，再建立隧道，随后验证出口、DNS、WebRTC，最后测试断线保护。建议第一次在不涉及敏感账户的页面上完成测试，不要一边修改配置一边登录银行、企业后台或主要邮箱。
先确认热点和设备设置
- 向场所工作人员确认官方 WiFi 名称、登录方式和是否需要浏览器认证。不要仅凭名称相似就连接。
- 连接后先完成必要的网页认证，但不要在陌生页面输入与 WiFi 无关的邮箱密码、支付密码或身份信息。
- 将系统网络设置为关闭自动加入未知热点，并暂时关闭文件共享、网络发现和不必要的局域网服务。
- 确认设备当前没有同时运行两个 VPN、代理或网络过滤客户端。若存在冲突程序，先停用不需要的那一个。
- 打开官方客户端，检查配置来源、订阅更新时间和当前线路是否正常，避免使用不明来源的安装包或配置文件。
建立连接并确认覆盖范围
客户端连接后，先查看系统是否出现 VPN 图标或虚拟网络接口，再打开一个普通 HTTPS 网站确认网络可用。不要只看客户端界面上的“已连接”字样，还应检查客户端的流量统计、连接日志或路由模式。若客户端支持“全局模式”“规则模式”和“直连模式”，公共 WiFi 场景下应明确当前使用哪一种。
在规则分流模式下，建议先确认 DNS 请求是否跟随隧道，以及浏览器和主要应用是否命中预期规则。若某个应用依然显示网络不可用，可能是它使用了不受系统代理影响的连接方式，也可能是该应用需要局域网访问。不要为了让单个应用恢复连接就盲目关闭所有保护，先记录它所需要的地址和端口，再调整最小范围的规则。
检查 DNS 是否泄漏
DNS 泄漏的核心问题不是“使用了哪个 DNS 品牌”，而是请求是否在不知情的情况下绕过 VPN，交给了公共 WiFi 的解析服务器。检查时可以使用可信的 DNS 检测页面，观察检测结果中的服务器归属、网络提供方和地区信息。若 VPN 已连接但结果明显显示为当前酒店、机场或咖啡店网络，说明 DNS 接管可能没有生效。
发现异常后，先在客户端中寻找“DNS 防泄漏”“远程 DNS”“通过代理解析”或类似选项，再检查系统是否启用了私有 DNS、加密 DNS、手动 DNS 或其他网络过滤应用。多个 DNS 机制同时工作时，结果可能与预期不同。修改后应断开并重新连接 VPN，再清理浏览器缓存或重启相关应用进行复测。
检查 WebRTC 暴露的信息
WebRTC 是浏览器用于实时音视频通信的功能，浏览器可能通过它获取网络接口信息，以帮助建立点对点连接。VPN 并不自动保证 WebRTC 不会披露地址，具体表现取决于浏览器版本、权限、扩展和客户端处理方式。使用可信检测页面查看结果时，应关注是否出现与当前真实网络有关的本地地址或公网地址，而不只看网页是否显示“VPN 已连接”。
如果发现不希望暴露的信息，先检查浏览器是否允许不必要的网站访问摄像头、麦克风和本地网络，再查看浏览器或企业策略是否限制 WebRTC。不要随意安装来历不明的“防泄漏”扩展，因为扩展本身可能读取浏览记录或修改网页内容。完成设置后，用不同浏览器或隐私窗口复测，并记下哪些应用需要 WebRTC，避免影响正常的视频会议。
测试 Kill Switch
Kill Switch 通常译为网络锁或断线保护。它的目标是：VPN 隧道意外断开时，阻止指定流量继续通过普通网络发送，从而避免连接在不知情的情况下回落到公共 WiFi。不同客户端的实现方式可能不同，有的阻断全部外网流量，有的只阻断 VPN 应覆盖的流量，有的还允许局域网访问。
- 先连接 VPN，并打开一个不涉及敏感信息的网页确认正常访问。
- 在客户端中开启 Kill Switch、网络锁或断线保护，并阅读它是否允许局域网连接。
- 使用客户端提供的断开方式，或暂时切换网络来模拟隧道中断。
- 观察浏览器和应用是否停止外网访问，而不是悄悄改走普通 WiFi。
- 恢复 VPN 后，再确认 DNS、网页访问和需要局域网的功能是否恢复正常。
客户端与网络的选择要点
在 Windows 和 macOS 上，优先使用能够明确显示连接状态、DNS 设置、分流模式和 Kill Switch 状态的客户端。需要导入订阅时，应使用服务面板提供的客户端或兼容客户端，并确认订阅格式与协议支持范围。Clash Verge、sing-box、Shadowrocket 等工具的配置方式并不完全相同；一个客户端能读取订阅，不代表它能运行其中全部协议。
在 Android 和 iOS 上，应特别留意系统的 VPN 权限、始终开启 VPN、阻止无 VPN 连接等选项。系统可能只允许一个 VPN 配置生效，切换客户端后，旧配置仍可能占用权限。iOS 的系统 VPN 状态标识只能说明某个 VPN 配置正在工作，仍需在客户端中确认线路、模式和 DNS 行为。Android 设备则要检查省电策略是否会在后台暂停客户端。
Linux 用户通常会在 NetworkManager、系统路由、浏览器代理与命令行工具之间切换。若使用 sing-box、WireGuard 或其他核心，应检查默认路由、策略路由和 DNS 服务的实际状态，不要只依据终端程序输出判断所有应用都已接管。企业网络还可能要求使用特定代理或证书，修改前应遵循组织安全政策。
| 使用方式 | 适合的保护重点 | 容易忽略的问题 |
|---|---|---|
| 官方客户端 | 权限申请、线路切换、断线保护较直观 | 默认分流与 DNS 选项可能隐藏在高级设置中 |
| Clash Verge | 规则、代理组和模式切换较灵活 | 系统代理开启不代表所有应用都遵守代理 |
| sing-box | 路由、DNS 与协议组合可精细配置 | 配置错误时较难从界面直观看出实际路径 |
| Shadowrocket | 移动端可快速导入配置并按规则分流 | 系统权限、按需连接与规则命中情况需要复核 |
- ✅ 使用前更新系统、浏览器和客户端，删除长期不用的网络配置。
- ✅ 为公共网络建立独立的使用习惯，不自动打开共享和网络发现。
- ✅ 重要账户优先使用多因素认证，并通过书签或官方应用进入服务。
- ✅ 离开场所后忘记该 WiFi，避免设备下次自动连接。
- ❌ 不要把“有密码的热点”直接当作可信热点。
- ❌ 不要在公共网络中安装临时推荐的证书、远程控制程序或未知配置文件。
公共 WiFi 与 VPN常见问题
连接公共 WiFi 后必须一直开启 VPN 吗？
如果需要使用该公共网络，建议在完成热点认证后再连接 VPN，并在退出 VPN 前确认已经切换到可信网络或移动数据。是否长期开启取决于自己的分流需求，但在陌生网络中，保持断线保护和 DNS 防泄漏通常比只看连接速度更重要。
VPN 已连接，还需要检查 HTTPS 吗？
需要。VPN 不能证明目标网站真实可信，也不能阻止用户主动把信息提交给仿冒页面。访问登录、支付或企业服务时，应检查域名、HTTPS 和证书警告，并尽量通过官方书签或应用进入。
DNS 没有泄漏，是否就代表完全安全？
不是。DNS 检查只说明域名解析路径的一部分，不能覆盖恶意软件、钓鱼网站、WebRTC、应用绕过代理或 VPN 断线回落等问题。安全自查应结合热点确认、设备设置、WebRTC 检查和 Kill Switch 测试。
Kill Switch 开启后无法上网，是不是配置错误？
不一定。网络锁的正常行为就是在 VPN 不可用时阻断受保护流量。先确认隧道是否真正建立、客户端是否获得系统 VPN 权限，再检查是否允许局域网访问。若恢复 VPN 后仍无法联网，可以重启客户端和网络接口，并检查是否存在其他代理或 VPN 程序冲突。