HTTP-Antwortcodes in Application Gateway

Zusammenfassung

In diesem Artikel finden Sie Gründe dafür, warum Azure Application Gateway bestimmte HTTP-Antwortcodes zurückgibt. Die beschriebenen allgemeinen Ursachen und Problembehandlungsschritte helfen Ihnen, die Hauptursache eines fehlerhaften HTTP-Antwortcodes zu finden. HTTP-Antwortcodes können unabhängig davon, ob eine Verbindung mit einem Back-End-Ziel initiiert wurde, auf eine Clientanforderung zurückgegeben werden.

3XX-Antwortcodes (Umleitung)

Antworten mit dem Code 300 bis 399 werden angezeigt, wenn eine Clientanforderung einer Anwendungsgatewayregel entspricht, für die Umleitungen konfiguriert sind. Umleitungen können für eine Regel ohne Änderungen oder über eine Pfadzuordnungsregel konfiguriert werden. Weitere Informationen zu Umleitungen finden Sie unter Übersicht über die Umleitung in Application Gateway.

301 Dauerhafte Umleitung

HTTP 301-Antworten werden angezeigt, wenn eine Umleitungsregel mit dem Wert Permanent (Dauerhaft) angegeben wird.

302 Found (302 Gefunden)

HTTP 302-Antworten werden angezeigt, wenn eine Umleitungsregel mit dem Wert Found (Gefunden) angegeben wird.

303 Siehe andere

HTTP 302-Antworten werden angezeigt, wenn eine Umleitungsregel mit dem Wert Siehe Andere angegeben wird.

307 Temporäre Umleitung

HTTP 307-Antworten werden angezeigt, wenn eine Umleitungsregel mit dem Wert Temporary (Temporär) angegeben wird.

4XX-Antwortcodes (Clientfehler)

Die Antwortcodes 400 bis 499 weisen auf ein Problem hin, das vom Client ausgeht. Diese Probleme können auftreten, wenn der Client Anfragen an einen nicht passenden Hostnamen sendet, ein Anforderungstimeout eintritt, eine nicht authentifizierte Anforderung gestellt wird, eine böswillige Anforderung erfolgt und andere Fälle.

Das Application Gateway sammelt Metriken, die die Verteilung von 4xx/5xx-Statuscodes erfassen, und verfügt über einen Protokollierungsmechanismus, der Informationen wie die URI-Client-IP-Adresse mit dem Antwortcode erfasst. Metriken und Protokollierung ermöglichen eine weitere Problembehandlung. Clients können auch 4xx-Antworten von anderen Proxys zwischen dem Clientgerät und dem Application Gateway empfangen. Beispielsweise CDN (Content Delivery Network) und andere Authentifizierungsanbieter. Weitere Informationen finden Sie in den folgenden Artikeln.

• Von Application Gateway V2 SKU unterstützte Metriken
• Diagnoseprotokolle

400 – Ungültige Anforderung

HTTP 400-Antwortcodes werden häufig in den folgenden Fällen beobachtet:

• Datenverkehr ohne HTTP/HTTPS wird für ein Anwendungsgateway mit einem HTTP- oder HTTPS-Listener initiiert.
• HTTP-Datenverkehr wird für einen Listener mit HTTPS initiiert, wobei keine Umleitung konfiguriert ist.
• Die gegenseitige Authentifizierung ist konfiguriert und kann nicht ordnungsgemäß ausgehandelt werden.
• Die Anforderung ist mit RFC nicht kompatibel.

Einige häufige Gründe der Nichtkompatibilität der Anforderung mit RFC sind:

