Problembehandlung bei schlechtem Gateway (502) in Azure Application Gateway

Zusammenfassung

Erfahren Sie, wie Sie Bad Gateway-Fehler (502) in Azure Application Gateway beheben, um den Zugriff auf Ihre Web-Apps schnell und zuverlässig wiederherzustellen.

Symptome

Nachdem Sie ein Application Gateway konfiguriert haben, wird Ihnen möglicherweise die Fehlermeldung „Serverfehler: 502 – Der Webserver hat eine ungültige Antwort empfangen, während er als Gateway oder Proxyserver fungierte“ angezeigt. Dieser Fehler kann aus einem der folgenden Gründe auftreten:

• Netzwerksicherheitsgruppe (NSG), benutzerdefinierte Route (UDR) oder benutzerdefiniertes DNS-Problem (Domain Name System)
• Standardintegritätssonde kann keine Back-End-VMs erreichen
• Das Zeitlimit für die Backend-Anfrage wurde überschritten.
• Der Back-End-Pool des Anwendungsgateways ist nicht konfiguriert oder leer.
• Fehlerhafte Instanzen in Back-EndAddressPool
• Vorgelagertes SSL-Zertifikat stimmt nicht überein

Netzwerksicherheitsgruppe, benutzerdefinierte Route oder benutzerdefiniertes DNS-Problem

Ursache

Wenn ein NSG-, UDR- oder benutzerdefinierter DNS-Zugriff auf das Back-End blockiert, können Anwendungsgatewayinstanzen den Back-End-Pool nicht erreichen. Dieses Problem verursacht Probefehler, was zu 502 Fehlern führt.

Möglicherweise haben Sie eine NSG oder UDR im Anwendungsgateway-Subnetz oder im Subnetz, in dem die virtuellen Computer (VMs) der Anwendung bereitgestellt werden.

Ebenso kann das Vorhandensein eines benutzerdefinierten DNS im virtuellen Netzwerk (VNet) auch Probleme verursachen. Der vom Benutzer konfigurierte DNS-Server für das VNet löst möglicherweise keinen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) auf, der für Back-End-Poolmitglieder verwendet wird.

Lösung

Überprüfen Sie Ihre NSG-, UDR- und DNS-Konfigurationen. Gehen Sie dazu folgendermaßen vor:

1. Überprüfen Sie die NSGs, die dem Anwendungsgateway-Subnetz zugeordnet sind. Stellen Sie sicher, dass die Kommunikation mit dem Back-End nicht blockiert wird. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

2. Überprüfen Sie die UDR, die dem Anwendungsgateway-Subnetz zugeordnet ist. Stellen Sie sicher, dass die benutzerdefinierte Route (UDR) nicht den ausgehenden Datenverkehr vom Back-End-Subnetz umleitet. Überprüfen Sie beispielsweise, ob das Routing zu virtuellen Netzwerkappliances erfolgt oder ob Standardrouten mithilfe von Azure ExpressRoute oder Azure VPN an das Subnetz des Application Gateway weitergegeben werden. Führen Sie die folgenden Befehle in Azure PowerShell aus.

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

3. Prüfen Sie die wirksamen NSGs und Routen für die Back-End-VM. Führen Sie die folgenden Befehle in Azure PowerShell aus.

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

4. Überprüfen Sie, ob benutzerdefinierte DNS im VNet vorhanden ist. Überprüfen Sie DNS, indem Sie sich die Details der VNet-Eigenschaften in der Ausgabe ansehen.

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

5. Wenn vorhanden, stellen Sie sicher, dass der DNS-Server den FQDN des Mitglieds des Backend-Pools ordnungsgemäß auflösen kann.

Standard-Gesundheitsprüfung kann Backend-VMs nicht erreichen

Ursache

Ein 502-Fehler kann auch darauf hinweisen, dass die Standardintegritätssonde keine Back-End-VMs erreichen kann.

