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.
Using matchers in the reverse_proxy directive works as well.
the warning persists. How to do it this way around?
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.
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
I don’t understand. What’s the warning? Please be more specific. Share your logs that show this problem.
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.
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.