Help players
reach your server.

01 / RECOMMENDED SETUP

Give players a clear way in

NAT lets several devices share one public internet address. Your router needs to know which device should receive a player’s packets. A port forward gives it that rule.

1. Keep the server’s LAN address stable. A DHCP reservation on your router is one way to do this.
2. Forward UDP to the NetherNet listener. In this example, public UDP port 29133 goes to 192.168.1.50:19133. Allow it through the server, container and hosting firewalls too.
3. Set the public address in Geyser. Merge the example below into your existing config. Keep your token, endpoint and other settings.
4. Restart and test from another network. Use an actual player connection, such as a device on mobile data.

bedrock:
  transport: both
  webrtc-port: 19133
  signaling:
    mode: nxs
    nxs:
      advertise-addresses:
        - "203.0.113.10:29133"

Replace 203.0.113.10 with your real public IP. It is a documentation address and will not work. Use a numeric IP and the external UDP port, not a hostname or your Warden address. Update the config if your public IP changes.

The configured address list is the complete set of endpoints you want to expose. Geyser then skips automatic address discovery (advanced.nxs.stun-discovery). Include each reachable address you need; an IPv4 entry does not automatically add IPv6. Players still join using the Warden Signal Server address.

02 / WHEN FORWARDING IS NOT POSSIBLE

Let both ends try to connect

Some routers allow incoming packets only after a device has sent packets out to that other address. Assisted joins tell the server about the player early, so the server can send those first packets too.

If you have no reachable address to configure, enable assistance with:

bedrock:
  transport: both
  webrtc-port: 19133
  signaling:
    mode: nxs
    nxs:
      advertise-addresses: []
advanced:
  nxs:
    assisted-joins: true

Use a Geyser/Network build with these options. Merge them into the existing config and keep your credentials. Assistance is off by default; enabling it keeps a WebSocket open to Warden.

All of these must be true

• The server stays connected to Warden. Assistance needs a live authenticated WebSocket and a fresh serving heartbeat. HTTPS fallback alone cannot deliver assisted offers.
• Both ends supply usable connection details. The player needs a public UDP address, and the server must return one too. They need a compatible IP version. Current Minecraft clients cannot find their own public address, so Warden predicts it from the signaling request; that only works when the player's router keeps the port.
• A first packet gets through. The NAT mappings and filters must let at least one connection check arrive, then allow checks and replies in both directions. See the comparison below.
• The UDP path stays open. Use the game’s actual UDP socket for discovery and checks. The mappings must stay alive through setup and gameplay. A WebSocket heartbeat does not keep UDP mappings alive.

The current assisted offer/answer exchange has a 15-second limit. After that exchange, connection checks, encryption and game admission still need to succeed. A successful response from Warden does not prove that the player reached the game.

03 / UNDERSTAND THE RESULT

Check both networks

Try NAT Checker on the server’s network and the affected player’s network. Record the full result, such as “Port-Restricted Cone NAT”. NATCheck calls the four NAT types below NAT1–NAT4.

Look at two things: mapping is the public IP and port your router assigns; filtering decides who can send packets back.

Open Internet means no NAT translation was detected; a firewall can still block the game. Blocked means the test did not establish a usable UDP path. Check firewall rules, network restrictions and test failures.

These NAT1–NAT4 labels are not PlayStation’s Type 1–3. Xbox Open/Moderate/Strict and other console labels are summaries for those platforms, not exact mapping and filtering measurements.

04 / SERVER + PLAYER

The combination matters

A server behind Port-Restricted Cone NAT may work for one player and fail for another behind Symmetric NAT. A forwarded server is easier to reach even when the player has a restrictive NAT.

Read the server down the left and the player across the top. These are expected IPv4 behaviours, not a guarantee or a record of tests of every combination. UDP, live mappings and working connection checks are still required. On small screens, scroll the table sideways.

Enable assistance for a Restricted Cone, Port-Restricted Cone or Symmetric server: it needs the player’s details before sending out a check. “Public / forwarded” means the actual game endpoint accepts incoming checks and replies from the same public IP and port. Blocked gameplay UDP at either end prevents these paths.

With two cone NATs, including two Port-Restricted Cone NATs, the public mappings stay the same. Both ends can send to the right address and open their filters. With a forwarded server, even a Symmetric player can start a normal outgoing connection and receive the server’s replies.

05 / CHECK THE REAL PATH

A checker result is a clue

A website tests its own browser sockets. It does not test your game server’s UDP port. A Symmetric result can coexist with a working port forward; a Full Cone result does not prove the game’s firewall is open.

1. Record both NAT results. Note the public IPs, IPv6 results and any VPN. A browser beside a headless server or console gives only an approximation of that device’s path.
2. Check the real UDP listener. Confirm the forwarding rule, local port and firewall. A TCP port-check website cannot verify a UDP forward. Do not copy a browser’s temporary mapped port into the config.
3. Try the affected player. A successful regional Warden probe proves that probe’s path. Test an actual game join from the network that is failing.
4. Separate setup from success. Registration, a heartbeat, successful signaling, a connected data channel and a player entering the game are different milestones.