No One Can Join the Java Server After the Bedrock Update: How to Check Geyser Systematically

1. Narrow It Down First: Who Really Can’t Get In?

“Nobody can get in” might mean that three friends installed the same new Bedrock version. It can also mean the entire Java server is offline. These cases call for different investigations. Before you change anything, write down four observations:

• Does a Java join work with a Java game version the server supports?
• Do all Bedrock devices fail, or only one device, one account, or one console?
• What full version number does each affected game show? Is it the regular release or a Preview/Beta?
• What does it say word for word on the screen, and when was the attempt made?

Fully restart the game once on an affected device. Then use the same address and port as in the documented attempt. That is a cross-check, not proof that the client was at fault. Don’t change the network, the account, and the server address at the same time: if it then works, you won’t know which change helped.

An unreachable Java server is a separate fault to begin with. Check its running state, its address, and its startup messages before you swap out Geyser. Geyser’s documentation generally places failed Java connections outside the Bedrock bridge itself. Connection troubleshooting

Your first success criterion: You can assign the fault to a group: all connections, Bedrock only, one client only, or one access path only. “Still unclear” is an honest finding too; a suspected cause is not yet a measurement.

Back to contents

2. The Decision Tree: From Symptom to Next Test

Read this tree from top to bottom. Only move on once the observation in question is established. The examples are typical diagnostic cases, not customer outages we measured.

• Can Java players get in?
  • No: Check the Java service and its network access first. A Geyser update on its own is not a reliable repair plan.
  • Yes: In the next branch, find out whether all Bedrock devices fail or only individual access paths.
• Do all Bedrock devices fail?
  • No, only one console: Check the console-specific connection path. If Bedrock on mobile or Windows works, don’t change the working access for everyone as a precaution.
  • No, only one device or account: Record its full version and sign-in; repeat the attempt under the same conditions.
  • Yes: Record the loaded Geyser build and the client versions. With 26.60, the NetherNet check comes next.
• How far does the connection get?
  • No server shown, or only a generic connection error: Compare address, port, transport, and the matching listener. A missing log line doesn’t automatically mean “broken client.”
  • Server visible, join times out: After signaling, check the UDP game path. A visible server list does not prove a complete join.
  • Geyser reports an error about the Java target: Check the Java address, TCP port, and accepted protocol version from the point of view of the Geyser instance.
  • Sign-in is rejected: Check the intended sign-in path and Floodgate. Don’t turn off authentication as an experiment.
  • Sign-in works, then the player is disconnected: Read the kick message from the matching time. Only then check resource packs, access rules, or extensions on the test copy.

Important: A working third-party test server only shows that this client could reach that other server. Conversely, an attempt that also fails there does not prove a pure client problem: both tests may share the same Wi-Fi, the same internet connection, or the same console relay service. So always note what stayed the same and what changed.

Back to contents

3. Version Matrix: Four Numbers You Must Not Mix Up

Minecraft Java Edition, the Java runtime, Geyser, and Minecraft Bedrock all have different version numbers. “Updated Java” is therefore not a sufficient diagnosis. A new Java runtime doesn’t turn an old Minecraft world into a current game version; a new Geyser JAR doesn’t update a Bedrock client.

As of the check date, Geyser lists Bedrock 26.40–26.60 and emulates a Java 26.3 client. The Java connection path has to accept this client. Older servers may need a suitable protocol translation. According to the current versions page, Geyser-Spigot requires at least Minecraft 1.20.5 and Java 21; the Fabric/NeoForge editions are tied to the current Java game version. These limits are platform-specific. Supported versions

Fill in the table for your setup. Don’t enter a version taken from the file name as the measured runtime state. A file can have been replaced while the process is still running the old code. With a proxy, the build of the Geyser instance loaded there belongs in the table; a backend’s plugin list doesn’t answer this question.

In the console of the instance Geyser runs on, these read-only commands are helpful:

geyser version
geyser help

In-game, these commands usually need a leading slash and the right permissions. geyser version shows the Geyser version and checks for updates; geyser help shows the available commands. An unknown command can mean the wrong console, a plugin that didn’t load, or a different Geyser edition. Command reference

