Delen via

Problemen met ongeldige gatewayfouten in Application Gateway oplossen

Leer hoe u 502 bad gateway-fouten kunt oplossen die optreden bij het gebruik van Azure Application Gateway.

Opmerking

We raden u aan om de Azure Az PowerShell-module te gebruiken om met Azure te communiceren. Zie Azure PowerShell installeren om aan de slag te gaan. Om te leren hoe u naar de Az PowerShell-module kunt migreren, zie Migrate Azure PowerShell from AzureRM to Az.

Overzicht

Nadat u een toepassingsgateway hebt geconfigureerd, is een van de fouten die u kunt zien serverfout: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver. Deze fout kan om de volgende hoofdredenen optreden:

Probleem met netwerkbeveiligingsgroep, door de gebruiker gedefinieerde route of aangepaste DNS

Oorzaak

Als de toegang tot de back-end wordt geblokkeerd vanwege een NSG, UDR of aangepaste DNS, kunnen application gateway-exemplaren de back-endpool niet bereiken. Dit probleem veroorzaakt testfouten, wat resulteert in 502-fouten.

De NSG/UDR kan aanwezig zijn in het subnet van de toepassingsgateway of in het subnet waarin de toepassings-VM's worden geïmplementeerd.

Op dezelfde manier kan de aanwezigheid van een aangepaste DNS in het VNet ook problemen veroorzaken. Een FQDN die wordt gebruikt voor leden van de back-endpool kan mogelijk niet correct worden opgelost door de door de gebruiker geconfigureerde DNS-server voor het VNet.

Oplossing

Valideer de NSG-, UDR- en DNS-configuratie door de volgende stappen uit te voeren:

  1. Controleer de NSG's die zijn gekoppeld aan het subnet van de toepassingsgateway. Zorg ervoor dat communicatie met 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 via ExpressRoute/VPN.

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

  3. Controleer de effectieve NSG en routings met de back-end VM

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

  4. Controleer de aanwezigheid van aangepaste DNS in het VNet. DNS kan worden gecontroleerd 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.

Problemen met standaardgezondheidstest

Oorzaak

502-fouten kunnen ook frequente indicatoren zijn dat de standaardstatustest geen back-end-VM's kan bereiken.

Wanneer een exemplaar van een toepassingsgateway is ingericht, wordt automatisch een standaardstatustest geconfigureerd voor elke BackendAddressPool met behulp van eigenschappen van de BackendHttpSetting. Er is geen gebruikersinvoer vereist om deze test in te stellen. Wanneer een taakverdelingsregel is geconfigureerd, wordt er een koppeling gemaakt tussen een BackendHttpSetting en een BackendAddressPool. Er wordt een standaardtest geconfigureerd voor elk van deze koppelingen en de toepassingsgateway start een periodieke statuscontroleverbinding 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 Beschrijving
Probe-URL http://127.0.0.1/ URL-pad
Tijdsegment 30 Testinterval in seconden
Pauze 30 Time-out 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

  • De hostwaarde van de aanvraag is ingesteld op 127.0.0.1. Zorg ervoor dat een standaardsite is geconfigureerd en luistert naar 127.0.0.1.
  • Het protocol van de aanvraag wordt bepaald door het protocol BackendHttpSetting.
  • URI-pad is ingesteld op /.
  • Als BackendHttpSetting een andere poort dan 80 opgeeft, moet de standaardsite worden geconfigureerd om naar die poort te luisteren.
  • De oproep naar protocol://127.0.0.1:port moet een HTTP-statuscode 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-netwerkbeveiligingsgroepen zijn die binnenkomend of uitgaand verkeer blokkeren op de poort die is geconfigureerd.
  • Als klassieke Azure-VM's of cloudservice worden gebruikt met een FQDN of een openbaar IP-adres , moet u ervoor zorgen dat het bijbehorende eindpunt wordt geopend.
  • Als de VIRTUELE machine is geconfigureerd via Azure Resource Manager en zich buiten het VNet bevindt waar de toepassingsgateway wordt geïmplementeerd, moet een netwerkbeveiligingsgroep worden geconfigureerd om toegang op de gewenste poort toe te staan.

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

