Proxy network#
A Velocity or BungeeCord proxy in front of several game servers. Players register once, on the proxy, and can then move freely between every server on the network.
The shape of it#
Proxy slimelogin.jar accounts, passwords, /login, /register, license key
├─ lobby slimelogin.jar bridge: player frozen until authenticated
├─ boxpvp slimelogin.jar bridge
└─ survival slimelogin.jar bridge
The proxy authenticates. The backends only enforce the result.
Why put it on the backends at all?
A proxy never sees movement, block breaking, inventories or damage — those happen on the game server. Without the jar on the backends, an unregistered player could walk around your lobby for the 30 seconds before the kick timer fires. See Bridge mode.
1. Proxy configuration#
online_mode: false
ip_forward: true
servers:
lobby:
address: 127.0.0.1:25566
restricted: false
boxpvp:
address: 127.0.0.1:25567
restricted: false
survival:
address: 127.0.0.1:25568
restricted: false
listeners:
- priority: 0
default_server: lobby
BungeeCord has no forwarding secret
ip_forward alone does not prove a connection came from your proxy. Firewall the backend
ports so only the proxy's address can reach them, or add a BungeeGuard-style plugin.
Without that, anyone who knows a backend's address skips your login system entirely.
The plugin's own config is the same on both:
license-key: "YOUR-KEY"
premium-bypass:
enabled: true
mode: auto
protection:
block-chat: true
block-commands: true
block-server-switch: true # no /server before logging in
2. Every backend server#
That is all. Drop the jar in and it detects the proxy, switches to bridge mode and writes a seven-line config it barely uses.
Close the backend ports
On Velocity, modern forwarding makes a backend reject any connection without the proxy's secret.
BungeeCord has no such check. Either way, add a firewall rule so only the proxy can reach the
backend ports — otherwise anyone who knows your-ip:25567 connects straight to BoxPvP and never
sees your login system.
3. What a player experiences#
- Connects to the proxy and lands on
lobby. - Frozen — cannot move, chat, run commands or switch server.
/register mypass mypasson the proxy.- Unfrozen instantly.
- Walks into the BoxPvP portal → no second login. The proxy tells BoxPvP they are already authenticated as they arrive.
They stay authenticated until they disconnect or run /logout. On their next visit, a valid
session or trusted IP usually logs them in with no password at all —
premium players never type one, and neither do
Bedrock players.
Do you need a limbo server?#
No — bridge mode covers it. But if you already run a limbo, or you prefer unauthenticated players never to touch a real server, you can use both:
auth-server:
enabled: true
server: "auth" # a server name from your proxy's configuration
lobby: "lobby" # where to send them once they log in
Migrating an existing network#
Copy players.db from the old server's plugins/slimelogin/ into the proxy's
plugins/slimelogin/. Same schema, same passwords.
Common mistakes#
| Symptom | Cause |
|---|---|
| Asked to log in twice | An auth plugin still installed on a backend, or mode: standalone forced there |
| Premium players get "Invalid session" | Online mode is on at the proxy — set online-mode = false (Velocity) or online_mode: false (BungeeCord) |
| Player can move before registering | Jar missing from that backend, or forwarding not set up so it never went into bridge mode |
| Players can reach a game server directly | Backend ports open to the internet — firewall them, and use modern forwarding on Velocity |
| Bedrock players are asked to register | bedrock-autologin turned off, or Geyser is not using Floodgate |