Kategorie	Beispiele
Ungültiger Host in Anforderungszeile	Host mit zwei Doppelpunkten (example.com:8090:8080)
Fehlender Hostheader	Anforderung hat keinen Hostheader
Falsch formatierte oder unzulässige Zeichen	Reservierte Zeichen sind &,!. Die Problemumgehung besteht darin, sie als Prozentsatz zu codieren. Beispiel: %&
Ungültige HTTP-Version	Abrufen von /content.css HTTP/0.3
Headerfeldname und URI enthalten Nicht-ASCII-Zeichen	GET /«úü¡»¿.doc HTTP/1.1
Fehlender Content-Length-Header für POST-Anforderung	Selbsterklärend
Ungültige HTTP-Methode	GET123 /index.html HTTP/1.1
Doppelte Kopfzeilen	Autorisierung:base64 kodierter Inhalt, Autorisierung: base64 kodierter Inhalt
Ungültiger Wert in der Inhaltslänge	Inhaltslänge: abc, Inhaltslänge: -10

Bei Fällen, in denen die gegenseitige Authentifizierung konfiguriert ist, können mehrere Szenarien zu einer HTTP 400-Antwort führen, die an den Client zurückgegeben wird, z. B.:

• Die gegenseitige Authentifizierung ist aktiviert, das Clientzertifikat wurde jedoch nicht angezeigt.
• Die DN-Überprüfung (Distinguished Name) ist aktiviert, und der DN des Clientzertifikats stimmt nicht mit dem DN der angegebenen Zertifikatkette überein.
• Die Clientzertifikatkette stimmt nicht mit der Zertifikatkette überein, die in der definierten SSL-Richtlinie konfiguriert ist.
• Das Clientzertifikat ist abgelaufen.
• Die OCSP(Online Certificate Status Protocol)-Clientsperrüberprüfung ist aktiviert, und das Zertifikat wird widerrufen.
• Die OCSP-Clientsperrüberprüfung (Online Certificate Status Protocol) ist aktiviert, kann jedoch nicht kontaktiert werden.
• Die OCSP-Client-Widerrufsprüfung (Online Certificate Status Protocol) ist aktiviert, aber der OCSP-Responder ist im Zertifikat nicht angegeben.

Weitere Informationen zur Problembehandlung bei der gegenseitigen Authentifizierung finden Sie unter Problembehandlung für Fehlercodes.

401 – Nicht autorisiert

Eine nicht autorisierte HTTP 401-Antwort wird an den Client zurückgegeben, wenn der Client nicht berechtigt ist, auf die Ressource zuzugreifen. Es gibt mehrere Gründe für die Rückgabe von 401. Im Folgenden sind einige Gründe für potenzielle Korrekturen aufgeführt.

• Wenn der Client Zugriff hat, kann es möglicherweise an einem veralteten Browsercache liegen. Löschen Sie den Cache des Browsers, und greifen Sie noch einmal auf die Anwendung zu.

Eine nicht autorisierte HTTP 401-Antwort kann an die AppGW-Probeanforderung zurückgegeben werden, wenn der Back-End-Pool mit NTLM Authentifizierung konfiguriert ist. In diesem Fall wird das Backend als gesund markiert. Es gibt mehrere Möglichkeiten, dieses Problem zu lösen:

• Lassen Sie auf dem Back-End-Pool den anonymen Zugriff zu.
• Konfigurieren Sie den Test so, dass die Anforderung an eine andere „gefälschte“ Website gesendet wird, die NTLM nicht voraussetzt.
• Nicht empfohlen, da dies uns nicht sagt, ob der tatsächliche Standort hinter dem Anwendungsgateway aktiv ist oder nicht.
• Konfigurieren Sie das Anwendungsgateway so, dass 401-Antworten für die Tests als gültig anerkannt werden: Übereinstimmungsbedingungen für Tests.

403 – Unzulässig

HTTP 403 Forbidden wird angezeigt, wenn Kunden WAF-SKUs (Web Application Firewall) verwenden und WAF im Präventionsmodus konfiguriert haben. Entsprechen die aktivierten WAF-Regelsätze oder benutzerdefinierten WAF-Ablehnungsregeln den Merkmalen einer eingehenden Anforderung, wird dem Client die Antwort „403: unzulässig“ angezeigt.

