Behandeln von häufigen Azure Front Door-Problemen

  • Artikel

In diesem Artikel wird beschrieben, wie Sie häufige Routingprobleme in Ihrer Azure Front Door-Konfiguration beheben können.

Andere HTTP-Header für Debuggen

Sie können von Azure Front Door zusätzliche Debugging-HTTP-Antwort-Header anfordern. Weitere Informationen finden Sie unter Optionale Debug-Antwort-Header.

Antwort des Typs 503 oder 504 von Azure Front Door nach einigen Sekunden

Symptom

  • Reguläre Anforderungen, die ohne Azure Front Door an das Back-End gesendet werden, sind erfolgreich. Wenn Sie Azure Front Door benutzen, erhalten Sie die Fehlercodes 503 oder 504.
  • Der Fehler von Azure Front Door wird in der Regel nach ungefähr 30 Sekunden angezeigt.
  • Intermittierende 503-Fehler werden mit „ErrorInfo: OriginInvalidResponse“ angezeigt.

Ursache

Für dieses Problem gibt es drei mögliche Ursachen:

  • Ihr Ursprung benötigt länger als das konfigurierte Timeout, um die Anforderung von Azure Front Door zu erhalten. Der Standardzeitraum bis zum Timeout beträgt 30 Sekunden.
  • Die zum Beantworten der Anforderung von Azure Front Door erforderliche Zeit überschreitet den Timeoutwert.
  • Der Client hat eine Bytebereichsanforderung mit einem Accept-Encoding-Header gesendet, was bedeutet, dass die Komprimierung aktiviert ist.

Schritte zur Problembehandlung

  • Senden Sie die Anfrage direkt an Ihren Ursprung, ohne den Umweg über Azure Front Door. Prüfen Sie, wie lange es normalerweise dauert, bis Ihr Ursprung antwortet.

  • Senden Sie die Anfrage über Azure Front Door und prüfen Sie, ob der Fehlercode 503 zurückgegeben wird. Falls nicht, ist das Timeout möglicherweise nicht das Problem. Erstellen Sie eine Supportanfrage, um weiter an der Problemlösung zu arbeiten.

  • Wenn Anfragen, die durch Azure Front Door gehen, einen Antwortcode 503 zurückgeben, konfigurieren Sie das Origin-Antwort-Timeout für Azure Front Door. Sie können die Standardzeitüberschreitung auf bis zu 4 Minuten (240 Sekunden) erhöhen. Um die Einstellung zu konfigurieren, wechseln Sie zur Übersichtsseite des Front Door-Profils. Wählen Sie Timeout für Ursprungsantwort aus, und geben Sie einen Wert zwischen 16 und 240 Sekunden ein.

    Hinweis

    Die Möglichkeit zum Konfigurieren des Timeouts für die Ursprungsantwort ist nur in Azure Front Door Standard/Premium verfügbar.

    Screenshot of the origin timeout settings on the overview page of the Azure Front Door profile.

  • Wenn die Erhöhung der Zeitüberschreitung das Problem nicht behebt, verwenden Sie ein Tool wie Fiddler oder das Entwicklertool Ihres Browsers, um zu prüfen, ob der Client Bytebereichsanforderungen mit Accept-Encoding-Headern sendet. Die Verwendung dieser Option führt dazu, dass der Ursprung mit unterschiedlichen Inhaltslängen antwortet.

    Wenn der Client Bytebereichsanforderungen mit Accept-Encoding-Headern sendet, haben Sie zwei Möglichkeiten. Die erste Option ist die Deaktivierung der Komprimierung auf dem Ursprung oder in Azure Front Door. Die zweite Option besteht darin, eine Regelsatzregel zu erstellen, die Accept-Encoding aus der Anforderung für Bytebereichsanforderungen entfernt.

    Screenshot that shows the Accept-Encoding rule in a rule set.

503-Antworten von Azure Front Door nur für HTTPS

Symptom

  • 503-Antworten werden nur für HTTPS-fähige Azure Front Door-Endpunkte zurückgegeben.
  • Reguläre Anforderungen, die ohne Azure Front Door an das Back-End gesendet werden, sind erfolgreich. Das Durchlaufen von Azure Front Door führt zu 503-Fehlermeldungen.
  • Intermittierende 503-Fehler werden mit „ErrorInfo: OriginInvalidResponse“ angezeigt.

Ursache