Problemen met aangepaste gezondheidstoets

Oorzaak

Aangepaste gezondheidscontroles bieden extra flexibiliteit voor het standaard testgedrag. Wanneer u aangepaste probes gebruikt, kunt u het interval van de probe, de URL, het te testen pad en hoeveel mislukte antwoorden moeten worden geaccepteerd voordat u het exemplaar van de back-endpool als ongezond markeert, configureren.

De volgende aanvullende eigenschappen worden toegevoegd:

Meeteigenschap Beschrijving
Naam Naam van de test. Deze naam wordt gebruikt 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
Gastheer (or Gastvrouw) Hostnaam om de sonde te verzenden. Alleen van toepassing wanneer meerdere sites zijn geconfigureerd op de toepassingsgateway. Dit verschilt van de hostnaam van de VIRTUELE machine.
Pad Relatief pad van de sonde. Het geldige pad begint met '/'. De test wordt verzonden naar <protocol>://<host>:<poort><pad>
Tijdsegment Testinterval in seconden. Dit is het tijdsinterval tussen twee opeenvolgende tests.
Pauze Tijdlimiet voor detectie 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 de Custom Health Probe correct geconfigureerd is, zoals aangegeven in de daaropzichtbare tabel. Naast de voorgaande stappen voor probleemoplossing moet u ook het volgende controleren:

  • Zorg ervoor dat de probe correct is aangegeven volgens de handleiding.
  • Als de toepassingsgateway voor één site is geconfigureerd, moet de hostnaam standaard worden opgegeven als 127.0.0.1, tenzij anders is geconfigureerd in een aangepaste test.
  • Zorg ervoor dat een aanroep naar http://< host>:<port><path> een HTTP-resultaatcode van 200 retourneert.
  • Zorg ervoor dat Interval, Timeout en UnhealthyThreshold binnen de acceptabele waarden vallen.
  • Als u een HTTPS-test gebruikt, moet u ervoor zorgen dat de back-endserver geen SNI vereist door een terugvalcertificaat te configureren op de back-endserver zelf.

Time-out aanvragen

Oorzaak

Wanneer een gebruikersaanvraag wordt ontvangen, past de toepassingsgateway de geconfigureerde regels toe op de aanvraag en stuurt deze door naar een exemplaar van een back-endpool. Het wacht een instelbare tijd op een reactie van de back-end instantie. Dit interval is standaard 20 seconden. Als in Application Gateway v1 in dit interval geen antwoord van de back-endtoepassing wordt ontvangen, krijgt de gebruikersaanvraag een 502-fout. Als in Application Gateway v2 in dit interval geen antwoord van de back-endtoepassing wordt ontvangen, wordt het verzoek naar een tweede lid van de back-endpool gestuurd. Als de tweede aanvraag mislukt, krijgt de gebruikersaanvraag een 504-fout.

Oplossing

Met Application Gateway kunt u deze instelling configureren via de BackendHttpSetting, die vervolgens kan worden toegepast op verschillende pools. Verschillende back-endpools kunnen verschillende BackendHttpSetting en een andere time-out voor aanvragen hebben geconfigureerd.

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

Lege BackendAdresPool

Oorzaak

Als de toepassingsgateway geen VM's of virtuele-machineschaalsets heeft geconfigureerd in de achtergrondadrespool, kan er geen klantaanvraag worden gerouteerd en wordt er een bad gateway-fout verzonden.

Oplossing

Zorg ervoor dat de backend-adresgroep niet leeg is. Dit kan via PowerShell, CLI of het portal.

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

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

Back-endadrespoelen Tekst

