OpenVPN remote-random：顺序会打乱，隧道仍只有一条

常见假设是：加入 remote-random 后，配置文件就变成一个轮换池，每次连接都从不同地址出去。该指令实际做的，是客户端开始连接时把 remote 列表打乱一次，然后按这个新顺序尝试。最终建立的隧道仍然只落在一个端点上，并在整个会话期间保持在那里。

这个区别对测试和隐私说法都很重要。

该选项在连接时改变了什么

客户端配置文件可以包含多条 remote 行，每条都有自己的主机名和端口。没有该指令时，它们按文件顺序尝试；有该指令时，列表会在会话开始时置换一次，先应答的地址胜出。其余地址只是本次尝试的备选，而不是并行路径。只含一个 remote 的配置文件没有可供打乱的对象，这是检验它是否有意义的最快方法。

OpenVPN 手册将该选项记录为影响连接尝试的顺序，行为上应当期待的正是这个范围。

重新连接会开启新的选择周期，因此之后的会话可能落在别处。正在运行的隧道不会移动。

误解：每个请求都会换一个新服务器

隧道路径建立后，该会话的所有流量都送往选定的对端。不存在按请求重新选择，该指令也不是针对单个连接的负载均衡器：它打乱候选顺序，并不分发数据包。共享该隧道的每个应用共享同一个对端。浏览器报告的出口信息属于整个会话，而不属于某个请求。

如果测试显示两个不同的出口，应寻找两个独立会话，而不是一个聪明的选项。这一区别也解释了为什么在两次测试之间发生过重连时，浏览器测试和下载测试可能不一致。

remote-random-hostname 是做什么的

第二个名称相近的指令改变的是用于解析的主机名，而不是 remote 列表的顺序。它适用于名称通过轮询 DNS 解析到多个地址的部署，并且只有在服务为此构建时才应使用。改变的只是解析步骤，候选列表的顺序不变。

因为名字看起来相关就启用它，是常见错误。通配符证书或没有预料到被修改名称的 DNS 布局，会直接解析失败或验证失败。

从日志读取实际选中的端点

在下结论之前，先记录会话实际使用了哪个对端。详细输出会给出正在尝试的地址，配置文件本身则显示候选数量。把该数字与日志中的地址对比，再判断打乱是否有关。

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

做性能对比时，注释掉其他 remote 以固定端点，使被测变量是协议或客户端，而不是路径。涉及隐私问题时，应整体评估服务的身份与日志记录；打乱首次选择不会清除 cookie、不会退出账号登录，也不会让两个运营方变得等价。

把随附的信任材料和受支持的端点集合放在一起。重新打乱只改变尝试该集合的顺序。