Don’t mix these up: A version number in the MOTD is freely editable display text. It replaces neither the startup log nor the protocol information of the running server. Likewise, without proof of the build, an “up to date” label in the hosting panel doesn’t tell you which instance your friends are reaching.

Back to contents

4. The Special Update Case: Bedrock 26.60 and NetherNet

Geyser’s announcement from October 8, 2026 describes the move away from RakNet for 26.60 and gives October 27 as the date planned at the time. Mojang’s official 26.60 changelog is dated October 27, 2026. What matters for diagnosis is the client version actually installed. The announcement names build 1237 as the start of NetherNet support; that is not a recommendation to use this old minimum build instead of a current, matching build. Geyser announcement

With NetherNet, there is an additional exchange before any game traffic: signaling negotiates the connection, and then the WebRTC connection takes over. Mojang’s protocol documentation describes these separate phases. For your troubleshooting, this means that a response to a server query and a playable join are two different results. Mojang: NetherNet protocol

On your test copy, check the existing Geyser configuration and its startup output. The current setup guide shows transport: nethernet for NetherNet. Combined NetherNet and RakNet operation is still available as transport: both; in that mode, NetherNet needs a separate UDP port via webrtc-port, as the port forwarding page and the configuration file of current builds describe. Build 1280 (October 31, 2026) removed the RakNet-only transport and switches an old transport: raknet to NetherNet when it starts. Current Geyser setup

A Limited Configuration Example

The following example describes only an isolated, self-hosted test with built-in signaling, a free port 19132, and NetherNet only. It does not replace a complete configuration. Don’t copy it blindly to a hosting provider, a proxy, or an access path with external signaling.

bedrock:
  port: 19132
  transport: nethernet

For this setup, both TCP and UDP must be reachable on the Geyser port. The TCP port must not be in use by the Java server at the same time. External signaling has different requirements; with combined transport, an additional UDP port comes into play. Port forwarding by transport

Compare the snippet with the configuration generated by your build. Fill in the existing keys in their proper place rather than appending a second bedrock block. Back up the previous file and note which line you change. After a controlled restart of the test instance, read the startup messages again; saving without errors in the editor is not yet proof of a valid configuration.

Why the Same Port Number Can Suddenly Collide

Previously, a Java TCP connection could use the same number as a separate Bedrock UDP access point. Built-in signaling now needs TCP as well. If Java is already listening there, a second service can’t simply take over that binding. So check clone-remote-port and the signaling address that is actually reported. External signaling can hand out a different join address; in that case, the old saved server entry may no longer lead to the right access point. Geyser announcement: port sharing

Success criterion: You know the transport mode, where signaling runs, the game port, and the address players should actually use. Write down four separate values, even if two of them happen to look the same.

Back to contents

5. Create an Isolated Test Copy Before Making Changes

Leave the production world unchanged for now. Use your existing backup or copy method to create a consistent snapshot, and check that you can restore it. If the method requires a stopped server, plan that time with your fellow players. A world folder copied while arbitrary writes are happening is not a reliably tested way back.

The test copy should include the files relevant to the fault: server and plugin versions, the Geyser configuration, the Floodgate configuration, the proxy configuration if there is one, and the world and player data you need. Note file names, build numbers, and the backup time. Keep keys protected; they don’t belong in a public screenshot or in a diagnostic archive for strangers.

Isolation means more than a new folder. The copy needs its own ports and must not quietly use the same production database, the same plugin data store, or the same automated actions. Check permission plugins, inventory sync, shops, and scheduled tasks in particular. Where you can’t establish this separation reliably, stop the attempt and use a smaller, explicitly isolated test environment.

Work with a change log:

This is a template, not a test log from this article. Only go on to C or D if the previous finding points in that direction. If the copy is already reachable after B, don’t make further changes as a precaution. Instead, check that the result is repeatable and then check the remaining success criteria.

Back to contents

6. Is the Right Geyser Instance Even Running?

