For simplicity, I’ll call them “front” and “back” Caddy instances.
If you want your back instances to manage TLS, your front instance must do TCP-layer proxying such that it doesn’t terminate TLS. This means you can’t use vanilla Caddy to do this, you’d need to use GitHub - mholt/caddy-l4: Layer 4 (TCP/UDP) app for Caddy (or any other layer4 proxy) to transparently proxy the TCP traffic. You could use TLS-SNI matching to split the traffic between different backend servers if necessary.
Simpler is to have the front instance terminate TLS, then you can proxy over HTTP to the back instances which are listening for HTTP (not HTTPS). You’d use http://domain1.com as your site address on your back instances for that. This approach is fine as long as your back instances are not publicly accessible and only accessible through your front instance (with a VPN or tunnel of somekind).
More complex is using mTLS (mutual TLS) between your front and back instances so you do HTTPS between them (instead of HTTP in my previous paragraph). This is complex to set up though. See Caddy reverse proxy + Nextcloud + Collabora + Vaultwarden with local HTTPS which covers how this is set up (you can ignore the Nextcloud-specific parts of that article, focusing on mTLS stuff).