Hi again, I’m wondering if anything has changed with the service handlers that would be a better choice for handing off requests to a reverse proxy on fly.
I’m running caddy instances and so far have been using no handlers at all, which works. But I think I lose features like fly-prefer-region header routing, and fly response headers. I see there’s now http_proto, but it’s not clear which if any would be appropriate. Thanks for any help!
Your Caddy is doing TLS, right? The HTTP handler is typically better, but it does requires that we do the TLS. I’d almost always run
handlers = ['tls', 'http'] for HTTP proxies.
proxy_proto is for TCP connections and lets you get the end user IP / port. If you’re accepting TCP and can handle proxy proto, it’s useful. It’s a little hard to setup and debug though! You probably wouldn’t use it with the
http handler, that includes all the same info in headers and is much simpler to use.
Sorry to revive an old thread, yes I’m terminating TLS with Caddy. I know I might be losing some extra TLS termination speed by not having fly do it, but there’s a lot of benefits to having Caddy handle it .
Things like in-flight on-demand tls generation on the first request to reach it, or the ability to have an L4 pass through and let my customers terminate TLS on their end. My business model also breaks a bit if I need to pay per SSL cert, because I differentiate on having flat rates per region (or at least, flatt-er than per domain or request).
So I’m wondering if there’s a way to get some of the benefits of the fly proxy while still terminating my own TLS with Caddy. Mainly things like having fly-prefer-region headers work (they don’t seem to without the http service) and sending requests to other instances if one goes down.
Is it a binary choice? Either fly terminates the TLS or I lose the fly proxy entirely? The stuff you’ve built for that is really powerful so, like the spoiled dev I am, I want to eat my cake and still have it.