← Back to Forum
0
Setup & Configuration
LocaltoNet HTTPS tunnel, TLS passthrough or termination?
I'm testing this pretty cautiously because the app already manages its own certs and a few flows depend on the original TLS session, not just "HTTPS somewhere in front." Things like client certs, strict redirects, and anything that inspects the handshake could break if the tunnel is actually terminating at the edge and then proxying plain HTTP back to localhost.
Has anyone confirmed how LocaltoNet behaves here, especially the difference between its HTTP/HTTPS tunnel mode and any raw TCP option if that's the only way to keep it end to end? If you use it this way, I'd also like to know the practical tradeoffs, not just whether it technically works.
Comments (3)
Use a TCP tunnel if you need the TLS session preserved end to end, the HTTP/HTTPS mode is a reverse proxy and it will handle the secure layer on the LocaltoNet side first. In practice that means no original client cert exchange or handshake details reach your app in HTTP mode, while TCP gives you the real socket but you lose the convenient web features like host based routing and the simpler browser-facing setup.
Yep, TCP is the one you want, and the annoying tradeoff is usually on the app side: your service needs to tolerate being reached on the tunnel host/port directly, because stuff that assumes a pretty public HTTPS URL or standard 443 can get weird fast. I ran into redirect/callback issues with a couple local dashboards because they kept generating their own canonical URL from the incoming host/port, so that's the bit I'd test first.
Set the app to trust forwarded host/proto only if you stay in HTTP mode, otherwise for TCP I’d also verify it supports SNI on the local listener, because that bit trips up a lot of services when you swap from a normal direct client path to a tunnel. I hit that with a small game panel and the cert looked fine, but the app picked the wrong vhost until I matched the server name properly.
Please log in to post a comment.