[{
    "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 niet in orde zijn, heeft de toepassingsgateway geen back-end waarnaar de gebruikersaanvraag moet worden doorgestuurd. Dit kan ook het geval zijn wanneer back-end instanties in orde zijn, maar niet de vereiste applicatie hebben geïmplementeerd.

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 VNet. Als deze is geconfigureerd met een openbaar eindpunt, moet u ervoor zorgen dat een browseraanvraag voor de webtoepassing verwerkbaar is.

Upstream SSL-certificaat komt niet overeen

Oorzaak

Het TLS-certificaat dat is geïnstalleerd op back-endservers komt niet overeen met de hostnaam die is ontvangen in de hostaanvraagheader.

In scenario's waarin End-to-end TLS is ingeschakeld, is een configuratie die wordt bereikt door de juiste 'BACK-end-HTTP-instellingen' te bewerken en daar de configuratie van het back-endprotocol te wijzigen in HTTPS, verplicht om ervoor te zorgen dat de DNS-NAAM van het TLS-certificaat dat op back-endservers is geïnstalleerd, overeenkomt met de hostnaam die in de http-hostheaderaanvraag wordt geplaatst.

Ter herinnering, het effect van het inschakelen van de optie van het protocol HTTPS in plaats van HTTP in de back-end HTTP-instellingen, is dat het tweede deel van de communicatie die plaatsvindt tussen de Application Gateway-exemplaren en de back-endservers wordt versleuteld met TLS.

Als gevolg van het feit dat application gateway standaard dezelfde HTTP-hostheader naar de back-end verzendt als die wordt ontvangen van de client, moet u ervoor zorgen dat het TLS-certificaat dat op de back-endserver is geïnstalleerd, wordt uitgegeven met een DNS-NAAM die overeenkomt met de hostnaam die door die back-endserver is ontvangen in de HTTP-hostheader. Houd er rekening mee dat deze hostnaam, tenzij anders is opgegeven, hetzelfde is als de hostnaam die van de client is ontvangen.

Voorbeeld:

Stel dat u een Application Gateway hebt om de https-aanvragen voor het domein www.contoso.comte verwerken. U kunt het domein contoso.com laten delegeren aan een openbare Azure DNS-zone, en een A DNS-record in die zone die www.contoso.com verwijst naar het openbare IP-adres van de specifieke toepassingsgateway die de aanvragen gaat verwerken.

Op die Application Gateway moet u een listener voor de host www.contoso.com hebben met een regel waarbij de 'achterliggende HTTP-instelling' het protocol HTTPS moet gebruiken om end-to-end TLS te garanderen. Dezelfde regel kan een back-endpool hebben geconfigureerd met twee virtuele machines waarop IIS wordt uitgevoerd als webservers.

Zoals we weten, zorgt het inschakelen van HTTPS in de 'Backend HTTP-instelling' van de regel ervoor dat het tweede deel van de communicatie tussen de Application Gateway-exemplaren en de servers in de back-end TLS gebruikt.

Als de back-endservers geen TLS-certificaat hebben uitgegeven voor de DNS-NAAM www.contoso.com of *.contoso.com, mislukt de aanvraag met serverfout: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver omdat het upstream SSL-certificaat (het certificaat dat op de back-endservers is geïnstalleerd) niet overeenkomt met de hostnaam in de hostheader, en daarom mislukt de TLS-onderhandeling.

www.contoso.com-- FRONT-END-IP van APP GW --> Listener met een regel waarmee 'Back-end-HTTP-instellingen' worden geconfigureerd voor het gebruik van protocol HTTPS in plaats van HTTP -->> Back-endpool - Webserver (moet een TLS-certificaat zijn geïnstalleerd voor >)www.contoso.com

Oplossing

Het is vereist dat de DNS-NAAM van het TLS-certificaat dat is geïnstalleerd op de back-endserver, overeenkomt met de hostnaam die is geconfigureerd in de instellingen van de HTTP-back-end, anders mislukt het tweede deel van de end-to-end-communicatie tussen de exemplaren van de Application Gateway en de back-end, mislukt met 'Upstream SSL-certificaat komt niet overeen', en wordt een serverfout geretourneerd: 502 - Webserver heeft een ongeldig antwoord ontvangen tijdens het fungeren als een gateway of proxyserver

Volgende stappen

Als het probleem niet wordt opgelost met de voorgaande stappen, opent u een ondersteuningsticket.