A backend server turned the proxy's player away over player info forwarding

[19:42:06 INFO]: [connected player] ExamplePlayer (/203.0.113.24:52611) has connected
[19:42:08 ERROR]: [connected player] ExamplePlayer (/203.0.113.24:52611): disconnected while connecting to survival: This server requires you to connect with Velocity.

What it means

Behind a proxy, the backend servers do not check players with Mojang themselves: the proxy does. To tell a backend who a player really is (their name, UUID, skin and IP address), the proxy can send that information along with the connection. This is called player info forwarding. Velocity has its own “modern” forwarding protected by a shared secret; BungeeCord and Waterfall use “IP forwarding” (also called legacy or BungeeCord forwarding).

Both sides must agree. When the backend expects forwarding the proxy does not send, or the proxy sends forwarding the backend does not expect, or the secrets differ, the backend refuses the player while they connect. Every join to that backend fails the same way until the settings match; the proxy and the other backends keep working.

Why it happens

The reason names which mismatch it is:

• velocity_secret_mismatch: the proxy sends Velocity forwarding with a secret the backend does not accept.
• velocity_not_enabled_on_backend: the proxy sends Velocity forwarding, but the backend is not set up for it.
• backend_requires_velocity: the backend expects Velocity forwarding, but the proxy sends none.
• backend_requires_bungeecord: the backend expects BungeeCord forwarding, but the proxy sends none.
• bungeecord_not_enabled_on_backend: the proxy sends BungeeCord forwarding, but the backend does not expect it.

It usually follows a change on one side only: a config file edited, a plugin or guide that turned forwarding on, or a backend copied from another network.

How to fix

Decide which forwarding the network uses, then make both sides say the same and restart them.

1. Velocity modern forwarding: in the proxy’s velocity.toml, set player-info-forwarding-mode = "modern" and keep the secret in forwarding.secret (or the file forwarding-secret-file names). On every Paper backend, in config/paper-global.yml, set proxies.velocity.enabled: true, online-mode: true and the same secret. Modern forwarding needs Paper (or a mod that supports it) on the backend.
2. BungeeCord IP forwarding: in the proxy’s config.yml, set ip_forward: true. On every backend, set settings.bungeecord: true in spigot.yml.
3. No forwarding: set player-info-forwarding-mode = "none" in velocity.toml or ip_forward: false in config.yml, and turn forwarding off on the backends (proxies.velocity.enabled: false, settings.bungeecord: false). The backends then see every player under an offline UUID.
4. Restart the backend and the proxy after the change, and try to join again.

Whatever you choose, keep the backends’ own port closed to the internet: a backend in offline mode that players can reach directly lets anyone join under any name.

In Perland

Perland writes a network’s proxy with player info forwarding off and runs its backends in offline mode behind it, so a network as Perland made it never shows this issue. It follows a change to a config file or a plugin: put velocity.toml or config.yml back to no forwarding, or set the backend’s paper-global.yml or spigot.yml back, in the backend’s files, and restart it. Perland’s diagnosis of the network’s proxy reports the issue with the backend and the reason.

References

• Velocity: configuring player information forwarding
• Velocity configuration reference
• BungeeCord installation guide (ip_forward and bungeecord)