Bedrock auf Java-Servern: Geyser und NetherNet

Dein Java-Server läuft seit Monaten, und deine Freunde am Handy, Tablet und Windows-PC kommen über Geyser rein. Dann ändert ein Bedrock-Update, wie das Spiel an die Tür klopft – und ein Aufbau, der immer nur UDP geöffnet hatte, steht plötzlich da wie ein Haus ohne Klingel.

Kurz gesagt

Wie kommen Bedrock-Spieler nach Bedrock 26.60 weiter über Geyser auf deinen Java-Server? Bring Geyser auf einen aktuellen Build, stell in der Konfiguration transport: nethernet ein und mach den Geyser-Port über TCP und UDP erreichbar, nicht nur über UDP [1][2]. Laut GeyserMC und Open Collaboration ist Bedrock 26.60 für den 27.10.2026 geplant, und ab dieser Version verbinden sich Bedrock-Clients nicht mehr über RakNet, das alte Verbindungsverfahren (Stand 25.10.2026) [1][9]. Kannst du keinen TCP-Port öffnen, braucht externes Signaling wie Warden nur einen erreichbaren UDP-Port [1][9][12]. Geyser lässt Bedrock-Spieler überhaupt herein; Floodgate lässt sie zusätzlich ohne gekauftes Java-Konto spielen [2][5].

Was sich mit NetherNet ändert

Bisher hat ein Bedrock-Client UDP-Pakete direkt an Adresse und Port des Servers geschickt. Das ist RakNet, und deshalb konnte der klassische Geyser-Aufbau sich eine Portnummer mit Java teilen: Java nutzt TCP, RakNet nutzte UDP, die beiden kamen sich nie in die Quere [1][9].

NetherNet stellt einen Schritt davor, das Signaling. Vor dem Beitritt schickt der Client eine HTTP- oder HTTPS-Anfrage über TCP und fragt, ob der Server NetherNet kann. Mojangs Onboarding-Anleitung beschreibt es genau: Der Client ruft GET /v1/join auf, und nur wenn der Server mit einem Erfolgsstatus antwortet, schickt er sein Verbindungsangebot per POST /v1/join/{networkId} [10]. Das Spiel selbst läuft danach über WebRTC – den offenen Standard, den Browser für Videoanrufe nutzen – auf UDP [9][10]. Auch MOTD und Spielerzahl in der Serverliste kommen jetzt über das Signaling [1].

Drei Folgen sind für dich wichtig:

• Geyser braucht zusätzlich zum UDP-Port fürs Spiel einen TCP-Port fürs Signaling. Standardmäßig nutzen beide 19132 [1][2].
• Der Geyser-Port darf nicht mehr der Port des Java-Servers sein, weil Java dort schon TCP belegt. Die Option clone-remote-port, auf die viele Hoster gesetzt haben, funktioniert nur noch mit externem Signaling [1].
• Wer per IP-Adresse oder über eine Domain ohne HTTPS verbindet, sieht beim ersten Beitritt eine Abfrage „Trust on First Use“, also eine Vertrauensfrage beim ersten Kontakt [1][10].

Daten und Versionen (Stand 25.10.2026)

Eine Mojang-Seite, die den 27. Oktober als Ende von RakNet nennt, haben wir nicht gefunden. Mojangs Changelog zu 26.50 sagt nur, dass NetherNet jetzt der Standard-Transport für Dedicated Server ist [11]. Das Datum stammt von GeyserMC und Open Collaboration, und beide knüpfen es an die Version 26.60: Verschiebt sich die Version, verschiebt sich das Datum mit.

So funktioniert’s: Geyser auf NetherNet umstellen