Wenn Sie eine Anwendungsgatewayinstanz bereitstellen, konfiguriert sie automatisch einen Standardintegritätstest für jeden BackendAddressPool mithilfe von Eigenschaften der BackendHttpSetting.

Sie müssen keine Eingabe bereitstellen, um diese Sonde einzustellen. Insbesondere verknüpfen Sie beim Konfigurieren einer Lastenausgleichsregel ein BackendHttpSetting mit einem BackendAddressPool. Jede dieser Zuordnungen hat eine Standardsonde konfiguriert, und das Anwendungsgateway initiiert zu jeder Instanz im BackendAddressPool über den im Element BackendHttpSetting angegebenen Port regelmäßig eine Verbindung zur Integritätsprüfung.

In der folgenden Tabelle sind die Werte aufgeführt, die dem Standardintegritätstest zugeordnet sind.

Lösung

Verwenden Sie die folgende Anleitung, um Probleme mit dem Standardintegritätstest zu beheben.

• Der Hostwert der Anforderung ist auf 127.0.0.1 festgelegt. Stellen Sie sicher, dass eine Standardwebsite konfiguriert ist und auf 127.0.0.1 läuft.
• Das BackendHttpSetting Protokoll bestimmt das Protokoll der Anforderung.
• Der URI Path ist auf /* gesetzt.
• Wenn BackendHttpSetting einen anderen Port als 80 angibt, konfigurieren Sie die Standardwebsite so, dass sie auf diesem Port lauscht.
• Der Aufruf von protocol://127.0.0.1:port sollte einen HTTP-Ergebniscode von 200 zurückgeben. Dieser Code sollte innerhalb des 30-Sekunden-Timeoutzeitraums zurückgegeben werden.
• Stellen Sie sicher, dass der konfigurierte Port geöffnet ist und dass keine Firewallregeln oder Azure-NSGs den ein- oder ausgehenden Datenverkehr über den konfigurierten Port blockieren.
• Wenn Sie Azure klassischen VMs oder Clouddienst mit einem FQDN oder einer öffentlichen IP verwenden, stellen Sie sicher, dass Sie den entsprechenden endpoint öffnen.
• Wenn Sie den virtuellen Computer mit Azure Resource Manager (ARM) konfigurieren und sich außerhalb des VNet befinden, in dem das Anwendungsgateway bereitgestellt wird, konfigurieren Sie eine NSG, um den Zugriff auf den gewünschten Port zu ermöglichen.

Weitere Informationen finden Sie unter Konfiguration der Application Gateway-Infrastruktur.

Ungültige oder fehlerhafte Konfiguration von benutzerdefinierten Integritätssonden

Ursache

Benutzerdefinierte Gesundheitsprüfungen bieten Ihnen mehr Flexibilität als das Standardverhalten bei der Überprüfung. Wenn Sie benutzerdefinierte Probes verwenden, können Sie das Abfrageintervall, die URL und den zu testenden Pfad festlegen. Zudem können Sie bestimmen, wie viele fehlgeschlagene Antworten akzeptiert werden, bevor die Back-End-Poolinstanz als fehlerhaft markiert wird.

In der folgenden Tabelle werden die zusätzlichen Eigenschaften beschrieben, die Sie festlegen können.

Lösung

Überprüfen Sie, ob Sie den benutzerdefinierten Integritätstest ordnungsgemäß konfiguriert haben, wie in der vorherigen Tabelle dargestellt. Befolgen Sie zusätzlich zu den vorherigen Anleitungen zur Problembehandlung auch diese Anleitung.

• Stellen Sie sicher, dass Sie die Sonde entsprechend der Anleitung richtig angeben.
• Wenn Sie das Anwendungsgateway für einen einzelnen Standort konfigurieren, geben Sie 127.0.0.1 als Standardhostnamen an, sofern Sie dies nicht im benutzerdefinierten Test anders konfiguriert haben.
• Stellen Sie sicher, dass ein Aufruf einen http://<host>:<port><path> HTTP-Ergebniscode von 200 zurückgibt.
• Stellen Sie sicher, dass sich Intervaldie UnhealthyThreshold Werte Timeoutinnerhalb der zulässigen Bereiche befinden.
• Wenn Sie einen HTTPS-Prüfpunkt in der v2-SKU verwenden, sendet Application Gateway auch den Hostnamen der Probe als SNI-Wert. Stellen Sie sicher, dass der Hostname mit dem alternativen Antragstellernamen (SAN) des Back-End-Zertifikats oder seinem gemeinsamen Namen (CN) übereinstimmt, wenn das Zertifikat kein SAN hat, wie in RFC 6125 beschrieben. Das Anwendungsgateway sendet SNI nicht, wenn der Hostname eine IP-Adresse ist, einschließlich der Standardeinstellung 127.0.0.1. Schritte zum Vergleichen des Probehostnamens mit dem Zertifikat finden Sie in der Lösung F bei der Problembehandlung von HTTP 502-Fehlern in Azure Application Gateway. Wenn Sie das Back-End-Zertifikat nicht ändern können, passen Sie die Back-End-HTTPS-Validierungseinstellungen an, um einen bestimmten SNI-Wert zu verwenden oder die Überprüfung des Antragstellernamens zu überspringen.

Timeout der Back-End-Anforderung wird überschritten.

Ursache

Wenn das Anwendungsgateway eine Benutzeranforderung empfängt, wendet es die konfigurierten Regeln auf die Anforderung an und leitet sie an eine Back-End-Poolinstanz weiter. Es wartet auf ein konfigurierbares Zeitintervall für eine Antwort aus der Back-End-Instanz. Dieses Intervall beträgt standardmäßig 20 Sekunden. Wenn das Anwendungsgateway v1 in diesem Intervall keine Antwort von der Back-End-Anwendung empfängt, erhält die Benutzeranforderung einen Fehler von 502. Wenn das Application Gateway v2 innerhalb dieses Intervalls keine Antwort von der Back-End-Anwendung erhält, wird die Anforderung an ein zweites Mitglied des Back-End-Pools weitergeleitet. Wenn die zweite Anforderung ebenfalls fehlschlägt, erhält die Benutzeranforderung stattdessen einen Fehler von 504. Wenn Benutzer 504 Fehler anstelle von 502 Fehlern erhalten, lesen Sie die Problembehandlung von HTTP 504-Fehlern in Azure Application Gateway.

Wenn Ihre Back-End-Anwendung regelmäßig länger als das konfigurierte Intervall für eine Antwort benötigt (etwa bei einer lang laufenden Abfrage oder Berichterstellung), erhöhen Sie das Anforderungszeitlimit in der Back-End-HTTP-Einstellung, die für diesen Back-End-Pool verwendet wird.

Lösung

Das Anforderungstimeout ist eine Eigenschaft der Back-End-HTTP-Einstellung, sodass unterschiedliche Back-End-Pools unterschiedliche Anforderungstimeoutwerte aufweisen können. Erhöhen Sie sie mithilfe des Azure Portals, Azure CLI oder Azure PowerShell. Der akzeptierte Bereich beträgt 1 bis 86400 Sekunden. Weitere Informationen finden Sie unter Anforderungstimeout.

Azure portal

führen Sie die folgenden Schritte aus:

1. Wechseln Sie im Azure-Portal zu Ihrem Anwendungsgateway.
2. Wählen Sie unter "Einstellungen" die Back-End-Einstellungen aus.
3. Wählen Sie die Back-End-Einstellung aus, die vom betroffenen Back-End-Pool verwendet wird.
4. Erhöhen Sie den Zeitüberschreitungswert für Anfragen (Sekunden), damit das Backend mehr Zeit zum Antworten hat.
5. Wählen Sie "Speichern" aus.

Azure CLI

Führen Sie in der Azure CLI den folgenden Befehl aus:

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

Führen Sie den folgenden Befehl in Azure PowerShell aus:

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

Der Back-End-Pool des Anwendungsgateways ist nicht konfiguriert oder leer.

Ursache

Wenn das Anwendungsgateway keine VMs oder VM-Skalierungsgruppen im Back-End-Adresspool konfiguriert hat, kann es keine Kundenanfrage weiterleiten und eine Bad Gateway-Fehlermeldung senden.

Lösung

Stellen Sie sicher, dass der Back-End-Adresspool nicht leer ist. Sie können diese Bedingung über Azure PowerShell, Azure CLI oder das Portal überprüfen. Sehen Sie sich das folgende Beispiel an, um den Back-End-Adresspool über Azure PowerShell zu überprüfen.

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

Die Ausgabe des vorhergehenden Cmdlets sollte einen nicht leeren Backend-Adresspool enthalten. Das folgende Beispiel zeigt zwei zurückgegebene Pools, die mit einem FQDN oder IP-Adressen für die Back-End-VMs konfiguriert sind. Der Bereitstellungsstatus der BackendAddressPool muss Succeeded sein.

[{
    "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"
}]

Fehlerhafte Instanzen im Backend-Adresspool

Ursache

Wenn alle Instanzen von BackendAddressPool fehlerhaft sind, hat das Anwendungsgateway kein funktionierendes Back-End, um Benutzeranforderungen weiterzuleiten. Diese Bedingung kann auch auftreten, wenn Backend-Instanzen funktionsfähig sind, aber die erforderliche Anwendung nicht bereitgestellt ist.

Lösung

Stellen Sie sicher, dass die Instanzen fehlerfrei sind und die Anwendung ordnungsgemäß konfiguriert ist. Überprüfen Sie, ob die Back-End-Instanzen auf einen Ping von einem anderen virtuellen Computer im selben virtuellen Netzwerk reagieren können. Wenn Sie einen öffentlichen Endpunkt konfigurieren, stellen Sie sicher, dass eine Browseranforderung an die Webanwendung dienstbar ist.

Vorgelagertes SSL-Zertifikat stimmt nicht überein

Ursache

Das auf Back-End-Servern installierte TLS-Zertifikat (Transport Layer Security) stimmt nicht mit dem Hostnamen überein, der im HTTP-Hostanforderungsheader empfangen wurde.

In Szenarien, in denen End-to-End-TLS aktiviert ist, erreichen Sie die Konfiguration, indem Sie die entsprechenden Back-End-HTTP-Einstellungen bearbeiten. Ändern Sie bei Bedarf die Konfiguration der Back-End-Protokolleinstellung auf HTTPS . Stellen Sie sicher, dass das DNS NAME auf Back-End-Servern installierte TLS-Zertifikat dem Hostnamen entspricht, der in der HTTP-Hostheaderanforderung an das Back-End gesendet wird.

Wenn Sie diesen Schritt abschließen, wird der zweite Teil der Kommunikation, die mit Application Gateway und den Back-End-Servern geschieht, mit TLS verschlüsselt.

Standardmäßig sendet Das Anwendungsgateway denselben HTTP-Hostheader an das Back-End, wie er vom Client empfangen wird. Stellen Sie sicher, dass das auf dem Backendserver installierte TLS-Zertifikat mit einem DNS NAME ausgestellt ist, das mit dem Hostnamen übereinstimmt, der diesem Backendserver im HTTP-Hostheader übermittelt wird. Dieser Hostname sollte mit dem vom Client empfangenen Hostnamen identisch sein.

Lösung

Schritte zum Ausrichten des Hostnamens des Prüfpunkts und SNI mit dem SAN oder CN des Zertifikats finden Sie unter Lösung F bei der Problembehandlung von HTTP 502-Fehlern in Azure Application Gateway. Informationen dazu, wie die Back-End-Einstellungen Hostnamen aus dem Back-End-Ziel auswählen und Mit bestimmtem Domänennamen überschreiben dem Zertifikatnamen zugeordnet werden, den Application Gateway erwartet, finden Sie unter Common Name (CN) doesn't match.