NetherNet auf deinem Geyser-Server einrichten

Bedrock-Freunde können deinem vorhandenen Geyser-Server nicht beitreten

Melden deine Bedrock-Spieler NetherNet, Door oder Details wie InitialConnection-83, während Java-Spieler beitreten? Die Fehlerreferenz beschreibt NetherNet als Multiplayer-Verbindungsfehler. Notiere den vollständigen Fehler sowie Client- und Serverversionen. Prüfe TCP-Signaling, danach den UDP-Spielweg. Wenn beide funktionieren, kontrolliere Versionen und Anmeldung.

Für deinen offiziellen Bedrock Dedicated Server: BDS-NetherNet-Guide.

RakNet ist die ältere Verbindungsmethode, NetherNet die neuere. Geprüft am 12. Oktober 2026: Der offizielle Geyser-Download 2.11.3, Build 1251, enthält NetherNet, verwendet aber weiterhin standardmäßig raknet. Nutze diesen Download statt der archivierten GeyserNetherNet-Erweiterung. Stelle die Methode bewusst ein und starte vollständig neu.

Direkte NetherNet-Verbindung konfigurieren

Ein Port ist ein nummerierter Netzwerkendpunkt. TCP und UDP sind unterschiedliche Verkehrsarten; eine TCP-Freigabe erlaubt nicht automatisch UDP mit derselben Nummer. Der NetherNet-Beitritt hat zwei Schritte:

1. Das Spiel baut die erste TCP-Verbindung auf, das Signaling. Geyser nennt Adresse und UDP-Port für das Spiel.
2. Das Spiel verbindet sich mit diesem UDP-Ziel. Ein erfolgreicher TCP-Porttest hilft nur beim ersten Schritt.

Aktualisiere Geyser über die offiziellen Downloads, sichere deine config.yml und bearbeite deren vorhandenen bedrock-Abschnitt. Ersetze DEINE_OEFFENTLICHE_IP vor dem Speichern durch deine erreichbare öffentliche IP; Geyser füllt diesen Platzhalter nicht automatisch aus:

bedrock:
  address: 0.0.0.0
  port: 19132
  clone-remote-port: false
  transport: nethernet
  webrtc-port: 0
  signaling:
    mode: builtin
    builtin:
      advertise-addresses:
        - "DEINE_OEFFENTLICHE_IP:19132"

Erlaube für diese Konfiguration TCP 19132 und UDP 19132. webrtc-port: 0 verwendet bedrock.port. Geyser nutzt einen WebRTC-UDP-Listener für alle Spieler. WebRTC ist die Technik der Spielverbindung; du musst keinen Zusatzdienst installieren.

Deine öffentliche IP ist von außen erreichbar. Eine LAN-IP, oft beginnend mit 192.168. oder 10., ist lokal. Die angekündigte Adresse nennt Geyser deinen Spielern. Die Bind-Adresse bestimmt, wo Geyser lokal Verbindungen annimmt. Nutze address: 0.0.0.0 für die lokalen Schnittstellen. Binde nicht an eine öffentliche IP, die dem Rechner nicht gehört, oder an Loopback 127.0.0.1 für NetherNet.

NAT ist Adress- und Portübersetzung durch Router oder Anbieter. Führt öffentliches UDP 20132 zu Geyser-UDP 19132, kündigst du DEINE_OEFFENTLICHE_IP:20132 an. Die TCP-Signaling-Zuweisung bleibt getrennt. Du kannst auch -DgeyserAdvertiseAddresses=DEINE_OEFFENTLICHE_IP:20132 vor -jar setzen. Die JVM-Einstellung überschreibt die Liste. Prüfe bei ignorierten Änderungen deine Startparameter.

Beide Wege freigeben und neu starten

Erlaube TCP 19132 und UDP 19132 in Server-Firewall, Routerweiterleitung und Provider-Firewall. Die Routerregel liefert eingehenden Verkehr an die lokale Serveradresse. Frage beim Mietserver nach passenden Panel-Zuweisungen.

