Troubleshooting#

The plugin keeps running rather than switching itself off — an auth plugin that disables itself leaves the server wide open, which is worse. It just stops admitting players.

• missing_key — no key in config.yml.
• bad_signature — something is intercepting the connection to the license server. Check for a proxy or a hosts entry redirecting license.devlio.store.
• no_connection — the server has no outbound HTTPS. After one successful check the plugin runs for 72 hours offline on the stored answer.
• expired / invalid — renew at devlio.store.

The SQLite database could not be opened. Usually a permissions problem on the plugins/slimelogin/ folder, or a full disk. Players are refused rather than let in unauthenticated.

• Is premium-bypass.enabled: true?
• Is the server actually in offline mode? (online-mode=false / online-mode = false)
• Can the server reach api.mojang.com? A blocked outbound connection means every name looks non-premium. The console warns when a lookup fails.
• In mode: command, the player has to run /premium once first.

Online mode is on where it should not be. The plugin does the Mojang verification itself, per player, so the platform must be in offline mode:

• Velocity — online-mode = false in velocity.toml
• BungeeCord — online_mode: false in config.yml
• Single server — online-mode=false in server.properties

Their name belongs to a real premium account, so the name is reserved for its owner — that part is correct. The screen they get depends on their client:

• 1.20.2 and newer — they should see your kick-premium-name message. If they do not, check protect-premium-names: true and turn on premium-bypass.debug to see what UUID the client claimed.
• Older than 1.20.2 — the client does not send a UUID, so nothing can be compared before Mojang is asked. The connection ends inside the encryption handshake and the client prints Failed to log in: Invalid session. No server can replace that screen.

A modern client that still sees it deliberately claimed the premium account's UUID; Mojang then refuses it, which is the correct outcome.

Two authentication systems are running. Check every backend server for:

• another auth plugin (nLogin, AuthMe …) — remove it;
• mode: standalone forced in a backend's config.yml — set it to auto.

A backend must be a bridge, not a second authenticator.

Exactly what it says: somebody joined that backend and it never announced itself, so nothing there is holding unauthenticated players. Put the same jar in that server's plugins/ folder and restart it — it detects the proxy and switches to bridge mode by itself.

The message appears once per server, the first time a player lands on it. If you use an auth-server instead, it is not printed at all.

That backend is not in bridge mode. Its console will say which mode it picked at startup. If it says nothing about bridge mode:

• the jar is missing from that server, or
• proxy forwarding is not enabled there, so it never detected the proxy. Set proxies.velocity.enabled: true in config/paper-global.yml (behind Velocity) or settings.bungeecord: true in spigot.yml (behind BungeeCord), or force mode: bridge.

They should join straight through. Check, in order:

• premium-bypass.bedrock-autologin is true;
• Geyser is using Floodgate for authentication, not a password-based mode — without Floodgate there is no Xbox identity to trust;
• the console line when they join. A Bedrock player logs as Name (Bedrock via Floodgate) - auto logged in. If it says something else, turn on premium-bypass.debug and send the output.

The backend accepts proxy logins without a shared secret, so anyone who can reach its port directly bypasses the login system entirely. Set up modern forwarding, or firewall the port to the proxy's IP. Details

Working as intended — a modified client tried to tell a backend it was authenticated and the proxy threw the message away. Worth noting the player's name.

The backend never got the unlock message.

• Is the Slime Login jar on the proxy as well? A bridge alone keeps everyone locked, by design.
• Look for [Bridge] errors on either side.
• Try /slimeadmin forcelogin <player> — if that frees them, the messaging path works and the problem is in the login flow instead.

• Was their account using PBKDF2 in nLogin? That is the one format that cannot be carried over — the import counts them and tells you how many. Those players must register again. BCrypt, MD5, SHA-256, SHA-512 and Argon2 all come across working.
• Did the import run with overwrite over an account they had already made here? The newer password would have been replaced.

Its stored hash is in a format nothing recognises — a truncated row, or a hash from a plugin that was never imported. It reads as a wrong password rather than an error, so nothing in the console points at it. Reset it:

/slimeadmin changepass <player> <newpassword>

BCrypt is deliberately slow — that is what makes it hard to crack. It runs off the main thread, so the server is not affected. If logins take too long on weak hardware, lower security.bcrypt-rounds to 10.