NetherNet (Minecraft Bedrock)

Jahrelang hat ein Bedrock-Client einfach an einem UDP-Port geklopft. Mit NetherNet klingelt er zuerst per HTTP und kommt erst danach über WebRTC herein.

Kurz gesagt

NetherNet ist die Peer-to-Peer-Netzwerkschicht von Minecraft Bedrock auf Basis von WebRTC [1]. Bevor jemand beitritt, fragt der Client den Server per HTTP(S), ob er NetherNet unterstützt, und tauscht mit ihm die Verbindungsdaten aus, das sogenannte Signaling; das Spiel selbst läuft danach über WebRTC-Datenkanäle [1][2]. Open Collaboration, die Organisation hinter Geyser, schreibt, dass Bedrock 26.60, geplant für den 27. Oktober 2026, keine Verbindungen über das alte RakNet mehr aufbaut, sodass jeder Bedrock-Server NetherNet können muss [2]. Unsere Einschätzung: Wenn du einen Bedrock- oder Geyser-Server betreibst, aktualisiere ihn vor diesem Datum und sorge dafür, dass ihn auch TCP erreicht, nicht nur UDP.

So funktioniert’s

1. Fähigkeitsprüfung. Der Client ruft beim Server zuerst GET /v1/join auf. Eine 2xx-Antwort heißt, dass NetherNet unterstützt wird, und der JSON-Inhalt enthält Servername, Protokoll, Spielversion, Weltname und Spielerzahlen [1].
2. Eine Anfrage für den Handschlag. Danach schickt der Client sein vollständiges WebRTC-Angebot, einen Text im Session Description Protocol (SDP) mit allen Netzwerkkandidaten, als einzelnes POST /v1/join/{networkId}. Trickle ICE ist abgeschaltet, es gibt genau eine Anfrage pro Versuch, und bei einem Fehler versucht der Client es nicht erneut [1].
3. Spieldaten über WebRTC. Sobald die Antwort da ist, testen Client und Host die Netzwerkwege direkt und öffnen per DTLS gesicherte Datenkanäle. Der Signaling-Server ist nur an diesem ersten Austausch beteiligt [1].
4. Identität in beide Richtungen. Das Angebot des Clients enthält eine Bestätigung der Identität des angemeldeten Spielers. Die Antwort des Servers enthält eine langlebige Betreiber-Identität, deren Schlüssel der Client bei der ersten Verbindung festhält und danach jedes Mal prüft („Trust on First Use“) [1]. Seit 26.50 hat der Dedicated Server den Befehl serveridentity, mit dem du seinen Identitätsschlüssel sicherst, löschst und prüfst [3].
5. Neue Anforderungen an Ports. Laut Open Collaboration muss ein Server für das Signaling einen zusätzlichen TCP-Port öffnen und ein TLS-Zertifikat bereitstellen. Mit dem Standard NetherNet External Signaling übernimmt ein externer Anbieter das Signaling, und der Spielserver braucht nur einen erreichbaren UDP-Port [2].
6. Der Zeitplan. Laut Open Collaboration führt Mojang NetherNet seit 26.40 schrittweise ein [2]. Der Changelog zu 26.40 beschreibt, dass der Client einen Dedicated Server mit einer Wartezeit von drei Sekunden auf NetherNet prüft, und behebt einen Fehler, damit diese Grenze für den gesamten Verbindungsversuch gilt [4]. Mit 26.50 wurde NetherNet zur Standard-Netzwerkschicht des Bedrock Dedicated Server [3]. Geyser unterstützt NetherNet seit Build 1237 [2].
7. Ein Port pro Spieler. Open Collaboration weist darauf hin, dass der Bedrock Dedicated Server derzeit für jeden Spieler einen eigenen Port braucht, weil Googles Standard-Umsetzung von WebRTC eine Verbindung pro IP-Adresse und Port verarbeitet; ihre Bibliothek bündelt alle Spieler auf einem UDP-Port [2].

Ein Praxisbeispiel

Du betreibst zu Hause einen Crossplay-Server und willst wissen, ob das NetherNet-Signaling erreichbar ist. Von einem Gerät außerhalb deines Netzes fragst du den Endpunkt ab, den ein Bedrock-Client zuerst aufruft [1]:

curl http://<server-address>:<port>/v1/join

Ein NetherNet-Server antwortet mit einem 2xx-Status und JSON [1]. Ein Timeout heißt meist, dass TCP den Server nicht erreicht; prüfe dann die Regeln in Router und Firewall für TCP und UDP. Welchen Port du nutzt, hängt von deiner Serversoftware ab; nimm ihn aus deren Dokumentation. Das ist ein allgemeiner Ablauf und kein Test auf unserem eigenen Server.

Prüfliste

• Aktualisiere den Bedrock Dedicated Server auf 26.50 oder neuer, dort ist NetherNet Standard [3].
• Aktualisiere Geyser auf Build 1237 oder neuer [2].
• Leite TCP für das Signaling neben UDP für die Spieldaten weiter und gib beides frei [2].
• Teste /v1/join von außerhalb deines eigenen Netzes [1].
• Sichere den Identitätsschlüssel des Servers, damit wiederkehrende Spieler keinem neuen Schlüssel vertrauen müssen [1][3].
• Lass STUN- und TURN-Server beim HTTP-Signaling weg, wie Mojang es empfiehlt [1].