Fix Azure Load Balancer Issues: Setup & Config Guide

Health probes are how Azure Load Balancer decides which backend VMs are fit to receive traffic. If a VM stops responding to probes, it gets pulled from rotation. The tricky part is that "not responding to probes" and "the probe is being blocked by an NSG" look identical to the load balancer. Both situations result in the VM being marked unhealthy.

In the Azure portal, go to your Load Balancer → Settings → Health probes. Check the following for each probe:

• Protocol: TCP probes just check if the port is open. HTTP/HTTPS probes expect a 200 OK response from a specific path. If you're using HTTP but your app returns 301 redirects, the probe will fail.
• Port: Must match the actual port your application is listening on inside the VM, not the frontend port of the load balancer.
• Interval and Unhealthy threshold: Default is 15-second intervals, 2 consecutive failures before marking unhealthy. If your app has a slow startup, increase the threshold.

To add or update a health probe via CLI:

az network lb probe create \
  --resource-group myResourceGroup \
  --lb-name myLoadBalancer \
  --name myHTTPProbe \
  --protocol Http \
  --port 80 \
  --path /health \
  --interval 10 \
  --threshold 3

To test whether your application actually responds correctly on the probe port, SSH or RDP into one of your backend VMs and run:

# Linux
curl -v http://localhost:80/health

# Windows PowerShell
Invoke-WebRequest -Uri "http://localhost:80/health" -UseBasicParsing

If this returns anything other than HTTP 200, your application isn't responding correctly to the probe path, and the load balancer will never mark that VM healthy. Fix the app endpoint first, then re-check the Insights dashboard. The DipAvailability metric should climb back toward 100% within two probe intervals once the endpoint is healthy.

This is where most Azure Load Balancer setup problems actually live. Standard Load Balancer is built on a Zero Trust security model, traffic is blocked by default unless you explicitly open it. Many people configure the load balancer rules perfectly and then forget that the NSG on the backend VMs' NICs (or the subnet NSG) is still locked down.

You need at minimum two inbound NSG rules on your backend instances:

1. A rule allowing your actual application traffic (e.g., TCP port 80 or 443 from any source)
2. A rule allowing health probe traffic from the AzureLoadBalancer service tag

In the Azure portal: navigate to your NSG → Inbound security rules → click + Add. Create the health probe rule first since it's the most commonly missing one.

Or do it with CLI, run both commands:

# Allow application traffic (port 80 example)
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowHTTPInbound \
  --priority 100 \
  --direction Inbound \
  --source-address-prefixes '*' \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges 80 \
  --protocol Tcp \
  --access Allow

# Allow health probe traffic from Azure Load Balancer
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowAzureLoadBalancerProbe \
  --priority 110 \
  --direction Inbound \
  --source-address-prefixes AzureLoadBalancer \
  --source-port-ranges '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*' \
  --protocol '*' \
  --access Allow

After adding these rules, wait about 60 seconds and check the Health Probe Status metric in Insights again. If it was sitting at 0% because of blocked probes, you should see it jump immediately. If traffic is still not flowing, check whether the NSG is applied at the subnet level as well, subnet-level NSGs are evaluated before NIC-level NSGs, and a deny rule at the subnet level will override any allow rule on the NIC.

One more thing: if your traffic still isn't getting distributed after NSG rules look correct, double-check that your load-balancing rule has Session persistence set correctly. If it's set to "Client IP" or "Client IP and protocol," all traffic from the same source IP will always go to the same backend VM, which can look like uneven distribution or no distribution at all if that one VM is unhealthy.

An empty or incorrectly configured backend pool is a surprisingly common Azure Load Balancer configuration error. The load balancer has no VMs to send traffic to, so nothing works, but the portal might not make this obvious at a glance.

Go to your Load Balancer in the Azure portal → Settings → Backend pools. Click your pool and verify:

• The correct VMs or Virtual Machine Scale Sets (VMSS) are listed
• Their state shows as "Succeeded" (not "Failed" or "Updating")
• The VMs are in the same virtual network as the load balancer
• For NIC-based backend pools, the correct NIC and IP configuration is selected

You can add a VM to the backend pool via CLI like this:

# Get the NIC ID of the VM you want to add
NIC_ID=$(az vm show \
  --resource-group myResourceGroup \
  --name myBackendVM \
  --query "networkProfile.networkInterfaces[0].id" \
  --output tsv)

# Add the NIC's IP config to the backend pool
az network nic ip-config address-pool add \
  --resource-group myResourceGroup \
  --nic-name myBackendVMNIC \
  --ip-config-name ipconfig1 \
  --lb-name myLoadBalancer \
  --address-pool myBackendPool

