openvpn --errors-to-stderr is a launch option, not an error

A command line containing --errors-to-stderr looks like a complaint and is not one. The word belongs to an option name, in the same way that a log file's name says nothing about what the file contains. Before you change any configuration, establish what you are actually reading.

The decision has three branches: the line is the launch itself, the line is output the program printed, or the line is text a wrapper echoed before the VPN started. Each branch points at a different place to look, and only one of them is the VPN's own message.

An option name is not a status message

For Community OpenVPN, --errors-to-stderr routes error output to standard error instead of standard output. That is a stream choice, not a severity filter, and it does not create an error. A later --log or --log-append can redirect the same messages to a file, which is why the flag's effect depends on the rest of the command. The upstream logging reference defines that ordering.

So the presence of the flag tells you where errors would go. It does not tell you that one occurred.

Launch line or process output

Start by asking who printed the text. A service unit, an application bundle or a shell wrapper often echoes the full argv before the VPN process writes anything. That echo is indistinguishable from a status line if you only see a fragment.

If the line came from the wrapper, the VPN has not run yet and has nothing to report. Look further down the output for the first message that carries a timestamp or a subsystem name.

If the line came from the VPN process, it is still just the invocation. OpenVPN does not print its own command line as an error, and the messages that matter follow it.

Find the process and its result

Establish whether the process is still running. A client that is up and retrying looks very different from one that exited immediately, and the same command line precedes both.

Then read the result through the component that owns the process. Under systemd, that is the unit's journal; under a desktop app, it is the app's own log or console. The exit status plus the last messages answer the question the option name only hints at.

A configuration parse error, a missing file, a rejected credential and a peer timeout are four different events. They arrive on the same stream. They need four different fixes. Decide which one you have before touching the profile, and quote the exact message when you ask for help.

When the flag earns its place

The flag earns its place when stdout carries data and errors must not contaminate it, or when a wrapper captures the two streams separately. For a foreground session in a terminal, both streams land in front of you. In that case the distinction rarely changes what you do.

Keep it if the surrounding script depends on the split. Removing it because the name looks alarming changes where messages appear and fixes nothing else.

What not to change

Do not treat the option as a repair step. Deleting it cannot fix a certificate, a route or an authentication failure.

If the invocation contains --config stdin, the configuration is being fed through standard input. That is a separate decision about how the file is supplied. Change one thing at a time, and re-read the actual message before you change the second.