这个公共 VPN 节点究竟提供哪些协议？

软件支持它，所以节点就提供它。这个推论错得足够频繁，已经可以当作一条规则：一次 SoftEther 部署可以只启用其兼容连接方式中的任意子集，而公共节点是一次有所有者和配置的部署。你能连接什么取决于那个节点，而不是它所运行项目的功能清单。大多数「协议坏了」的工单，其实就住在这两者之间的落差里。

项目清单真正承诺了什么

项目的协议功能描述的是服务器的能力。某个具体节点只启用其中一部分监听器，而不是全部，运营方无需改动软件版本就能改变这个集合。因此同一构建的两个节点表现不同，一个能用的配置文件对下一个目标什么也证明不了。选择连接目标时，节点自己的清单比项目页面更权威。

把清单当作五个字段来读，而不是一份菜单：端点、端口、传输方式、协议族和认证方式。一个宣传 SSTP 的公共节点只告诉了你某个端口上有监听器；它没有告诉你它出示哪张证书，也没有告诉你你的账户在那里是否可用。把这五个字段与自己的配置文件对照，比反复重装客户端更快，而且会形成一份日后可以检验的书面预期。

让配置文件与它指名的端点对应

原生 SoftEther 条目并不自动等于 OpenVPN 配置，即使两者出现在同一供应商页面的同一标题下。当节点同时发布 OpenVPN 的 TCP 与 UDP 监听器时，请把它们当成两个端点：从其中一个改到另一个的配置文件，指向的是一个没人启用的监听器。文件里的传输标签是地址的一部分，不是装饰性设置。

客户端接受导入的文件，只能证明该文件可以被解析。它完全没有说明另一端是否有远程监听器在等待，所以第一次连接尝试才是真正的检验。在归咎于协议之前，先把配置文件的 remote 行与节点公布的 host 和端口对照一遍。

探测真正失败的那个阶段

能应答网页流量的主机，仍然可能缺少想要的 VPN 服务，而拒绝一种协议的主机，未必对所有协议都不通。这两个错误会在同一个下午把人引向相反的方向。一个去追查本来正常的防火墙；另一个去重装从来不是问题所在的客户端。把每条路径分开探测，答案描述的才是某个监听器，而不是整台主机。

这五项检查覆盖了公共节点常见的几种方式。请从客户端所用的同一网络执行，因为被过滤的端口从远处看与不存在的监听器一模一样。

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

在改动任何东西之前，先把每个观察到的错误对应到它所在的那一行。TLS 身份错误证明监听器存在，因此把配置文件改写成另一种协议，会丢掉本来有效的证据。连接被拒绝只证明这个端口没有应答，这比「节点不支持 OpenVPN」要窄得多。

在改动任何东西之前先保留错误

写下确切的结果：超时、证书身份错误、账户被拒和应用层拒绝，是四种不同的结局。只有第一种与协议不可用有关，只有最后一种与连接成功之后的权限有关。重置客户端或更换协议会摧毁这个区分，因为下一次失败会带着不同的历史到来，也没有可比对的基线。

不要为了让不兼容的配置文件看起来能用而削弱验证。关掉证书检查，会把清晰的身份错误变成一次连向你并不打算到达的对象的连接；由此得到的成功比原来的错误更糟，因为它掩盖了到底是哪个阶段出了问题。

每换一个节点就重新检查一次

公共节点清单上的原生 SSL、OpenVPN、L2TP/IPsec 与 SSTP 选项，描述的是该节点在那个时刻的配置。同样的软件在别处可能给出另一套，供应商也可能在你收藏与下次尝试之间撤掉某个监听器。旧笔记描述的是旧部署。

把已验证的配置文件连同它的端点与方法记录下来，然后在节点变化或连接开始失败时重复探测。SoftEther 协议规范是软件能做什么的参考；节点自己的清单则是它实际做什么的参考。把两份文档分开来看，诊断就会变短。