Can't get my tunnel to work and connect to my amp hosted MC server

help
,
1

I have been going crazy trying to fix this. I’m coming up on almost 10 hours of troubleshooting time. I have reinstalled and resetup the playit structure twice now. Both the agent and the tunnel are set up correctly and showing active but don’t show up in the dashboard and don’t assign an ip:port. I am on an ububtu server hosting though AMP. I have been working though this with claude and here is an explanation of what I have tried so far and the issue that I am having:

playit.gg Minecraft Java tunnel — “Connection reset”, everything else checks out

Setup: Ubuntu + AMP-hosted Minecraft (Fabric 1.21.11), playit agent v1.0.10 (fresh install), server on 0.0.0.0:25566.

Problem

Joining through the tunnel (along-vincent.gl.joinmc.link, and also the raw relay address) gives Internal Exception: java.net.SocketException: Connection reset. The Minecraft server log shows no new lines at all when a connection is attempted — traffic never reaches the server process.

Ruled out

  • Local port open (nc -zv 127.0.0.1 25566 succeeds)

  • Server itself is healthy (starts clean, reaches Done)

  • No firewall blocking (ufw inactive, iptables/nftables policy ACCEPT)

  • DNS/SRV resolves correctly to the relay

  • Relay port is reachable both externally and from the server (nc and external port checker both succeed)

  • Tunnel mapping confirmed correct via CLI: along-vincent.gl.joinmc.link => 127.0.0.1:25566

The one lingering anomaly

Every time the agent starts, the log shows this before settling down:

ERROR ... address_selector: failed to send initial ping error=NetworkUnreachable addr=[2602:fbaf:864:1::1]:5525
ERROR ... address_selector: failed to ping tunnel server
WARN  ... control session expired; reconnecting reason=SessionNotSetup
INFO  ... playit connected; tunnels loaded tunnel_count=1 account_status="verified"
WARN  ... control session expired; reconnecting reason=SessionNotSetup

The host has an IPv6 address but no working global IPv6 route, and the agent tries IPv6 first before falling back. After this, tunnel_count=1/account_status=verified stay stable for hours — so it’s unclear if this is harmless noise or if it’s quietly preventing the data tunnel from ever finishing its own handshake (which would explain the relay accepting connections from outside but nothing reaching the server).

Tried disabling IPv6 (sysctl, then persisted via /etc/sysctl.d/), but a reboot revealed the specific NIC (enp2s0) still had disable_ipv6=0 even though the global setting was 1 — currently re-testing with the interface-specific key set too.

Question

With DNS, port reachability, local binding, firewall, and tunnel mapping all confirmed correct, and the only anomaly being a control-channel reconnect loop that appears to stabilize — can the control session report healthy/verified while the underlying data tunnel never completes its own handshake? Is there a way to check that data channel’s health specifically, separate from the control channel?