Für dieses Problem gibt es drei mögliche Ursachen:

  • Der Back-End-Pool ist eine IP-Adresse.
  • Der Back-End-Server gibt ein Zertifikat zurück, das nicht mit dem FQDN des Azure Front Door-Back-End-Pools übereinstimmt.
  • Der Back-End-Pool ist ein Azure-Web-Apps-Server.

Schritte zur Problembehandlung

  • Der Back-End-Pool ist eine IP-Adresse.

    EnforceCertificateNameCheck muss deaktiviert sein.

    Azure Front Door verfügt über einen Switch namens EnforceCertificateNameCheck. Diese Einstellung ist standardmäßig aktiviert. Wenn diese Option aktiviert ist, überprüft Azure Front Door Service, ob der FQDN des Hostnamens des Back-End-Pools mit dem Zertifikatnamen des Back-End-Serverzertifikats oder einem der Einträge in der SAN-Erweiterung (Subject Alternative Names, alternative Antragstellernamen) übereinstimmt.

    • Deaktivieren von EnforceCertificateNameCheck über das Azure-Portal:

      Verwenden Sie im Portal eine Umschaltfläche, um diese Einstellung im Entwurfsbereich von Azure Front Door (klassisch) zu aktivieren oder deaktivieren.

      Screenshot that shows the toggle button.

      Für den Azure Front Door Standard- und Premium-Tarif finden Sie diese Einstellung in den Ursprungseinstellungen, wenn Sie einer Ursprungsgruppe einen Ursprung hinzufügen oder eine Route konfigurieren.

      Screenshot of the certificate subject name validation checkbox.

  • Der Back-End-Server gibt ein Zertifikat zurück, das nicht mit dem FQDN des Azure Front Door-Back-End-Pools übereinstimmt. Sie haben zwei Optionen, dieses Problem zu beheben:

    • Das zurückgegebene Zertifikat muss mit dem FQDN übereinstimmen.
    • EnforceCertificateNameCheck muss deaktiviert sein.

  • Der Back-End-Pool ist ein Azure-Web-Apps-Server:

    • Überprüfen Sie, ob die Azure-Web-App mit IP-basiertem SSL anstelle von SNI-basiertem SSL konfiguriert ist. Wenn die Web-App als IP-basiert konfiguriert ist, sollte dies in SNI geändert werden.
    • Wenn das Back-End aufgrund eines Zertifikatfehlers fehlerhaft ist, wird eine 503-Fehlermeldung zurückgegeben. Sie können die Integrität der Back-Ends an Port 80 und 443 überprüfen. Wenn nur 443 fehlerhaft ist, liegt wahrscheinlich ein Problem mit SSL vor. Da das Back-End für die Verwendung des FQDN konfiguriert ist, wissen wir, dass es SNI sendet.

    Überprüfen Sie mit OPENSSL das Zertifikat, das zurückgegeben wird. Stellen Sie hierzu mithilfe von -servername eine Verbindung mit dem Back-End her. Die SNI sollte zurückgegeben werden, die mit dem FQDN des Back-End-Pools übereinstimmen muss:

    openssl s_client -connect backendvm.contoso.com:443 -servername backendvm.contoso.com

Für an die benutzerdefinierte Domäne gesendete Anforderungen wird der Statuscode 400 zurückgegeben

Symptom

  • Sie haben eine Azure Front Door-Instanz erstellt. Für eine Anforderung an die Domäne oder den Front-End-Host wird der HTTP-Statuscode 400 zurückgegeben.
  • Sie haben eine DNS-Zuordnung für eine benutzerdefinierte Domäne zu dem von Ihnen konfigurierten Front-End-Host erstellt. Beim Senden einer Anforderung an den Hostnamen der benutzerdefinierten Domäne wird ein HTTP-Statuscode 400 zurückgegeben. Außerdem wird offenbar kein Routing zu dem von Ihnen konfigurierten Back-End durchgeführt.

Ursache

Das Problem tritt auf, wenn Sie keine Routingregel für die benutzerdefinierte Domäne konfiguriert haben, die als Front-End-Host hinzugefügt wurde. Für diesen Front-End-Host muss explizit eine Routingregel hinzugefügt werden. Sie müssen die Regel auch dann erstellen, wenn bereits eine Routingregel für den Front-End-Host unter der Azure Front Door-Subdomäne *.azurefd.net konfiguriert wurde.

Schritte zur Problembehandlung

Fügen Sie eine Routingregel für die benutzerdefinierte Domäne hinzu, um Datenverkehr an die ausgewählten Ursprungsgruppe weiterzuleiten.

