Minecraft Bedrock Server Setup & Geyser NetherNet Configuration

Minecraft: Bedrock Edition utilizes a modernized connection pipeline based on NetherNet, a protocol built on top of WebRTC. Unlike legacy setups that relied exclusively on UDP-based RakNet, modern Bedrock multiplayer connections operate in two distinct phases:

1. Signaling Phase (TCP): The Bedrock client opens an HTTP request over TCP to the server's signaling endpoint. Here, client identity, capabilities, and WebRTC Interactive Connectivity Establishment (ICE) session candidates are negotiated.
2. Gameplay Phase (UDP WebRTC): Once signaling negotiation completes, real-time game traffic (chunk loading, block placement, player movements, and combat state) streams over high-speed UDP via WebRTC.

For optimal reliability, performance, and DDoS scrubbing on Pterodactyl hosting, we recommend a three-port architecture (one for Java gameplay, one for Bedrock TCP signaling, and one for Bedrock UDP WebRTC gameplay):

To establish dual-port NetherNet routing, your container must have two secondary allocations assigned in Pterodactyl. Follow these exact steps:

1. Assigning Allocations in Pterodactyl

1. Log in to your Pterodactyl Control Panel (dash.azioncloud.com).
2. Select your Minecraft server from the dashboard list.
3. Click the Network tab located in the left sidebar menu.
4. Inspect your existing allocations:
   • The port marked with the Primary badge (usually e.g. 25565) is reserved for Java Edition.
   • You need two additional allocations: one for Bedrock TCP Signaling (e.g. 25675) and one for Bedrock UDP WebRTC (e.g. 25633).
