Which program owns that config.json in your OpenVPN setup?

You find a file named config.json, it mentions a VPN server, and the assumption follows immediately: this must be the OpenVPN connection. It often is not. A JSON file with that name can belong to a desktop frontend that launches the client, to a daemon that stores its own settings, or to a product's export format, and each of those has its own schema.

The filename is the least useful clue. Start from the process that reads the file, then check whether the format it expects is even JSON, and only then decide whether editing the file is the supported way to change anything.

Start from the process, not the filename

Look at what is actually running. A service unit, a launcher script, or a tray application will name the binary it starts and often the configuration path it passes. The directory that holds the file is a second clue: application data directories, service configuration directories, and user profile directories imply different owners.

Then read the owning product's documentation for that component. If the JSON belongs to a wrapper, its keys are the wrapper's keys, and a plausible-looking object built from another product's example will be rejected or silently ignored.

Two files with the same name in different directories are a common trap. One may be generated state that the service rewrites at every start, and the other may be the template a human is supposed to edit. Changing the wrong one produces a fix that survives until the next restart.

What a Community OpenVPN profile actually is

Community OpenVPN 2.6 reads an option-based text format. A profile is a sequence of directives: a client mode line, a device line, a remote endpoint, plus identity, cipher, and route options, and it may embed certificate and key material inside inline blocks.

That format is parsed line by line by the client itself. Handing it a JSON document through the config option does not switch on a JSON parser; the first line will be rejected as an unknown directive. Renaming a JSON file to end in .ovpn does not convert its contents either, and a valid option file does not become invalid because its extension is unusual.

OpenVPN Connect and OpenVPN 3 Linux have their own import and management paths for profiles. Those products can accept a profile and store it in their own database or service state, which is not the same thing as a JSON file that happens to describe a server.

Editing state that another component owns

If the JSON is generated, editing it is a race. A running service may write it back on shutdown, on reconnect, or on the next settings change, and a hand edit disappears without an error. Prefer the product's import command, management API, or settings interface, because those paths update whatever internal state the file represents. A file that reverts after a restart is telling you which path was the durable one.

If you do edit a generated file, stop the service first, keep a backup, and make the smallest possible change. Then check whether the service rewrites the file when it starts, because a file that reverts on start means the real source of truth is elsewhere, and the edit was never going to persist.

Passwords and inline private keys are a separate concern. JSON can carry a complete key just as easily as an option file, so treat any export as secret, keep it out of shared drives, and redact values before pasting structure into a forum question.

Verifying the change and protecting the file

Verification is not "the JSON parses". Parsing only proves that the braces match; it says nothing about whether the owner recognises the keys. Check the product's own state: the active profile list, the selected connection, and a reconnect that actually uses the new values. A profile that appears in the list but never becomes the selected one is still not the profile in use.

Watch the log for the component you edited, not only the VPN client. A wrapper that rejects your file usually reports it in its own log, and a client that never received the file looks identical to a client that received bad settings.

Keep a copy of the working file and record the version of the product you tested against. These formats change between releases, and a structure that worked last year may be rejected after an upgrade with a message that does not mention the schema at all.

Walkthrough summary: identify the process, read its documentation, confirm whether the file is JSON at all, use the supported edit path, and verify through the product's own state. The filename never answered any of those questions.