1. The problem I’m having:
I am trying to setup a reverse_proxy for my domain and subdomains: *.example.com. I am using the map directive to map the host to backend. But certain backends are https, so I need to specially handle them with tls_insecure_skip_verify. (Please don’t tell me to use TLS, this is an internal reverse proxy and I don’t have control over it 
).
Please pardon redactions, I am sorry I need to redact domains.
2. Error messages and/or full log output:
Website is not accessible because TLS verification fails if it.
If I set tls_insecure_skip_verify under transport http directive, then foo.example.com fails to resolve.
If I don’t set tls_insecure_skip_verify, then bar.example.com fails to resolve.
I want to handle both scenarios. I don’t mind unrolling the map directive, but I don’t understand how it works. {host} in the map directive seems like a keyword that’s built into the caddy parser. I am assuming some magic happens in the reverse_proxy directive that maps the hosts to the backend.
3. Caddy version:
v2.7.6
4. How I installed and ran Caddy:
Downloaded cloudflare version of caddy and put it in /usr/bin/caddy. I used the service that was setup from apt install caddy on Debian machine. Caddy runs fine.
a. System environment:
Debian 12
b. Command:
systemctl start caddy.service
d. My complete Caddy config:
*.example.com {
tls {
dns cloudflare <redacted>
}
map {host} {backend} {
foo.example.com foo.internal-company.com:80
bar.example.com bar.internal-company.com.:443
}
reverse_proxy {backend} {
transport http {
resolvers 1.1.1.1 1.0.0.1
}
}
}
Failed experiments to unroll map directive
Trial 1
*.example.com {
tls {
dns cloudflare <redacted>
}
reverse_proxy foo.example.com foo.internal-company.com:80 {
transport http {
resolvers 1.1.1.1 1.0.0.1
}
}
reverse_proxy bar.example.com bar.internal-company.com:443 {
transport http {
resolvers 1.1.1.1 1.0.0.1
tls_insecure_skip_verify
}
}
}
Trial 2
*.example.com {
tls {
dns cloudflare <redacted>
}
@foo handle host foo.example.com
reverse_proxy @foo foo.internal-company.com:80 {
transport http {
resolvers 1.1.1.1 1.0.0.1
}
}
@bar handle host bar.example.com
reverse_proxy @bar bar.internal-company.com:443 {
transport http {
resolvers 1.1.1.1 1.0.0.1
tls_insecure_skip_verify
}
}
}
Failed experiments to use multiple map directives to handle http/https upstreams.
Didnt work:
*.example.com {
tls {
dns cloudflare <redacted>
}
# Non TLS backends list
map {host} {backend} {
foo.example.com foo.internal-company.com:80
}
reverse_proxy {backend} {
transport http {
resolvers 1.1.1.1 1.0.0.1
}
}
# TLS backends list
map {host} {tls_backend} {
foo.example.com foo.internal-company.com:443
}
reverse_proxy {tls_backend} {
transport http {
resolvers 1.1.1.1 1.0.0.1
tls_insecure_skip_verify
}
}
}
Using multiple outputs in map directive doesn’t work either:
*.example.com {
tls {
dns cloudflare <redacted>
}
map {host} {backend} {tls_verify} {
foo.example.com foo.internal-company.com:80 -
bar.example.com bar.internal-company.com.:443 tls_insecure_skip_verify
}
reverse_proxy {backend} {
transport http {
resolvers 1.1.1.1 1.0.0.1
{tls_verify}
}
}
}
I don’t care about using map directive or not, I’ve already spent 5 hours on this issue so it is fine to unroll it or not. I would be really happy with any solution where I can handle both scenarios.
Any help really appreciated! Thank you!!!