Ensure the configured port is open and there are no firewall rules or Azure Network Security Groups blocking incoming or outgoing traffic on the port configured.This should be returned within the 30-second timeout period.
Problems with default health probe Causeĥ02 errors can also be frequent indicators that the default health probe can't reach back-end VMs. If present, ensure that the DNS server can resolve the backend pool member's FQDN correctly. Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName DNS can be checked by looking at details of the VNet properties in the output. Check presence of custom DNS in the VNet.Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg Check effective NSG and route with the backend VM.Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName For example, check for routing to network virtual appliances or default routes being advertised to the application gateway subnet via ExpressRoute/VPN. Ensure that the UDR isn't directing traffic away from the backend subnet. Check UDR associated with the application gateway subnet.Ensure that communication to backend isn't blocked. Check NSGs associated with the application gateway subnet.Validate NSG, UDR, and DNS configuration by going through the following steps: A FQDN used for backend pool members might not resolve correctly by the user configured DNS server for the VNet. Similarly, the presence of a custom DNS in the VNet could also cause issues. The NSG/UDR could be present either in the application gateway subnet or the subnet where the application VMs are deployed. This causes probe failures, resulting in 502 errors. If access to the backend is blocked because of an NSG, UDR, or custom DNS, application gateway instances can't reach the backend pool. Network Security Group, User Defined Route, or Custom DNS issue Cause Request time-out or connectivity issues with user requests.None of the VMs or instances in virtual machine scale set are healthy.Azure Application Gateway's back-end pool isn't configured or empty.Invalid or improper configuration of custom health probes.Back-end VMs or instances of virtual machine scale set aren't responding to the default health probe.NSG, UDR, or Custom DNS is blocking access to backend pool members.This error may happen for the following main reasons: OverviewĪfter configuring an application gateway, one of the errors that you may see is "Server Error: 502 - Web server received an invalid response while acting as a gateway or proxy server".
To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
To get started with the Az PowerShell module, see Install Azure PowerShell. This article uses the Azure Az PowerShell module, which is the recommended PowerShell module for interacting with Azure.