HTTP-Antwortcodes in Application Gateway

  • Artikel

Dieser Artikel beschreibt Gründe, 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 Verweis

HTTP 302-Antworten werden angezeigt, wenn eine Umleitungsregel mit dem Wert See Other (Verweis) 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 u. a. von einem Client, der Anforderungen an einen nicht übereinstimmenden Hostnamen initiiert, einem Anforderungstimeout, einer nicht authentifizierten Anforderung bis zu einer böswilligen Anforderung reichen.

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 und andere Authentifizierungsanbieter. Weitere Informationen finden Sie in den folgenden Artikeln.

Von der Application Gateway V2-SKU unterstützte MetrikenDiagnoseprotokolle

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 Headers Autorisierung:<base64 encoded content>, Autorisierung: <base64 encoded content>
Ungültiger Wert in der Inhaltslänge Content-Length: abc,Content-Length: -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.:

  • Das Clientzertifikat wird nicht präsentiert, aber die gegenseitige Authentifizierung ist aktiviert.
  • Die DN-Überprüfung ist aktiviert, und der DN des Clientzertifikats entspricht nicht dem DN der angegebenen Zertifikatkette.
  • Die Clientzertifikatkette stimmt nicht mit der Zertifikatkette überein, die in der definierten SSL-Richtlinie konfiguriert ist.
  • Das Clientzertifikat ist abgelaufen.
  • Die OCSP-Clientsperrüberprüfung ist aktiviert, und das Zertifikat wird widerrufen.
  • Die OCSP-Clientsperrüberprüfung ist aktiviert, kann jedoch nicht kontaktiert werden.
  • Die OCSP-Clientsperrüberprüfung ist aktiviert, aber der OCSP-Antwortdienst wird nicht im Zertifikat bereitgestellt.

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 Back-End als fehlerfrei 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 eine gültige 401-Antwort für die Tests Vergleichsbedingungen testen zulässig ist.

403 – Unzulässig

„HTTP 403: unzulässig“ wird angezeigt, wenn Kunden WAF-SKUs 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:

  • 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 Speicherblog zugreifen und sich der Application Gateway und Speicherendpunkt in einer anderen Region befindet, wird ein 403-Fehler zurückgegeben, wenn die öffentliche IP-Adresse des Application Gateway nicht zugelassen ist. Siehe Gewähren von Zugriff aus einem Internet-IP-Adressbereich.

404: Seite nicht gefunden

Eine HTTP 404-Antwort kann zurückgegeben werden, wenn eine Anforderung an ein Anwendungsgateway gesendet wird, für das Folgendes gilt:

408: Anforderungstimeout

Eine HTTP 408-Antwort kann kommen, wenn Clientanforderungen an den Front-End-Listener des Application Gateways nicht innerhalb von 60 Sekunden reagieren. Dieser Fehler kann aufgrund einer Datenverkehrsüberlastung zwischen lokalen Netzwerken und Azure auftreten, wenn der Datenverkehr von virtuellen Geräten überprüft wird oder der Client selbst überlastet wird.

413 – Anforderungsentität zu groß

Eine HTTP 413-Antwort kann kommen, wenn die Azure Web Application Firewall auf dem Application Gateway verwendet wird und die Clientanforderungsgröße die maximale Anforderungstextgröße ü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 WAF-Anforderungsgrößenlimits.

499: Verbindung vom Client geschlossen

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, wenn das Timeout auf der Clientseite niedrig ist und es nicht lange genug wartet wird, bis die Antwort vom Server empfangen ist. 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 für den Client, der die Verbindung schließt, bevor die Antwort des Servers abgeschlossen ist, ausgelöst werden.

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

Für Azure Application Gateway sollten keine 500-Antwortcodes angezeigt werden. Ö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 Erstellen einer Azure-Supportanfrage.

502: Ungültiges Gateway

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

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 – Gatewaytimeout

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

IIS

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

nginx

Wenn der Back-End-Server nginx oder nginx-Eingangscontroller ist und einen vorgeschalteten Server hat, stellen Sie sicher, dass der Wert der nginx:proxy_read_timeout Übereinstimmungen entspricht oder das in der Back-End-Einstellung eingestellte Timeout nicht überschreitet.

Nächste Schritte

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