Pretty much what the title says.
We were originally requesting a monitoring page from our IIS servers that was something like http://192.168.x.x/lb/health.asp.
Due to a new configuration requirement, it was necessary to change this to something like http://web1.ourdomain.com/lb/health.asp. So we configured a send string that was something like:
GET /lb/health.asp HTTP/1.1\r\nHost:web1.ourdomain.com\r\nConnection: close\r\n\r\n
Now, as part of the configuration change, the backend IIS servers were configured to no longer respond to those requests that went to http://192.168.x.x. They should only be responding to the traffic to http://web1.ourdomain.com
After this change was made, we found that the HTTP version of the monitors worked fine. However, the HTTPS versions did not.
We can go into bash and confirm that the load balancer can reach the HTTPS version of the page just fine, gets a status 200, and finds the receive string we're looking for. But regardless. the load balancer still thinks that pool member is down.
Curiously, the HTTPS monitors work fine if we leave IIS configured such that it will accept requests from any URL that reaches it, as if the HTTPS monitors were still trying to access the monitoring page via an IP address-based URL.