Sonst kann der Client die 403-Antwort aus folgenden Gründen erhalten:

• h2c-Protokollupgradeversuche: Das Anwendungsgateway gibt 403 Fehler zurück, wenn Clients versuchen, ein Upgrade von HTTP/1.1 auf HTTP/2.0 mithilfe des h2c-Protokolls (HTTP/2 Cleartext) durchzuführen. Das Anwendungsgateway unterstützt nur HTTP/2 über TLS (HTTPS-Listener); h2c-Protokollupgrades über HTTP-Listener werden nicht unterstützt. Dieses Verhalten tritt unabhängig vom WAF-Modus auf. Clients sollten systemeigene HTTP/2-Verbindungen über HTTPS verwenden oder ohne Upgradeversuche auf HTTP/1.1 verbleiben.
• Sie verwenden einen App-Service als Back-End und seine Konfiguration erlaubt nur den Zugriff über das Application Gateway. Dies kann einen 403-Fehler von App Services ausgeben. Dies geschieht in der Regel, weil die Umleitungen/href-Links nicht auf die IP-Adresse des Application Gateways, sondern direkt auf App-Services hinweisen.
• Wenn Sie auf einen Speicher-Blog zugreifen und sich das Application Gateway und der Speicherendpunkt in unterschiedlichen Regionen befinden, wird ein 403-Fehler zurückgegeben, wenn die öffentliche IP-Adresse des Application Gateway nicht auf der Zulassungsliste steht. Siehe Gewähren von Zugriff aus einem Internet-IP-Adressbereich.

404: Seite nicht gefunden

Eine HTTP 404-Antwort wird generiert, wenn eine Anforderung an Application Gateway (V2 SKUs) mit einem Hostnamen gesendet wird, der keinem der konfigurierten Listener mit mehreren Standorten entspricht, und es ist kein einfacher Listener vorhanden. Erfahren Sie mehr über Listenertypen.

408 – Timeout anfordern

Eine HTTP 408-Antwort kann beobachtet werden, wenn Clientanforderungen an den Front-End-Listener des Application Gateways nicht innerhalb von 60 Sekunden beantwortet werden. Dieser Fehler kann aufgrund von Verkehrsüberlastungen zwischen lokalen Netzwerken und Azure beobachtet werden, wenn die virtuelle Appliance den Datenverkehr prüft oder der Client selbst überfordert wird.

413 – Anforderungsentität zu groß

Eine HTTP 413-Antwort kann auftreten, wenn Azure Web Application Firewall auf dem Anwendungsgateway verwendet wird und die Größe der Clientanforderung die maximale Größe des Anforderungstextkörpers überschreitet. Der Wert im Feld für die maximale Größe des Anforderungstexts bestimmt das Anforderungsgrößenlimit insgesamt mit Ausnahme von Dateiuploads. Der Standardwert für die Größe des Anforderungstexts beträgt 128 KB. Weitere Informationen finden Sie unter Web Application Firewall Anforderungsgrößenbeschränkungen.

499 – Verbindung geschlossen vom Client

Eine HTTP 499-Antwort wird angezeigt, wenn eine an Anwendungsgateways mit v2-SKU gesendete Clientanforderung geschlossen wird, bevor der Server reagiert hat. Dieser Fehler kann in zwei Szenarien beobachtet werden. Das erste Szenario ist, wenn eine umfangreiche Antwort an den Client zurückgegeben wird und der Client die Anwendung möglicherweise geschlossen oder aktualisiert hat, bevor der Server das Senden dieser großen Antwort abschloss. Das zweite Szenario ist der Fall, wenn das Timeout auf der Clientseite niedrig ist und nicht lange genug wartet, um die Antwort vom Server zu empfangen. In diesem Fall ist es besser, das Timeout auf dem Client zu erhöhen. In Anwendungsgateways, die v1 SKU verwenden, kann ein HTTP 0-Antwortcode ausgelöst werden, wenn der Client die Verbindung schließt, bevor der Server mit dem Antworten fertig ist.

