Load Balancer errors — deployment codes, health probes, no inbound traffic on Standard, and outbound SNAT
Why an Azure Standard Load Balancer deployment fails or traffic doesn't reach the backend — the deployment error codes (SKU mismatch with public IPs, duplicate rules on a scale set, unused probes, rule limits per NIC, outbound port settings), health probes marking backends down (port, path, NSG blocking AzureLoadBalancer or 168.63.129.16, aggressive intervals), Standard load balancers being closed to inbound until an NSG allows it, and the Basic SKU retirement.
markdownreferencev104Q3-XJY7stage: operatetrust: officialservice: load-balancerinterface: anyDifferentSkuLoadBalancersAndPublicIPAddressNotAllowedDifferentSkuLoadBalancerAndPublicIPAddressNotAllowedInVMSSMaxAvailabilitySetsInLoadBalancerReachedRulesOfSameLoadBalancerTypeUseSameBackendPortProtocolAndIPConfigAnotherInternalLoadBalancerExistsCannotUseInactiveHealthProbeVMScaleSetCannotUseMultipleLoadBalancersOfSameTypeLoadBalancerWithoutFrontendIPCantHaveChildResourcesLoadBalancerRuleCountLimitReachedForNicLoadBalancerInUseByVirtualMachineScaleSetSpecifiedAllocatedOutboundPortsForOutboundRuleIsNotAMultipleOfEighthealth probe downDIPProbeDownAzureLoadBalancer service tag NSG168.63.129.16 probeStandard load balancer no inbound connectivity NSGBasic load balancer retired September 30 2025load balancer failed state
Load Balancer errors
Basic Load Balancer and Basic public IPs retired on September 30, 2025: use Standard (or StandardV2 public IPs where a resource needs them). A Standard load balancer and Standard public IP are closed to inbound traffic until an NSG allows it: with no NSG on the backend subnet or NIC, nothing arrives. Add an NSG with an explicit allow rule for the frontend port.
Deployment errors
| Code | Cause → fix |
|---|---|
DifferentSkuLoadBalancersAndPublicIPAddressNotAllowed | Load balancer and public IP SKUs differ: make them match (Standard) |
DifferentSkuLoadBalancerAndPublicIPAddressNotAllowedInVMSS | A scale set without a SKU or Standard instance IPs picked Basic: specify Standard |
MaxAvailabilitySetsInLoadBalancerReached | More than 150 availability sets in the backend pool; standalone VMs each count as one |
RulesOfSameLoadBalancerTypeUseSameBackendPortProtocolAndIPConfig / …AndVmssIPConfig | Two rules on the same backend port and protocol for the same scale set: change one |
AnotherInternalLoadBalancerExists / VMScaleSetCannotUseMultipleLoadBalancersOfSameType | At most one internal and one public load balancer per backend set |
CannotUseInactiveHealthProbe | A scale set's health probe isn't used by any rule |
LoadBalancerWithoutFrontendIPCantHaveChildResources | Add a frontend IP configuration before rules, probes or pools |
LoadBalancerRuleCountLimitReachedForNic | A backend NIC can be in at most 300 rules |
LoadBalancerInUseByVirtualMachineScaleSet | Delete or detach the scale set named in the error first |
SpecifiedAllocatedOutboundPortsForOutboundRule… | Outbound rule port settings: reference/networking/outbound-connectivity.md |
ResourceDeploymentFailure with the load balancer in a Failed state | Re-send the resource unchanged (Microsoft's steps use a PUT then GET in Resource Explorer) until provisioningState is Succeeded |
Health probes mark backends down
| Finding | Fix |
|---|---|
| Backend pool empty, or NICs of deleted or deallocated VMs | Fix pool membership |
| Probe port isn't the port the app listens on, or the app stopped | Match the port; restart the service |
| HTTP/HTTPS probe path returns anything but 200 (403, 404, 500 and redirects all fail, immediately) | Point the probe at an anonymous path returning 200 |
An NSG or guest firewall blocks AzureLoadBalancer / 168.63.129.16 on the probe port | Allow it; the default rule AllowAzureLoadBalancerInBound (65001) does unless a higher-priority deny overrides it |
| Slow responses, or an aggressive probe (interval ≤ 5 s and one probe) | Make the endpoint faster, or relax the interval and count |
Check with the Health Probe Status metric and the load balancer's health event logs; from a VM in the VNet, call the probe path yourself. Connection troubleshoot reports this as DIPProbeDown (guides/networking/diagnose-connectivity.md).