iOS NetherNet connection failure and HTTPS workaround
Test environment
Client: Minecraft for iOS 1.26.52 (iOS 18.7.8)
Server: Bedrock Dedicated Server 1.26.52.3 (protocol 2193)
Server environment: Linux VPS with public IPv4 and IPv6 addresses
Test 1: Direct connection to BDS
When connecting directly to the BDS using its built-in plaintext HTTP signaling endpoint, the iPhone failed to connect.
The error screen showed:
InitialConnection-13
Transport: RakNet:2193
Test 2: HTTPS reverse proxy
I exposed the same BDS signaling endpoint through Cloudflare Tunnel, which terminates HTTPS and forwards requests to the original BDS over HTTP.
The BDS instance and gameplay UDP endpoint remained unchanged.
Results:
The client selected NetherNet:2193.
GET /v1/join returned HTTP 200.
POST /v1/join/{networkId} successfully exchanged SDP.
Bidirectional UDP traffic was confirmed through packet captures.
The iPhone successfully joined the server.
The BDS SDP answer already contained publicly reachable IPv4 and IPv6 ICE candidates. No UDP relay or ICE candidate rewriting was required.
Expected behavior
According to the official NetherNet onboarding documentation, both HTTP and HTTPS signaling are supported, with Trust On First Use (TOFU) used for plaintext HTTP connections.
Additional observations
The results suggest that the iOS client may not be correctly falling back to plaintext HTTP when TLS signaling is unavailable.
However, this is not a confirmed root cause, as the HTTPS test also changed the signaling hostname and network path.
dokokaringo
iOS NetherNet connection failure and HTTPS workaround
Test environment
Client: Minecraft for iOS 1.26.52 (iOS 18.7.8)
Server: Bedrock Dedicated Server 1.26.52.3 (protocol 2193)
Server environment: Linux VPS with public IPv4 and IPv6 addresses
Test 1: Direct connection to BDS
When connecting directly to the BDS using its built-in plaintext HTTP signaling endpoint, the iPhone failed to connect.
The error screen showed:
InitialConnection-13
Transport: RakNet:2193
Test 2: HTTPS reverse proxy
I exposed the same BDS signaling endpoint through Cloudflare Tunnel, which terminates HTTPS and forwards requests to the original BDS over HTTP.
The BDS instance and gameplay UDP endpoint remained unchanged.
Results:
The client selected NetherNet:2193.
GET /v1/join returned HTTP 200.
POST /v1/join/{networkId} successfully exchanged SDP.
Bidirectional UDP traffic was confirmed through packet captures.
The iPhone successfully joined the server.
The BDS SDP answer already contained publicly reachable IPv4 and IPv6 ICE candidates. No UDP relay or ICE candidate rewriting was required.
Expected behavior
According to the official NetherNet onboarding documentation, both HTTP and HTTPS signaling are supported, with Trust On First Use (TOFU) used for plaintext HTTP connections.
Additional observations
The results suggest that the iOS client may not be correctly falling back to plaintext HTTP when TLS signaling is unavailable.
However, this is not a confirmed root cause, as the HTTPS test also changed the signaling hostname and network path.