Velocity hosting for Minecraft networks

A well tuned Paper handles a good crowd long before a proxy makes sense. What pushes a project towards Velocity is how many Java processes run in parallel, not how full the server gets.

The maths flips once the instances stop being compatible: different versions, different mod loaders, different restart cycles. None of that fits in one server, and that is where the proxy pays for itself.

The reverse holds just as strongly: the proxy is one more service to watch and the point everybody passes through. If you run one server and just want one more world, a multiworld plugin is the better answer.

The proxy is what authenticates the player against Mojang, so the backends run with online-mode off and take its word about who just arrived. In legacy forwarding that information travels attached to the handshake, unsigned.

Modern forwarding closes the gap with a shared secret: Velocity signs the player data with the contents of forwarding.secret and the backend refuses the connection when the signature does not match. On Paper, that lives in paper-global.yml.

Two details trip up more people than the theory does. The secret has to match byte for byte, and a single trailing newline is enough to refuse everyone. And whoever comes in through the proxy gets an online UUID: turning forwarding on for an older server means migrating inventories and permissions.

A backend with online-mode off accepts any name. If its port answers on the internet, somebody connects from outside claiming to be the owner and walks in with every permission. That is no fault of Velocity or BungeeCord: it is the price of delegating authentication and stopping halfway.

The rule: only the proxy port stays public, 25577 by default, and each backend accepts connections from its IP alone. With UFW that is one rule per backend plus the default deny on incoming. Then test from another network: if the direct connection completes, your network is wide open.

Velocity loads no chunks, simulates no entities and stores no world. It reads a packet, decides where it goes and writes it again, per player, in both directions. Raising the heap changes almost nothing: what tightens first is the packet rate and the limit on open connections.

That is why a small VPS carries the proxy while the backends sit on machines with CPU headroom. What you cannot economise on is distance: every hop between the two ends lands in the ping, and with both in São Paulo that layer drops out of the equation.