Read the startup log from the beginning. First look for the loaded Geyser output and its version, then for binding, configuration, or runtime errors. A later “server ready” may refer only to Java. If Geyser didn’t load before that, a firewall change won’t help a bridge that isn’t running.

For an update of the plugin edition, Geyser describes a full stop, swapping the JAR file, and then starting the server again. For our diagnosis, that happens only on the copy. A general plugin hot reload is not an equivalent update test. Update note

Also check whether several Geyser files or a second instance are claiming the same ports. Don’t randomly move suspicious files around in the production folder. On the copy, first compare the loaded names with the planned setup. A proxy that is there on purpose and a backend plugin installed in addition by mistake are two different situations.

A message containing Address already in use points to a binding that is already taken; an error about a newer Java runtime points to a runtime that doesn’t match. Both happen before a successful player join. So record the complete first error message with its context, not just the last follow-up exception. Geyser: common startup problems

Success criterion: The startup log confirms the expected instance without an unhandled startup error, and geyser version matches your change log. If a hosting provider manages files automatically, find out the intended update path before a manually added test file gets replaced again at the next start.

Back to contents

7. Address and Ports: Check Each Leg Separately

Sketch your actual setup. For a simple installation, the order Bedrock device → Geyser → Java server is enough. In a server network, a signaling service, a proxy, and backends come into play. Write the address, port, and protocol on every connection. That keeps you from confusing a Java port with a Bedrock port, or an internal container address with a public one.

Bedrock Can’t Reach Geyser

Compare the saved server entry with the Bedrock address the operator has confirmed. Enter the address and port in the fields meant for them. With external signaling, use the address provided for it. A Java SRV record is not automatic proof that the same name also describes the Bedrock access correctly. Address problems

With a local server, distinguish between access from the server machine itself, from your home network, and from another network. Write down the starting point next to each result. “Reachable from the server itself” doesn’t prove that router port forwarding works. “Reachable from the home network” doesn’t prove reachability via the public address.

With a hosting provider, check the assigned ports in the panel; on a VPS, also check the firewall there; and with home hosting, check the forwarding to the right device. In container environments, the required port mapping must also exist at the container boundary. A correct Geyser file can’t create these outer openings by itself. Geyser port forwarding

Don’t open all ports across the board, and don’t disable the entire firewall. Instead, document the expected path and check the one rule responsible for it. If you don’t have the rights to do that, the operator can work with a precise port/protocol specification. A general request like “Please unblock Minecraft” is too vague now that the transport has changed.

Signaling Responds, but the Join Fails

A visible server description can mean that signaling works while the UDP game path still fails. If that’s what you see, first check the UDP mapping that belongs to the active transport, not the world files again. An ordinary TCP port tester doesn’t evaluate UDP. A positive result only ever confirms the service that was actually tested.

For advanced users: Mojang describes GET /v1/join as a request that checks for NetherNet support and returns server metadata. A matching response verifies this phase; it replaces neither the exchange that follows nor the game join. An arbitrary HTTP 200 from a website sitting in front of it doesn’t count as success either. Check the content and the target of the response. Mojang: signaling flow

Geyser’s troubleshooting guide mentions geyser connectiontest <ip> <port>. Only use the command if your installed edition actually offers it, and replace both placeholders with the intended public access point. The output is a supplementary diagnosis, not complete proof of NetherNet, sign-in, and world join. Connection test

An Upstream Proxy Passes On HAProxy Headers

If a service in front of Geyser passes on the real player address via HAProxy headers, it belongs in your sketch as a leg of its own. Geyser’s NetherNet announcement describes the situation like this: at first, HAProxy headers applied to RakNet and built-in signaling, but not yet to NetherNet gameplay over WebRTC. According to the update from October 26, 2026, Geyser supports them there as of build 1272, and you have to enter the trusted addresses that send these headers in the configuration. The announcement does not name the exact key, and build 1280 (October 31, 2026) reorganized these settings: listing a proxy now turns HAProxy support on, also for RakNet in combined operation, and relays in front of the WebRTC port have a list of their own. Take the key from the configuration file of your installed build, not from a forum post. Geyser: HAProxy support

