多个 OpenVPN 远程：故障转移列表，而非链路聚合

一个配置里的两行 remote 看起来像第二条通道，其实只是第二次尝试。第一个端点停止响应时，客户端会继续往下走，会话并不会变宽。请一开始就把它称为故障转移列表，否则你调的是错误的旋钮。

remote 列表能给你什么

把配置看成一串有顺序的尝试，而不是容量池。每个条目轮流建立隧道，会话停留在有应答的那一个上。更长的列表提高的是连上的概率，而不是管道的宽度。

真正的聚合是另一套机器。要把一条流分散到多条路径上，两端都需要软件来分流并按顺序重组。

承诺用更多服务器提供更快隧道的厂商，卖的正是第二种模型，而不是更长的列表。如果客户端只是逐个尝试端点，五个条目改变的只是概率，别的什么都不会变。看一次故障：会话断开并出现在别处，日志显示的是新端点，从来不是更宽的管道。

把设置与单个端点绑在一起的块

普通的 remote 行带一个地址，有时还有端口和协议。当某个端点需要代理，或需要文件其余部分不用的传输方式时，把这些设置放进连接块，让它与端点待在一起。内联块在单个 .ovpn 文件里也能用，多数配置就是这样分发的。

块之外的一切，都是没有覆盖它的条目的默认值。这就是为什么一个构建块加上四个普通 remote，会出现地址列表解释不了的行为。

删掉不认识的块不是外观问题。它所属的端点会回退到文件的默认值，而那可能是与它监听的传输方式不同的传输。去掉错误的包装，一个条目失败而其余正常，看起来就像服务器坏了，而不是配置损坏。编辑之前，请把每个 remote 连同它的传输、端口和代理一起读一遍。

重试顺序与 remote-random 的代价

顺序很重要，因为每个失效条目在下次尝试前都要花时间。把想要的端点放在最前，其余当作有排序的后备。

remote-random 打乱起始顺序，这会把负载分散到对等的服务器上，而在某个端点明显是主用时反而帮倒忙。无论哪种情况，都要记录客户端选中的端点；连接变慢时，配置名什么也说明不了。从详细日志里 grep 链接行，可以看出会话落在哪里。

混用运营商会破坏信任声明

配置也是对身份的声明：这些地址就是你要访问的服务，固定的证书属于它。把免费公共服务器塞进那个文件会破坏这个声明：它们的证书和你的证书描述的是不同服务。常见结果是身份校验失败，或者凭据被发给你提供商网络之外的主机。把备选放在你的运营商分发的集合里，凭据和信任材料要匹配。

如果你需要两个提供商的端点，那是路由问题，不是改配置。请在隧道之上解决，在那里才能说清哪种流量走哪条路径。

逐个测试，而不是假设

配置更新获批后，逐个有意连接每个必需端点，确认上来的是哪种传输。详细运行能让它显现。启动 openvpn --config office.ovpn --verb 4，读取你期望地址的链接行。然后检查隧道后面的资源；条目可以完成握手，却仍然不把你路由到任何地方。

故障转移需要自己的测试，而不是指望。在实验环境里阻断第一个端点，启动客户端，测量它花多久才转走。慢的第一个条目后面拖着长列表，比短而启动良好的列表更糟。

运营商每次改动列表后都要重新检查。导入的集合只有在条目存在、并且说你的块所描述的传输时才有用。OpenVPN 2.6 手册在这里覆盖了 remote、connection 和 random-order 指令，语法有疑问时就该查这个版本。