Started getting 502 on LocaltoNet HTTP tunnel while 127.0.0.1 still works

Check the Host header first, that’s the one that can break "suddenly" even when 127.0.0.1 and the port still work fine locally. I’ve had apps behind nginx and some dev servers return a bad gateway through an HTTP tunnel because they only accepted localhost/127.0.0.1 as Host, so if your app has allowed-hosts or vhost config, that’s where I’d look before messing with bind addresses.

Yeah, and one easy sanity check is to hit the app with a custom Host locally before touching the tunnel config, like curl -H "Host: whatever-your-public-subdomain-is" http://127.0.0.1:PORT/. If that fails or serves a different site, you've basically narrowed it down without changing three other variables first.

Use curl -v http://127.0.0.1:PORT/ and look at the actual listen address first, because if the process flipped to IPv6-only (::1) the browser can still seem fine while the tunnel agent trying 127.0.0.1 just gets nothing useful back. I've hit that with dev servers after an update, especially when "localhost" quietly resolves differently, so if your app answers on localhost but not on literal 127.0.0.1, thats the next thing I'd check.

That IPv6-only angle might actually be annoyingly plausible. I just tried the app on localhost and 127.0.0.1 separately and it's fine on one but not the other, which is a very cool and normal thing for software to do.

If LocaltoNet is dialing 127.0.0.1 for an HTTP tunnel, is there any way to force it to target ::1 instead, or is the fix basically "make the app listen on both and stop being clever"?

Yeah, I'd stop trying to make the tunnel adapt and just fix the listener. In my experience these agents usually expect an IPv4 target for HTTP anyway, so if the app drifted to ::1 only after an update, binding it to both stacks or explicitly to 127.0.0.1 is the least stupid fix.

Make the app listen on an actual IPv4 socket, don’t try to get cute with the tunnel side. A lot of dev servers say they’re on "localhost" but after an update they only grabbed IPv6, and the fast check for that is curl http://127.0.0.1:PORT/ versus curl http://[::1]:PORT/, if those differ you found it.

Set the app to bind explicitly to 127.0.0.1 or 0.0.0.0, yeah, trying to make the tunnel chase an IPv6-only listener is usually a waste of everyone's time. One extra tell is if the LocaltoNet agent logs show connection refused or timeout to the local target while your browser still happily loads via localhost, that's basically the app listening on the wrong stack and not some magical 502 mystery.

Check what the app itself reports as its bind address at startup, not just what curl does after the fact. I've had Node and Python dev servers print http://localhost:3000 and people assume all good, but ss -ltnp or netstat -ano showed the process was only on one family after an update, which made the tunnel look broken when it really wasnt.