What a proxy is actually for
Both Velocity and BungeeCord do the same job: they accept every player connection, then hand each player to one of several backend servers and move them between those servers without a disconnect. That is what makes a hub, a lobby, and instant `/server survival` transfers possible. Neither runs game logic itself — no worlds, no entities, barely any memory — which is why a proxy that serves a thousand players can happily live in 1 GB.
Because the proxy is the single public entry point, it is also the single point of failure and the thing every attack aims at. Whatever you choose, the proxy is what you put behind edge mitigation.
The comparison that matters
| Performance under load | Velocity handles more concurrent connections per core; the gap widens as player counts and login rates rise |
| Forwarding security | Velocity's modern forwarding is signed; BungeeCord's legacy forwarding is unsigned and must be firewalled |
| Plugin ecosystem | BungeeCord has the deeper back catalogue; Velocity covers everything current and mainstream |
| Active development | Velocity — Waterfall, the patched BungeeCord fork, has been deprecated by PaperMC |
| Configuration | velocity.toml, structured and typed; BungeeCord uses config.yml |
| Version support | Both cover a wide protocol range; Velocity's is modern-leaning, BungeeCord's is more permissive with very old clients |
| Migration cost | Real — plugins must be re-sourced and backend forwarding reconfigured on every server |
The security difference is the real argument
This is the part worth understanding properly, because it is the difference between a configuration preference and an actual vulnerability. With BungeeCord's legacy forwarding, the backend server trusts whatever identity arrives in the handshake. Your proxy sends it honestly. So does anyone else who can open a TCP connection to that backend — which is why a BungeeCord backend reachable from the internet can be joined by anyone claiming to be any username, with any UUID, including one that your permissions plugin has made an administrator.
The defence is a firewall: backends must accept connections only from the proxy, and never from the internet. That works, and thousands of networks run it safely — but it is a mitigation you have to get right and keep right forever, on every backend you ever add. Velocity's modern forwarding removes the class of bug instead: the proxy signs the player data with a shared secret, the backend verifies the signature, and an unsigned connection is rejected on arrival. You should still firewall your backends. You are just no longer one misconfigured host away from an open door.
When BungeeCord is still the right call
- A plugin you cannot replace. If your network is built around a BungeeCord-only plugin with no Velocity port and no equivalent, that settles it — a broken feature is worse than an older proxy.
- A large, stable, working network. Migration is not free. If your BungeeCord setup is firewalled properly and performing fine, "it works" is a legitimate engineering position.
- Very old client support. If your player base genuinely depends on ancient protocol versions, verify support on both before assuming they are equivalent.
- No time to test. A proxy migration touches every backend's forwarding config at once. Do it on a schedule you chose, not during a crisis.
If you migrate, the order that avoids downtime
- Inventory your BungeeCord plugins first and find the Velocity equivalent for each. Anything without one is a blocker, not a detail — resolve it before touching a server.
- Stand Velocity up on a different port alongside the running BungeeCord proxy. Nothing is switched over yet.
- Configure modern forwarding: set the forwarding mode in `velocity.toml`, copy the forwarding secret to every backend, and switch each backend to accept it.
- Test with a real client against the new port — joins, server switches, permissions, chat, and anything IP-based.
- Move traffic last: point your hostname's routing at the new proxy, then enable `haproxy-protocol` once all traffic arrives through the edge — the sequence is covered in the Velocity PROXY protocol guide.
- Keep the old proxy running until the new one has survived a peak-hour session.
Neither one protects you
A proxy is a router, not a shield. Both Velocity and BungeeCord will happily accept ten thousand bot connections per second and fall over, because accepting connections is precisely their job. Antibot plugins running on the proxy help with the small stuff, but they act after the connection, the handshake and the login have already cost you resources — the reason that distinction matters is laid out in edge antibot vs plugin antibot. The proxy question and the protection question are independent: pick the proxy on plugins and forwarding, and filter the flood before it ever reaches either one.
Common questions
Is Velocity better than BungeeCord?+
For most new networks, yes. Velocity handles more concurrent connections on the same hardware, uses a modern forwarding scheme that cryptographically signs player data instead of trusting it, and is actively developed. The one area where BungeeCord still wins is plugin availability — a long tail of older plugins was never ported, and if your network depends on one of them, that decides it.
Is BungeeCord still supported in 2026?+
BungeeCord itself is still maintained by the SpigotMC project. What changed is the ecosystem around it: PaperMC deprecated Waterfall, its BungeeCord fork, and now directs users to Velocity, so the performance-patched middle option most large networks were running is no longer receiving development. Plain BungeeCord works, but the momentum has clearly moved.
What is the difference between modern forwarding and BungeeCord IP forwarding?+
BungeeCord's legacy forwarding sends the player's identity to the backend server as plain, unsigned data, so any connection that reaches a backend directly can simply claim to be any player, including an operator. Velocity's modern forwarding signs that handshake with a shared secret, so a backend rejects anything that did not genuinely come from your proxy. Legacy forwarding is only safe when a firewall makes direct backend connections impossible.
Do BungeeCord plugins work on Velocity?+
No. Velocity has its own plugin API, so BungeeCord plugins must be ported rather than dropped in. Most widely-used plugins now ship a Velocity build, and common needs like permissions, chat and Discord bridging are well covered — but check every plugin your network actually depends on before committing to a migration.
Does switching from BungeeCord to Velocity change how DDoS protection works?+
No. Protection sits in front of the proxy either way: players resolve your hostname to the mitigation edge, filtered traffic is forwarded to whichever proxy you run, and the proxy reads the real client IP from the PROXY protocol header. The only thing that changes is which config file you set the flag in — haproxy-protocol in velocity.toml, proxy_protocol in BungeeCord's config.yml.
Running Velocity or BungeeCord and tired of your proxy being the target? Create a free network — real client IPs on every plan, one DNS record, about five minutes.