So from looking at the caddy output, there was no reaction to curl. The log output occured when I started caddy.
That’s because your curl command was issued directly to the upstream service (port 8055) and not Caddy (port 8555), bypassing Caddy. As for the record length issue…
The reason you can’t connect to https://*:8555 is because Caddy is serving HTTP on this port. The “SSL record” is too long because Caddy simply isn’t responding with proper HTTPS.
Caddy can’t easily manage a certificate for a site for which the domain name is not known. You would require On-Demand TLS for that functionality.
See:
https://caddyserver.com/docs/automatic-https#on-demand-tls
Alternatively, if you set a hostname (e.g. caddy reverse-proxy --from localhost:8555 --to :8055), it should use internal TLS, and setting a full domain name should see it attempting to requisition a certificate from a public service.
Further, because your caddy reverse-proxy command didn’t have a colon(:) in front of the upstream port, it assumed (as you can see in the above quoted Caddy log detail) that 8055 is the hostname and then proxied to the default port 80 on that host. You’ll need to specify the full --to :8055 to ensure Caddy knows you’re talking about a port, here.