Ergänze diese Docker-Freigaben; behalte Dienst und Daten-Mounts:

ports:
  - "19132:19132/tcp"
  - "19132:19132/udp"

Behalte auch die Java-TCP-Freigabe. Für übersetzte Spielports verwendest du 20132:19132/udp. Docker betreibt Geyser in einem Container, der sonst eine private Container-Adresse ankündigen könnte.

Stoppe Server oder Proxy regulär und starte ihn nach Konfigurationsänderungen wie gewohnt. Starte vollständig neu statt /geyser reload. Bei Docker-Portänderungen erstellst du den Dienst mit docker compose up -d neu und behältst das vorhandene Volume. Bei Hosting verwendest du den Panel-Neustart und kontrollierst die Startlogs.

Wenn du bewusst beide Verbindungsmethoden annimmst

Ersetze DEINE_OEFFENTLICHE_IP vor dem Speichern dieser Konfiguration durch deine erreichbare öffentliche IP:

bedrock:
  address: 0.0.0.0
  port: 19132
  clone-remote-port: false
  transport: both
  webrtc-port: 19134
  signaling:
    mode: builtin
    builtin:
      advertise-addresses:
        - "DEINE_OEFFENTLICHE_IP:19134"

Das nutzt TCP 19132 für Signaling, UDP 19132 für RakNet und UDP 19134 für NetherNet. Veröffentliche und erlaube alle drei. Die UDP-Dienste benötigen getrennte Ports. Spieler kontaktieren zunächst den Signaling-Port, nicht den angekündigten Spielport. Plane RakNet als Übergang; prüfe vor Updates die Transporte.

Versionen und Anmeldung prüfen, bevor du Ports verdächtigst

Geyser unterstützt Bedrock 26.30-26.52 und emuliert einen Java-26.2-Client. Der Java-Server muss diesen annehmen können. Eine Meldung „veraltet“ kann Java betreffen, obwohl Bedrock unterstützt wird. ViaVersion hilft Java-Protokollen; es ergänzt Geyser nicht um fehlende Bedrock-Versionen.

Verwende das passende Geyser-Artefakt für deine Plattform. Bei Fabric/NeoForge muss die unterstützte Java-Spielversion passen. Behalte Floodgate-Anmeldung und Java-Backend-Einstellungen; der Transportwechsel ersetzt sie nicht. Nutze den Crossplay-Guide für Anmeldeprüfungen.

Im vorhandenen Velocity-/BungeeCord-Netzwerk bleibt Geyser auf dem öffentlichen Proxy. Dieser Einstieg leitet Spieler an einzelne Java-Server weiter, die Backends heißen. Prüfe, ob Java-Spieler dieselben Backends erreichen.

Kontrolliere Startlogs auf Portkonflikte, fehlende native WebRTC-Bibliotheken oder nicht anlegbare Zustandsdateien. Behalte den Ordner nethernet neben Geysers Konfiguration samt Signaturidentität. Deren Löschung kann Spieler zu einer erneuten Bestätigung zwingen. Meldet Geyser ein nicht unterstütztes Betriebssystem oder eine Prozessorarchitektur, kläre zuerst dieses Startproblem.

Kontaktaufnahme und Spiel getrennt testen

Gib deine öffentliche Serveradresse im NetherNet-Verbindungstest ein. Er prüft die erste Kontaktaufnahme und zeigt dir die nächsten Schritte. Teste danach den vollständigen Beitritt mit einem Bedrock-Client aus einem anderen Netzwerk.

Servername, Version und Spielerzahl siehst du im Minecraft-Server-Status-Checker. Wähle für deinen NetherNet-Server Bedrock aus und teste anschließend im Spiel, ob der Beitritt funktioniert.

Prüfe einfaches HTTP-Signaling aus einem anderen Netz:

curl --fail --max-time 10 http://DEINE_OEFFENTLICHE_IP:19132/v1/join

