For most of its life, Minecraft Bedrock spoke RakNet — a custom reliable-UDP protocol. Newer builds add NetherNet, a transport built on WebRTC. If you run a server, the switch changes how clients find you, which ports you open, and how connections are secured. This article compares the two.
| RakNet | NetherNet | |
|---|---|---|
| Foundation | Custom reliable protocol over UDP | WebRTC (ICE + DTLS + SCTP data channel) |
| Discovery / status | Unconnected UDP ping/pong on the game port | HTTP GET /v1/join on a TCP port |
| Connect | UDP handshake, then a Minecraft login packet | HTTP POST /v1/join/{networkId} exchanges an SDP offer/answer, then ICE + DTLS |
| Ports | One UDP port (default 19132) | A TCP signaling port + a range of UDP media ports |
| Encryption | Application-level, negotiated after login | DTLS from the start (mandatory, via WebRTC) |
| NAT traversal | Port-forward required | ICE candidates (host / server-reflexive), designed for P2P |
| server.properties | transport=raknet | transport=nethernet |
RakNet is a single UDP service on the game port. A client discovers a server by sending an unconnected ping; the server replies with an unconnected pong that carries the MOTD string (name, protocol, version, player counts, and so on). To join, the client performs RakNet’s connection handshake and then sends Minecraft’s login packet inside the now-reliable UDP channel. Everything — discovery, handshake, and gameplay — happens on that one UDP port.
NetherNet borrows the browser’s connection model. Signaling happens over a small HTTP server the game opens on a TCP port:
GET /v1/join -> status JSON (name, protocol, version, players, …)
POST /v1/join/{networkId} -> an SDP answer with the server’s ICE candidatesThe client sends an SDP offer; the server replies with an SDP answer listing the UDP endpoints (ICE candidates) it can be reached at. The two sides then run ICE connectivity checks, complete a DTLS handshake, and carry gameplay over an SCTP data channel — the same stack a WebRTC data channel uses in a browser. Gameplay therefore flows over UDP, but the negotiation is HTTP over TCP.
Under RakNet, authentication is part of Minecraft’s login sequence after the transport connects. NetherNet attaches identity at the signaling step: the offer carries an a=identity attribute — a signed assertion whose token is bound to a public key (the client proves possession of the matching private key during DTLS). Combined with mandatory DTLS, this means a NetherNet connection is encrypted end-to-end from the first media packet, and the server can reject an offer that lacks a valid identity before any media is exchanged.
RakNet needs exactly one UDP port open. NetherNet needs two things: the TCP signaling port, and a range of UDP media ports (set with server-udp-ports). You need at least one UDP port per concurrent player, plus headroom, because each pending session also holds a port until it times out. This is a genuinely new capacity-planning consideration — a range that is too small will start refusing connections once it fills.
Because NetherNet signaling is plain HTTP, it can be put behind a normal reverse proxy. Large networks front it with nginx and a TLS certificate, serving the signaling over HTTPS while the UDP media flows directly. RakNet, being a custom UDP protocol, has no equivalent — you cannot simply wrap it in nginx.
RakNet expects a straightforward port-forward. NetherNet’s ICE model advertises candidate addresses and was designed with peer-to-peer and NAT traversal in mind, which is part of why Mojang adopted it for cross-platform play and hosted “featured” experiences. In practice, a publicly reachable dedicated server still needs its signaling port and its UDP media range reachable from the internet.
Status checks differ. A RakNet monitor sends an unconnected ping and parses the pong. A NetherNet monitor makes an HTTP request to /v1/join. If you have a NetherNet server, you can check its status and see the exact candidates it advertises with the iceFetch tool — useful for confirming your server-udp-ports mapping is publishing the right public address.
NetherNet is the direction Bedrock is moving, and recent Dedicated Server builds default to it. RakNet remains widely deployed and is simpler operationally (one UDP port, no signaling service). If you are standing up a new server on a current build, expect NetherNet and plan for the TCP signaling port plus a UDP media range. If you specifically need the old single-port model or compatibility with RakNet-only tooling, you can still select transport=raknet.
RakNet and NetherNet solve the same problem — get a Bedrock client talking to a server — very differently: one custom UDP protocol versus a WebRTC stack with HTTP signaling, ICE, and DTLS. For a step-by-step NetherNet server setup (ports, systemd, and nginx HTTPS), see Set up a Bedrock server with NetherNet, and How iceFetch works for a closer look at the signaling exchange.
ToolLearnArticlesPrivacyTerms · iceFetch is not affiliated with Mojang or Microsoft.