Minecraft
Geyser crossplay: check the connection before opening joins
Check Java compatibility, Floodgate identities and the TCP/UDP path before inviting Bedrock players to your Minecraft server.
A Java player joining your server proves that the Java connection works. It leaves several parts of Bedrock crossplay untested: Geyser's listener, its authentication route and the path that Bedrock clients use to reach it. Test those parts before announcing that everyone can join.
Write down the connection you are building
Record your Java server version, Java runtime, Geyser build and installation type. Add the public address and allocated Geyser port. If you use Velocity, draw the path from the player through the proxy to the backend. This small record helps you avoid changing the wrong configuration file during an outage.
Check the current Geyser support matrix before choosing a download. Geyser emulates a particular Java client version; an older backend may need a compatible ViaVersion setup. Fabric and NeoForge builds have different restrictions from the Paper plugin. Do not assume a loader update gives Bedrock clients access to Java mods that require matching client installations.
Reserve a port for the installed transport
Older guides often describe Geyser as a UDP-only service. The current setup instructions describe NetherNet using TCP for discovery and signalling alongside UDP for gameplay. A firewall rule that allows one protocol can leave the other path broken.
Use an allocated port that no other service occupies on either protocol. Check voice chat, query listeners, web maps and proxy services before reusing a number. Keep the Geyser port separate from your Java listener. On managed hosting, ask for the required allocation rather than choosing an unassigned port in the configuration.
After a normal restart, read the startup log for bind errors and the announced listener addresses. A successful Java startup message does not confirm that Geyser bound its ports. Save the relevant log lines with your connection notes so another administrator can check the same values.
Choose the intended identity route
Floodgate allows Bedrock players to join without owning a separate Java account. Follow the Floodgate setup for your platform, including its authentication setting and key handling. Treat the key as a credential; keep it out of public tickets and shared screenshots.
Use a disposable Bedrock test account to check permissions, inventory ownership and the visible player name. Confirm that your whitelist and permissions plugin recognise the identity you expect. Record that result before inviting an existing player who has valuable inventory or claims. Avoid changing authentication modes to solve a network timeout: those settings control a different part of the login.
Test both the public path and a real session
From the server console, use Geyser's documented reachability test, substituting your allocated public address and port:
geyser connectiontest PUBLIC_ADDRESS GEYSER_PORTThe official connection troubleshooting guide explains how to use this result. Treat it as a diagnostic, then join with an actual Bedrock client from another network. A local connection may bypass the external firewall or routing problem that affects your players.
- If the server does not appear, inspect the discovery and signalling path.
- If the listing appears but joining times out, investigate the gameplay path and read the Geyser log during that attempt.
- If authentication fails after a connection reaches Geyser, check Floodgate and account settings before changing ports.
Keep the exact error, timestamp, client version and network used for each attempt. Change one setting between tests. Testing several firewall, identity and version changes together makes a successful result difficult to reproduce.
Finish with the features your players use
Join, disconnect and rejoin. Check a portal, a menu-driven plugin and a permission-protected command. Include a second player on Java so you can confirm that normal Java access still works. Use the Minecraft launch checklist to record the final acceptance checks.
For NetherNet HTTPS, follow the official certificate and signalling instructions. Test the domain players will enter, not just the IP address. Plan certificate renewal and the required reload or restart. Ask your host which HTTPS arrangement they support before adding a reverse proxy.
Crossplay compatibility and geographical latency need separate checks. Once login works, use the server location guide to judge whether your Java and Bedrock players can share the same region with acceptable latency.
