Over-riding a wildcard domain with a specific host

Help
1

I have a quick question that I’d like to confirm before pushing a prod config.

I have a Caddyfile with a wildcard domain match in it, like this:

 *.mydomain.com {
    proxy / 192.168.0.1 192.168.0.2 {
        transparent
    }
    # some other stuff
}

But I now need to send a specific subdomain to a different backend, so have tried just putting it in the config:

 specialhost.mydomain.com {
    proxy / 192.168.0.3 {
        transparent
    }
    # some other stuff
}

 *.mydomain.com {
    proxy / 192.168.0.1 192.168.0.2 {
        transparent
    }
    # some other stuff
}

But that doesn’t seem to work - I’m still getting the content form the old backend.

2

Did you reload (SIGUSR1)?

3

Yeah, I just did it again to be sure. It’s a bit odd.

What’s the order of priority for domain names? I have three blocks, in this order:

:443, :80 {}
*.mydomain.co.uk {}
specialhost.mydomain.co.uk {}
4

Aah, okay. So it works when I add :443 to it:

:443, :80 {}
*.mydomain.co.uk {}
specialhost.mydomain.co.uk:443 {}

Otherwise it seems to always pick up the first block.

It does mean that it now works on https://specialhost but http://specialhost takes me to the wrong backend. I guess I could just put both :443 and :80 on the specialhost entry, and then redirect http to https.

I’m now using this, which seems to work:

:443, :80 {
  root /opt/caddy/html

  proxy / 10.117.1.21 10.117.1.22 {
    policy ip_hash
    transparent
    except /proxy_health
  }

  log / /var/log/caddy/access.log "[{when}] {hostname} {method} {host} {path} {query} {status} {latency} {size} {>X-Forwarded-For} {>X-Forwarded-Proto} {>X-Dest-Ip}"
  errors /var/log/caddy/errors.log

  tls letsencrypt@mydomain.co.uk
  tls {
    max_certs 10
  }

  realip {
    from 1.1.1.1/32
  }
}

*.mydomain.co.uk {
  proxy / 10.117.1.21 10.117.1.22 {
    policy ip_hash
    transparent
  }

  tls /opt/caddy/ssl/static/mydomain.co.uk.pem /opt/caddy/ssl/static/mydomain.co.uk.key

  realip {
    from 1.1.1.1/32
  }

  log / /var/log/caddy/access.log "[{when}] {hostname} {method} {host} {path} {query} {status} {latency} {size} {>X-Forwarded-For} {>X-Forwarded-Proto} {>X-Dest-Ip}"
  errors /var/log/caddy/errors.log
}

specialhost.mydomain.co.uk:80 {
  redir https://specialhost.mydomain.co.uk{uri}
}

specialhost.mydomain.co.uk:443 {
  proxy / 10.117.4.20 {
    transparent
  }
  tls /opt/caddy/ssl/static/mydomain.co.uk.pem /opt/caddy/ssl/static/mydomain.co.uk.key
  log / /var/log/caddy/access.log "[{when}] {hostname} {method} {host} {path} {query} {status} {latency} {size} {>X-Forwarded-For} {>X-Forwarded-Proto} {>X-Dest-Ip}"
  errors /var/log/caddy/errors.log
}
5

The difference is in that “other stuff” that you originally elided; when you specify your own certificates, Caddy doesn’t change the port for you because it’s not “auto HTTPS” - hence it was serving on a different port.

(See, this is why including the full and complete Caddyfile is always vital!)

1 Like
6

Fair enough. I get shouted at just as much for including too much information. Can’t win either way, so might as well build up rather than down.

7

Hm, sorry if I’ve ever done that. That’s never the intent. I didn’t mean this as a personal jab at you, either, but I’m taking note next time someone complains that I ask for too much information. :wink: (Happens quite often and it irritates people. But I don’t know how we can help them otherwise.)

8

Sad to hear that :frowning:

I hope that’s never your experience here on these forums. I think anyone in IT who cares about their work (or hobby) should be as detail-friendly as possible - you can always skip a few lines of text, but you can’t afford to extrapolate something that was left out!

1 Like