1. Hol den neuesten Build. Lade ihn von der Download-Seite von GeyserMC. Jeder Build ab 1237 kann NetherNet, GeyserMC empfiehlt aber den neuesten, weil spätere Builds Fehlerkorrekturen enthalten [1].
2. Nimm die Datei für deine Plattform. Geyser-Spigot gehört bei Paper oder Spigot in plugins, Geyser-Fabric zusammen mit der Fabric API in mods, Geyser-NeoForge in mods, Geyser-Velocity oder Geyser-BungeeCord nur auf den Proxy, und Geyser Standalone läuft als eigenes Programm neben dem Java-Server [2]. Geyser gibt sich als Java-26.3-Client aus: Ein Paper- oder Spigot-Server mit älterer Version braucht ViaVersion, und Geyser-Spigot selbst setzt mindestens 1.20.5 und Java 21 voraus. Unter 1.20.5 verweist GeyserMC stattdessen auf einen Proxy, Geyser Standalone oder ViaProxy. Geyser-Fabric und Geyser-NeoForge laufen nur auf einem 26.3-Server [2][3].
3. Stell den Transport um. Öffne die Konfiguration (Paper: plugins/Geyser-Spigot/config.yml, Fabric: config/Geyser-Fabric/config.yml, NeoForge: config/Geyser-NeoForge/config.yml, Velocity: plugins/Geyser-Velocity/config.yml), such bedrock: und ändere diese Zeilen [2]:

bedrock:
  port: 19132
  transport: nethernet

4. Öffne TCP und UDP. Gib den Geyser-Port für beide Protokolle frei, im Router und in der Firewall des Servers. Die Einrichtungsanleitung von GeyserMC sagt es deutlich: Über TCP finden Spieler deinen Server, über UDP spielen sie darauf, ohne TCP taucht der Server gar nicht erst auf [2]. Kein anderes Programm darf den Port nutzen – weder eine UDP-Voicechat-Mod oder Query noch eine Webkarte oder Website über TCP [2].
5. Starte neu und lies die Konsole. GeyserMC nennt typische Meldungen. „Built-in signaling cannot use port … because the Java server already uses it“ heißt, dass sich Bedrock und Java einen Port teilen. „… is a loopback address“ heißt, dass address auf 127.0.0.1 statt auf 0.0.0.0 steht [1]. Seit einer Änderung vom 16.10.2026 schreibt Geyser einen Fehler mit Link zum NetherNet-Beitrag ins Protokoll, solange NetherNet aus ist [8].
6. Teste von außerhalb deines Netzes. Öffne am Handy über mobile Daten http://DEINE-ÖFFENTLICHE-IP:19132/v1/join. Ein NetherNet-Server beantwortet diese Fähigkeitsabfrage mit JSON, darin Name, Version und Spielerzahl [10]. Danach trittst du mit einem Bedrock-Client ab 26.40 bei, so wie GeyserMC es vorschlägt [1].

Der Übergang: NetherNet und RakNet nebeneinander

Spielen manche noch mit Versionen vor 26.40, nimmt transport: both beide Verfahren an. Sie können sich keinen UDP-Port teilen, also bekommt NetherNet über webrtc-port einen eigenen, den du ebenfalls für UDP öffnest [1][2]:

bedrock:
  port: 19132
  webrtc-port: UDP_PORT
  transport: both

Ersetze UDP_PORT durch einen freien Port, der nicht port ist [2]. Die Begründung von GeyserMC: NetherNet wird ab 26.50 vollständig unterstützt, Versionen wie 26.40 holen MOTD und Spielerzahl aber noch über RakNet [2]. Sobald 26.60 da ist und alle aktualisiert haben, stellst du auf nethernet um und schließt den alten RakNet-Port [1]. GeyserMC hat außerdem angekündigt, dass die Unterstützung für 26.30 endet, sobald 26.60 dazukommt [1].

Zu Hause, beim Hoster, hinter CGNAT

