I'd like to reverse proxy to another reverse proxy

1. Output of caddy version:

v2.6.1 h1:EDqo59TyYWhXQnfde93Mmv4FJfYe00dO60zMiEt+pzo=

2. How I run Caddy:

I am running caddy in docker with a very simple docker compose file and a very simple caddyfile, and it works flawlessly. I am a “homelabber” so this is not a production type setup, nor do I bring the needed IT skills to express myself appropriately, as by trade I am a mere physicist.

a. System environment:

debian bullseye, latest docker

c. Service/unit/compose file:

version: "3.7"
    image: caddy:latest
    container_name: caddy
    restart: always
    stdin_open: true
    tty: true
      - ./caddy/container-data:/data
      - ./caddy/container-config:/config
      - /etc/localtime:/etc/localtime:ro
      - 80:80
      - 443:443
    entrypoint: /usr/bin/caddy run --adapter caddyfile --config /config/Caddyfile

d. My complete Caddyfile:

web.example.com {
	encode gzip
	reverse_proxy *

web.beispiel.de {
	encode gzip
	reverse_proxy *

3. The problem I’m having:

Caddy v2.6.1 works out of the box and it is fantastic. It works well if I reverse proxy to individual services without any issues. e.g. web.example.com.

However, the second domain in this example is not a simple single service, but instead another reverse proxy that needs port 80 and port 443 to generate its own certificates as well. Would there be a way to do this.

That’s a complicated question.

Why do you need your upstream server to manage its own cert? Is it available with a different domain name or something?

Typically you’ll just have Caddy terminate TLS for everything behind it, because that’s what it excels at.

If you’re putting a TLS server in front of your backend, then it’s not possible for the backend to solve the TLS-ALPN challenge because Caddy can’t proxy that part. So that leaves you with the HTTP challenge, but Caddy also won’t proxy that (by default anyway) because it responds with an HTTP->HTTPS redirect to make sure users are served HTTPS only for privacy and security.

So all that to say, if your upstream isn’t otherwise available to the public internet, just serve it over port 80 on that server only, and have Caddy manage a cert for that domain.

Thank you for your answer; this is what I thought might be the case. As I mentioned, I am a mere homelabber, but played around with haproxy, nginx and traefik as well, and thus pretty much learned the basics of what is possible with all of them, I just picked caddy two days ago, and could create a stable reverse proxy in 12 minutes, It was a breeze.

To your question, why would anyone do this? For me, I serve two domains on one IP address and have a bunch of individual services running on multiple hosts, often some of those are more involved services they do come with their own reverse proxies that want their own cert in their own folder and its a mess to rsync the certs around. And so I thought It would be nice if I could basically just do something like I mentioned.

1 Like

See this article:

Essentially, Caddy will be the point of entry into your network, so you can just let it manage TLS.

Of course, keep in mind that this assumes your LAN is trusted, and that there’s no bad actors connected to the network (they could intercept/sniff/manipulate the traffic between Caddy and your app).

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.