SSTP 是 HTTPS 之上的 PPP，而不是 443 端口上的网页

SSTP在 HTTPS 连接内部承载 PPP，因此在中间的任何设备看来它都像网页流量。TLS 和 HTTP 建立外层通道，随后 SSTP 控制消息准备隧道，PPP 提供会话行为。在同一个地址上加载页面的浏览器只完成了第一阶段的一部分。把它当作 VPN 测试，正是让一个正常工作的代理背上协议不匹配黑锅的做法。

按顺序走完这四个阶段，你看到的故障总会落在其中之一。

阶段 1：TCP 与 TLS

客户端向 443 端口建立 TCP 连接并执行 TLS 握手。证书链必须与客户端配置的主机名一致。此处名称不匹配会在任何 SSTP 消息交换之前就产生故障，而SSTP 规范假定这条外层 HTTPS 通道已经存在。后续阶段中的任何环节都无法弥补这里的信任失败。

普通 Web 服务器可以完美完成这一阶段，却仍在下一阶段失败。TLS 成功证明的是证书，而不是它背后的协议。

阶段 2：HTTPS 请求

SSTP 用一种特定的方法 SSTP_DUPLEX_POST 发出请求，并保持连接不返回文档。为普通页面请求配置的服务器或代理可能接受连接、随后拒绝该方法。这种拒绝才是人们通常所说的 443 端口被封锁——它其实是兼容性问题。

查看服务器日志中的响应码和方法。这一阶段的拒绝与 TCP 超时是不同的问题，两者的修法也不同。

阶段 3：控制消息

请求被接受后，SSTP 交换用于协商和准备隧道的控制消息。这些是 HTTPS 正文内部的协议消息，而不是 HTTP 请求，因此会检查并改写正文的代理可能破坏它们，而页面请求却不受影响。

深度检测中间设备的名声正是在这里挣来的。如果页面能加载而 VPN 失败，要检查正文是否被改动，而不是端口是否开放。

阶段 4：PPP 接手

接着 PPP 提供会话行为：链路协商、认证，以及随后的网络层配置。PPP 认证与客户端已经通过的 TLS 检查相互独立。客户端接受的服务器证书，完全不能说明用户凭据是否有效、账号是否被授权。

证书被接受与登录被拒绝并不矛盾。它们是结果彼此独立的连续阶段。

认证有多个角色

客户端依据自己的信任库和配置的主机名验证 TLS 服务器身份。随后 PPP 按部署方式对用户或机器进行认证。服务器还可能附加自己的策略，规定谁能连接、能到达哪里。请让主机名与证书身份保持一致，因为换成裸地址会把原本可用的配置变成名称检查失败。

记下是哪个阶段报告了故障。证书、方法、控制消息、PPP 认证，最后是路由：五个位置，五种修法。

浏览器测试能说明和不能说明什么

在该地址加载页面证明了 DNS 解析、TCP 可达，以及有东西在监听并说 HTTP。它不能证明方法被接受、控制交换能存活，或 PPP 认证已配置。请使用实现了 SSTP 的客户端，而不是改个端口去转换另一份配置文件。

会话建立之后，路由、DNS 和服务器侧转发仍然决定用户能到达哪里。隧道是一条路径，不是授权。