• Zu Hause mit eigener öffentlicher IPv4-Adresse: Java bleibt auf seinem TCP-Port, standardmäßig 25565. Geyser bekommt einen eigenen Port, offen für TCP und UDP. Die GeyserMC-Seite zur Portfreigabe zeigte beim Abruf noch Befehle nur für UDP, die Einrichtungsanleitung verlangt inzwischen beide Protokolle [2][7]. Auf das ufw-Beispiel der Seite übertragen heißt das zwei Regeln – unsere Ableitung aus beiden Seiten: sudo ufw allow 19132/tcp und sudo ufw allow 19132/udp. In Docker veröffentlichst du den Port genauso doppelt, als 19132:19132/tcp und 19132:19132/udp.
• Beim Hoster: Bitte um einen zweiten Port, der für TCP und UDP offen ist, oder nutze externes Signaling [1]. Merkt Geyser, dass der Java-Server seinen Port schon belegt, weicht es von selbst auf Warden aus, und die Konsole zeigt, wo Spieler beitreten können. Die Spieler nutzen dann diese Adresse statt deiner Java-Adresse, außer du hinterlegst bei Warden eine eigene Domain [1]. GeyserMC beschreibt Warden als kostenlosen Dienst von Ziax, dem Unternehmen hinter CubeCraft; Warden selbst schreibt, dass es keinen Spielverkehr weiterleitet und die IP deines Servers nicht verbirgt. Außerdem nennt sich Warden „in aktiver Entwicklung“, vor allem für private Server gedacht, ohne SLA und ohne Verfügbarkeitsgarantie [1][12]. Hoster können Geyser über Startparameter wie -DgeyserTransport=nethernet vorkonfigurieren [1]. Die Liste „unterstützter Hoster“ hat GeyserMC entfernt; fehlt ein Hoster auf der neuen Liste, heißt das nicht, dass Geyser dort scheitert [1].
• Hinter CGNAT oder DS-Lite: Dein Anschluss hat keine eigene öffentliche IPv4-Adresse, also erreicht keine Freigaberegel deinen Server. Externes Signaling spart dir den TCP-Port, der Server braucht aber weiterhin einen UDP-Port, den Spieler erreichen [9]. Bleiben ein Tunnel oder ein VPS. GeyserMC nennt playit.gg und verlinkt dazu eine eigene Seite für NetherNet; Ngrok funktioniert nicht, weil es kein UDP überträgt [2].
• In Containern oder hinter NAT: Kennt der Server seine öffentliche Adresse nicht selbst, teilt -DgeyserAdvertiseAddresses den Spielern mit, welche Adresse sie nutzen sollen [1]. Eine Änderung im Geyser-Code vom 20.10.2026 lässt Geyser seine öffentliche Adresse per STUN ermitteln und legt die beiden Listen advertise-addresses zu einer zusammen, bedrock.signaling.advertise-addresses; bestehende Konfigurationen werden automatisch umgestellt [8]. Anleitungen von vor diesem Datum zeigen womöglich noch zwei getrennte Listen.

Netzwerke mit Velocity oder BungeeCord

Installiere Geyser nur auf dem Proxy. Floodgate darf auf alle Server, das hilft bei Skins und macht die Floodgate-API im ganzen Netzwerk verfügbar [2]. Jeder Server im Netzwerk muss Java-26.3-Clients annehmen, Backends mit älterer Version brauchen also ViaVersion [2][3]. Eine Lücke bleibt: HAProxy-Header funktionieren für RakNet und das eingebaute Signaling, aber noch nicht für das Spiel über WebRTC; GeyserMC kündigt das an [1].

Floodgate

Floodgate lässt Bedrock-Spieler mit ihrem Bedrock-Konto beitreten, ohne Java Edition zu kaufen. Es läuft auf Spigot und Paper, BungeeCord, Velocity und als Mod auf Fabric [5]. NeoForge steht nicht auf dieser Liste (Stand 25.10.2026) [5]. Der NetherNet-Beitrag von GeyserMC nennt keinen eigenen Floodgate-Schritt, und die Umstellung des Transports ersetzt deine Anmeldeeinstellungen nicht [1]. Bei Geyser Standalone setzt du in dessen Konfiguration auth-type auf floodgate und kopierst die Datei key.pem von Floodgate vom Java-Server in den Ordner von Geyser Standalone. Gib diesen Schlüssel nie weiter: Mit ihm umgehen Bedrock-Konten die Java-Anmeldung [15]. Den Java-Server auf Offline-Modus umzustellen, empfehlen wir nicht; Floodgate ist der vorgesehene Weg.

HTTPS und die Vertrauensfrage

Mojangs Anleitung erklärt die Abfrage. Über HTTPS ist das Zertifikat der Vertrauensanker, und der Spieler sieht nie einen Dialog. Über reines HTTP fragt der Client einmal pro Betreiberschlüssel und nimmt danach still an. Vertraut wird dem Schlüssel, nicht der Adresse, und ein neuer Schlüssel lässt jeden wiederkehrenden Spieler erneut bestätigen [10]. Geyser bietet zwei Wege zu HTTPS: ein Zertifikat in der Konfiguration des eingebauten Signalings oder einen Reverse Proxy vor dem Signaling-Port. Auch Warden liefert HTTPS mit [1]. Sichere den ganzen Konfigurationsordner von Geyser, damit eine Neuinstallation deinen Spielern keinen neuen Schlüssel vorsetzt.

