Skip to main content

Players cannot join: follow the connection checks

Use this route when a service appears running but one or more players cannot enter. Start with what fails, then narrow the check. A timeout, refusal or failed login suggests where to investigate; it is not a definite diagnosis. Keep the server's authentication, whitelist and assigned allocations intact.

Choose the closest symptom

Use Tab and Enter to follow links, or tap one on mobile. The full checklist remains visible without scripts.

1. Is the game actually ready?

Check: read the current console or latest log for completed startup and an active process. “Running” in the panel can include a game still loading a world. Check whether installation or restoration is in progress before attempting another operation.

If startup has an error: use the existing startup guide for your game; for Minecraft, collect the first startup error. If the browser console itself fails: use the console connection guide. If readiness is confirmed: check the player address.

2. Does the address match the service?

Check: copy the assigned game endpoint from this service, including its port. Do not use the panel web address, a database endpoint, RCON port or a different service's allocation. Ask one authorised player to try the exact current endpoint and note the result.

If a custom domain fails but the assigned endpoint works: follow the Minecraft DNS/domain checks; that is evidence to inspect DNS rather than reinstalling the server. Use the edition-specific connection format when entering a Minecraft address.

If the correct endpoint also fails: check whether anyone else can join. If yes, follow the single-player branch. If nobody can, check the game-specific route and then report the failed path. Do not open all firewall ports or assign yourself an unallocated one.

3. What does the login error say?

Record the complete player-facing message and matching server log time. A rejection shows more than a generic timeout, but its cause still needs confirmation.

  • Version/protocol mismatch: compare the client's edition and exact version with the server and supported compatibility plugins. Use the Minecraft error guide; do not downgrade a world merely to match one client.
  • Whitelist, ban or permission denial: have authorised staff check the specific account through the access-management guide. Keep authentication enabled. A player request alone does not authorise removing a ban.
  • Missing mods or resource mismatch: compare the required pack and loader with the player's installation. Use the modpack compatibility procedure before altering server files.
  • Unrecognised message: send the exact text privately, not a paraphrase such as “broken.”

4. Does only Bedrock fail?

Check: record the Bedrock client version, Geyser build, configured transport/signaling mode and allocated Bedrock endpoint. Java and Bedrock connection paths differ. Follow the Geyser/Floodgate guide for the installed release.

For NetherNet-capable deployments, the current Geyser setup documentation and NetherNet transition notes distinguish built-in TCP signaling plus UDP gameplay from external signaling arrangements. Old UDP-only advice is not universally sufficient. Ask support to confirm the exact allocation and mode; do not reuse the Java port blindly or disable host protection.

If another Bedrock player joins: check the affected player's path. If all fail: include the transport details in the report. Do not change account authentication to disguise a network error.

5. Is one player or network affected?

Check: compare a successful and failed attempt at the same time, recording client versions and exact addresses. Ask the affected player to check normal account sign-in and their edition's connection method. With permission, compare another connection such as a personal hotspot, considering data charges. Do not request their account password.

If only one network fails: retain that evidence for support or the player's network provider. Do not direct players to disable security software wholesale. If the failure follows one account across networks: revisit the login/access message. If everyone now fails: return to readiness.

6. Match the game and network mode

Use Rust endpoint checks, FiveM joining checks, ARK Ascended checks or Valheim Steam/crossplay checks. Browser listing, direct joining and administration can use different paths. Do not treat one successful path as proof of all the others.

Outcome: verify access or request a path investigation

After one supported correction, repeat the original join attempt with an ordinary player. Verify the expected world and access rules. If unsuccessful, report the service ID, game/build, time, public endpoint, full error, affected editions and whether others can join. Redact tokens and private logs. Return to symptom choices.