Where would an HTTPS request fail if the domain erroneously resolves to the wrong IP address?

Question

I just learned that, for whatever reason, domain names can get resolved to the wrong IP address, therefore requests can hit the wrong servers. (Just some examples of erroneous domain resolutions from Server Fault: 1, 2, 3.)

Now, if this scenario does happen and the server is configured to accept every HTTPS requests (such as in the NGINX config at the bottom), where will the process fail?

For example, if the 2 parties are server and client:

• server's TLS certificate is for domain.name where domain.name resolves to the IP address of server.

• client wants to visit https://another.org/, but, for some unforeseen reason, it resolves to server's IP address.

I have a vague idea:

1. client (erroneously) hits up server with an HTTPS request

2. This kicks off a TLS handshake

   ... which should go through because, as far as I know, client will only verify the validity of server's certificate, and not if the domain name client requested matches the domain in server's certificate.

3. The first requests go through the newly established TLS connection, but all will fail in the application level as nothing makes sense.

---

The fairly standard NGINX config:

#############
# CATCH-ALL #
#############
server {
   listen 80 default_server; 
   server_name _;
return 404;
}
##########################
HTTP-to-HTTPS redirect
##########################
server {
    listen 80;
    server_name ourdomain.com;
return 301 https://ourdomain.com$request_uri;

}
#########
HTTPS
#########
server {
    listen 443 default_server ssl http2;
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;

# ... rest of the instructions ...

}