OpenVPN remote-random: Shuffled Order, One Tunnel

The assumption is that adding remote-random turns a profile into a rotating pool, so each connection comes out of a different address. What the directive actually does is shuffle the list of remotes once, when the client starts connecting, and then try them in that new order. The tunnel that eventually comes up still terminates at one endpoint and stays there for the life of the session.

That difference matters for both testing and privacy claims.

What the Option Changes at Connect Time

A client profile can carry several remote lines, each with its own hostname and port. Without the directive they are attempted in file order; with it, the list is permuted once at session start and the first address that answers wins. The rest remain fallbacks for this attempt, not parallel paths. A profile carrying a single remote gives the directive nothing to shuffle, which is the quickest way to see whether it can matter.

OpenVPN's manual documents the option as affecting the order of connection attempts, which is exactly the scope to expect in behaviour.

A reconnect starts a new selection cycle, so a later session can land somewhere else. The live tunnel does not move while it is up.

Myth: Every Request Gets a New Server

Once established, the tunnel carries all traffic for that session to the chosen peer. There is no per-request reselection, and the directive is not a load balancer for individual connections: it shuffles candidates, it does not spread packets. Every application sharing that tunnel shares the same peer. Whatever a browser reports about its exit belongs to the session, not to an individual request.

If a test shows two different exits, look for two separate sessions rather than one clever option. That distinction also explains why a browser test and a download test can disagree when a reconnect happened between them.

What remote-random-hostname Is For

A second directive with a similar name changes the hostname used for resolution, not the order of the remote list. It exists for deployments where a name resolves to several addresses through round-robin DNS, and it should only be used when the service is built for it. Only the resolution step changes; the order of the candidate list does not.

Enabling it because the names look related is a common mistake. A wildcard certificate or a DNS layout that does not expect the modified name will simply fail to resolve or fail to validate.

Read the Selected Endpoint From the Log

Record which peer a session actually used before drawing conclusions. Verbose output names the address being attempted, and the profile itself shows how many candidates exist. Compare that count with the address in the log before blaming the shuffle.

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

For a performance comparison, pin the endpoint by commenting out the other remotes so the variable under test is the protocol or client rather than the path. For a privacy question, evaluate the service's identity and logging as a whole; a shuffled first choice does not clear cookies, remove an account login or make two operators equivalent.

Keep the shipped trust material and the supported endpoint set together. Reshuffling changes only the order in which that set is tried.