Ssl – ERR_CONNECTION_TIMED_OUT with IIS 10 on some SSL IPv6 Bindings, dependent on host name

Running IIS 10 on Windows Server 2016, I have encountered an issue where an IPv6 binding has mysteriously stopped working.

When connecting from the server via IPv6 or connecting from any system via IPv4, everything works fine and the site loads as expected.

When connecting to the hostname with no subdomain or when connecting to another domain bound to the same site, IPv6 works fine, however when attempting to connect with a www subdomain or several other previously working subdomains, the connection times out over HTTPS. HTTP (which is setup just to redirect to HTTPS) also is working fine regardless of hostname.

Both working and unworking bindings are going to the same IPv6 addresses and both the working IPv4 bindings and the IPv6 bindings are on the same IIS site. I have rebuilt the bindings without any luck.

I'm running out of ideas on what to check. What could be causing HTTPS over IPv6 to time out on only some subdomains? (I've also tried with simple text files to ensure that it isn't a scripting issue. I've also tried clearing the web.config without any luck.)

The site in question is ajhenderson.com. robots.txt is available on the root and can be used for seeing the behavior.

• https://ajhenderson.com/robots.txt should work over IPv4 and IPv6.
• https://www.ajhenderson.com/robots.txt is working over IPv4, but not over IPv6.
• https://www.synthesissoftware.com/robots.txt is working over both.

Other sites on the same IIS instance but using different IPv6 addresses and IIS sites are working fine. Attempting to use the IPv6 address for ajhenderson.com with one of the other sites had the same failure (moved the www.ajhenderson.com binding to another IIS site).

Update: It appears whatever was causing the problem resolved itself. I had run tests in both Chrome and Firefox from both Windows machines and Android from 4 different devices with 4 different internet connections in 2 different states. They were all showing the same behavior earlier, but now have mysteriously corrected themselves.

Update again: It appears to be a somewhat intermittent problem, however it is back at this time, though it looks like maybe it is IPv4 not working and IPv6 working this time around. Here is a line from httperr.log:

2018-05-04 18:44:52 x.x.x.x 27313 74.208.155.100 443 - - - - - - ClientCancel -