Keep in mind that Azure Load Balancer distributes inbound flows to backend pool instances according to its load-balancing algorithm, by default, a 5-tuple hash based on source IP, source port, destination IP, destination port, and IP protocol. This means you need at least two healthy VMs in the backend pool to actually see traffic distribution. With one VM, all traffic goes to that one instance, which is fine for availability, but not for load testing.

If you're running a Virtual Machine Scale Set, make sure the VMSS instances are not in a "Deallocating" or "Stopped (deallocated)" state, deallocated instances are automatically removed from the backend pool and won't receive traffic. Check the VMSS instance health in the portal under the VMSS resource → Instances.

Once VMs are properly added and the health probes pass, the Insights dashboard will show both Data Path Availability and Health Probe Status at or near 100%. That's your confirmation.

Here's a scenario I hear about constantly: "My VMs behind the load balancer suddenly can't reach the internet. Outbound connections are failing with timeouts." This is one of the most confusing Azure Load Balancer issues because the problem isn't with the load balancer itself, it's with how Standard Load Balancer handles outbound SNAT (Source Network Address Translation).

When you attach VMs to a public Standard Load Balancer, Azure automatically provides outbound internet connectivity by translating the VMs' private IPs to the load balancer's public IP. But this only works if you have outbound rules configured, or if your load-balancing rules have "Outbound SNAT" enabled. By default in Standard SKU, outbound rules are not automatically created.

For a Standard internal load balancer, there is no outbound internet connectivity at all by default. The internal LB only handles traffic within the virtual network. If your VMs need internet access, you need a separate solution, either attach a public load balancer with outbound rules, deploy an Azure NAT Gateway on the subnet, or assign public IPs directly to the VMs.

To create an outbound rule on your public Standard Load Balancer via CLI:

# First, ensure you have a frontend IP configuration for outbound
az network lb outbound-rule create \
  --resource-group myResourceGroup \
  --lb-name myPublicLoadBalancer \
  --name myOutboundRule \
  --frontend-ip-configs myFrontendIP \
  --protocol All \
  --outbound-ports 10000 \
  --address-pool myBackendPool

If you're seeing SNAT port exhaustion errors, which show up as intermittent connection failures to external services, look at the SNAT Connection Count metric in Azure Monitor for your load balancer. A high number of failed SNAT connections indicates you're running out of SNAT ports. The fix is to either increase the number of outbound ports in your outbound rule, add more frontend IPs to multiply your SNAT port allocation, or move to a NAT Gateway which provides significantly more SNAT ports per VM.

To check SNAT connection counts via PowerShell:

Get-AzMetric `
  -ResourceId "/subscriptions/{subId}/resourceGroups/myRG/providers/Microsoft.Network/loadBalancers/myLB" `
  -MetricName "SnatConnectionCount" `
  -TimeGrain 00:01:00 `
  -StartTime (Get-Date).AddHours(-1) `
  -EndTime (Get-Date)

Once you configure outbound rules correctly and the SNAT ports are no longer exhausted, outbound connections from your backend VMs will start working again immediately. No restart required.

I want to be direct about this: Basic Load Balancer was officially retired on September 30, 2025. If you're reading this after that date and you're still running Basic, Microsoft is no longer providing support, SLAs, or bug fixes for your load balancer. Your environment is in a precarious spot.

You cannot do an in-place SKU upgrade. Basic and Standard Load Balancers are architecturally different enough that you need to migrate resources, not just click an "upgrade" button. The good news: Microsoft provides a PowerShell migration module that automates most of this.

Key differences you need to understand before migrating:

• Security model: Basic is open to the internet by default. Standard uses Zero Trust, closed by default, NSGs required.
• Availability zones: Basic does not support availability zones. Standard is zone-redundant by default.
• Backend pool size: Basic supports up to 300 instances. Standard supports up to 5,000.
• Diagnostics: Standard has multidimensional metrics and Azure Monitor integration. Basic has minimal diagnostics.
• Gateway Load Balancer chaining: Only available with Standard SKU.

To run the automated migration:

# Install the migration module (run in PowerShell as Administrator)
Install-Module -Name AzureLoadBalancerMigration -Force

# Connect to your Azure account
Connect-AzAccount

# Run the migration (this creates a new Standard LB and migrates your config)
Start-AzBasicLoadBalancerMigration `
  -ResourceGroupName "myResourceGroup" `
  -BasicLoadBalancerName "myBasicLB" `
  -StandardLoadBalancerName "myNewStandardLB"

The script will pause and ask for confirmation before making changes. Review everything carefully, especially the NSG rules it recommends creating. After migration, verify your Health Probe Status and Data Path Availability metrics in Insights immediately. Because Standard LB is closed by default, if you didn't have NSG rules before, traffic will be blocked post-migration until you add them. That's the number one post-migration complaint: "migration worked but now nothing reaches my VMs." Add the AzureLoadBalancer service tag rule and your application port rule as described in Step 2, and you'll be back online.