> ## Content Index > Fetch the complete content index at: https://dedicatedmc.io/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Scaling to a network with Velocity - URL: https://dedicatedmc.io/blog/scaling-with-velocity/ - Published: 2026-08-24T10:00:00.000Z - Updated: 2026-10-30T12:21:13.000Z - Description: When one server is not enough, how a Velocity proxy ties several Minecraft servers into one address, and the security rule you must not skip. - Author: Mark E - Tags: Guide, Minecraft, Networking, Server Admin Most SMPs never need more than one server, and it is worth saying that plainly before anything else. A single well-tuned box carries a surprising number of players. The reason to add a second server is almost never raw performance alone. It is structure: you want a creative world that does not share rules with survival, a minigames lobby, or a way to split simulation so one busy area does not tax the whole community. When that day comes, the tool that ties several servers into one address is a proxy, and the modern choice is Velocity. This post covers what a proxy does, why Velocity, how the pieces connect, and the one security rule you do not get to skip. It follows on from [running a Minecraft SMP](https://dedicatedmc.io/blog/running-a-minecraft-smp), so start there if you have not built the single server yet. ## When one server is not enough The honest trigger for a network is structural, not a slow tick. A single tick thread has a hard ceiling on how much simulation and how many players it can carry, and no amount of tuning moves that ceiling once you are against it. More often, though, you split for design reasons: survival and creative want different gamerules, a minigames mode wants its own world that resets, and a lobby gives players somewhere to land and choose. If you are building a community or content around the server, the shape of that is covered in [running a Minecraft server for creators](https://dedicatedmc.io/blog/minecraft-server-for-creators). If none of those apply, stay on one server. A network is real work, and running it for its own sake just gives you more to maintain. ## What a proxy does A proxy sits in front of several backend servers and presents them to players as one address. Players connect to the proxy, the proxy hands them to a backend, and moving between servers becomes an in-game transfer rather than a disconnect and reconnect to a new address. Your survival world, creative world and lobby each run as their own separate server process, and the proxy is the front door that routes players between them without them ever seeing the join screen twice. It also gives you one place to manage the network: one address to share, one set of forced hosts, and one point where players enter. ## Why Velocity Velocity is the modern proxy for this job. It is actively maintained, it is built for current Minecraft versions, and it is faster and lighter than the older proxy software a lot of guides still assume. For a new network there is little reason to reach for anything else. It supports the modern forwarding model described below, which is the secure way to tell backends who a player really is, and it handles large numbers of concurrent players without becoming the bottleneck it is supposed to prevent. ## Modern forwarding with a shared secret The problem a proxy has to solve is identity. When a player arrives at a backend through the proxy, the backend needs to trust who they are, and it must not accept that claim from just anyone who can reach it. Velocity's modern forwarding solves this with a shared secret: the proxy and every backend hold the same secret value, and a backend only accepts player information that is signed with it. In `velocity.toml`, set `player-info-forwarding-mode = "modern"`. Velocity writes a `forwarding.secret` file next to the config on first start, and that file holds the shared secret (you can point at a different file with `forwarding-secret-file` if you prefer). On each Paper or Purpur backend, open `paper-global.yml` and under `proxies.velocity` set `enabled: true`, `online-mode: true`, and `secret:` to the exact value from that `forwarding.secret` file. The backend's own `server.properties` must then have `online-mode=false`, because the proxy is now the thing verifying accounts. Get this wrong and either players cannot join or, worse, a backend trusts identity claims it should not. ## Connecting backend servers Each backend is a normal Paper or Purpur server, one per world or mode, registered with the proxy so it knows where to route players. You give each backend a name and its internal address in the proxy config, choose which one new players land on first, usually a lobby or your survival spawn, and the proxy handles the transfers between them from there. In `velocity.toml`, the `[servers]` table lists each backend as a `name = "address:port"` entry, for example `lobby = "127.0.0.1:30066"` and `survival = "127.0.0.1:30067"`. A special `try` list inside the same table names the servers, in order, that a player is sent to on first connection, so `try = ["lobby", "survival"]` puts them on the lobby and falls back to survival if the lobby is down. Keep the backends on the same internal network as the proxy so those hops are fast and, as the next section explains, so they are never exposed directly. ## Forced hosts Forced hosts let one proxy answer on several domain names and drop players onto a specific backend depending on which name they used. Point creative.yourserver.net at the creative backend and the main address at your lobby, and a player connecting to the creative name lands there directly instead of walking through the lobby first. It is a quality-of-life feature rather than a requirement, but it is the tidy way to give each mode its own front door while still running everything behind one proxy. In `velocity.toml`, the `[forced-hosts]` table maps a hostname to one or more backend names, for example `"creative.yourserver.net" = ["creative"]`. A player connecting on that name is sent straight to the listed server, or to the first one that is reachable if you list several. ## The security rule you do not skip Here is the rule that matters most, and it is not optional: only the proxy is exposed to the internet, and every backend sits behind it, firewalled so nothing but the proxy can reach it. With modern forwarding, a backend trusts identity information signed by the shared secret, which means a backend reachable from the open internet can be connected to directly by an attacker who bypasses the proxy entirely. That is how offline-mode bypass attacks work, and it is why backends must be firewalled to accept connections only from the proxy's address. Bind backends to the internal network, block their game ports at the firewall for everyone except the proxy, and expose only the proxy's port to players. The full picture of running an open server safely, including online-mode, anti-cheat and rate-limiting, is in [securing a public SMP](https://dedicatedmc.io/blog/securing-a-public-smp), and this firewall rule is the part of it a network cannot leave out. Getting a network right is mostly discipline: one exposed proxy, backends locked behind it, a shared secret they all agree on, and each world running as its own tuned server. If you would rather run that on hardware and a network built for it, you can [browse game hosting](https://dedicatedmc.io/games?ref=dedicatedmc.io) and put the proxy and its backends on boxes that are genuinely yours.