Hi @magikstm, I’d say the easiest way to do that would be to have a fourth server running Caddy, terminating SSL and load balancing your domain to your three upstream servers.
http.proxy can indeed handle this kind of setup out of the box, with minimal configuration.
You can handle certificates manually if you like, but the load-balancing Caddy can manage your certificates automatically with no problem. If you don’t want to use Caddy as a load-balancer (maybe you’re using round-robin DNS?), there are options you can look into for the three upstream Caddy servers to each requisition and manage their own certificates, but that might get complicated.
Are you able to elaborate on which part of the documentation was vague? We’d love to improve them if possible. Was there a particular question you couldn’t find an answer for or feature that wasn’t clear?
I’ve found the Examples section to be a good resource for someone looking for a practical application of the capabilities of the proxy middleware.
The site is currently hosted on a single dedicated server and I want to add more redundancy to it and possibly https (it doesn’t use it at the moment).
More details on how https is handled on a load-balanced setup (possibly a subsection under “Policies”)
I reread this part 2-3 times and had a hard time figuring what the word “scheme” meant: to is the destination endpoint to proxy to. At least one is required, but multiple may be specified. If a scheme (http/https/quic) is not specified, http is used. Unix sockets may also be used by prefixing "unix:". QUIC connections are experimental, but to try it, just use "quic://" for the scheme.
It may be because english isn’t my first language (english). I think using “protocol” and/or possibly rewriting these a bit would make it easier to understand on a first read.
For 2, I would maybe rewrite as such:
to is the destination endpoint to proxy to. At least one is required, but multiple may be specified. A protocol or scheme as well as a port range may be specified.
Possible protocol or scheme: http://, https://, quic:// or unix: (http is default) (unix is for unix sockets)
QUIC connections are experimental.
I’m not sure “Policies” is the right place - strictly speaking, HTTPS is terminated by Caddy, so the load-balancing policy used or whether it’s load-balancing at all has no bearing on how Caddy handles HTTPS between itself and the connecting client.
The client talks HTTPS to Caddy, then Caddy talks [whatever] to the upstream server. If you want to talk HTTPS to the upstream, you designate https://upstream.example.com, and your upstream has to have its own TLS implemented as a matter of its own responsibility.
To be unambiguous, the word “scheme” in the context of a URI is defined by RFC 3986 section 3.1.
The scheme may or may not also be the name of a protocol, so it’s not particularly correct to say. To quote the RFC:
[…] the URI syntax is a federated and extensible naming system wherein each scheme’s specification may further restrict the syntax and semantics of identifiers using that scheme.