One IP. Many servers. A proxy lets you connect multiple Minecraft servers together under a single address — so players can bounce between survival, creative, minigames, and hub without ever disconnecting.
/ the big picture
You know how big servers like Hypixel have a hub where you click signs or NPCs to join different games? That's a proxy network. Instead of running one server, you run several — but players see them as one seamless experience.
A proxy sits between players and your backend servers. Players connect to the proxy's IP, and the proxy decides which backend server to send them to:
A single server can only run one world, one game mode, one set of plugins. A network lets you:
/ choose your fighter
These are your two options for proxy software. One's been around forever, the other's newer and better in almost every way.
| Feature | BungeeCord | Velocity |
|---|---|---|
| Release Year | 2012 (legacy) | 2020 (modern) |
| Performance | Good, but single-threaded bottlenecks | Excellent — multi-threaded, 3-5x faster |
| DDoS Protection | Basic connection throttling | Built-in: connection limiting, timeouts, keepalive filtering |
| Modern Forwarding | Not supported | Encrypted forwarding — prevents fake proxy connections |
| Plugin Compatibility | Massive library — most existing proxy plugins are for Bungee | Good but growing — most popular plugins are ported now |
| Eaglercraft Support | EaglercraftBungee plugin works natively | EaglercraftXVelocity plugin available |
| Setup Complexity | Simple — download and run | Simple — similar process |
| Minecraft Version Support | Supports 1.7.x to latest | Supports 1.7.2 to latest, better protocol translation |
| Maintenance | Rarely updated, community forks (Waterfall) exist | Actively maintained, regular updates |
Bottom line: Start with Velocity unless you need a BungeeCord-only plugin that hasn't been ported. Velocity is faster, safer, and actively maintained.
I'll walk you through a real Velocity setup with a hub server and a survival backend. This isn't abstract — you can follow along right now.
Grab the latest Velocity JAR from velocitypowered.com. Choose the regular or "build" version — regular is fine. Save it in a folder called proxy.
Also download PaperMC for your backend servers. You'll need at least two: one for the hub, one for survival. Put each in its own folder (hub-server, survival-server).
Run java -jar velocity-3.x.x.jar once, it'll generate velocity.toml. Edit it:
If you don't need Eaglercraft support, set online-mode = true. Velocity will then verify Mojang sessions — but Eaglercraft players can't join.
Velocity uses a shared secret to verify that connections from backend servers are actually coming from your proxy. Generate one:
Put this file in both the proxy folder and each backend server's folder. Velocity reads it to authenticate connections.
Each backend server needs to accept proxy connections. In server.properties:
Also add Velocity's modern forwarding config to each backend's velocity.toml (yes, Paper reads it too). Place the forwarding-secret.txt in each backend folder.
Start each backend with java -jar paper.jar nogui to verify they work independently before connecting through the proxy.
Now register your backend servers in velocity.toml:
try defines the order Velocity tries when a player first connects. Set it to your hub/lobby server first. Start the proxy: java -jar velocity-3.x.x.jar.
If both backends connect successfully, you'll see them in the proxy's console output. Connect to localhost:25565 in Minecraft — you should land in your hub.
Players need a way to move between servers. Options:
/server survival — works out of the box with Velocity[survival] on the first line of a sign. Clicking it sends the player to the "survival" server/server <name> when clicked/server or DeluxeMenus create a clickable GUIThese plugins make a network feel like a network instead of a bunch of separate servers duct-taped together.
Without these, each server has its own chat. Players on survival can't see messages from players on creative. Cross-server chat plugins sync messages across all backend servers through the proxy. VentureChat also supports Discord bridging, private messaging, and channel-based chat (global, local, staff).
Players expect to see their friends' online status regardless of what server they're on. A cross-server friends plugin like FriendsAPI or PartyAndFriends syncs friend lists, online status, and party invites across your entire network.
Most friends plugins also support party systems — invite friends to a party, then the leader can move the whole party between servers. Essential for network play.
If survival players earn money and creative players earn money, they should be able to spend it anywhere. Use Craftconomy or AndroEconomy with a MySQL backend so all servers share the same balance database.
MySQL is key here — SQLite stores data per-server, so balances won't sync. With MySQL, all servers read/write the same data.
You already know LuckPerms from the single-server guide. On a network, you need it in SQL mode so permissions sync across all servers. A player promoted to "Mod" on survival automatically has mod permissions on creative, hub, and every other server.
You can also set per-server permissions: /lp group Admin permission set essentials.fly true server=survival — fly works on survival but not on hub.
Networks attract more attacks than single servers. On a network, you can run security plugins at the proxy level that apply to all backend servers at once:
Run these at the proxy level so blocked players never touch your backend servers at all — reducing load and log noise.
Your hub server is the first thing players see. Make it good:
Here's how real servers structure their networks. Steal these ideas.
The classic starter network. One survival world, one creative plots world, and a hub to switch between them.
Players: 20-50 • RAM per server: 2-4GB • VPS: 8GB RAM, 4 vCPU (~$25/mo)
Multiple game servers under one hub. Each minigame is its own server with its own world and plugins.
Players: 50-200 • Scaling: Add more SkyWars servers when one fills up • Use: Waterfall (Bungee fork) for better player distribution
Multiple worlds for different groups, all moderated centrally.
Key: Shared LuckPerms groups across all servers. A ban on any server bans across the network. DiscordSRV bridges chat to a staff Discord.
One network, two types of players. Java players get full Mojang auth; Eaglercraft players use AuthMe.
Note: Set player-info-forwarding-mode = "legacy" for Eaglercraft compatibility. Modern forwarding may not work depending on the Eaglercraft version.
/ stay safe at scale
One server is already a target. A network with 3+ servers is a bigger attack surface. Here's what changes at scale.
If someone compromises your survival server, they should NOT automatically have access to your hub or creative server. Each server needs its own:
Example UFW rules for a Linux VPS with a proxy on the same machine:
Backend ports are only accessible from localhost — the proxy connects to them internally. External connections can only reach port 25565.
Single-server networks can get away with SQLite. For multi-server networks, MySQL is required:
mc_economy, mc_perms, mc_coreprotectGRANT ALL ON mc_economy.* TO 'economy'@'localhost'With 3+ servers, console spam becomes unmanageable. Set up proper monitoring:
When players join, which backend do they get? Without a plan, you'll end up with 50 players on survival and 2 on creative:
max-players=30) so players spread outFor small networks (under 100 players), just set reasonable per-server limits and let players choose. For larger networks, look into Waterfall's proxy balancing plugins.
Because something will break, and here's how to fix it when it does.
This is almost always a forwarding secret mismatch. The forwarding-secret.txt in your proxy folder must be identical to the one in each backend server's folder. Check for trailing newlines or whitespace. Regenerate the secret and copy it to all servers.
Your proxy can't reach the backend server. Check: (1) are the backend servers actually running? (2) are the IP/port correct in velocity.toml? (3) is a firewall blocking the connection? (4) if using Docker, are the containers on the same network? (5) if localhost doesn't work, try 127.0.0.1 explicitly.
Make sure you have a switching plugin or permissions set for /server. On Velocity, you need to add velocity.command.server permission to your players/groups via LuckPerms: /lp group default permission set velocity.command.server true.
That's by design — each backend server is independent. If you want shared inventories, use a plugin like RedisSync or AdvancedPortals with MySQL storage. Most networks keep inventories separate per server (you want different inventories on survival vs creative anyway).
Eaglercraft uses WebSocket, not raw TCP. Make sure the EaglercraftXVelocity (or EaglercraftBungee) plugin is installed on the proxy. Also check that online-mode is set to false on the proxy, and that you're using player-info-forwarding-mode = "legacy" — modern forwarding may not work with all Eaglercraft versions.
Velocity shows the correct player count by default (sum of all backends). If it shows 0, check your velocity.toml config for player-info-forwarding-mode — if it's "modern" but backends are configured for "legacy", the count won't update. Also verify the status section of your config isn't overriding the player count.
Your MySQL connection is timing out. Add ?autoReconnect=true to your JDBC connection URL. Example: jdbc:mysql://localhost:3306/mc_economy?autoReconnect=true. Also increase the wait_timeout in MySQL config to 28800 (8 hours).
When a player switches servers, their player data is serialized, sent through the proxy, and deserialized on the new server. If it's lagging, check: (1) are you using SSDs? Network-level world switching with HDDs is painful. (2) is player data bloated? Large inventories or ender chests can slow switching. (3) You can limit inventory size with plugins to reduce serialization overhead.
Stuff people always ask when setting up their first network.
No — you can run the proxy on the same machine as your backend servers. Just use different ports and point the proxy to 127.0.0.1. For production networks with 50+ players, a separate VPS for the proxy is recommended to distribute load and add a DDoS buffer.
Velocity itself uses very little — about 100-200MB for the JVM. Most of the memory goes to your backend servers. Run Velocity with -Xms128M -Xmx256M. Backend servers need their own RAM allocation based on what they do (2GB for survival, 1GB for hub, etc.).
Yes! Velocity supports protocol translation — players on Minecraft 1.17, 1.18, 1.19, 1.20, and 1.21 can all connect to the same proxy and play together. Backend servers should be the same version, but the proxy translates the protocol for clients. This is one of Velocity's biggest advantages over BungeeCord.
Proxy plugins run on the proxy JAR and affect the whole network — chat bridging, server switching, player counting, connection throttling. Backend plugins run on individual servers — CoreProtect, GriefPrevention, gameplay mechanics. Most plugins are backend plugins. Proxy-specific plugins go in the proxy's plugins/ folder (they're usually labeled "BungeeCord" or "Velocity").
Strongly recommended but not strictly required. With a domain, you can use Cloudflare to proxy connections and hide your IP. For the proxy itself, you just need one domain (play.yourserver.com). The backend servers don't need domains — they're internal. Without a domain, players connect to your raw IP, which works but is harder to secure.
Three layers of defense: (1) Firewall — backend ports only accept connections from localhost or the proxy's IP, (2) Velocity modern forwarding — backends only accept connections that present the correct forwarding secret, and (3) Don't publish backend IPs — players should only ever know your proxy's address. If someone does find a backend IP, the forwarding secret stops them from connecting directly.
Get a $10-15/mo VPS from Hetzner or BuyVM with 4 vCPU and 8GB RAM. Run the proxy and 2-3 backend servers on it. Use Docker to manage them. If you grow past 50 players, scale up to a bigger VPS or split servers across multiple VPSs. For zero cost, run everything on localhost and expose port 25565 via ngrok or a tunnel — but this is only for testing, not production.
Not completely. Some plugins are only compatible with BungeeCord (or its fork Waterfall). If you need a specific plugin that hasn't been updated for Velocity, use Waterfall (a maintained BungeeCord fork). But for any new network, start with Velocity. It's objectively better in every metric and most plugins are ported now. The only reason to use BungeeCord in 2025 is legacy plugin compatibility.