This leads to a targeted cross-check on the test copy: if the server appears but the join fails only through the upstream service, first compare the loaded build number with 1272 and 1280 and then the trusted addresses or relays you entered. If the direct path without the proxy works, the fault area is considerably smaller. An HTTPS reverse proxy in front of the signaling port is a different case: it passes on the address via X-Forwarded-For and, according to the Geyser wiki, is entered under signaling-trusted-proxies. If several proxies sit in front of signaling, list all of them; since build 1280, Geyser reads X-Forwarded-For from the right. NetherNet over HTTPS

Settings Look Right but Behave Differently

With managed installations, check the startup parameters too. Geyser documents geyserTransport, geyserSignalingPort, geyserWebrtcPort, and geyserSignalingMode, among others, as system properties. Values from startup parameters can explain why the YAML file you read doesn’t match the behavior you observe. Don’t change both places at the same time; first note which source supplies the effective value. Geyser system properties

Back to contents

8. Geyser Can’t Reach the Java Server

If a connection attempt shows up in the Geyser log, check the next leg. Where is Geyser running, and which Java address does exactly this process see? localhost always refers to the environment it is used in. With separate machines or containers, that is not automatically the machine running the Java server.

A Connection Refused message for the Java target suggests checking its service, address, port, or network access. It does not prove that Bedrock is outdated. Geyser’s troubleshooting guide attributes it to a Java service that couldn’t be found or to a rejection at the network level. Java target connection

If the target is reachable, the protocol question comes next. For older Java servers, ViaVersion may be the right fit. The direction is what matters: the server has to accept the newer Java client that Geyser emulates. Install the translation tool where your platform intends it and check its startup message. An installed file name alone doesn’t prove a working translation. Version compatibility

With a proxy, test the lobby first and then each intended backend. If the lobby works and only switching servers fails, you’ve found a narrower fault area. Document the source server, the target server, and the time. Then don’t randomly update all components at once.

Geyser is also not a blanket conversion of every Java client mod for Bedrock. A modpack that requires its own Java client installation won’t automatically become compatible through a connection update. If joining was only intended with certain limitations even before the update, those belong in your starting conditions. Platform notes

Back to contents

9. Tell Sign-In, Floodgate, and the Trust Prompt Apart

If the attempt reaches sign-in, separate three questions: Is the player signed in with the intended Bedrock account? Which authentication path does Geyser expect? Is Floodgate loaded in the place intended for this setup?

Floodgate enables the intended Bedrock access without an additional Java Edition account. Setup requires the matching Floodgate component and auth-type: floodgate in Geyser. Key and forwarding requirements differ between standalone and proxy setups. So don’t apply instructions for a single server to a network without checking them. Floodgate setup

A rejection at sign-in is no reason to turn off online-mode as an experiment. That would change the server’s trust assumptions and could produce an apparent success that no longer tests your intended access path at all. Instead, compare the expected and the actual sign-in path on the copy.

The NetherNet trust prompt is a separate matter. With built-in signaling over HTTP, a trust prompt can appear on the first join; HTTPS with a matching certificate establishes the server’s identity. Use the intended domain name. Using an IP address instead can produce a different result when the certificate was issued for a name. HTTPS for NetherNet

Don’t blindly confirm an unexpected identity change. Ask the operator about the intended target and about any planned change. Don’t delete account data, keys, or all saved servers as a precaution. You would lose observations and possibly working mappings.

Success criterion: The intended test player joins with the right account, gets their expected permissions, and doesn’t end up in the game as an unintended new identity. Check inventory and access rules against the backed-up starting state; “some player is in” is not enough.

Back to contents

10. Reading Symptoms Correctly

The following classifications are signposts. The exact wording depends on the client, language, and build. Copy the actual wording into your report.

The general error classes are documented in Geyser’s Common Issues. For the new transport, the specific NetherNet announcement and the current setup guide take precedence over older, blanket UDP advice. These sources are not worded consistently everywhere; always read statements in the context of the transport in use.

Back to contents

11. Three Traceable Diagnostic Examples