5. Click the Create Allocation button in the top right corner to assign additional ports from your node's available pool.
6. Note the exact port numbers assigned to your server. (If you have reached your plan's allocation limit, open a ticket on Discord or Client Area to have our staff assign more allocations).

2. How Docker and Wings Expose Both Ports

Pterodactyl's daemon (Wings) generates container port forwarding rules based strictly on the allocations assigned to your server in the panel database. When Wings starts your Minecraft Docker container:

• Wings creates both TCP and UDP port bindings for every assigned allocation (e.g. -p <node_ip>:25675:25675/tcp -p <node_ip>:25675:25675/udp and -p <node_ip>:25633:25633/tcp -p <node_ip>:25633:25633/udp).
• Critical: If an allocation is not explicitly added to your server in the Network tab, Wings will not bind it to the Docker container. Even if Geyser listens on port 25633 inside the container, external packets will be dropped at the host boundary.

3. Opening TCP & UDP Firewall Ports

Network firewalls must permit ingress traffic for both protocols:

• Azion Cloud Managed Nodes: All port allocations assigned through our Pterodactyl panel are pre-authorized on our hardware firewall and routed through our 12+ Tbps Anti-DDoS scrubbing network. No manual firewall modification is required.
• Self-Hosted Linux VPS / Dedicated Servers: If you run your own Wings daemon or VPS, ensure your firewall (UFW, iptables, or Cloud Security Groups) permits both ports:
  Linux UFW Commands Copy Code

  # Open TCP Signaling Port (Example: 25675)
  sudo ufw allow 25675/tcp comment "Geyser Bedrock TCP Signaling"
  
  # Open UDP WebRTC Port (Example: 25633)
  sudo ufw allow 25633/udp comment "Geyser Bedrock UDP WebRTC"
  
  # Reload UFW to apply
  sudo ufw reload

  If hosting on AWS, Oracle Cloud, Google Cloud, or Azure, also add ingress security group rules for TCP 25675 and UDP 25633 from source 0.0.0.0/0.

You do not need to rewrite or replace your entire Geyser configuration. Only adjust the specific keys in the bedrock: section of plugins/Geyser-Spigot/config.yml (or plugins/Geyser-Paper/config.yml):

bedrock:
  # Bind address (0.0.0.0 binds to all container network interfaces)
  address: 0.0.0.0

  # The primary Bedrock port (TCP signaling endpoint entered by players)
  # Replace 25675 with your secondary assigned TCP allocation
  port: 25675

  # Must remain false when running an independent multi-port setup
  clone-remote-port: false

  # Modern transport protocol for Bedrock clients
  transport: nethernet

  # Dedicated UDP port for NetherNet WebRTC gameplay packets
  # Replace 25633 with your tertiary assigned UDP allocation
  webrtc-port: 25633

  signaling:
    # Supported modes: builtin, nxs, hybrid. NEVER use custom.
    mode: builtin

    # Public IP or Domain advertised to Bedrock clients for WebRTC gameplay
    # Crucial: Must match your public node address and your webrtc-port
    advertise-addresses:
      - "in1.azioncloud.com:25633"

Signaling Modes Explained

Geyser's signaling.mode setting controls how Bedrock connection handshakes are negotiated:

• builtin (Recommended for Dedicated Allocations): Geyser hosts its own lightweight HTTP signaling server locally on the Bedrock TCP port (25675). Bedrock clients connect directly to your server node.
• nxs (External Relay): Geyser registers with an external NXS signaling relay (such as Warden). Useful in environments where opening a second local TCP port is prohibited.
• hybrid: Runs both the local built-in signaling listener and registers with an external NXS signaling relay simultaneously.
• Never Use custom: There is no custom mode in Geyser. Using mode: custom will result in configuration parse failures or silent signaling crashes.

Why advertise-addresses Is Critical

When running inside Docker containers or behind NAT routers, Geyser only sees internal container network interfaces (e.g. 172.18.0.5). If advertise-addresses is omitted or misconfigured, Geyser may hand its internal private IP to connecting Bedrock clients during the signaling phase.

External Bedrock clients cannot reach internal Docker IPs, resulting in immediate InitialConnection-149 or connection timeout errors. Setting advertise-addresses to your public server domain or node IP with your assigned UDP WebRTC port (e.g. in1.azioncloud.com:25633) guarantees the client knows exactly where to direct its WebRTC game traffic.

Bedrock players (on Android, iOS, Windows 10/11, Xbox, PlayStation, and Nintendo Switch) add the server using the standard in-game server list:

By default, Minecraft Java servers enforce online-mode=true in server.properties, requiring every connecting player to validate against Mojang's authentication servers. Because Bedrock players log in with Microsoft/Xbox Live accounts rather than Mojang Java accounts, standard Java servers would reject them.

How Floodgate Bridges Authentication

Floodgate solves this without requiring your server to run in insecure offline/cracked mode (online-mode=false):

1. When a Bedrock player connects through Geyser, Floodgate gathers their verified Microsoft/Xbox Live credentials (including Xbox Gamertag and unique XUID).
2. Floodgate constructs a deterministic offline UUID for the player (prefixed with . by default, such as .Steve, to avoid namespace collisions with Java usernames).
3. Floodgate cryptographically signs this identity payload using an asymmetric RSA private key (stored in key.pem).
4. The Java server plugin verifies this signature using the public key and admits the player as an authentic, verified user, allowing the server to keep online-mode=true strictly enforced for Java players.

Floodgate Configuration in Geyser

Open plugins/Geyser-Spigot/config.yml and ensure the authentication type is configured for Floodgate:

remote:
  address: auto
  port: auto
  # Use floodgate authentication
  auth-type: floodgate

advanced:
  # Path to Floodgate RSA key file (automatically loaded on Spigot/Paper)
  floodgate-key-file: key.pem

If players encounter connection issues, consult the diagnostic table below for verified resolutions:

Generating a Diagnostic Dump

If you need to contact support, run the official diagnostic command in your Pterodactyl Console:

geyser dump

This command securely analyzes your server architecture, Geyser build version, network bindings, and Java runtime, returning a sanitized diagnostic URL that you can provide to our engineers on Discord or via support ticket.

GeyserMC and Floodgate are active open-source projects providing continuous updates whenever Mojang releases Bedrock Edition updates. Always ensure your server runs official, verified builds:

• GeyserMC Official Setup Guide: https://geysermc.org/wiki/geyser/setup/
• GeyserMC Configuration Reference: https://geysermc.org/wiki/geyser/
• Floodgate Documentation: https://geysermc.org/wiki/floodgate/
• Official Geyser Downloads & Builds: https://geysermc.org/download