为什么 VPN 适配器的名称可能掩盖另一种协议
适配器旁边的标签描述的是创建它的软件，而不是线上的数据包。在选择修复方案之前，请检查客户端、配置文件和通信对端。
VPN 适配器旁边的标签描述的是创建该接口的软件，而它比真正穿越网络的数据包高一层。插件可能显示一个适配器，其名称反映的是插件自身的分类，而不是线上的封装方式。阅读客户端、配置文件和通信对端，可以回答名称无法回答的问题。在设置菜单里看起来完全相同的两个连接，在抓包中可能表现截然不同。
名称来自提供商，而不是线路
Windows 为其内置 VPN 客户端定义了一份简短的连接类型列表，第三方产品则在一旁安装自己的协议栈。网络列表中出现的适配器由拥有该连接的驱动程序创建，因此它的名称是关于驱动程序的证据，而不是关于外层协议的保证。这也是卸载一个客户端后可能留下适配器名称的原因。
Microsoft 关于 VPN 连接类型的文档明确指出，类型描述的是客户端针对该连接的配置。当涉及插件时，显示的类型会跟随插件所注册的内容，而实际封装可能完全是另一回事。
同样的分层也出现在别处。Linux 主机上的虚拟适配器、TAP 设备或移动 VPN 服务扩展，都是由软件创建的接口，而接口名称由该软件选择，而不是与服务器协商。
端口和地址能告诉你什么、不能告诉你什么
每一层留下的证据各不相同。把它们分开来看，标签就不再是结论：
| Evidence | What it establishes | Where it misleads |
|---|---|---|
| Adapter name | Which driver bound the interface | Plugins choose their own labels |
| Profile file | Which client consumes the configuration | Abstraction layers hide the transport |
| Outer port | Which port the peer accepts | 443 carries several protocols plus HTTPS |
| Tunnel address | The inner interface's network | Says nothing about encapsulation |
TCP 443 是最清楚的例子。它可以承载 SSTP、OpenVPN TCP 隧道、SoftEther SSL-VPN 会话或普通网页流量，仅凭端口号无法区分它们。因此，允许 443 的防火墙规则并不能证明正在使用哪个客户端。在外层接口上抓包就能确定，而且几秒钟内就能确定。
阅读配置文件格式和对端
配置文件是比适配器更有力的线索。OpenVPN 配置文件包含 remote、proto 和 ca 等指令；WireGuard 配置包含带有私钥的 [Interface] 段和带有允许 IP 的 [Peer] 段；Windows 电话簿条目以自己的格式保存连接类型。每种语法都属于一种实现。
然后查看对端的文档和日志。服务器知道是哪个协议处理程序接受了该会话，其日志会写明完成的阶段。这一证据胜过任何桌面标签，因为它记录在数据包真正被解析的地方。
按协议而不是按标签选择手册
OpenVPN 指令属于 OpenVPN，WireGuard 的密钥和允许 IP 属于 WireGuard，而 SSTP 配置文件两者都不是。因为适配器名称听起来兼容，就把一个客户端的选项粘贴到另一个客户端里，正是把可用配置弄坏的方式。
一旦确定了协议，选择对应的故障排查路径：客户端自己的日志、服务器针对该协议的日志，以及显示外层交互的抓包。从那里起，故障有了名称，而不是一个标签。