Geyser NetherNet Errors in the Console: What Each One Means

You moved Geyser to NetherNet for Bedrock 26.60, and now the console prints lines you have never seen: NetherNet will not start!, juice: Send failed, errno=97, a player who "could not connect over NetherNet", or every Bedrock player arriving from 172.16.0.1. This page matches the Geyser NetherNet errors from the GitHub issues opened since 25 October 2026 to the GeyserMC team's answers and the builds that changed them, all rechecked on 3 November 2026, when the newest build was Geyser 2.12.1 build 1283.

The setup itself, with ports, Warden and HTTPS, is in our Geyser NetherNet setup guide, whose troubleshooting table also covers the startup messages about shared ports and loopback addresses.

Quick answer: A Geyser NetherNet error that names libcrypto.so.3 means OpenSSL 3 is missing where the server runs; GeyserMC's answer was "Installing libssl3 should resolve your issue" (libssl3t64 on Ubuntu 24.04). juice: Send failed, errno=97 is noise from IPv6 candidates on an IPv4-bound Geyser, harmless when players get in. "Could not connect over NetherNet: no network path" means the player cannot reach your UDP port. Players showing as 172.16.0.1 or as a relay's address was fixed in build 1280, with prefer-signaling-proxy-address for forwards that hide the address. Update to the newest build first.

Check your build first

Run geyser version in the console; the number after -b is the build. These builds from GeyserMC's build list matter here:

NetherNet will not start: "Could not load its WebRTC native library"

NetherNet runs on a native WebRTC library that Geyser unpacks at startup. When the system lacks a library it depends on, build 1279 and older printed this, as posted in issue #6852 on 31 October (shortened):

[07:35:19 WARN]: [Geyser-Spigot] NetherNet is not available on Linux (amd64). Bedrock players can still join over RakNet: set "transport" in the "bedrock" section of the config to "raknet".
java.lang.UnsatisfiedLinkError: /tmp/datachannel-java-.../libdatachannel-java.so: libcrypto.so.3: cannot open shared object file: No such file or directory

From build 1280, Geyser's source words the same failure as NetherNet will not start! Could not load its WebRTC native library on Linux (amd64), followed by the missing file and "This usually means a system library it depends on is not installed, or that it is not built for this platform."

libcrypto.so.3 belongs to OpenSSL 3. For a server on Ubuntu 24.04, Geyser contributor hasankayra04 answered: "Installing libssl3 should resolve your issue." Ignore the old hint to switch to RakNet: GeyserMC's NetherNet post says Bedrock 26.60 clients stop connecting over RakNet, and build 1280 moves a raknet setting to nethernet anyway. Check for the library:

/sbin/ldconfig -p | grep libcrypto.so.3

No output means it is missing. The package name depends on the release:

# Ubuntu 24.04 and Debian 13
sudo apt install libssl3t64
# Ubuntu 22.04 and Debian 12
sudo apt install libssl3

Then restart the server. In a Docker container, the library has to be inside the container's image, because the Java process only sees the image's files, as a commenter in the same issue pointed out. On a hosted server, send your host the UnsatisfiedLinkError line, since the fix belongs in the image they run your server in.

Two platforms fail with a different message, and neither has a fix yet:

• Android with Termux (#6848): Cannot identify the JVM's libc; set -Dlibdatachannel.libc=glibc or -Dlibdatachannel.libc=musl. Android's bionic libc is neither. A GeyserMC member wrote on 2 November that it is "Not a high priority atm" and on hold until Geyser can download native libraries at runtime.
• Windows 11 with Smart App Control (#6822): Windows blocks libdatachannel-java.dll because it "did not meet the Enterprise signing level requirements". A Geyser contributor replied on 28 October: "Time should fix this."

"juice: Send failed, errno=97"

rtc::impl::IceTransport::LogCallback@406: juice: Send failed, errno=97
rtc::impl::IceTransport::LogCallback@406: juice: STUN message send failed

These WARN pairs come from libjuice, the connectivity part of the WebRTC library. Errno 97 on Linux is EAFNOSUPPORT, "Address family not supported by protocol". Issue #6841 of 28 October explains when they appear: bedrock.address is an IPv4 address, a player with IPv6 joins, and the IPv4-only socket tries the player's IPv6 candidates. The reporter saw every burst followed by a normal join over IPv4 one to three seconds later: "console noise that reads like a real fault".

The issue is open on 3 November, without a fix. If the player gets in, ignore it; advertise-addresses cannot silence it. If the player never gets in, see the join warnings below.

A related startup line is information, not an error: STUN discovery through stun.cloudflare.com:3478 cannot reach [2606:4700:49::]:3478 from here, asking 162.159.207.0:3478 only. The server cannot reach the STUN server's IPv6 address, so Geyser asks the IPv4 one.

"juice: Lost connectivity", then a kick

Issue #6850 of 31 October reports Bedrock players kicked at random with juice: Lost connectivity in the console on build 1275. GeyserMC asked for a log dump and has not named a cause yet. Update to the newest build, and if the kicks continue, add a dump to that issue with geyser dump logs, which includes your logs.

"Could not connect over NetherNet": the failed join warnings

When a join fails, Geyser logs a warning that starts with the player's name. These texts come from the NetherNet library's source on 3 November; according to PR #6843, build 1280 started telling a stalled join apart from one that found no path, so older builds word them differently.

The first three start with "could not connect over NetherNet", and the port is your own WebRTC port. Two STUN lines at startup help with the first row:

• STUN discovery through ... maps this host to ..., a different port than udp/19132 (INFO): something in front of your server changes the UDP port. On Aternos, where an owner saw this in #6856, the Geyser team answered: "Please ensure your players are connecting using port 19132."
• STUN discovery through ... maps this host to ..., which players elsewhere cannot reach, so it is not announced (WARN): STUN only found an address that outside players cannot use. Put your public IP in advertise-addresses, as the setup guide shows.

Every Bedrock player shows as 172.16.0.1, or as the relay's address

In #6835 (27 October), Geyser Standalone in its own Pterodactyl Docker container passed the private address 172.16.0.1 to the Java proxy for every Bedrock player, and anti-VPN plugins blocked them. In #6834, every player who joined through a signaling relay, such as an MCXboxBroadcast friend join, got the relay's address. The cause, as the reporter of #6834 traced it: Geyser read the player's address before the WebRTC connection was up and kept the address the signaling request came from.

GeyserMC member onebeastchris closed both on 1 November: "Fixed with https://github.com/GeyserMC/Geyser/pull/6843". That is build 1280, where a player's address comes from the WebRTC connection itself, the way RakNet reported the UDP source.

If players still share one address on build 1280 or newer, something forwards your WebRTC port without passing on the source. PR #6843 added two options under advanced.bedrock for that:

• webrtc-proxy-protocol-relays: for UDP relays that send a PROXY protocol v2 header. List them here and in bedrock.signaling.advertise-addresses. The PR calls this the better fix.
• prefer-signaling-proxy-address, off by default: keeps the address built-in signaling's proxies sent (listed in haproxy-protocol-whitelisted-ips or signaling-trusted-proxies). Geyser's config comment: "Enable this when the WebRTC port is forwarded without PROXY protocol, so every player would otherwise show the forwarder's address."

advanced:
  bedrock:
    haproxy-protocol-whitelisted-ips:
      - 203.0.113.10
    prefer-signaling-proxy-address: true

Replace 203.0.113.10 with your signaling proxy's address. Geyser warns at startup when the option can do nothing, for example when neither proxy list is set. One exception from the maintainer: if you forward real addresses for signaling only, relay WebRTC traffic through a filter without HAProxy headers and use MCXboxBroadcast, which does not forward real player addresses to signaling, disable prefer-signaling-proxy-address and set up HAProxy forwarding for the relayed WebRTC traffic instead.

"Duplicate handler name: rak-error-handler"

java.lang.IllegalArgumentException: Duplicate handler name: rak-error-handler, logged after Error occurred while initializing player!, hit joins through external signaling on build 1270 (#6824). A GeyserMC member wrote on 27 October: "Should be resolved with the build released yesterday." Builds 1272 and 1273 both came out on 26 October, so any build from 1273 on has the fix.

Terracotta on the player's screen, nothing in the console

Several owners opened issues with only the client's Terracotta error (#6856, #6859, #6861, #6864). GeyserMC closed them as setup problems, with "Please make sure your players are joining with the port 19132" for an Aternos server and, on 2 November in #6859, "'Terracotta' type errors typically indicate setup issues." A join that got through signaling and then failed logs one of the warnings above, so an empty console points at the signaling step: TCP on the Geyser port, and the port players type in. Mojang's meaning of each client code is in our Door and Terracotta post.

Other tools that broke on NetherNet: status on 3 November

How console players reach a server after 26.60 is in our Switch 2, Xbox and PS5 join guide.

When your message is not on this page

1. Update to the newest build.
2. Run geyser dump logs. From build 1282 the dump shows your Linux distro and version, which the Geyser team asked for first in #6852.
3. Ask on GeyserMC's Discord: the team closes setup questions on GitHub and points there.

If your server runs on our Minecraft hosting, Bedrock players join through Geyser, and every plan includes three port allocations, so Geyser gets a port of its own. Send us the console lines by live chat, Discord or email, between 08:00 and 20:00 UTC.

FAQ

Why does Geyser say NetherNet is not available on Linux? It does not mean Linux is unsupported. Builds 1279 and older printed it whenever the native WebRTC library could not load, in the reports we read because libcrypto.so.3 was missing. Install libssl3 (Ubuntu 22.04, Debian 12) or libssl3t64 (Ubuntu 24.04, Debian 13) where the server runs, inside the Docker image if there is one.

Should I switch Geyser back to RakNet to get rid of a NetherNet error? No. GeyserMC says Bedrock 26.60 clients stop connecting over RakNet, and build 1280 and newer move a raknet setting to nethernet by themselves.

Is "juice: Send failed, errno=97" dangerous? Not when players still get in: the IPv4-only socket tried a player's IPv6 candidate before the join went through over IPv4. Issue #6841 has no fix on 3 November.

Why do all Bedrock players have the IP 172.16.0.1 after the NetherNet update? Builds before 1280 kept the address the signaling connection came from, which behind a container or relay is not the player's. Update to build 1280 or newer; if the WebRTC port is forwarded without PROXY protocol, use webrtc-proxy-protocol-relays or prefer-signaling-proxy-address.

What does "no network path to this server was found" mean? The player reached Geyser's signaling over TCP, but found no UDP route to the WebRTC port on the addresses Geyser hands out. Open that UDP port and check geyser nethernet advertised for your public address.

Sources

All opened on 3 November 2026:

• GeyserMC issues: #6852, #6848, #6822, #6841, #6850, #6856, #6835, #6834, #6824, #6859, #6861, #6864
• GeyserMC pull requests: #6843, #6867
• GeyserMC downloads: Geyser 2.12.1 builds, build 1272
• Geyser source: NetherNetServer.java at build 1279 and build 1280, GeyserConfig.java, DumpCommand.java
• CloudburstMC Network, nethernet branch: NetherNetServerChannel.java, StunObserver.java
• GeyserMC blog: Preparing Your Geyser Server for NetherNet
• Linux kernel: errno.h
• Packages: Ubuntu libssl3t64 (24.04) and libssl3 (22.04), Debian libssl3 (12) and libssl3t64 (13)
• MCXboxBroadcast: issue #405, releases
• BedrockConnect: issue #730, releases 1.72.0 and 1.72.1
• bedrocktool: issue #356, release r1.63.0
• Home Assistant: issue #189458; mcstatus: pull request #1226
• itzg/mc-monitor: issue #185