Example A: every Bedrock device fails after 26.60. Java still works. The test copy loads a build from before October 31, 2026 (1273 to 1279) that still uses the old RakNet-only transport; build 1280 and later switch that setting to NetherNet on their own. You check the NetherNet setup, including free TCP and UDP access. Then you repeat the same client attempt. Only once it succeeds do you look into the remaining devices; the timing close to the update alone would not have proven the cause.

Example B: the server shows up, but no one can enter the world. You document the visible server description and the timeout that follows separately. On the copy, you compare the UDP mapping with the effective game port. A confirmed signaling response narrows the search, but it doesn’t clear the UDP path. Changing Floodgate on top of that would needlessly skew this attempt.

Example C: mobile works, console doesn’t. The working mobile join shows that the server is reachable in principle under these conditions. You now check the console path and the connection method it supports. Geyser maintains a separate guide for this. Third-party methods can change; their availability is not a property of your world file. Geyser with consoles

These examples describe the method, not guaranteed causes. If a test disproves the assumption, document exactly that and go back to the last confirmed observation.

Back to contents

12. Verify the Fix and Secure Your Way Back

A fix is only reliable once you can repeat it. On the copy, check the original failure case with the same regular Bedrock version, then a second intended client and Java access. If you play from different networks, an external join is part of this. With a proxy, also check switching to the backends you actually use.

Don’t just check that the player appears in the player list. Have the test player fully load the world, move around, reconnect, and use their expected permissions. Check the features that matter to your group and compare the logs for new errors. These criteria are a suggested acceptance framework, not playtests carried out here.

Then document:

• The original error and a reproducible test path.
• Changed files or settings, with the previous and the new value.
• Loaded versions after the restart.
• Tested devices, networks, and account paths.
• Remaining limitations and the prepared way back.

Only from this record do you derive a planned change to the real server. Apply only the proven fix, not the entire experimental state. A way back for a plugin update includes its matching configuration. A world downgrade is something else and does not belong in this process as a spur-of-the-moment repair step.

Back to contents

13. An Error Report to Pass On

If you don’t administer the server yourself, send the operator this information. Leave out passwords, tokens, and private keys. Check full logs for personal and confidential content before sharing them.

Problem: Bedrock join fails after update
Time with time zone:
Bedrock version and device:
Regular release or Preview/Beta:
Error message, word for word:
Java join: works / fails / not checked
Other Bedrock devices:
Connection method used: direct / console / relay service
Address and port: only in the appropriate private support channel
Geyser platform and loaded build, if known:
Transport and signaling mode, if known:
Log excerpt from that time, cleaned up:
Cross-checks already done and their results:
Changes so far: none / test copy only, details

geyser dump creates additional diagnostic data. Before using it, find out what information your installed edition collects and how it is shared. Only share a dump deliberately with the responsible support team. The command is not a repair step. geyser reload, on the other hand, changes the running state and, according to the command reference, disconnects players; don’t run it casually as a supposedly read-only check. Commands and their effects

Back to contents

14. Short Glossary

Geyser: Bridge between the Bedrock and Java game protocols. Floodgate: Add-on for the Bedrock sign-in path. Build: A specific release of a piece of software. Java runtime: The program environment that executes the server code; not the Minecraft game version. Proxy: An instance placed in front that relays connections to backends. Backend: The actual game server behind a proxy. Signaling: The preparatory exchange for setting up the NetherNet connection. Listener: A service that accepts connections on an address and port. Rollback: A prepared return to the previously backed-up state.

Back to contents

Sources and Last Review

Checked on October 29, 2026, versions, setup, and HAProxy settings rechecked on November 1, 2026 against Geyser build 1280 and the Bedrock 26.60 changelog: Geyser overview, Version support, Setup, NetherNet announcement, Port forwarding, HTTPS, Commands, Common issues, Connection troubleshooting, Floodgate, Consoles, System properties, and Mojang protocol.

Versions and transport details can change. This article documents researched requirements and a diagnostic method; it does not claim any Minecraft server or customer connection tests carried out by us.

Back to contents