Bei HTML, Timeout oder 404 prüfst du Signaling und Routing. Bei TLS nutzt du den tatsächlichen HTTPS-Hostnamen. Erhältst du Server-JSON, tritt anschließend mit einem Bedrock-Client von außerhalb bei, etwa per Mobilfunk-Hotspot. Damit prüfst du auch den Beitritts-POST und Spiel-UDP.

Prüfe bei Cloud-NAT die öffentliche Ankündigung, wie im Oracle-Hosting-Fall. Dort gelang der Beitritt nach der Korrektur trotz verbleibender Warnungen. Teste deshalb die Verbindung, bevor du weitere Einstellungen änderst.

IPv4 und IPv6 sind unterschiedliche Adressformate. Prüfe beide Wege, wenn dein Hostname beide veröffentlicht, und klammere IPv6-Ankündigungen wie [DEINE_OEFFENTLICHE_IPV6]:19132 ein. CGNAT bedeutet, dass Kunden des Internetanbieters eine öffentliche IP teilen. Deine Routerfreigabe kann allein keinen öffentlichen IPv4-Weg erzeugen. Nutze eine geprüft erreichbare Adresse oder einen Dienst, der nötige Signaling- und UDP-Wege ausdrücklich unterstützt. Teste Spiel-UDP auch nach erfolgreicher externer Signaling-Registrierung.

Konsolen-Connectoren ergänzen einen weiteren Weg. Teste zuerst einen direkt konfigurierbaren mobilen oder Windows-Bedrock-Client. Prüfe NetherNet mit einem tatsächlichen Beitritt statt einem alten RakNet-Statusprüfer.

Grenzen bei Hosting und Servernetzwerken

Plane direkt einen TCP-Signaling-Listener und einen UDP-Spiel-Listener je Instanz. Bei both brauchst du den TCP-Listener und zwei UDP-Listener. Gib Instanzen auf derselben öffentlichen IP getrennte Ports. Plane pro Listener, nicht pro Spieler; frage den Hoster nach verfügbaren Zuweisungen.

Frage deinen Hoster: „Ich betreibe Geyser DEINE_GEYSERVERSION mit NetherNet. Bitte bestätigt meinen TCP-Kontakt-Port, den angekündigten UDP-Spielport und bei both den zusätzlichen RakNet-Port. Verhindern Startparameter oder mein vorhandener Java-TCP-Port den Signaling-Start?“

Reserviere einen eigenen TCP-Port für Geysers erste Verbindung. Dieser Build kann den Java-TCP-Listener nicht über clone-remote-port teilen. Prüfe das Startlog auf diesen Portkonflikt: Geyser deaktiviert eingebautes Signaling und kann auf einen externen Dienst zurückfallen. Nutzt du nxs oder hybrid, folge dessen dokumentierten Verbindungsprüfungen.

Richte deinen HTTP-Reverse-Proxy so ein, dass er GET /v1/join und POST /v1/join/{networkId} mit unveränderten Inhalten weiterleitet. Leite Spiel-UDP separat weiter und plane dessen DDoS-Schutz. Prüfe auch alte RakNet-Schutzregeln. Teste Hostnamen-Routing-Plugins: Issue 6710 meldet URL-förmige virtuelle Hosts auf Velocity. Prüfe, ob deine Plugins diese verarbeiten.

TLS verschlüsselt die erste HTTP-Verbindung. Konfiguriere für TLS PEM-Zertifikat/Schlüssel oder PKCS12 unter bedrock.signaling.builtin.https. Nutze ein vertrauenswürdiges Zertifikat, um die erste HTTP-Vertrauensbestätigung zu vermeiden; prüfe Namen, Vertrauen und Gültigkeit. Lass Signaling ohne Browser-Login, Umleitung oder CAPTCHA passieren. Ergänze bei einem reinen HTTP-Tunnel einen erreichbaren UDP-Spielweg.

Quellen

Primärquellen geprüft am 12. Oktober 2026. Versions- und Buildangaben beziehen sich auf dieses Prüfdatum.

• Official Geyser current-build metadata
• Geyser supported versions
• Geyser configuration at reviewed build
• Geyser NetherNet implementation at reviewed build
• Geyser port forwarding
• Minecraft named error codes