I have an Azure VM behind an Azure Public Load Balancer. The VM is running a website. I can load the website in a browser over HTTP with no issues, but when I try HTTPS I get a 502 error.

I've got a load balancing rule set up to send 443 to the VM. I allow all connections on 443 via a Network Security Group. I've triple checked the config and been looking at this for hours, but can't make any progress.

One additional clue is that if I remote into the VM, set my DNS name to point to the internal IP of the VM ( instead of pointing to the public IP of the load balancer), and load the site in a browser over HTTPS it works. I'm not sure what that means other than it seems my IIS config isn't the issue.

Any thoughts would be extremely appreciated, and I'm happy to provide more details. Thanks!

In my Azure Load Balancer when I deleted my HTTPS load balancing rule and instead added a NAT rule redirecting 443 traffic directly to one of my VMs then HTTPS worked perfectly. So it appears to be something specific to my config using HTTPS with a Load Balancing rule.

  • Have you turned on diagnostics in the web application, does anything show up? Does the request even reach the application, can you see the request in the IIS log of the web server? – Sam Cogan Mar 31 '16 at 10:24
  • I have turned on logging and it appears the request never makes it to IIS. – NorthFork Mar 31 '16 at 14:19

I finally figured out the issue, hope this saves somebody else a few hours. The problem turned out to be a combination of my load balancer Probe settings and the IIS bindings for my websites.

In IIS on the VMs I have 2 websites configured. Since the 2 websites share 1 public IP, I'm using a Host Name when setting up the bindings in IIS. So basically my bindings are configured to send www.site.com traffic to site #1 and test.site.com traffic to site #2. I didn't set up a default binding to handle port 80 traffic with a DNS name other than those 2. So if you go to http://[internal_ip_or_machine_name] no page gets loaded because there isn't a binding to handle it.

My probe was an HTTP probe set to hit /probe.html on port 80. The problem is that the probe likely hits http://[internal_ip_or_machine_name]/probe.html since the probe knows nothing about the DNS names I use, and that URL doesn't have a binding to handle it in IIS. So the probe was failing and assuming all of my VMs were offline. This resulted in the 502 error.

Not sure what fix I'll do yet. I'll either add a default binding for port 80 in IIS that points to the production website, or I'll use a TCP probe.

What really threw me for a loop is that HTTP worked fine as I mentioned above. I must have happened to have a default IIS binding in place while testing HTTP and then removed it before testing HTTPS. Now without a valid probe, both HTTP and HTTPS fail. With a valid probe, both work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.