Common account gates
Java Edition deployments commonly use one or combine several of these layers, followed by allowlists, bans, multiplayer eligibility, or custom access policy. Knowing the likely layer turns a vague “why can’t I join?” into a better test, not a guaranteed diagnosis.
Microsoft-authenticated online-mode=true · the default
The server asks Microsoft’s session services to confirm your client is signed into a game-owning account. This ordinarily supplies a stable account identity. Signed-in singleplayer shows the launcher has an account session; it does not prove multiplayer eligibility, session-service health, or permission to join every server that uses online mode.
Local / offline profiles online-mode=false · “cracked”
The server skips the central check and takes the name your client offers. Legitimate for LAN parties, tests, and isolated backends; risky in public, because names are claims rather than identities there.The full picture has its own page.
Proxy-verified gateway authenticates · backends isolated
Networks built on proxies (Velocity and similar) can authenticate you once at the gateway; the world servers behind it run offline-mode on purpose and trust identity forwarded by the proxy. Done right, players never notice. Done wrong — backends reachable directly from the internet — anyone can walk in as anyone. That is why serious proxy documentation treats backend isolation as a security requirement, not a tip.
Identifying the gate from outside
You usually cannot — and this desk will not pretend a status ping proves authentication mode. What you can read are the kick messages: an ownership or verification failure can look like“failed to verify username”, an account-feature requirement announces itself like “secure profile required”, and a version mismatch says “outdated”. The message suggests the next branch; it does not prove the architecture or a single fix. A verified operator requirement card is the only target-specific source this desk will treat as authoritative.