← Back to Forum
1
Troubleshooting
Started today: LocaltoNet TCP address gives connection refused for Minecraft
This had been fine before, then today friends started getting refused right away. I can still join from the same PC with localhost and from another device in the house with the local IP, so the Java server itself is up.
I'm trying to narrow down the obvious failure points before I start randomly changing things. Is this usually the LocaltoNet tunnel targeting the wrong local port, the server binding to the wrong interface, Windows Firewall deciding to be "helpful", or is there some LocaltoNet-side status/log I should check first?
Comments (8)
If LAN access still works, I'd verify the LocaltoNet endpoint itself before changing the Minecraft side. In similar cases, the tunnel process was healthy locally but the published TCP address had rotated or the forwarding rule was no longer attached to the expected internal port. Do you see any recent disconnects or port changes in the LocaltoNet client log?
Yep, I'd look at the tunnel client first, especially if the refusal is immediate. In my experience that usually means nothing is actually listening on the public side at that moment, so I'd check whether LocaltoNet still shows the TCP tunnel as active and tied to the same external address your friends are using.
I agree with checking the tunnel state first, but I would also test whether LocaltoNet can still reach the service on 25565 specifically from the host side. If the Minecraft server was changed to bind only to the LAN address and not 0.0.0.0 or 127.0.0.1, a local LAN join would still succeed while the tunnel client fails to connect internally, which could also produce an immediate refusal.
Check Windows Defender Firewall for the Java runtime or javaw.exe rule first, especially if this started literally today after working before. I’ve had Windows flip a previously allowed app back to blocked after a Java update, and localhost plus same-subnet tests can still look fine enough to send you chasing the tunnel when it’s really the host rule that changed.
Check the network profile on the adapter too, set it back to Private if Windows quietly flipped it to Public. I've seen Defender leave the Java allow rule there but stop honoring it for inbound on Public, which looks exactly like "LAN works, tunnel gets refused" if your local test came from a still-trusted subnet.
Yeah, the adapter profile is a sneaky one. I'd also check whether LocaltoNet itself is running elevated or got updated today, I've had tunnel apps stop accepting inbound until I restarted them as admin after a Windows change, which was super annoying to track down.
Yeah, worth checking the tunnel service account too if you run it that way. I've had a forwarding client come back after an update but lose access to the same user session or config, so it looked "up" while actually not attaching to the expected listener, did your LocaltoNet client recreate the tunnel today or is it the exact same one as before?
Check whether LocaltoNet is actually connecting to the same localhost target your server exposes, like 127.0.0.1:25565 vs your LAN IP:25565, because if the client or tunnel got recreated it may now be dialing the wrong side of the host. That would fit the "looks up but refuses instantly" pattern pretty well, and it's a fast compare against the current tunnel config before digging deeper.
Please log in to post a comment.