Azure Load Balancer Not Passing HTTPS (443) Traffic to Backend VMs Despite Healthy Probes

Question

Azure Load Balancer Not Passing HTTPS (443) Traffic to Backend VMs Despite Healthy Probes

Danny Yim 0

We have a Standard Azure Load Balancer (azure-lb-primary) in front of two Ubuntu 22.04 VMs running Nginx. HTTP (port 80) is working correctly and all backend instances are healthy. However, HTTPS (port 443) traffic is failing with PR_END_OF_FILE_ERROR / SSL unexpected EOF on the client side.

What we have confirmed:

Both VMs are healthy in the backend pool
HTTP:80 health probe passing successfully on both VMs
SSL certificate is valid and verified (openssl s_client confirms handshake succeeds when connecting directly to the VM)
Nginx is listening on 0.0.0.0:443
NSG rules allow port 443 inbound
Minimal Nginx config (no ModSecurity, no custom ciphers) still reproduces the issue
The SSL EOF error occurs before any HTTP data is exchanged, suggesting the LB is terminating the TLS connection rather than passing it through

Suspected issue: The Load Balancer rule lb-rule_443 (TCP/443) is not transparently passing TLS traffic through to the backend VMs.

Resources:

Load Balancer: azure-lb-primary
Frontend IP: xxx.xxx.xx.xxx
Backend pool: azure-primary (2 instances: 10.10.10.4, 10.10.10.5)
Region: (add your Azure region)
Resource Group: (add your resource group) We have a Standard Azure Load Balancer (azure-lb-primary) in front of two Ubuntu 22.04 VMs running Nginx. HTTP (port 80) is working correctly and all backend instances are healthy. However, HTTPS (port 443) traffic is failing with PR_END_OF_FILE_ERROR / SSL unexpected EOF on the client side.
```
**What we have confirmed:**
```
- Both VMs are healthy in the backend pool
- HTTP:80 health probe passing successfully on both VMs
- SSL certificate is valid and verified (openssl s_client confirms handshake succeeds when connecting directly to the VM)
- Nginx is listening on 0.0.0.0:443
- NSG rules allow port 443 inbound
- Minimal Nginx config (no ModSecurity, no custom ciphers) still reproduces the issue
- The SSL EOF error occurs before any HTTP data is exchanged, suggesting the LB is terminating the TLS connection rather than passing it through

Suspected issue: The Load Balancer rule lb-rule_443 (TCP/443) is not transparently passing TLS traffic through to the backend VMs.

Resources:

Load Balancer: azure-lb-primary
Frontend IP: xxx.xxx.xx.xxx
Backend pool: azure-primary (2 instances: 10.10.10.4, 10.10.10.5)
Region: US East

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-06-09T16:11:05.0233333+00:00
Hi @ Danny Yim,

Welcome to Microsoft Q&A Platform.

I understand your concern regarding whether Azure Load Balancer is terminating the TLS connection. However, Azure Standard Load Balancer operates at Layer 4 (TCP/UDP) and does not terminate or inspect TLS traffic; it simply forwards packets to the backend pool.

To further isolate the issue, please verify the following:

Make sure your 443 rule has a proper TCP (or HTTPS) health probe

Right now you have a probe on port 80. Create a new probe on port 443 (preferably TCP for a simple “is the port open?” check) and attach it to your lb-rule_443.

Without a correct probe, LB might mark a backend “healthy” on 80 but never really confirm 443 is reachable.

Validate NSG rules allow both the LB probe IP and client IPs on 443

Even if you opened 443, double-check there’s no higher-priority NSG deny rule blocking traffic from the health-probe IP or your users.

Confirm Nginx really sees the incoming handshake

SSH to one of the VMs and run: sudo tcpdump -n -i any port 443

While you attempt the HTTPS connect to the frontend IP, you should see the SYNs and TLS ClientHello hit your VM. If you don’t, the LB/NSG side is at fault. If you do, check Nginx error logs—maybe the default_server or ssl settings are incorrect.

Use Network Watcher to simulate connectivity

In Azure Portal navigate to Network Watcher → Connection troubleshoot. Test from the LB probe IP to your VM’s private IP on port 443. This will pinpoint whether Azure’s data path or your VM is dropping the traffic.

Once you have a TCP-based probe on 443 and you confirm packets reach your VM, your TLS handshake should complete just as it does when you hit the VM directly.

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.

References:
https://learn.microsoft.com/azure/load-balancer/load-balancer-custom-probe-overview#probe-protocol
https://learn.microsoft.com/azure/load-balancer/load-balancer-standard-diagnostics#are-the-backend-instances-for-my-load-balancer-responding-to-probes

Please "upvote" if the information helped you. This will help us and others in the community as well.
Rachana Thipparapu 10 Reputation points Microsoft External Staff Moderator

2026-07-14T14:24:56.07+00:00

Hello @Danny Yim

I wanted to follow up on our previous conversation and check if you had an opportunity to review the information shared. If you have any questions or concerns please feel free to let me know.
Rachana Thipparapu 10 Reputation points Microsoft External Staff Moderator

2026-07-16T15:58:16.05+00:00

Hello @Danny Yim

Following up to see if the above information was helpful. And, if you have any further query do let us know.

1 answer

Your answer

Rachana Thipparapu 10 Reputation points Microsoft External Staff Moderator

2026-07-14T14:24:56.07+00:00

Hello @Danny Yim

I wanted to follow up on our previous conversation and check if you had an opportunity to review the information shared. If you have any questions or concerns please feel free to let me know.
Rachana Thipparapu 10 Reputation points Microsoft External Staff Moderator

2026-07-16T15:58:16.05+00:00

Hello @Danny Yim

Following up to see if the above information was helpful. And, if you have any further query do let us know.

Answer 1

Hi Danny, Standard Load Balancer is Layer 4 and does not terminate TLS, so an EOF normally means the 443 flow is being reset or sent to a backend that cannot complete the handshake. Verify the load-balancing rule is TCP frontend 443 to backend 443, attach a TCP 443 health probe, and confirm the NSG permits both client traffic and the AzureLoadBalancer probe service tag. While testing the frontend IP, run tcpdump on both VMs and check the Nginx error log; that quickly separates an Azure data-path issue from an Nginx/SNI/default-server problem. Also confirm both backends present the same certificate/configuration and that no host firewall is rejecting one node. If no SYN reaches either VM, use Network Watcher connection troubleshoot and capture the rule, probe, flow-log, and correlation details for support.