OpenVPN 报错：无法识别的选项 tls-remote 或 keysize

通常的起点是一个用了几年的配置，在新客户端上打开，还没建立隧道就失败。终端会打印类似 Options error: Unrecognized option ... in client.ovpn:130: tls-remote 的内容，末尾括号里带一个版本号。把它当作解析器的抱怨来读：文件里有一条这个客户端已不认识的指令。

这条消息解释了为什么重新生成密钥、重输密码或检查服务器都没有用。失败发生在客户端读取自身配置的时候，还没有打开套接字。真正该做的是找出被拒绝的指令，并用当前的等价指令替换它。

先读懂出错的那一行再动手

自己从命令行运行客户端，而不是从托盘图标启动，这样消息看得见，配置路径也不会含糊。打开报错的那一行，看客户端点名的 token。行号是配置文件里的行号，不是版本号；人们常在这里搞错，因为同一个数字也会出现在括号里当版本标识。

旧的配置生成器往往不止写出一条坏指令，而是好几条。修好第一个错误，重新运行客户端，准备好迎接下一个。这种连环出现是正常的，不代表改动把事情弄得更糟。

keysize 和 tls-remote 到底怎么了

keysize 是在配置显式选择加密算法的年代用来指定密钥长度的。OpenVPN 2.4 将其废弃，之后的客户端把它从选项表里删掉，所以解析器现在直接拒绝这一行，而不是忽略它。现代协商会从所选算法推导密钥长度，因此这条指令已经没有可控制的东西。

tls-remote 在 2.4 中已被移除。它把服务器证书与一个期望名称作比较，替代它的是 verify-x509-name，后者在名称匹配方式上更严格。旧指令已经不存在，所以带着它的配置在现行客户端上永远无法解析。

每次只改一条指令。如果配置还指定了客户端不提供的算法，那会在稍后产生另一个错误；把两处改动混在一次编辑里，就无法判断是哪一个破坏了握手。每次修改后重新连接，并保留错误文本。这个习惯还能留下可用的退路，万一某次修改让情况更糟。

重写服务器身份检查

替代指令接收期望名称和比较模式。verify-x509-name vpn.example.edu name 要求证书的 subject 与该值完全相等。其他模式匹配前缀或完整 subject 字符串，选错模式会把一个能用的配置变成一次干净的验证失败。

如果旧的 tls-remote 参数是服务器完整的 common name，精确的 name 比较通常是对的。如果它只是部分值，就用前缀模式，而不要把期望名称缩短，因为更短的精确匹配不会通过验证。如果原值没有记录，就去问运维服务器的人他们公布的 subject 是什么。

不要为了消除错误而关掉检查。移除服务器身份验证会把一个可修复的配置问题变成未经验证的隧道，而这正是这条指令原本要防止的风险。

修正后的配置、本地修改，还是更老的客户端

当服务器归别人管时，最干净的做法是向他们要一份当前配置。你手上的副本来自旧生成器，而他们的导出已经在用现行指令。一次下载就能消掉整类错误，并把未来的修改集中在一处。

当两端都由你掌控时，改副本并保留原文件。一次只改一条指令，保存、连接，并记下你测试的客户端版本。每次修改旁留一条简短备注，因为跨多次会话改过的配置很难凭记忆审计。用命令行运行改过的文件能让这个循环更快，因为错误直接进终端。

固定或回退到 2.4 之前的客户端也能让消息消失，而对于永远不会更新的设备，这也许是唯一可行的临时办法。把它当作临时措施：在当前桌面上跑老客户端通常意味着旧库和不被支持的配置，这是把问题推后，而不是解决。

隧道起来之后，再通读一遍整个配置。带着一条被移除指令的配置往往还带着另一条，而第二条只有在第一条消失之后才会浮现。