(I'm surprised it works at all though... I wouldn't have thought you could have an HTTPS certificate for an IP address? You learn something new every day.)
Yes, the browser checks the certificate presented includes a name which exactly matches the name in the URL it is trying to fetch.
The relevant RFC specifies two types of name suitable for servers, dnsName (a Fully Qualified DNS name written as text, except that there is no final dot, and optionally an asterisk may be used to make "wildcards") and ipAddress (an IPv4 or IPv6 address stored as a numeric value). Because this RFC is only about 20 years old, some software (but not e.g. Chrome, Firefox) also checks the X.500 series Common Name on a certificate to see if that seems to be textually equivalent to the name in the URL, which is how Netscape originally did this in like 1995 or whenever they invented SSL.
Unlike for DNS names we haven't substantially cleaned up the validation mechanisms Certificate Authorities may use for IP addresses, so they're a bit... lax, but the basic structure is you need to show you really have control over the address which was easy in this case.
Before SNI, every cert had to go to a static public IP address. Everything between you and the TLS terminator had to handle this. As a side-effect, you didn't actually need to know the domain name to get the tunnel, because everything handling the packets was running on the destination IP.
You are using a slightly more recent version than me, but not significantly. There's no obvious reason there, unless Apple decided to kill support for ip addresses entirely. Is it possible that your machine has been configured in an unconventional fashion?
(I'm surprised it works at all though... I wouldn't have thought you could have an HTTPS certificate for an IP address? You learn something new every day.)