If you run more than one Minecraft server, you have probably hit the same wall: players need to move between worlds, minigames, and lobbies without ever typing a new IP address. A proxy sits in front of your backend servers and turns a messy cluster into one seamless network. The two names that come up again and again are Velocity and BungeeCord. This guide exists to help you choose between them with confidence, whether you are launching your first network or migrating a busy one that already has hundreds of players online.

This article is written for server owners, network administrators, plugin developers, and staff who need a straight answer instead of forum hearsay. We built it from hands-on testing across both proxies, real deployment notes, and a close reading of the official Velocity documentation, the BungeeCord wiki, and both projects’ source code. Where the two disagree, we say so plainly.

By the end you will understand what a proxy does, how the two architectures differ under load, why modern player-info forwarding matters for security, how the plugin ecosystems compare, and exactly when to pick each one. If you are still deciding how to host the whole stack, our comparison of Pterodactyl vs Multicraft pairs well with this guide.

What a Minecraft Proxy Actually Does

A proxy is a single entry point that accepts player connections and then hands each player off to the correct backend server. Instead of publishing five different addresses for your lobby, survival world, creative plot world, and minigames, you publish one. The proxy keeps its own connection to every backend, mirrors the player list, and switches players between servers in milliseconds. To the player it feels like one giant world; to you it is a fleet of independent servers you can restart, scale, and update separately.

The proxy is also where the clever parts of a network live. It handles forced hosts, so a domain like play.example.com can route different subdomains to different lobbies. It manages tab list and scoreboard merging across servers, runs the login handshake, and often applies global chat or punishment plugins. Because every connection passes through it, the proxy is the natural chokepoint for rate limits, authentication, and whitelist logic.

• One address, many servers: players join once and travel freely.
• Central control: global chat, permissions, and bans apply everywhere.
• Independent scaling: crash one backend and the rest of the network survives.
• Forced hosts and routing: send players to a lobby based on the domain they used.

Velocity vs BungeeCord: Architecture and Performance

Architecture: How the Two Differ

BungeeCord is the original, battle-tested proxy written by md_5 and maintained under the SpigotMC umbrella. It has years of production history and an enormous plugin library. It also carries legacy design decisions from an era when Minecraft’s networking was far less flexible. Velocity, built by PaperMC, was written from scratch with modern networking, asynchronous packet handling, and a focus on performance and correctness. Its source lives on GitHub, as does BungeeCord’s.

The practical differences show up in three places: concurrency, compression, and the plugin API. Velocity processes packets asynchronously and uses a more efficient internal representation, so it tends to hold lower CPU per player, especially with hundreds of connections and heavy player-list traffic. BungeeCord does more work on a smaller set of threads, which is usually fine for small and medium networks but becomes a bottleneck at scale. Velocity also ships with native compression tuning and a cleaner, type-safe plugin API that encourages third-party code to behave correctly.

• Concurrency: Velocity handles packets asynchronously; BungeeCord is more synchronous.
• Compression: Velocity exposes native compression level and threshold control.
• API: Velocity’s API is modern and type-safe; BungeeCord’s is older but familiar.
• Maintenance: Both are actively maintained, but Velocity moves faster on modern protocol features.

Performance in Practice

On identical hardware and the same backend servers, Velocity generally wins on raw throughput. In our testing with a few hundred simulated players joining, switching, and disconnecting, Velocity used noticeably less CPU for the same player count and recovered faster during login bursts. BungeeCord was never unstable, but it needed more headroom once the player list and chat traffic grew. The gap widens the more you stress connection churn, because that is exactly where async handling pays off.

One caveat: a proxy is rarely your bottleneck. If your worlds lag, the cause is usually the backend servers, disk I/O, or a misconfigured GC, not the proxy. Velocity buys you margin and headroom, not a fix for a badly tuned backend. Our guide on containerizing your Minecraft server with Docker is a good place to standardize how those backends are deployed.

Player Info Forwarding: Modern vs Legacy

When a player joins your proxy, the proxy knows their real UUID, username, and skin. The backend server does not, unless the proxy forwards that information. How that forwarding works is the single most important configuration decision you will make, and it has direct security consequences.

Legacy forwarding injects the player’s identity into the handshake packet as a plain-text field. It is simple and works with almost anything, but it has a fatal flaw: any client can craft a handshake that claims to be a network operator or another player. This means a backend server using legacy forwarding and running in offline mode is trivially impersonatable unless it is firewalled so that only the proxy can reach it.

Modern forwarding solves this with a shared secret. The proxy and backend share a secret key; the proxy signs the player data and the backend verifies the signature before trusting it. Velocity calls this player-info-forwarding and it is the recommended default. A forged handshake from anywhere except the proxy fails verification. This is why the community repeatedly tells people to set online-mode correctly on the backend and never expose it directly.

# server.properties on each backend
online-mode=false
# velocity.toml on the proxy
[advanced]
  forwarding-secret = "a-long-random-string"

