Velocity is the modern proxy and it is worth moving to. It is not a drop-in replacement, though — the config format, the plugins and the forwarding security are all different, and the last one is the part that silently leaves a network exposed.
What changes
| BungeeCord | Velocity | |
|---|---|---|
| Config file | config.yml | velocity.toml |
| Plugins | BungeeCord plugins | Velocity plugins — not compatible |
| Forwarding | Legacy forwarding | modern with a shared secret |
| Backend setting | bungeecord: true in spigot.yml | velocity section in paper-global.yml |
| Performance | Fine | Noticeably better under load |
The migration, in order
- List your BungeeCord plugins and find equivalents first
Do this before anything else. If a plugin your network depends on has no Velocity version, that decides whether you move at all.
- Set up Velocity alongside, not instead
Run it on a different port with the same backends listed. You can test the whole thing before switching a single player over.
- Switch forwarding to modern on both sides
player-info-forwarding-mode = "modern"invelocity.toml, and the matchingproxies.velocityblock in each backend'spaper-global.yml, with the secret copied across. - Move the address across last
When it works, point your DNS or your published address at the new proxy. That is the only step players notice.
If a backend is still configured for BungeeCord forwarding while the proxy sends modern, players either cannot connect or — worse, depending on the settings — connect unauthenticated. Every backend must be switched at the same time as the proxy, and every backend must be unreachable from the internet regardless.
If something turns out to be broken on a Tuesday evening, switching back is a start button rather than a rebuild. Delete it when you have gone a week without wanting it.
You connect through Velocity, /server moves you between backends, your skin and UUID are correct on each, and connecting directly to a backend's port fails.