Multiple reverse proxys on different ports

[loeffelpan (Jan)]

1. Output of caddy version:

v2.6.2 h1:wKoFIxpmOJLGl3QXoo6PNbYvGW4xLEgo32GPBEjWL8o=

2. How I run Caddy:

a. System environment:

Ubuntu 20.04.5 LTS with Caddy on Docker
Caddy container run with network_mode: host.

b. Command:

docker-compose up -d with this YAML:

c. compose file:

version: '3.7'
services:
  caddy:
    container_name: caddy
    image: caddy
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./data:/data
    restart: unless-stopped
    network_mode: host

d. My complete Caddy config:

toothless.goip.de {
        reverse_proxy localhost:11111
}

toothless.goip.de:8443 {
        reverse_proxy localhost:8123
}

pi.hole:80 {
        reverse_proxy localhost:8000
}

3. The problem I’m having:

srv0 and svr2 working fine except a warning for svr2 that server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server. Which is intended because pi.hole is only resolvable on local network. srv0 working with automatic HTTPS.
But srv1 (at port 8443) is not working.

4. Error messages and/or full log output:

Error 400 Bad Request on accessing srv1.
No errors in caddy log.

5. What I already tried:

Adding another http-port to my Caddyfile makes srv1 working, but not with proxying to port 8123 rather than 11111. So with same result as srv0.

{
        https_port 8443
}

Using matchers in the reverse_proxy directive works as well.

reverse_proxy <path> localhost:11111
reverse_proxy <otherpath> localhost 8123

But I would like to use ports to differ between services.

6. Questions:

How to avoid the warning of srv1 (only HTTP)?
Is it possible to configure second https server on same domain and different port to proxy to another local service?

[francislavoie]

@loeffelpan

How to avoid the warning of srv1 (only HTTP)?

You need to explicitly tell Caddy to use HTTPS when using a different port, by prefixing the site address with https://.

Why are you using a different port though? You could just use another subdomain instead for that service. It’s more discoverable, easier to remember, and looks better in the browser’s address bar.

[loeffelpan (Jan)]

Thanks for your reponse.

@francislavoie

You need to explicitly tell Caddy to use HTTPS when using a different port, by prefixing the site address with https://.

Sorry there was a typo. The warning is concerning the server pi.hole:80. If I change this to

http://pi.hole:80 {
        reverse_proxy localhost:8000
}

the warning persists. How to do it this way around?

@francislavoie

Why are you using a different port though? You could just use another subdomain instead for that service. It’s more discoverable, easier to remember, and looks better in the browser’s address bar.

You’re completely right. This would be the most pretty solution.

But I do not own a domain and have to use DynDNS. And my router can only update one DynDNS service. So there is only one domain for me to use.
And the domain is only used in a app on our smartphones and will never shown in any addressbar.

Any way to do this with caddy?

As an alternative I will use two DynDNS domains and keep them up to date with ddns on my ubuntu webserver.

[francislavoie]

Some services like DuckDNS (another dynamic DNS service) lets you use unlimited sub-sub-domains (and they all resolve to the same IP). I couldn’t say if the one you’re currently using does or not, but it might. For example another-app.toothless.duckdns.org

@loeffelpan

Sorry there was a typo. The warning is concerning the server pi.hole:80. If I change this to

http://pi.hole:80 {
        reverse_proxy localhost:8000
}

the warning persists. How to do it this way around?

I don’t understand. What’s the warning? Please be more specific. Share your logs that show this problem.

[loeffelpan (Jan)]

@francislavoie

Some services like DuckDNS (another dynamic DNS service) lets you use unlimited sub-sub-domains (and they all resolve to the same IP). I couldn’t say if the one you’re currently using does or not, but it might. For example another-app.toothless.duckdns.org

Thats may be a good solution for me. I take a look at this.
So I guess caddy cannot serve multiple domains on different ports with automatic HTTPS and redirects.

@francislavoie

I don’t understand. What’s the warning? Please be more specific. Share your logs that show this problem.

Nevermind. That was an configuration issue. No more warnings in my log for now.

Thanks for advice.

[francislavoie]

@loeffelpan

So I guess caddy cannot serve multiple domains on different ports with automatic HTTPS and redirects.

It can serve HTTPS on different ports. It’s just not a good idea to do so when there are better options.

Also, redirects are complicated. It depends what you mean by that. If you make an HTTP request to port 80, it’s ambiguous which site you’re trying to reach. Caddy has no way to know whether you meant to connect to the site at port 443, or at port 8443, because nothing in the request implies where you wanted to go.

If you mean redirecting HTTP traffic on your custom HTTPS port, you can enable that with the http_redirect listener wrapper, but I don’t think your usecase is a good reason to use this; you should use subdomains instead.

[loeffelpan (Jan)]

I will take a look at wildcard forwarding with duckdns (already have an account there) and maybe go with that solution.

But you may give an configuration example of this usecase, if it’s possible.

my.dydns.domain is handled by caddy with automatic https and port 80 redirects to that site on 443 proxying to my nextcloud instance.
And I would be fine with another site listening on port 8443 only available via https secured with the same certificate.

[francislavoie]

@loeffelpan

But you may give an configuration example of this usecase, if it’s possible.

I already did. Just use https:// in front of that site. Like https://toothless.goip.de:8443.

But yeah, DuckDNS will be a better solution. And it’s not “wildcard forwarding”, it’s multiple sub-sub-domains. No wildcards.

yourname.duckdns.org {
	reverse_proxy localhost:11111
}

nextcloud.yourname.duckdns.org {
	reverse_proxy localhost:8123
}

That’s it.

[loeffelpan (Jan)]

@francislavoie

I already did. Just use https:// in front of that site. Like https://toothless.goip.de:8443.

Sorry for missing that. I’ll try out. Thanks.

@francislavoie

And it’s not “wildcard forwarding”

You’re right. No wildcard or something caddy’s config.
That was just my naming of forwarding every *.my.duckdns.org to the same IP like my.duckdns.org without specifying any single sub-subdomain.

Thanks again for your advice.