But if your administrator’s proxy only forwards app1.example.com to you, then you won’t be able to add app2.example.com just by adding it to your Caddyfile.
Instead, your administrator might have to add that to their proxy as well (and maybe create another dns record).
If you only care about app1.example.com for now, then sure.
Your B. Topology from that image you shared with
will suffice. auto_https off on the other hand, not.
What you’re asking for is a TCP proxy, which means not decrypting the connection before passing it on upstream.
Vanilla Caddy doesn’t do that, but you could do it with GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy which is a plugin for Caddy that can proxy TCP/UDP. But this is a lot more complicated to use because it only supports JSON config at the moment, no Caddyfile support (see the GitHub issues for details on that).
Why must you keep the TLS connection unbroken? You could have Caddy terminate TLS using its own certificate issued from an ACME issuer, then proxy upstream over either HTTP (if your upstream has an HTTP port exposed) or HTTPS (i.e. another TLS connection to upstream, if necessary).
By using above caddy config, I can successfully browse to https://app1.example.com/v2022-dev and load my login page of PHP app,
I have inspect using chrome devtools, and here is one error sample (other issue have more or less similar error) shows on the console:
Mixed Content: The page at 'https://app1.example.com/v2022-dev/?f=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://app1.example.com/v2022-dev/asset/plugins/datatables-bootstrap/dataTables.bootstrap.custom.css'. This request has been blocked; the content must be served over HTTPS
Is it can be handled by caddy or there’s should be some changes in my code?
I also try to issue certificate using caddy. The certificate issued successfully, no error on caddy logs. But the browser end up with too many redirects error. I am using this caddyfile:
Your upstream app needs to be updated to produce URLs with the same scheme as the incoming requests (or just use //app1.example.com, i.e. no scheme, which will let browsers use the appropriate scheme, or use absolute URLs with no hostname in it which would be even better).