Spieler auf Konsolen

Minecraft auf Xbox, PlayStation und Switch hat kein Feld für einen eigenen Server. Das GeyserMC-Wiki verweist auf BedrockConnect, ein Drittprojekt, das du über eine geänderte DNS-Einstellung der Konsole erreichst [6]. Dessen neueste Version 1.71.0 vom 15.09.2026 bringt Unterstützung für 26.50; keine Version erwähnt NetherNet oder 26.60 (Stand 25.10.2026) [13]. Ob der DNS-Weg nach 26.60 noch funktioniert, ist unbelegt. Sag deinen Konsolen-Spielern vor dem Update Bescheid, damit am Tag selbst niemand vor verschlossener Tür steht.

Noch offen (Stand 25.10.2026)

• Das Datum für 26.60 ist ein Plan, keine Veröffentlichung [1][9].
• Noch kein Geyser-Build unterstützt Bedrock 26.60. Der neueste endet bei 26.52, nach der Veröffentlichung aktualisierst du Geyser also ein zweites Mal [3][4].
• Dass der Build für 26.60 NetherNet wirklich zum Standard macht, ist angekündigt, nicht ausgeliefert [9].
• Der Konsolenweg über BedrockConnect nach 26.60 ist unbelegt [13].
• Ein einzelner Nutzerkommentar zum Fehlerbericht BDS-23108 vom 19.10.2026 beschreibt ein iPhone mit 26.52, das über reines HTTP nicht auf einen Bedrock Dedicated Server kam und über HTTPS beitrat. Die Ursache ist nicht bestätigt, Geyser war am Test nicht beteiligt [14].
• Mit externem Signaling (NXS) werden MOTD und Spielerzahl regelmäßig statt live aktualisiert [1].

Ein Praxisbeispiel

Das ist ein Plan, kein Bericht aus unseren Systemen. Angenommen, Paper 26.3 läuft auf einem Mini-PC zu Hause, acht Freunde spielen mit, drei davon am Handy, einer auf der Switch. Leg Geyser-Spigot und Floodgate in plugins, stell transport: nethernet mit Port 19132 ein und starte neu. Im Router gibst du 25565 TCP an den Java-Server frei und 19132 TCP und UDP an denselben Rechner. Prüf vorher deinen Anschluss: Bei DS-Lite oder CGNAT hilft keine Freigaberegel, dann übernehmen ein Tunnel oder ein VPS. Öffne am Handy über mobile Daten http://DEINE-ÖFFENTLICHE-IP:19132/v1/join und erwarte JSON, tritt dann mit Bedrock bei und bestätige die Vertrauensfrage einmal. Die Handys laufen. Für den Freund an der Switch lautet die ehrliche Antwort am 25.10.2026 „nach 26.60 unklar“, bis BedrockConnect eine Version mit NetherNet veröffentlicht.

Prüfliste

• Lade den neuesten Geyser-Build und prüfe, dass er 1237 oder neuer ist.
• Stell unter bedrock: den Wert transport: nethernet ein, im Übergang both mit eigenem webrtc-port.
• Gib Geyser einen Port, den der Java-Server nicht nutzt.
• Öffne diesen Port für TCP und UDP im Router und in der Firewall oder lass ihn dir vom Hoster geben.
• Lies nach dem Neustart die Konsole und behebe jede NetherNet-Warnung.
• Teste GET /v1/join und einen echten Beitritt von außerhalb deines Netzes.
• Teile deinen Spielern den neuen Port mit, falls Geyser sich bisher den Java-Port geteilt hat.
• Sichere den Konfigurationsordner von Geyser, bevor du neu installierst oder umziehst.
• Schau am 27.10.2026 wieder auf die Download-Seite von GeyserMC und aktualisiere, sobald ein Build 26.60 unterstützt.

Passt dazu: Minecraft-Server zu Hause hosten; Minecraft-Server auf einem VPS; Worauf du bei Minecraft-Server-Hosting achtest; Portfreigabe: was sie ist und wie sie wirkt; Gameserver hinter CGNAT oder DS-Lite: 5 Wege; Whitelist (Minecraft); TCP; Reverse Proxy im Homelab.