VPN 的宣传页面大同小异：军用级加密、零日志、全球节点。这些词本身无法验证。更有用的做法是把判断拆成具体的技术问题，每个问题都有一个可以核对的答案。下面 10 个问题按四类整理，可以当作发给服务商的清单，也可以自己动手验证。
协议与加密
1. 支持哪些协议，默认用哪一个
应该能明确说出协议名称和版本，例如 WireGuard、OpenVPN、IKEv2。“自研高速协议”但没有文档、没有公开实现的，属于需要警惕的答案，因为密码协议的安全性靠公开审查积累，不靠保密。
2. 加密套件是什么，是否有前向保密
要问到具体算法（如 ChaCha20-Poly1305、AES-256-GCM）和密钥交换方式（如 Curve25519），并确认会话密钥会定期轮换。有前向保密意味着事后泄露长期私钥，也解不开以前的流量。
隐私与日志
3. 日志策略写得具体吗
可信的策略会列出具体字段和保留时间，例如“不记录目标地址和源 IP，仅保留当前在线连接数用于限制设备数”。只写“零日志”三个字、没有解释计费和限设备数依赖什么数据的，说服力较弱。
4. 有没有独立审计，审计覆盖什么
第三方审计报告应该能公开获取，并标明审计对象是服务器配置、客户端代码还是日志策略，以及审计时间。一份三年前、只覆盖官网的报告，不能代表今天的服务。
5. 账号、支付和连接之间能否被关联
要问清楚服务商手上有哪些可以把真实身份和流量连起来的数据，例如邮箱、支付记录、连接时间。架构上把认证和转发分开、使用无身份凭证的设计，比“我们不看”的承诺更可靠。
泄露防护
6. DNS 查询是否全部走隧道
要求客户端在连接时把系统 DNS 切到隧道内解析器，并处理多网卡并行查询。自己验证可以用抓包观察物理网卡的 53 端口。
7. IPv6 怎么处理
正确的答案是“隧道同时承载 IPv6”或“明确阻断 IPv6”，不应该是没有处理。连接后用 curl -6 验证。
8. Kill Switch 工作在哪一层
工作在防火墙规则层的方案能在客户端进程崩溃时仍然阻断流量，只靠应用内检测断线再关网络的方案，在进程被结束时不会生效。这两种写法在宣传页上往往都叫 Kill Switch。
网络与运维
9. 出口地址是共享的还是独享的，如何变更
共享出口意味着同一个地址上有很多用户，这对匿名性有利，但他人的行为会影响地址声誉。独享地址则相反。要明确地址多久更换一次，以及是否可以自选。
10. 客户端和服务端的可验证程度
客户端代码是否开源、构建是否可复现、支持的平台和系统版本范围，这些直接决定了你能不能核对客户端真的按文档工作。
答案质量对照
| 问题类别 | 值得信的答案 | 需要警惕的答案 |
|---|---|---|
| 协议 | 明确名称、有公开实现 | “自研协议”且无文档 |
| 日志 | 列出字段与保留期 | 只写“零日志” |
| 审计 | 近期第三方报告，范围明确 | 报告过时或只覆盖官网 |
| 泄露防护 | DNS、IPv6、防火墙级 Kill Switch | 不说明实现方式 |
| 出口地址 | 说明共享或独享及更换策略 | 只对“节点数量”做宣传 |
怎么用这份清单
不需要每一项都满分。先确定自己防的是公共 Wi-Fi、运营商还是服务商本身，再把对应类别的问题排到前面。服务商对具体技术问题的回答方式本身也是一个信号：能给出细节和文档的，比只给营销文案的更值得继续评估。
