Problemen met ongeldige gateway (502) fouten in Azure Application Gateway oplossen

Samenvatting

Meer informatie over het oplossen van slechte gatewayfouten (502) in Azure Application Gateway, zodat u snel betrouwbare toegang tot uw web-apps kunt herstellen.

Opmerking

Gebruik de Azure Az PowerShell-module om te communiceren met Azure. Zie Install Azure PowerShell om aan de slag te gaan. Zie Migrate Azure PowerShell van AzureRM naar Az voor meer informatie over het migreren naar de Az PowerShell-module.

Symptomen

Nadat u een toepassingsgateway hebt geconfigureerd, ziet u mogelijk de fout 'Serverfout: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver'. Deze fout kan de volgende oorzaken hebben:

Netwerkbeveiligingsgroep, door de gebruiker gedefinieerde route of aangepast DNS-probleem

Oorzaak

Als een NSG, UDR of aangepaste DNS de toegang tot de back-end blokkeert, kunnen exemplaren van de toepassingsgateway de back-endpool niet bereiken. Dit probleem veroorzaakt testfouten, wat resulteert in 502-fouten.

Mogelijk hebt u een NSG of UDR in het subnet van de toepassingsgateway of in het subnet waarin de virtuele machines (VM's) van de toepassing worden geïmplementeerd.

Op dezelfde manier kan de aanwezigheid van een aangepaste DNS in het virtuele netwerk (VNet) ook problemen veroorzaken. De door de gebruiker geconfigureerde DNS-server voor het VNet kan een FQDN (Fully Qualified Domain Name) die wordt gebruikt voor leden van de back-endpool mogelijk niet correct omzetten.

Oplossing

Valideer uw NSG-, UDR- en DNS-configuraties. Voer hiervoor de volgende stappen uit:

  1. Controleer de NSG's die zijn gekoppeld aan het subnet van de toepassingsgateway. Zorg ervoor dat de communicatie met de back-end niet wordt geblokkeerd. Zie Netwerkbeveiligingsgroepen voor meer informatie.

  2. Controleer de UDR die is gekoppeld aan het subnet van de toepassingsgateway. Zorg ervoor dat de UDR geen verkeer wegleidt van het back-endsubnet. Controleer bijvoorbeeld op routering naar virtuele netwerkapparaten of standaardroutes die worden geadverteerd naar het subnet van de toepassingsgateway met behulp van Azure ExpressRoute of Azure VPN. Voer de volgende opdrachten uit in Azure PowerShell.

    $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet

  3. Controleer op effectieve NSG's en routes met de back-end-VM. Voer de volgende opdrachten uit in Azure PowerShell.

    Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg

  4. Controleer op de aanwezigheid van aangepaste DNS in het VNet. Controleer DNS door de details van de VNet-eigenschappen in de uitvoer te bekijken.

    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
DhcpOptions            : {
                           "DnsServers": [
                             "x.x.x.x"
                           ]
                         }

  5. Als deze aanwezig is, moet u ervoor zorgen dat de DNS-server de FQDN van het back-endpoollid correct kan oplossen.

De standaardgezondheidstest kan geen back-end-VM's bereiken

Oorzaak

Een 502-fout kan ook aangeven dat de standaardstatustest geen back-end-VM's kan bereiken.

Wanneer u een exemplaar van een toepassingsgateway implementeert, wordt automatisch voor elke BackendAddressPool een standaardstatuscontrole geconfigureerd op basis van de eigenschappen van de BackendHttpSetting.

U hoeft geen invoer op te geven om deze test in te stellen. Wanneer u een taakverdelingsregel configureert, koppelt u een BackendHttpSetting aan een BackendAddressPool. Elk van deze associaties heeft een standaard-probe geconfigureerd en de Application Gateway start een periodieke verbinding voor gezondheidscontrole met elk exemplaar in de BackendAddressPool, op de poort die is opgegeven in het element BackendHttpSetting.

De volgende tabel bevat de waarden die zijn gekoppeld aan de standaardstatustest.

Meeteigenschap Waarde Description
Probe-URL http://127.0.0.1/ URL-pad
Tijdsegment 30 Testinterval in seconden
Time-out 30 Timeout van probe in seconden
Ongezonde drempelwaarde 3 Aantal nieuwe pogingen voor de test. De back-end-server wordt als niet operationeel gemarkeerd nadat het aantal opeenvolgende testfouten de ongezonde drempelwaarde heeft bereikt.

Oplossing

Gebruik de volgende richtlijnen om problemen met de standaardstatustest op te lossen.

  • De hostwaarde van de aanvraag is ingesteld op 127.0.0.1. Zorg ervoor dat er een standaardsite is geconfigureerd en dat er wordt geluisterd op 127.0.0.1.
  • Het BackendHttpSetting protocol bepaalt het protocol van de aanvraag.
  • Het URI-pad is ingesteld op /*.
  • Als in BackendHttpSetting een andere poort dan 80 is opgegeven, configureert u de standaardsite om op die poort te luisteren.
  • De aanroep naar protocol://127.0.0.1:port moet een HTTP-resultaatcode van 200 retourneren. Deze code moet worden geretourneerd binnen de time-outperiode van 30 seconden.
  • Zorg ervoor dat de geconfigureerde poort is geopend en dat er geen firewallregels of Azure NSG's die binnenkomend of uitgaand verkeer blokkeren op de poort die is geconfigureerd.
  • Als u Azure klassieke VM's of cloudservice gebruikt met een FQDN of een openbaar IP-adres, moet u ervoor zorgen dat u de bijbehorende endpoint opent.
  • Als u de VM configureert met behulp van Azure Resource Manager (ARM) en deze zich buiten het VNet bevindt waar de toepassingsgateway wordt geïmplementeerd, configureert u een NSG om toegang op de gewenste poort toe te staan.

Zie De configuratie van de infrastructuur van Application Gateway voor meer informatie.

Ongeldige of onjuiste configuratie van aangepaste statustests

Oorzaak

Aangepaste health probes bieden u meer flexibiliteit dan het standaardgedrag bij peilen. Wanneer u aangepaste probes gebruikt, kunt u het probe-interval, de URL, het te testen pad en hoeveel mislukte antwoorden moeten worden geaccepteerd voordat u het exemplaar van de back-endpool markeert als ongezond.

In de volgende tabel worden de aanvullende eigenschappen beschreven die u kunt instellen.

Meeteigenschap Description
Naam Naam van de test. Gebruik deze naam om te verwijzen naar de test in de HTTP-instellingen van de back-end.
Protocol Protocol gebruikt om de sonde te verzenden. De test maakt gebruik van het protocol dat is gedefinieerd in de HTTP-instellingen van de back-end.
Host Hostnaam om de sonde naar toe te sturen. Deze hostnaam verschilt van de hostnaam van de VIRTUELE machine. In de v1-SKU gebruikt Application Gateway deze waarde alleen als hostheader van de testaanvraag. In de v2-SKU wordt de waarde gebruikt als zowel de hostheader als de SNI-waarde (Server Name Indication).
Path Relatief pad van de sonde. Het geldige pad begint met '/'. De probe wordt verzonden naar <protocol>://<host>:<port><path>.
Tijdsegment Testinterval in seconden. Met deze waarde wordt het tijdsinterval tussen twee opeenvolgende tests ingesteld.
Time-out Time-out van de probe in seconden. Als er binnen deze time-outperiode geen geldig antwoord wordt ontvangen, wordt de test gemarkeerd als mislukt.
Ongezonde drempelwaarde Aantal nieuwe pogingen voor de test. De back-end-server wordt als niet operationeel gemarkeerd nadat het aantal opeenvolgende testfouten de ongezonde drempelwaarde heeft bereikt.

Oplossing

Controleer of u de aangepaste statustest correct hebt geconfigureerd, zoals wordt weergegeven in de voorgaande tabel. Volg deze richtlijnen naast de voorgaande richtlijnen voor probleemoplossing ook.

  • Zorg ervoor dat u de probe correct specificeert volgens de handleiding.
  • Als u de toepassingsgateway voor één site configureert, geeft u de standaardhostnaam op als 127.0.0.1, tenzij u dit anders configureert in de aangepaste test.
  • Zorg ervoor dat een aanroep van http://<host>:<port><path> een HTTP-resultaatcode van 200 retourneert.
  • Zorg ervoor dat Interval, Timeouten UnhealthyThreshold waarden zich binnen de acceptabele bereiken bevinden.
  • Als u een HTTPS-test in de v2-SKU gebruikt, verzendt Application Gateway ook de hostnaam van de test als de SNI-waarde. Zorg ervoor dat de hostnaam overeenkomt met de alternatieve naam van het onderwerpcertificaat (SAN) of de algemene naam (CN) als het certificaat geen SAN heeft, zoals beschreven in RFC 6125. Application Gateway verzendt geen SNI wanneer de hostnaam een IP-adres is, inclusief de standaardwaarde 127.0.0.1. Zie Oplossing F in HTTP 502-fouten in Azure Application Gateway voor stappen om de hostnaam van de test te vergelijken met het certificaat. Als u het back-endcertificaat niet kunt wijzigen, past u de instellingen voor de HTTPS-validatie van de back-end aan om een specifieke SNI-waarde te gebruiken of om validatie van de onderwerpnaam over te slaan.

De time-out voor de backendaanvraag is overschreden

Oorzaak

Wanneer de toepassingsgateway een gebruikersaanvraag ontvangt, worden de geconfigureerde regels toegepast op de aanvraag en doorgestuurd naar een exemplaar van een back-endpool. Er wordt gewacht op een configureerbaar tijdsinterval voor een reactie van de backendinstantie. Dit interval is standaard 20 seconden. Als in Application Gateway v1 binnen dit interval geen antwoord van de back-endtoepassing wordt ontvangen, krijgt de gebruikersaanvraag een 502-fout. Als in Application Gateway v2 binnen dit interval geen antwoord van de back-endtoepassing wordt ontvangen, wordt de aanvraag geprobeerd tegen een tweede lid van de back-endpool. Als de tweede aanvraag ook mislukt, krijgt de gebruikersaanvraag in plaats daarvan een 504-fout. Als gebruikers 504-fouten ontvangen in plaats van 502-fouten, raadpleegt u HTTP 504-fouten in Azure Application Gateway oplossen.

Als uw back-endtoepassing regelmatig langer duurt dan het geconfigureerde interval om te reageren (bijvoorbeeld een langlopende query of rapport), verhoogt u de time-out van de aanvraag op de back-end-HTTP-instelling die door die back-endpool wordt gebruikt.

Oplossing

De time-out van de aanvraag is een eigenschap van de HTTP-instelling voor de back-end, zodat verschillende back-endpools verschillende time-outwaarden voor aanvragen kunnen hebben. Verhoog deze met behulp van de Azure-portal, Azure CLI of Azure PowerShell. Het geaccepteerde bereik is 1 tot 86400 seconden. Zie Time-out aanvragen voor meer informatie.

Azure portal

Volg deze stappen:

  1. Ga in de Azure-portal naar uw toepassingsgateway.
  2. Selecteer onder Instellingen de optie Backendinstellingen.
  3. Selecteer de backendinstelling die wordt gebruikt door de betrokken backendpool.
  4. Verhoog de time-outwaarde voor aanvragen (seconden) zodat de back-end langer kan reageren.
  5. Kies Opslaan.

Azure CLI

Voer de volgende opdracht uit in Azure CLI:

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Voer de volgende opdracht uit in Azure PowerShell:

New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

Opmerking

Het verhogen van de time-out van de aanvraag maskert alleen het symptoom als de back-end traag is vanwege een onderliggend probleem, zoals een hoge CPU- of geheugenbelasting, databaseconflicten of een inefficiënte query. Onderzoek ook de reactietijd van de back-endtoepassing voordat u de time-outwaarde verhoogt.

De back-endpool van de toepassingsgateway is niet geconfigureerd of is leeg

Oorzaak

Als de toepassingsgateway geen VM's of virtuele-machine-schaalset heeft geconfigureerd in de achtergrondadrespool, kan er geen klantaanvraag worden gerouteerd en wordt er een onjuiste gatewayfout verzonden.

Oplossing

Zorg ervoor dat de back-end-adrespool niet leeg is. U kunt deze voorwaarde controleren via Azure PowerShell, Azure CLI of de portal. Zie het volgende voorbeeld om de back-endadresgroep te controleren via Azure PowerShell.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

De uitvoer van de voorgaande cmdlet moet een niet-lege back-endadresgroep bevatten. In het volgende voorbeeld ziet u twee geretourneerde pools die zijn geconfigureerd met een FQDN of IP-adressen voor de back-end-VM's. De inrichtingsstatus van de BackendAddressPool moet Succeeded zijn.

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Beschadigde exemplaren in BackendAddressPool

Oorzaak

Als alle exemplaren van BackendAddressPool ongezond zijn, heeft de application gateway geen back-end om gebruikersaanvragen naar te routeren. Deze voorwaarde kan ook optreden wanneer backend-instanties gezond zijn, maar niet de vereiste toepassing hebben uitgerold.

Oplossing

Zorg ervoor dat de exemplaren in orde zijn en dat de toepassing correct is geconfigureerd. Controleer of de back-endinstanties kunnen reageren op een ping vanaf een andere VIRTUELE machine in hetzelfde virtuele netwerk. Als u een openbaar eindpunt configureert, moet u ervoor zorgen dat een browseraanvraag voor de webtoepassing kan worden gebruikt.

Upstream SSL-certificaat komt niet overeen

Oorzaak

Het TLS-certificaat (Transport Layer Security) dat is geïnstalleerd op back-endservers, komt niet overeen met de hostnaam die is ontvangen in de HTTP-hostaanvraagheader.

In scenario's waarin end-to-end TLS is ingeschakeld, moet u de configuratie bereiken door de juiste HTTP-instellingen voor de back-end te bewerken. Wijzig waar nodig de configuratie van de back-endprotocolinstelling in HTTPS . Zorg ervoor dat het DNS NAME TLS-certificaat dat is geïnstalleerd op back-endservers overeenkomt met de hostnaam die naar de back-end komt in de HTTP-hostheaderaanvraag.

Wanneer u deze stap voltooit, wordt het tweede deel van de communicatie die plaatsvindt met Application Gateway en de back-endservers versleuteld met TLS.

Application Gateway verzendt standaard dezelfde HTTP-hostheader naar de back-end als deze van de client ontvangt. Zorg ervoor dat het TLS-certificaat dat op de back-endserver is geïnstalleerd, is uitgegeven met een DNS NAME die overeenkomt met de hostnaam die is ontvangen door die back-endserver in de HTTP-hostheader. Deze hostnaam moet hetzelfde zijn als de hostnaam die van de client is ontvangen.

Oplossing

Zie Oplossing F in HTTP 502-fouten in Azure Application Gateway oplossen voor stappen om de sondehostnaam en SNI af te stemmen op de SAN of CN van het certificaat. Zie Common Name (CN) komt niet overeen voor informatie over hoe de back-endinstellingen Hostnaam kiezen van back-enddoel en Overschrijven met specifieke domeinnaam overeenkomen met de certificaatnaam die Application Gateway verwacht.

  • Last updated on