If you are standing up a Minecraft network in 2026 and wondering which proxy to put in front of it, the short answer is Velocity for almost every new network. This post explains why, honestly, including the one real reason you might still reach for BungeeCord. A proxy is the piece that ties several backend servers into one address, so if you have not decided whether you even need a network yet, scaling with Velocity covers that question first and this post assumes you have already answered it.
The three names you will see
Guides throw around three names, and it helps to know what each one is before comparing them.
BungeeCord is the original. It has been the standard way to run a Minecraft network for years, it is maintained by md_5, and a very large amount of the network plugin ecosystem was written for it. It still works, and it still gets occasional updates, but development on it is minimal at this point.
Waterfall was a fork of BungeeCord by the PaperMC team that aimed to improve performance and stability while keeping the same plugin API. It mattered for a long time, which is why so many older guides recommend it. It no longer does, because PaperMC declared it end of life on 26 March 2024. The downloads and documentation are still up, but there are no guaranteed updates for new Minecraft versions, so building a new network on Waterfall today means building on software that has stopped moving.
Velocity is the modern proxy, also from the PaperMC team. It was written from scratch rather than forked, it is actively maintained, and it is built for current Minecraft versions. The knowledge from the people who worked on Waterfall went into Velocity, which is a large part of why PaperMC now points everyone at it.
Performance
Velocity is the lighter and faster of the two live options, and the reason is in how it is built rather than in a marketing number.
A proxy spends most of its time compressing, decompressing and shuffling packets between players and backends. Velocity uses libdeflate, a native compression library, in place of the standard Java zlib path that BungeeCord uses, and that alone makes the compression work noticeably cheaper on CPU. PaperMC's own comparison rates Velocity's resource efficiency above both BungeeCord and Waterfall.
For most networks the proxy is not where your tick budget goes, because the proxy does not run the game simulation, your backends do. What proxy performance buys you is headroom at scale: a proxy that stays cheap under thousands of concurrent connections is one less thing that falls over on your busiest night. If you are running a handful of backends for a few dozen friends, you will not feel the difference. If you are growing towards a real player count, you will.
Security and forwarding
This is the part that actually decides the choice for a public network, and it is worth understanding rather than taking on trust.
When a player connects through a proxy, the backend has to be told who that player is, because the backend itself is running in offline mode and no longer verifies accounts directly. The proxy does that verification and then forwards the player's identity to the backend. The question is how the backend knows to trust that forwarded identity.
BungeeCord uses legacy IP forwarding, which passes the player's details to the backend without a cryptographic signature. If a backend is reachable from the open internet, an attacker can connect to it directly and simply claim to be any player they like, including a staff account, because nothing proves the claim came from your proxy. That is the classic offline-mode bypass.
Velocity's modern forwarding closes that hole. The proxy and every backend share a secret value, and a backend only accepts identity information that is signed with that secret. An attacker who reaches a backend directly cannot forge a valid signature, so the claim is rejected. You still have to firewall your backends so only the proxy can reach them, and that rule does not go away with either proxy, but modern forwarding gives you a second line that legacy forwarding never had. The exact settings for it are in scaling with Velocity, and the wider job of running an open server safely is in securing a public SMP.
Plugins, and the honest caveat
Here is the one place BungeeCord still has an edge, and it is worth being straight about it.
Velocity has its own plugin API, and it does not run BungeeCord or Waterfall plugins natively. The two APIs are different, so a plugin written for BungeeCord will not simply drop into Velocity. Most of the common network jobs are well covered on Velocity now: proxy-side permissions, chat and Discord bridges, server management, MOTD and queue plugins, party and friends systems. For a standard survival, creative and lobby network you will find modern Velocity equivalents for everything you need.
The gap shows up with older or more niche plugins that only ever got a BungeeCord build and are no longer maintained. If your network depends on one specific legacy plugin that has no Velocity version and no active developer, that is a real reason to either stay on BungeeCord or find a replacement before you migrate. There is an experimental third-party compatibility layer called Snap that aims to run some BungeeCord plugins on Velocity, but it is not official and not something to build a network's stability on. Check your must-have plugin list against Velocity availability before you commit, because discovering the gap after migration is the expensive way to learn it.
The recommendation
For a new network in 2026, use Velocity. It is the actively maintained option, it is the faster and lighter one, and its modern forwarding is the safer way to tell your backends who a player is. Waterfall is end of life and should not be the foundation of anything new. BungeeCord still runs and still has the deepest legacy plugin catalogue, so the one case for choosing it is a hard dependency on a BungeeCord-only plugin you cannot replace.
If you are already on BungeeCord or Waterfall and everything works, there is no emergency. Plan the move to Velocity for when you next have time to test your plugin set against it, rather than doing it live on a Friday night. When you do migrate, the setup, the forwarding secret and the backend firewall rule are all covered in scaling with Velocity.
Whichever proxy you land on, the network underneath it wants hardware and a connection built for the job. You can browse game hosting and put the proxy and its backends on boxes that are genuinely yours.