5XX-Antwortcodes (Serverfehler)

Antwortcodes von 500 bis 599 geben an, dass ein Problem mit dem Anwendungsgateway oder dem Back-End-Server aufgetreten ist, während die Anforderung ausgeführt wird.

500: interner Serverfehler

Azure Application Gateway sollte keine 500 Antwortcodes aufweisen. Öffnen Sie eine Supportanfrage, wenn dieser Code angezeigt wird, da es sich bei diesem Problem um einen internen Dienstfehler handelt. Informationen zum Öffnen eines Supportfalls finden Sie unter Create an Azure-Support request.

502: Ungültiges Gateway

HTTP 502-Fehler können mehrere Grundursachen haben, z. B.:

• NSG (Netzwerksicherheitsgruppe), UDR (benutzerdefinierte Route) oder benutzerdefiniertes DNS blockiert den Zugriff auf Back-End-Poolmitglieder.
• Virtuelle Back-End-Computer oder Instanzen von VM-Skalierungsgruppen reagieren nicht auf die standardmäßige Integritätsüberprüfung.
• Benutzerdefinierte Integritätsüberprüfungen sind ungültig oder nicht korrekt konfiguriert.
• Azure Application Gateway backend-Pool ist nicht konfiguriert oder leer.
• Keine der virtuellen Maschinen oder Instanzen in der VM-Skalierungsgruppe ist fehlerfrei.
• Request-Timeout- oder Verbindungsprobleme mit Benutzeranforderungen: Das Azure Anwendungs-Gateway V1 SKU hat HTTP 502-Fehler gesendet, wenn die Backend-Antwortzeit den Timeout-Wert überschreitet, der in der Backend-Einstellung konfiguriert ist.

Informationen zu Szenarien, in denen 502-Fehler auftreten, sowie zur Problembehandlung finden Sie unter Behandeln von Problemen mit Fehlern vom Typ „Ungültiges Gateway“.

504 Gateway-Timeout

Azure Anwendungsgateway V2-SKU hat HTTP 504-Fehler gesendet, wenn die Back-End-Antwortzeit den Timeoutwert überschreitet, der in der Back-End-Einstellung konfiguriert ist.

IIS (Internetinformationsdienste Webserver)

Wenn Ihr Back-End-Server IIS ist, lesen Sie die Standardgrenzwerte für Websites , um den Timeoutwert festzulegen. Details finden Sie im Attribut. Stellen Sie sicher, dass das Verbindungstimeout in IIS übereinstimmt oder das in der Back-End-Einstellung festgelegte Timeout nicht überschreitet.

Nginx

Wenn der Backend-Server Nginx oder Nginx Ingress Controller ist und über Upstream-Server verfügt, stellen Sie sicher, dass der Wert von mit dem in dieser Einstellung festgelegten Timeout übereinstimmt oder es nicht überschreitet.

Problembehandlungsszenarien

Fehler "ERRORINFO_INVALID_HEADER" in Zugriffsprotokollen

Problem: Das Access-Protokoll zeigt einen Fehler "ERRORINFO_INVALID_HEADER" für eine Anforderung an, obwohl der Back-End-Antwortcode (serverStatus) 200 ist. In anderen Fällen kann der Back-End-Server 500 zurückgeben.

Ursache: Der Client sendet einen Header mit CR-LF-Zeichen.

Lösung: Ersetzen Sie die CR-LF-Zeichen durch SP (Leerzeichen), und senden Sie die Anforderung an das Anwendungsgateway erneut.

Nächste Schritte

Wenn Sie das Problem mithilfe der Informationen in diesem Artikel nicht beheben können, senden Sie ein Supportticket.