Minecraft Bedrock iOS 26.52 fails to connect to public NetherNet servers without HTTPS

Short description of the issue

Minecraft Bedrock Edition 26.52 on iOS fails to connect to a publicly accessible Minecraft server using NetherNet (WebRTC) with built-in HTTP signaling.

The exact same server works when connecting through a local network or Tailscale VPN. Minecraft Bedrock Edition on Windows can also connect using the server's public IPv4 address.

Packet captures suggest that the iOS client attempts to establish an HTTPS/TLS connection when connecting through the public IPv4 address, but does not successfully fall back to unencrypted HTTP when the server does not support TLS.

As a result, the connection fails before the NetherNet/WebRTC handshake begins.

Steps to reproduce the issue

1. Set up a Minecraft Java server with GeyserMC and Floodgate.

2. Configure Geyser to use transport: nethernet with built-in HTTP signaling on port 19132 (TCP and UDP), without an HTTPS certificate.

3. Forward TCP and UDP port 19132 from the router to the Minecraft server.

4. Verify that the server's public HTTP signaling endpoint is accessible at http://<public-ip>:19132/v1/join.

5. On an iPhone running Minecraft Bedrock Edition 26.52 add the server using its public IPv4 address and port 19132

6. Disable Wi-Fi and VPN and connect using mobile data.

7. Attempt to join the server.

8. Repeat the test using the server's local IP address or its Tailscale VPN address.

9. Optionally compare the behavior with Minecraft Bedrock Edition on Windows.

Expected result

The iOS client should successfully establish a NetherNet connection to the publicly accessible server.

If the client attempts HTTPS first and the server only supports HTTP signaling, it should correctly fall back to HTTP, as it appears to do on the windows version of Bedrock Edition.

The server should be joinable through its public IPv4 address without requiring HTTPS when HTTP signaling is supported.

Actual result

The iOS client fails to connect when using the public IPv4 address.

The issue does not occur when connecting to the same server through the local network or Tailscale VPN. The Windows Bedrock client (26.52) can also connect using the public address.

When attempting to connect publicly, the Geyser server logs do not show an incoming NetherNet join attempt or the beginning of ICE/WebRTC negotiation.

However, packet captures on the server confirm that both TCP and UDP traffic from the iPhone reach the server.

Technical findings

I investigated the problem using tcpdump on the Debian server.

1. The public HTTP signaling endpoint works correctly.

Opening http://<public-ip>:19132/v1/join from the iPhone over mobile data returns a valid JSON response, including:

"dataVersion": 7,
"protocol": 2193,
"version": "26.52",
"transportLayer": 2,
"connection": 4

This confirms that the public HTTP signaling endpoint is reachable from the iPhone.

1. TCP connections from the iPhone reach the server.

A packet capture confirms that the iPhone successfully establishes a TCP connection to port 19132.

However, instead of sending an unencrypted HTTP request, the client sends a TLS ClientHello:

16 03 01 ...

The client subsequently resets the TCP connection (RST). No successful HTTP signaling request or fallback is observed during this connection attempt.

1. UDP traffic also reaches the server.

Additional tcpdump captures confirm that UDP packets sent by the iPhone arrive on port 19132.

The captured UDP packet sizes (33, 1464, 1172 and 548 bytes) are consistent with RakNet discovery and connection attempts, despite the server being configured exclusively for NetherNet.

1. NetherNet itself works correctly through other connection paths.

When connecting through Tailscale VPN, the Geyser logs show the complete WebRTC connection sequence:

Changed ICE state to checking
Changed ICE state to connected
Changed ICE state to completed
DTLS handshake finished
SCTP connected
Player connected

None of these messages appear during the failed public iOS connection attempt.

1. Different networking configurations did not resolve the issue.

The issue was reproduced using both Docker host networking and bridge networking.

Explicitly advertising the public IPv4 address and disabling automatic STUN discovery did not resolve the problem.

The server's TCP and UDP port forwarding was verified, and other Minecraft clients can connect.

Suspected cause

The observations suggest a possible issue in the Minecraft Bedrock iOS client's NetherNet signaling implementation.

When connecting to a public IPv4 address, the iOS client appears to initiate TLS but does not recover correctly when the server only supports HTTP signaling.

The precise reason for the missing HTTP fallback has not been confirmed.

This may be related to how the iOS client selects or negotiates the signaling protocol for public versus private server addresses.