验证 VPN 时同时检查 IPv4 与 IPv6
检查 VPN 时同时观察 IPv4 与 IPv6，记录预期路由，区分不支持和连接失败，避免仅凭一次测试下结论。
由 Codex editorial review 从英文翻译
连接 VPN 后，公网地址页面可能显示了不同的 IPv4，但仍留下一个重要问题：应用使用 IPv6 时会怎样？许多日常连接能够使用不止一种地址族，而有些网络只提供一种。有用的验证既要检查实际可用能力，也要了解所选配置原本应如何工作。目的不是到处强行开启 IPv6，也不是一律禁用它，而是避免把一次成功请求当成设备所有可能路径的完整说明。
先明确 IPv6 测试的预期结果
确认客户端与配置是应当承载 IPv6、阻止它从隧道外传输，还是采用其他有文档说明的安排。这些是不同策略。在一种配置下，没有 IPv6 结果可能符合预期，在另一种配置下则可能是故障。不了解设计行为，就很难解释测试结果。
端点地址与隧道内部流量也是不同概念。通过 IPv4 地址连接 VPN 服务器，本身并不能说明隧道支持哪些地址族。同样，看到 IPv6 端点，也不能证明之后所有应用都使用 IPv6。能力取决于完整配置和所在网络。
修改之前先阅读协议与客户端说明。VLESS 与 WireGuard 对比有助于识别正在测试的连接类型，但协议名称本身并不等于路由策略。记录应用、版本、所选配置，以及是否启用了分流或本地例外。
确认普通网络本身提供什么
在适合不连接 VPN 进行非敏感对比的情况下，确认底层网络的 IPv4、IPv6 或两者是否可用。不要仅仅为了获取基线而断开必须使用的工作隧道，或暴露敏感活动。如果策略不允许比较，应记录这项限制，并向管理员询问获准的方法。
使用分别报告两种地址族的诊断工具。只显示一个地址的页面，可能只是采用了最先可用的路径。IETF 的 Happy Eyeballs 规范解释了应用如何尝试替代地址或地址族，以减少连接等待。这有利于使用体验，但也意味着页面成功打开，不一定证明两条路径都能用。
让观察结果对应实际网络。家庭 Wi-Fi 的结果不能代表移动数据，通过手机共享上网的笔记本，也不一定等同于提供连接的手机本身。记录接入方式和时间。如果测试说 IPv6 不可用，不要为了填满表格而虚构地址，也不要把缺失直接归类为泄漏。
隧道启用后重复同样的观察
连接预定配置，在同一设备和应用中发起新请求。分别记录 IPv4 结果，以及可用时的 IPv6 结果。失败应如实记录为失败，不要因为另一个页面偶然打开就忽略它。在对比过程中保持端点选择不变。
浏览器测试测量的是浏览器请求。如果另一个应用也很重要，应使用适合它的诊断方式，或向客服询问。例外规则、系统代理和应用专属网络行为都可能改变覆盖范围。VPN 状态检查指南解释了为什么“已连接”标记只是起点，不能证明之后每次连接都符合预期。
如果本应使用保护路径的位置，看起来却显示了普通网络提供商的地址，在确认策略之前，停止用这套配置处理敏感任务。私下保留观察并准确描述。不要在地址测试旁公开完整配置或密钥。客服通常先需要客户端信息和预期行为，而不是秘密访问材料。
比起国家标签，更认真解读地址
地址查询可能给观察到的地址附上组织或国家名称。这些标签可以提供背景，却不是对物理位置的最终测量。不同数据库可能意见不一，同一服务相关的 IPv4 与 IPv6 结果也可能被归到不同位置。
验证路由时，应将观察到的地址与提供商对该配置的预期相比较。地理位置表现则应另作一个问题处理。VPN 国家与网站语言一文解释了为什么网站的语言偏好无法独自解答它。俄语界面或英语搜索页，不能代替地址族检查。
建立一个包含四项的简单记录：普通 IPv4、普通 IPv6、隧道内 IPv4、隧道内 IPv6。明确标注不可用或尚未测试的项目，并在下方写出预期策略。这种格式便于区分不支持某地址族、意外直连路径和地理标签分歧，而不把三者一概归为“VPN 坏了”。
不要靠猜测配置字段来修复路由
不要仅因论坛示例里出现了某条大范围路由，就添加或删除它。例如，Android VPN 文档分别说明了覆盖全部 IPv4 和 IPv6 目标的路由。它们决定哪些目标进入虚拟接口，并不是可以在不理解整体配置时随意复制的装饰性文字。
手动导入配置文件也需要同样谨慎。修改路由可能影响 DNS 可达性、本地服务和重新连接能力。安全保存原先可用的文件，并使用提供商针对该客户端支持的配置。绝不要为了询问某一行是否正确而公开整份配置。
如果受支持的方案有意阻止不可用的地址族，应通过文档规定的客户端控制项验证。直接在整个操作系统或路由器上禁用 IPv6，可能影响无关应用和其他用户。只有在理由明确且具有相应权限时才这样做，不要把它作为处理某一个网站异常结果的通用办法。
接入网络变化后重新检查
昨天 Wi-Fi 上的结果，不能保证今天移动网络中有同样表现。客户端重大更新、配置替换或常用接入方式改变后，重复这项小范围观察即可。没有必要对未变动的配置无限测试；重点应放在可能改变可用路径的切换上。
如果问题仍未解决，向 Lumeraya 帮助中心提供客户端版本、网络类型、预期策略和两种地址族的独立结果。说明是否能够获得未使用 VPN 的基线。报告不要包含私钥；如果只测了一个应用，也不要声称所有连接都故障。
清楚的双栈检查应得出有边界的结论：观察到的 IPv4 路径符合预期，IPv6 也符合预期或按设计不可用，尚存的不确定性已标明。这比一个让人放心的地址更有用，因为它将结果与真实配置及想保护的流量联系起来。