A proxy is useful when your community has a lobby and a separate survival server. It gives players one front door, while each backend keeps its own world and resources. The important part is making sure players cannot walk around that front door.
Run Velocity separately, connect it to the correct backend addresses, and configure matching forwarding secrets. Restrict backend access to the proxy; modern forwarding adds protection but does not replace a firewall.
Draw the network first
Write down the public proxy address and the private or host-approved address of each backend. For example: Velocity → lobby and Velocity → survival. Each process needs its own allocation. A second world inside one server is not automatically a separate backend.
Confirm that your hosting arrangement permits the required internal connections and backend restrictions. Loopback addresses work only where the processes share the appropriate network namespace; two containers on one machine do not necessarily share localhost.
Start Velocity and register the servers
Use the Java version required by your chosen Velocity release. Start it once to generate velocity.toml, stop it, then edit the generated file. The following is a partial example; replace both addresses with your actual reachable backend addresses and retain the other generated settings.
online-mode = true
player-info-forwarding-mode = "modern"
[servers]
lobby = "127.0.0.1:25566"
survival = "127.0.0.1:25567"
try = ["lobby"]
Configure Paper forwarding as one matched setup
For a compatible Paper backend, follow the current PaperMC forwarding guide: enable Velocity support in Paper’s global configuration, use the same secret as the proxy, and match the proxy’s online-mode setting there. The backend server.properties online-mode setting differs from a standalone public server because the proxy performs authentication.
Never make that backend change while leaving the backend exposed to arbitrary internet clients. Do not enable legacy BungeeCord forwarding alongside modern forwarding. Use the documented configuration path for your Paper version.
Protect the backend addresses
Restrict backend game ports to the proxy’s trusted connection source using the host’s firewall or an approved private-network setup. If you cannot manage this on shared hosting, ask the provider to configure the restriction. Test that a normal player cannot join a backend directly.
Keep the forwarding secret out of screenshots and public repositories. If it is exposed, replace it consistently on the proxy and backends. Do not use a forwarded web DNS record as a substitute for protecting game ports.
Rehearse joining and switching servers
Join the public proxy with a normal, non-operator account. Verify the correct UUID, inventory, permissions and server-switching behavior. Then stop one backend briefly during a private test and confirm what the proxy tells a player.
Keep proxy and backend logs together when investigating a failed connection. A timeout between Velocity and a backend is a different problem from a player failing to reach Velocity. For Bedrock access, continue with the Geyser setup guide.
Before you finish
- Use separate proxy and backend allocations.
- Keep modern forwarding settings and secrets consistent.
- Restrict backend access and test direct-join rejection.
- Check player identity and permissions through the proxy.
Common questions
Does Velocity combine the RAM of my servers?
No. The proxy and each backend are separate processes with separate resource requirements.
Can I leave backend ports public because I enabled modern forwarding?
Use network restrictions too. PaperMC explicitly recommends a firewall; forwarding is an additional layer.
Official documentation
Commands and configuration depend on your installed software version. Check its current documentation, keep a backup and test one change at a time.
Build a setup that fits your server
Compare monthly allocations and CPU tiers, or use the plan finder for a starting estimate.
Compare Minecraft hosting plans Find a plan