\"Did You Forget To Enable BungeeCord / IP Forwarding?\" And The Security Hole Behind It

If you have ever set up a Minecraft network, you have seen this:

Unexpected disconnect during server login,
did you forget to enable BungeeCord / IP forwarding on your server?

It is the single most common proxy setup error. The fix takes five minutes. But there is a second half to this that a lot of guides skip, and it is the reason people end up posting "my server got hacked again" a few weeks later.

Why the error happens

A proxy (BungeeCord or Velocity) sits in front of your backend servers. Players connect to the proxy, the proxy authenticates them with Mojang, then hands them off to a backend server.

Because the proxy already did the authentication, your backend servers are told not to authenticate. They run with online-mode=false and simply trust whatever player information the proxy forwards to them.

That forwarding has to be switched on explicitly on both sides. If the proxy is forwarding but the backend is not expecting it (or the reverse), the login handshake fails and you get the error above.

The fix for BungeeCord

Three settings, all of which must agree:

1. On every backend server, spigot.yml:

settings:
  bungeecord: true

2. On the proxy, BungeeCord's config.yml:

ip_forward: true

3. On every backend server, server.properties:

online-mode=false

Then check the boring stuff, which is what actually catches most people:

• Every backend server must be listed under servers: in the BungeeCord config, and the port there must match that server's server-port in server.properties.
• Every backend must run on a different port.
• Backend ports must not be the same as the proxy's host port. The proxy is the only thing players connect to.

The fix for Velocity (modern forwarding)

Velocity's modern forwarding is different and more secure, because it signs the forwarded data with a shared secret. Do not mix the two up.

1. On the proxy, velocity.toml:

player-info-forwarding-mode = "modern"

Velocity generates a forwarding.secret file. Open it and copy the value. Do not share it, and do not commit it anywhere public.

2. On every backend Paper server (1.19 and newer), config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'paste-the-secret-here'

On Paper 1.18.2 and older these live in paper.yml under settings.velocity-support.enabled, .secret and .online-mode.

3. On every backend server, server.properties:

online-mode=false

4. Important: on every backend, spigot.yml must have settings.bungeecord: false. Leaving BungeeCord forwarding on while using Velocity modern forwarding is a very common cause of this exact error on Velocity networks.

Now the part that matters more

Look again at step 3 in both setups. Your backend servers run with online-mode=false. They do not check with Mojang who anyone is. They believe whatever they are told.

That is completely fine as long as the proxy is the only thing that can reach them.

If a backend server port is reachable from the open internet, anyone who finds it can connect straight to it, skip the proxy entirely, and claim to be any username they like. Including yours. Including your admins'. They arrive already trusted, and any permissions attached to that name are theirs.

This is what is actually happening in threads titled "hacker logged in with a localhost IP" or "my server got hacked again". Nothing was cracked. The front door was simply left open behind the proxy.

Closing that hole

Bind backends to localhost where you can. If your proxy and backends are on the same machine, set each backend's server-ip to 127.0.0.1 in server.properties. Nothing outside the machine can then reach them at all.

Firewall the backend ports. If backends are on separate machines, allow inbound connections on those ports only from your proxy's IP, and drop everything else. This is the single most important step on a multi machine network.

Use modern forwarding if you can. Velocity's modern mode requires the shared secret, so a direct connection without it is rejected even if the port is reachable. It is a real second layer, not a replacement for the firewall.

On BungeeCord, add BungeeGuard. Plain BungeeCord IP forwarding has no secret and no way to verify that a connection genuinely came from your proxy. BungeeGuard adds a token check that closes that gap. If you are on BungeeCord and exposed, install it.

Never expose a backend just to "test" it. Temporarily opening a backend port to check something is how a lot of these incidents start.

Quick checklist

Before you call a network done:

1. Proxy and backends agree on forwarding mode (both BungeeCord, or both Velocity modern, never mixed).
2. Every backend has online-mode=false.
3. Every backend is on its own port, and those ports match the proxy config.
4. Backends are bound to 127.0.0.1, or firewalled to accept only the proxy's IP.
5. Velocity networks: secret matches on both sides, spigot.yml bungeecord is false.
6. BungeeCord networks: BungeeGuard installed if backends are not fully isolated.
7. You have tried connecting directly to a backend port from outside. It should fail.

That last one is worth doing deliberately. If you can reach a backend directly from your own connection, so can anyone else.

Space-Node's BungeeCord network hosting keeps backend servers isolated behind the proxy by default, so the direct connection path is closed without you configuring anything. If you are moving an existing network over, open a ticket and we will check the forwarding setup with you.

Related: Velocity vs BungeeCord, which proxy to use, Velocity and BungeeCord network setup guide

---

Running a Minecraft network? View BungeeCord Network Hosting