Azure Front Door leitet HTTP oder HTTPS nicht weiter

Symptom

Für Azure Front Door ist eine Routingregel vorhanden, nach der HTTP zu HTTPS umgeleitet wird, doch beim Zugriff auf die Domäne wird HTTP als Protokoll beibehalten.

Ursache

Dieses Verhalten kann auftreten, wenn Sie die Routingregeln für Azure Front Door nicht ordnungsgemäß konfiguriert haben. Ihre aktuelle Konfiguration ist nicht spezifisch und kann miteinander in Konflikt stehende Regeln aufweisen.

Schritte zur Problembehandlung

Eine Anforderung an den Front-End-Hostnamen gibt den Statuscode 411 zurück

Symptom

Sie haben eine Standard-/Premium-Instanz für Azure Front Door erstellt und Folgendes konfiguriert:

  • Einen Front-End-Host
  • Eine Ursprungsgruppe mit mindestens einem Ursprung
  • Eine Routingregel, die den Front-End-Host mit der Ursprungsgruppe verbindet

Ihre Inhalte sind offenbar nicht verfügbar, wenn Sie eine Anforderung an den konfigurierten Front-End-Host senden, da der HTTP-Statuscode 411 zurückgegeben wird.

Antworten auf diese Anforderungen können auch eine HTML-Fehlerseite mit einer Erläuterung im Antworttext enthalten. Beispiel: „HTTP Error 411. The request must be chunked or have a content length.“ (HTTP-Fehler 411. Die Anforderung muss in Blöcke aufgeteilt sein oder eine Inhaltslänge aufweisen.)

Ursache

Dieses Symptom kann verschiedene Ursachen haben. Grundsätzlich liegt es daran, dass Ihre HTTP-Anforderung nicht vollständig RFC-konform ist.

Ein Beispiel für Nichtkonformität ist eine POST-Anforderung, die ohne einen Content-Length- oder Transfer-Encoding-Header gesendet wird. Ein Beispiel wäre die Verwendung von curl -X POST https://example-front-door.domain.com. Diese Anforderung erfüllt nicht die Voraussetzungen, die in RFC 7230festgelegt sind. Azure Front Door würde sie mit einer HTTP 411-Antwort blockieren. Solche Anforderungen werden nicht protokolliert.

Dieses Verhalten ist unabhängig von der WAF-Funktionalität (Web Application Firewall) von Azure Front Door. Derzeit gibt es keine Möglichkeit, dieses Verhalten zu deaktivieren. Alle HTTP-Anforderungen müssen die Anforderungen erfüllen, selbst wenn die WAF-Funktion nicht verwendet wird.

Schritte zur Problembehandlung

  • Vergewissern Sie sich, dass Ihre Anforderungen die Vorgaben in den entsprechenden RFCs erfüllen.
  • Notieren Sie sich den HTML-Nachrichtentext, der als Antwort auf Ihre Anforderung zurückgegeben wird. Ein Nachrichtentext erläutert häufig genau, in welcher Hinsicht Ihre Anforderung nicht kompatibel ist.

Mein Ursprung ist als IP-Adresse konfiguriert.

Symptom

Der Ursprung ist als IP-Adresse konfiguriert. Der Ursprung ist fehlerfrei, lehnt jedoch Anforderungen von Azure Front Door ab.

Ursache

Azure Front Door verwendet den Ursprungshostnamen als SNI-Header während des SSL-Handshakes. Da der Ursprung als IP-Adresse konfiguriert ist, kann der Fehler durch einen der folgenden Gründe verursacht werden:

  • Die Überprüfung des Zertifikatnamens ist in der Front Door-Ursprungskonfiguration aktiviert. Es wird empfohlen, diese Einstellung aktiviert zu lassen. Die Überprüfung des Zertifikatnamens erfordert, dass der Ursprungshostname mit dem Zertifikatnamen oder einem der Einträge in der Erweiterung „alternative Antragstellernamen“ übereinstimmt.
  • Wenn die Überprüfung des Zertifikatnamens deaktiviert ist, liegt die Ursache wahrscheinlich darin, dass die Logik des Ursprungszertifikats alle Anforderungen ablehnt, die keinen gültigen Hostheader in der Anforderung enthalten, die dem Zertifikat entspricht.

Schritte zur Problembehandlung

Ändern Sie den Ursprung von einer IP-Adresse in einen FQDN, für den ein gültiges Zertifikat ausgestellt wird, das dem Ursprungszertifikat entspricht.

Nächste Schritte