如何判断一个 VPN 客户端是否真正支持 SSTP

把某个产品称作 VPN 客户端，并不能说明它是否会说 SSTP，地址里的 443 端口更证明不了什么。SSTP 先是在 TCP 443 上跑 TLS，然后是一次 SSTP 控制交换，再是为链路本身准备的 PPP，最上面还有证书校验和一种 PPP 认证方式。只有当所声称的实现、在已安装的版本下，按你的服务器要求跑通上面每一层，这个客户端才算支持该协议。按下面的顺序逐项检查，遇到第一个不通过的就停下，因为那才是值得解决的问题。

对齐实现、版本与平台

先从平台、应用程序和已安装的构建版本入手，因为同一个厂商名号可能落在两套完全不同的实现上。内置的 VPN 类型与第三方客户端不是一回事，而某个插件显示的适配器名称，也未必描述它底下的协议。当前版本的文档描述的并不是你眼前这台机器上运行的构建。请读对应版本的页面，再拿它与客户端自报的信息对照。

在 Windows 上，隧道类型由平台决定而不是由图形界面决定，所以要问平台。当原生客户端准备尝试该协议时，Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress 会给出 Sstp，而 连接类型参考也把它列入内置隧道类型。Linux 根本没有原生 SSTP 客户端，于是问题就变成：sstp-client 软件包里那种独立实现（例如 sstpc）是否已安装、是否够新。

先读配置文件格式，再看标签

配置文件之间不能互换，而别人递给你的那个文件通常比任何功能清单都更快地把问题定性。OpenVPN 指令、WireGuard 密钥和 SSTP 连接参数描述的是三种互不相干的协议，没有任何导入对话框能把一种变成另一种。共用 TCP 443 端口说明不了任何问题，因为 SSTP、基于 TLS 的 OpenVPN 和普通 HTTPS 服务可以占用同一个端口，而在它之上毫无共同之处。

如果这个文件是 .ovpn 或 WireGuard 配置，答案已经摆在桌面上了：没人要求那个客户端去说 SSTP。把它导入只做 SSTP 的客户端，会在配置文件这一步就失败，远在任何协议协商开始之前。

TLS 证明不了部署的哪些方面

一次完成的 TLS 握手只能证明服务器持有证书，完全证明不了你的客户端是否信任签发链、是否匹配链中的名字。校验必须在目标服务器上成功，包括单位自建的任何私有 CA；而一个提供忽略证书错误选项的客户端，是把校验去掉了，而不是获得了协议支持。链式校验与名称匹配是两项独立的测试，过得了其中一项的协议栈仍可能栽在另一项上。两者都属于验收标准，而不是故障排查附录。

接下来要确认 PPP 认证方式，因为采用 EAP-TLS 的部署需要客户端能在 PPP 内部出示证书，而基于口令的方式则需要客户端支持这种交换。一个服务器地址加一个口令，描述不了单位的真实要求，尤其当前面还挡着第二因素或设备检查时。在假定客户端能满足之前，先问清服务器强制要求的是哪一种。

沿四个环节跟踪会话

观察连接如何越过四道边界：到服务器的 TCP 与 TLS、SSTP 控制交换、PPP 协商，最后才是你真正需要的资源。日志停在 TLS 之后，与停在 PPP 之内，描述的是两种不同故障，也指向不同的责任人。浏览器能打开该主机的网页，只能证明 443 端口上有什么在应答，而这正是这一领域最常见的误判。如果网页能打开、客户端却依然失败，那么 问题出在 TLS 之上，网页服务器并不是嫌疑对象。

最后用真实的内网资源和一次名称解析收尾，因为一个建立起来却不承载任何流量的会话，在大多数状态窗口里看起来和正常会话一模一样。对所需资源成功发出一次请求，才能裁定图标裁定不了的问题。

没有支持时，改变方案

如果客户端说不了 SSTP，就另找经过批准的替代方案，或者请服务器所有者提供一个双方都支持的协议。为了让导入成功而不断删掉不认识的选项，最终只会得到一个连不上任何地方的配置文件，这是通往同一个死胡同的更慢路径。来自不明来源、宣称通用兼容的安装程序，会给机器塞进一条未经批准的信任路径，而且常常用单位无法更新的东西替换掉平台客户端。这两种做法都不是修复，而且都比原问题更难回退。

把兼容性问题与性能、接入点选择分开看，因为当客户端说不了对方的协议时，再近的服务器也没有用。调延迟修不好一个永远走不完的环节。