← Back to Forum
1
Troubleshooting

LocaltoNet tunnel suddenly giving ERR_TOO_MANY_REDIRECTS for local web app

Posted by vkingdev • July 12, 2026

This one has me weirdly excited and confused at the same time 😅 the app itself is definitely up because it opens totally fine on localhost, but through the LocaltoNet link the browser just spins into a redirect loop. I didn't intentionally change anything major today, so I'm trying to narrow this down before I start randomly flipping settings.

For anyone who's run into this, would you check app-level HTTPS redirects first, then base URL / reverse proxy config, or is this usually a forwarded headers thing when it's behind a tunnel? Happy to compare notes if there's a quick sanity check I'm missing.

Comments (7)

vkingdev Jul 12, 2026

yeah, that's exactly the weird part, localhost is fine and only the public LocaltoNet URL gets stuck bouncing. I haven't changed the app itself, so I'm leaning toward it misreading the original scheme/host through the tunnel.

Next thing I'm trying is checking whether the app trusts X-Forwarded-Proto and X-Forwarded-Host, because it kinda feels like it's redirecting to what it thinks is the "right" URL over and over.

ashleygomez Jul 12, 2026

Check the app’s canonical/base URL setting first, especially if it’s cached anywhere, because I’ve had one tiny mismatch there make the tunnel URL keep getting sent back to some other “preferred” address forever while localhost looked perfectly happy. If that value still points at an old host or assumes plain localhost, you get the little redirect merry-go-round real fast.

kyoung Jul 12, 2026

Check whether your framework is actually trusting proxy headers, because if it ignores X-Forwarded-Proto it often thinks the request came in over plain HTTP and keeps forcing HTTPS back through the tunnel forever. I've hit that with tunnels and local reverse proxies a few times, same app looked normal on localhost because there was no proxy layer involved.

Amberreed Jul 12, 2026

Yep, and one fast way to separate header trust from app config is to look at the first Location response in devtools or with curl -I. If it's rewriting to the same path but flipping scheme or host each hop, that usually tells you which input the app is deriving incorrectly.

lortiz Jul 12, 2026

Yep. Also check the status codes, 301/302 over and over is app logic, but if you see a 307/308 that can point at framework middleware being stubborn about scheme/host. I've also had LocaltoNet itself add one extra hop before the app, so I usually run curl -IL on the public URL and see exactly where the chain starts.

Lucy Jul 12, 2026

+1 to checking the full chain with curl -IL, that usually makes this way less mysterious. One extra thing I'd watch for is whether the redirect adds or drops a trailing slash, or changes /login to /login/ back and forth, I've seen routers get stuck on that through a tunnel even when the scheme looked right.

harpertech Jul 13, 2026

Check for a port getting injected into the redirect target, like :80 or your local dev port showing up in the public URL, because I’ve seen apps build absolute redirects from the wrong host info and browsers just keep chasing them. If curl -IL shows the path staying basically the same but the authority changing weirdly, thats the first thing I’d fix.

×