There are a few alternatives, depending on the setup:
First I'd make sure it's a SNI problem, does curl <IP> --resolve <domain> work as expected?
What's the response from VIP like, cached content or redirections? If it's a redirect, you could configure max_redirects and heartbeat will follow them to the end server.
Hearbeat does not support custom SNI negotiation at the moment, it uses provided host for the request. I know it's not ideal but, if you don't need to perform tls verification on the webserver, you can skip SNI by setting ssl.verification_mode: none and setting request Host headers . Something like this:
urls: ["https://<my server ip>"]
Host: "<my domain>"
X-Forwarded-Host: "<my domain>"
curl -X GET https://test.domain.com:1443 --resolve test.domain.com:1443:22.214.171.124 retured 'HTTP 200 OK'
But, curl -X GET https://126.96.36.199:1443 returned 'OpenSSL SSL_connect: SSL_ERROR_SYSCALL'.
ignore option in curl was same. (curl version 7.64.0)
(in curl Version 7.29.0, it returned 'Encountered end of file)
I`m not sure, but there is a problem with TLS handshake...
running curl --resovle with verbose, it said
Added test.domain.com:1443:188.8.131.52 to DNS cache
Hostname test.domain.com was found in DNS cache
Unfortunately, heartbeat does not have a simil --resolve option atm. If you'd like to see this feature added to heartbeat, I'd like to ecourage you to open an enhancement request over our beats repo and we will be able to analyze it internally.
In the mean time,there might be ways to work around this limitation, with some caveats. For one, you could disable tls verification in heartbeat.yml for that specific monitor. This is an example:
With ssl.verification_mode: none and check.request.headers, heartbeat will bypass SNI and request the correct domain from the end server. On the other hand, it won't verify server's certificate validity, so that information won't be attached to the monitor result.