• Never trust legacy forwarding on a publicly reachable backend.
• Set backends to offline mode and block direct access with a firewall.
• Use a long, random forwarding secret and rotate it if it leaks.
• Keep the proxy itself in online mode so Mojang sessions verify real players.

Plugin Ecosystems: BungeeCord vs Velocity

BungeeCord’s biggest advantage is history. Thousands of plugins were written for it, from chat managers and anti-bot tools to lobby and punishment systems. If your network depends on an old, unmaintained BungeeCord plugin, switching proxies is not trivial. Velocity’s ecosystem is smaller but growing quickly, and most actively developed network plugins now ship Velocity builds. Many popular paid and free plugins now offer both.

Where Velocity lacks a native port, there is a compatibility bridge. The Velocity/BungeeCord compatibility plugin lets many BungeeCord plugins run on Velocity by translating the older API calls. It is a useful migration tool, but treat it as a bridge and not a destination. For anything performance-critical or security-sensitive, prefer a native Velocity build. For cross-platform networks, remember that Bedrock players route through GeyserMC, and you should check GeyserMC guidance on proxy support before committing. If you run a mixed Java/Bedrock network, our crossplay scaling guide covers the extra moving parts.

Velocity vs BungeeCord: Side-by-Side Comparison

Setting Up or Migrating to Velocity

If you are starting fresh, Velocity is the sensible default. Migration from BungeeCord is straightforward if you plan it. The outline below covers both.

1. Back up every backend server and your current proxy configuration.
2. Download the latest Velocity build from the official source and place it in a clean directory.
3. Run it once to generate velocity.toml and forwarding.secret, then stop it.
4. Set each backend to offline mode and add it to the servers section of velocity.toml.
5. Enable modern player-info-forwarding and copy the same secret to every backend.
6. Install a native Velocity variant of each BungeeCord plugin where one exists; otherwise add the compatibility plugin.
7. Firewall every backend so only the proxy can reach its port.
8. Point your DNS and forced hosts at the proxy, then test with a staging account before opening the doors.

Give yourself a maintenance window. Cut over during low traffic, keep the old BungeeCord setup intact until you are sure, and watch the proxy console and your backend logs together during the first hour. Networking details like DNS, tunneling, and port exposure are covered in our port forwarding and tunnels guide.

Security Hardening Checklist

• Keep the proxy in online-mode so Mojang verifies real sessions.
• Set backends to offline-mode and never expose them to the internet.
• Firewall backend ports so only the proxy’s IP can connect.
• Use a long random forwarding secret shared between proxy and backends.
• Enable proxy-level rate limiting to blunt bot floods and connection spam.
• Lock down the proxy console and restrict who can issue remote commands.
• Keep everything updated; proxy exploits are rare but devastating when they land.

When to Choose Each

Choose Velocity When

• You are building a new network and want the modern, supported path.
• You expect to scale past a few hundred concurrent players.
• Your plugins have native Velocity builds or viable alternatives.
• You care about security defaults and modern forwarding out of the box.

Choose BungeeCord When

• You depend on legacy plugins that have no Velocity equivalent.
• Your network is small and stable and you value zero migration effort.
• Your team already knows BungeeCord config and you need it working today.

In short, Velocity is the stronger technical choice for most new deployments. BungeeCord remains a valid choice when legacy compatibility outweighs performance and modernization.

Common Mistakes and Expert Tips

Most proxy problems come from a handful of recurring errors. Avoid these and your network will be stable from day one.

• Exposing backends to the internet. If your survival server is directly reachable, players can join it and bypass the proxy, including its permissions, rate limits, and whitelist.
• Mixing online-mode states. Proxy online-mode with offline-mode backends is correct; getting it backwards breaks UUIDs and lets impersonation in.
• Using legacy forwarding by default. Modern signed forwarding exists precisely to stop forged identities. Turn it on.
• Ignoring the forwarding secret. A short or reused secret weakens the whole trust chain. Use a long random value.
• Porting every plugin blindly. Some BungeeCord plugins behave badly under the compatibility layer. Test each one.
• Forgetting fallback behavior. If a backend dies mid-session, players need somewhere to land. A fallback server keeps them in the network instead of kicking them out.

Frequently Asked Questions

Conclusion

Velocity and BungeeCord both solve the same problem: one address, many servers. Velocity is the modern, faster, more secure default, while BungeeCord stays relevant for legacy plugin compatibility. The right answer depends on your plugins, your scale, and your appetite for migration. If you are starting now, run Velocity with modern forwarding and a firewalled backend fleet; if you are running a stable legacy network, keep BungeeCord and plan a test migration before you commit. Whichever you choose, configure forwarding, firewalls, and fallbacks carefully, and your players get the seamless network they expect. Ready to build? Pick your proxy, lock down those backend ports, and launch your first test network this week.