Azure Front Door häufig gestellte Fragen (FAQ)

Azure Front Door ist ein cloudbasierter Dienst, der Ihre Anwendungen schneller und zuverlässiger bereitstellt. Er verwendet den Lastenausgleich der Ebene 7, um Datenverkehr auf mehrere Regionen und Endpunkte zu verteilen. Zudem bietet er Beschleunigung dynamischer Websites (Dynamic Site Acceleration, DSA) zum Optimieren der Webleistung und Failover in Quasi-Echtzeit, um eine hohe Verfügbarkeit sicherzustellen. Azure Front Door ist ein vollständig verwalteter Dienst, sodass Sie sich keine Gedanken über die Skalierung oder Wartung machen müssen.

Azure Front Door und Azure Application Gateway sind beide Lastenausgleichsgeräte für HTTP/HTTPS-Datenverkehr, weisen jedoch unterschiedliche Bereiche auf. Front Door ist ein globaler Dienst, der Anforderungen auf mehrere Regionen verteilen kann, während Application Gateway ein regionaler Dienst ist, der einen Lastenausgleich für Anforderungen innerhalb einer Region vornehmen kann. Azure Front Door arbeitet mit Skalierungseinheiten, Clustern oder Stempeleinheiten, während Azure Application Gateway mit VMs, Containern oder anderen Ressourcen in derselben Skalierungseinheit arbeitet.

Sie können verschiedene Arten von Ursprüngen für Azure Front Door verwenden, z. B.:

• Speicher (Azure Blob, Klassisch, statische Websites)
• Clouddienst
• App-Dienst
• Statische Web-App
• API-Verwaltung
• Anwendungs-Gateway
• Öffentliche IP-Adresse
• Azure Spring Apps
• Container Instances
• Container-Anwendungen
• Beliebige benutzerdefinierte Hostnamen mit öffentlichem Zugriff

Der Ursprung muss über eine öffentliche IP-Adresse oder einen DNS-Hostnamen verfügen, der öffentlich aufgelöst werden kann. Sie können Back-End-Dateien aus verschiedenen Zonen, Regionen oder sogar außerhalb von Azure kombinieren und abgleichen, sofern sie öffentlich zugänglich sind.

Azure Front Door ist nicht auf eine Azure Region beschränkt, sondern global tätig. Der einzige Ort, den du beim Erstellen einer Front Door wählst, ist der Standort der Ressourcengruppe, die bestimmt, wo die Metadaten der Ressourcengruppe gespeichert sind. Das Front Door-Profil ist eine globale Ressource, und seine Konfiguration wird an alle Edgestandorte weltweit verteilt.

Die vollständige Liste der Standorte (POPs), die den globalen Lastenausgleich und die Inhaltsübermittlung für Azure Front Door bereitstellen, finden Sie unter Azure Front Door POP-Standorte. Diese Liste wird regelmäßig aktualisiert, wenn neue POPs hinzugefügt oder entfernt werden. Sie können auch die Azure Resource Manager-API verwenden, um die aktuelle Liste der POPs programmgesteuert abzufragen.

Azure Front Door ist ein Dienst, der Ihre Anwendung global über mehrere Regionen verteilt. Es verwendet eine gemeinsame Infrastruktur, die alle Kunden teilen, aber Sie können Ihr eigenes Front Door-Profil anpassen, um die spezifischen Anforderungen Ihrer Anwendung zu konfigurieren. Ihre Front Door-Konfiguration ist von den Konfigurationen anderer Kund*innen isoliert, sodass diese Ihre Konfiguration nicht beeinträchtigen können.

Front Door sortiert die Routen für Ihre Webanwendung nicht. Stattdessen wird die Route ausgewählt, die am besten für die jeweilige Anforderung geeignet ist. Informationen dazu, wie Front Door Anforderungen Routen zuordnet, finden Sie unter Abgleich von Anforderungen mit Routingregeln durch Front Door.

Um die optimale Leistung der Funktionen von Front Door sicherzustellen, lassen Sie nur den Datenverkehr, der von Azure Front Door kommt, Ihren Ursprung erreichen. Dadurch wird nicht autorisierten oder schädlichen Anforderungen aufgrund der Sicherheits- und Routingrichtlinien von Front Door der Zugriff verweigert. Informationen zum Schützen Ihres Ursprungs finden Sie unter Sicherer Datenverkehr zu Azure Front Door-Ursprüngen.

Die Konfigurationsverbreitungszeiten für eine einzelne Erstellung, Aktualisierung, Löschung oder WAF-Operation für Azure Front Door- und CDN-Profile können für zusätzliche Sicherheit bis zu 15 Minuten dauern. Eine einzelne Cache-Purge-Operation wird innerhalb von 10 Minuten abgeschlossen. Ständige Änderungen können die gesamte Bereitstellungszeit auf etwa 30 Minuten verlängern. Jedes Konfigurationsupdate, einschließlich Regelsatzanpassungen, Routing-Änderungen, Ursprungs- oder Domänenupdates sowie WAF-Modifikationen, wird als globale Operation behandelt. Wenn Sie zusätzliche Operationen einreichen, während die erste Operation noch in Gang ist (innerhalb ihres ~15-Minuten-Fensters), stellt das System diese in eine Warteschlange und beginnt erst, nachdem die vorherige Operation abgeschlossen ist. In diesem Szenario wird die erste Operation innerhalb der ersten 15 Minuten abgeschlossen, und die folgenden Änderungen werden im folgenden Fenster verarbeitet. Laufende Plattformverbesserungen werden in Gang gebracht, die diese Zeit weiter reduzieren werden.

Senden mehrerer Bereinigungsanforderungen

Jede Bereinigungsanforderung kann bis zu 100 URLs (Kombination aus Domäne und Pfad) enthalten. Die erste Charge wird verarbeitet und wirkt innerhalb von etwa 10 Minuten.

Wenn Sie mehr als 100 URLs löschen müssen, müssen Sie warten und überprüfen, ob die erste Charge abgeschlossen ist, bevor Sie die nächste Charge einreichen. Wenn du vor Abschluss des vorherigen Batches eine neue Purge-Anfrage einreichst, wird die Anfrage abgelehnt.

Beispiel: Löschen von 256 URLs

1. Übermitteln Sie die ersten 100 URLs in der anfänglichen Bereinigungsanforderung.
2. Warte etwa 10 Minuten und prüfe, ob die erste Charge erfolgreich abgeschlossen wurde.
3. Übermitteln Sie die nächsten 101-200 URLs in der zweiten Anforderung.
4. Warte etwa 10 Minuten, bis die zweite Charge fertig ist.
5. Übermitteln Sie die verbleibenden URLs von 201-256 in der dritten Anforderung.

Aktualisierungen von Routen oder Ursprungsgruppen/Back-End-Pools usw. erfolgen nahtlos und verursachen keine Downtime (sofern die neue Konfiguration korrekt ist). Zertifikataktualisierungen werden auch atomisch durchgeführt, sodass keine Ausfallzeiten vorhanden sind.

• Du kannst Front Door Standard/Premium und Azure CDN-Profile zwischen Ressourcengruppen oder Abonnements ohne Ausfallzeiten verschieben. Führen Sie zum Verschieben die folgenden Anweisungen aus.
• Azure Front Door (klassisch) unterstützt keinen Wechsel zwischen Ressourcengruppen oder Abonnements. Du kannst stattdessen das Azure Front Door (klassische) Profil auf Standard/Premium migrieren und dann den Umzug ausführen.
• Wenn Sie eine WAF-Police mit Azure Front Door Standard oder Premium verknüpfen, schlägt die Verlagerungsoperation fehl. Du musst zuerst die WAF-Richtlinie dissoziieren, den Umzug abschließen und dann die Richtlinie wieder verknüpfen.

Azure Front Door bietet viele Vorteile für Ihre Webanwendungen, wie zum Beispiel dynamische Site-Beschleunigung (DSA), die die Leistung und das Nutzererlebnis Ihrer Seiten verbessert. Azure Front Door übernimmt außerdem TLS/SSL-Offloading und End-to-End-TLS, was die Sicherheit und Verschlüsselung Ihres Webverkehrs verbessert. Zusätzlich bietet Azure Front Door eine Web-Anwendungs-Firewall, cookie-basierte Sitzungsaffinität, URL-pfadbasiertes Routing, kostenlose Zertifikate, Verwaltung mehrerer Domänen und mehr. Weitere Informationen zu den Features und Funktionen von Azure Front Door finden Sie unter tier comparison.

Azure Front Door unterstützt HTTP, HTTPS und HTTP/2.

Azure Front Door unterstützt das HTTP/2-Protokoll für Clientverbindungen. Für die Kommunikation des Back-End-Pools wird jedoch das HTTP/1.1-Protokoll verwendet. Die HTTP/2-Unterstützung ist standardmäßig aktiviert.

Nein. Derzeit unterstützt Azure Front Door nur HTTP/1.1 vom Rand zum Ursprung. Damit gRPC funktioniert, ist HTTP/2 erforderlich.

Sie können Host-, Pfad- und Abfragezeichenfolgenkomponenten einer URL mit Azure Front Door umleiten. Um zu erfahren, wie man URL-Weiterleitung konfiguriert, siehe URL-Weiterleitung.

Ja. Siehe die MatchedRulesSetName Eigenschaft unter Zugriffsprotokolle.

Ja. Weitere Informationen finden Sie unter Microsoft Antwort auf DDoS-Angriffe auf HTTP/2.

Nein. Azure Front Door kann den Client-Datenverkehr nicht zu einem bestimmten POP leiten. Anfragen werden zwecks Leistung und Zuverlässigkeit an den nächstgelegenen verfügbaren Edge-Standort weitergeleitet. Wenn Sie den Zugriff nach Geografie einschränken müssen, verwenden Sie benutzerdefinierte Azure Web Application Firewall (WAF)-Regeln mit GeoMatch Bedingungen. Dieser Ansatz ermöglicht oder blockiert Anforderungen auf der Grundlage von Clientland/Region, aber diese Clients werden nicht an einen anderen POP in einem anderen Land/einer anderen Region umgeleitet. Wenn Sie beispielsweise Land/Region A blockieren, werden Anfragen von Clients in Land/Region A blockiert, egal welches POP sie bedient hätte. Weitere Informationen finden Sie unter Geofilterung in Azure WAF für Azure Front Door.

Azure Front Door unterstützt die Header "X-Forwarded-For", "X-Forwarded-Host" und "X-Forwarded-Proto". Diese Header helfen Front Door, die ursprüngliche Client-IP und das ursprüngliche Protokoll zu identifizieren. Wenn „X-Forwarded-For“ bereits vorhanden ist, fügt Front Door die Client-Socket-IP-Adresse am Ende der Liste hinzu. Andernfalls wird der Header mit der Client-Socket-IP-Adresse als Wert erstellt. Für „X-Forwarded-Host“ und „X-Forwarded-Proto“ ersetzt Front Door die vorhandenen Werte durch seine eigenen Werte.

Weitere Informationen finden Sie unter Protokollunterstützung für HTTP-Header in Azure Front Door.

Um Azure Front Door Standard oder Azure Front Door (klassisch) zu verwenden, benötigt man eine öffentliche IP-Adresse oder einen öffentlich auflösbaren DNS-Namen. Diese Anforderung erlaubt es Azure Front Door, den Datenverkehr auf Ihre Backend-Ressourcen zu leiten. Sie können Azure-Ressourcen wie Azure Application Gateways oder Azure Load Balancer verwenden, um Datenverkehr an Ressourcen in einem virtuellen Netzwerk weiterzuleiten. Wenn Sie Azure Front Door Premium verwenden, können Sie Private Link nutzen, um über einen privaten Endpunkt eine Verbindung mit Ursprungsservern hinter einem internen Lastenausgleich herzustellen. Weitere Informationen finden Sie unter Secure origins with Private Link.

Nein. Zur Sicherheit unterstützt Azure Front Door nur die verwaltete identitätsbasierte Authentifizierung beim Zugriff auf Zertifikate in Key Vault. Weitere Informationen finden Sie unter Use managed identities in Azure Front Door.

Nein. Azure Front Door unterstützt derzeit keine verwaltete Identitätsintegration mit Azure Event Hubs.

Nein. Azure Front Door unterstützt derzeit keine benutzerdefinierten Fehlerseiten.

In den folgenden Fällen ist die Bereitstellung von Application Gateway hinter Front Door nützlich:

• Sie möchten nicht nur global, sondern auch innerhalb Ihres virtuellen Netzwerks einen Lastenausgleich für den Datenverkehr vornehmen. Front Door kann nur einen pfadbasierten Lastenausgleich auf globaler Ebene vornehmen, Application Gateway ermöglicht jedoch einen Lastenausgleich innerhalb Ihres virtuellen Netzwerks.
• Sie benötigen einen Verbindungsausgleich, der von Front Door nicht unterstützt wird. Application Gateway kann den Verbindungsausgleich für Ihre VMs oder Container ermöglichen.
• Sie möchten die gesamte TLS/SSL-Verarbeitung abladen und nur HTTP-Anforderungen in Ihrem virtuellen Netzwerk verwenden. Dies kann durch Bereitstellen von Application Gateway hinter Front Door erzielt werden.
• Sie möchten die Sitzungsaffinität sowohl auf regionaler Ebene als auch auf Serverebene verwenden. Front Door kann den Datenverkehr von einer Benutzersitzung an dasselbe Back-End in einer Region senden, aber Application Gateway kann den Datenverkehr an denselben Server im Back-End senden.

Zwei CDNs zu ketten wird im Allgemeinen nicht empfohlen. Obwohl es funktionieren kann, hat es folgende Nachteile:

1. Die Last-Mile-Beschleunigung eines CDNs funktioniert, indem der Verbindungsstream mit dem Ursprung aufrechterhalten und der optimale Pfad zum Ursprung gefunden wird, um die besten Ergebnisse zu erzielen. Durch das Verketten von zwei CDNs können in der Regel einige der Vorteile der Beschleunigung auf der letzten Meile nicht genutzt werden.
2. Sicherheitskontrollen sind am zweiten CDN weniger effektiv. Die Client-IP-basierte Zugangskontrolle funktioniert dort nicht, weil das zweite CDN den Ausgangsknoten des ersten CDN als Client-IP identifiziert. Die Inhaltsnutzlast wird weiterhin inspiziert.
3. Das Chainen zweier CDNs erhöht die Fehlerbehebungskomplexität. Wenn ein Problem auftritt, kann es schwierig sein zu bestimmen, welches CDN es verursacht.

Um Azure Front Door zu verwenden, müssen Sie über eine öffentliche virtuelle IP-Adresse (VIP) oder einen öffentlich zugänglichen DNS-Namen verfügen. Azure Front Door verwendet die öffentliche IP, um den Datenverkehr an Ihren Ursprung weiterzuleiten. Ein häufiges Szenario besteht darin, einen Azure Load Balancer hinter Front Door bereitzustellen. Sie können auch Private Link mit Azure Front Door Premium verwenden, um eine Verbindung mit einem internen Lastenausgleichsursprung herzustellen. Weitere Informationen finden Sie unter Aktivieren von Private Link mit internem Lastenausgleich.

Azure Front Door und Azure CDN sind zwei Dienste, die eine schnelle und zuverlässige Webbereitstellung für Ihre Anwendungen bieten. Sie sind jedoch nicht miteinander kompatibel, da sie dasselbe Netzwerk von Azure Edgewebsites gemeinsam nutzen, um Inhalte an Ihre Benutzer zu übermitteln. Dieses gemeinsam genutzte Netzwerk verursacht Konflikte zwischen ihren Routing- und Zwischenspeicherungsrichtlinien. Daher müssen Sie je nach Leistung und Sicherheitsanforderungen entweder Azure Front Door oder Azure CDN für Ihre Anwendung auswählen.

Die Tatsache, dass beide Profile/Endpunkte dasselbe Azure Edge POP verwenden, um eingehende Anfragen zu verarbeiten, führt zu einer Einschränkung, die verhindert, dass man ein Azure Front Door-Profil/-Endpunkt hinter ein anderes verschachtelt. Dieses Setup würde Routingkonflikte und Leistungsprobleme verursachen. Wenn du also mehrere Profile/Endpunkte für deine Anwendungen verwenden musst, solltest du sicherstellen, dass deine Azure Front Door-Profile/Endpunkte nicht miteinander verknüpft sind.

Azure Front Door verwendet Unicast-Routing zur Namensauflösung und leitet Anfragen an den optimalen Point of Presence (POP) weiter. Unicast ersetzte die Anycast-Routing-Methode, die Azure Front Door zuvor verwendete.

Eine Anforderung zur Namensauflösung für einen Ursprung hinter Azure Front Door wird an den Traffic Manager-Endpunkt von Front Door weitergeleitet. Die Traffic Manager-Profile von Front Door nutzen zahlreiche Integritäts- und Verfügbarkeitssignale von den PoPs weltweit. Basierend auf diesen Signalen wird die Unicast-IP-Adresse des optimalen Front Door PoP zurückgegeben. Die Anforderung wird dann direkt an die zurückgegebene IP-Adresse gestellt, die der Front Door-Routingarchitektur folgt und die Antwort an den Benutzer oder die Anwendung übermittelt.

Azure Front Door verwendet drei Diensttags, um den Datenverkehr zwischen Ihren Clients und Ihren Ursprüngen zu verwalten:

• Das Diensttag AzureFrontDoor.BackEnd enthält die IP-Adressen, die Front Door für den Zugriff auf Ihre Ursprünge verwendet. Sie können dieses Diensttag anwenden, wenn Sie die Sicherheit für Ihre Ursprünge konfigurieren.
• Das Diensttag AzureFrontDoor.Frontend enthält die IP-Adressen, die Clients zum Herstellen einer Verbindung mit Front Door verwenden. Sie können das AzureFrontDoor.Frontend-Dienste-Tag anwenden, wenn Sie den ausgehenden Datenverkehr steuern möchten, der mit Diensten hinter Azure Front Door eine Verbindung herstellen können.
• Das AzureFrontDoor.FirstParty Servicetag ist für eine ausgewählte Gruppe von Microsoft-Dienste reserviert, die auf Azure Front Door gehostet wird.

Weitere Informationen zu Azure Front Door Diensttagsszenarien finden Sie unter available service tags. Um bei Änderungen an IP-Adressen auf dem Laufenden zu bleiben und entsprechende Maßnahmen zu ergreifen, entwickeln Sie eine Automatisierung, um regelmäßig die neuesten IP-Adressen mithilfe der Diensttag-Ermittlungs-API oder einer JSON-Datei abzurufen.

Eine Ursprungsgruppe ist eine Sammlung von Ursprüngen, die ähnliche Anforderungstypen verarbeiten können. Für jede Anwendung oder Workload, die sich von anderen unterscheidet, benötigen Sie eine andere Ursprungsgruppe.

Innerhalb einer Ursprungsgruppe erstellen Sie einen Ursprung für jeden Server oder jeden Dienst, der Anforderungen verarbeiten kann. Wenn Ihr Ursprung über einen Lastenausgleich verfügt, z. B. Azure Application Gateway, oder auf einem PaaS mit einem Lastenausgleich gehostet wird, hat die Ursprungsgruppe nur einen Ursprung. Ihr Ursprung übernimmt die Ausführung des Failovers und Lastenausgleichs zwischen Ursprüngen, die für Front Door nicht sichtbar sind.

Wenn Sie beispielsweise eine Anwendung auf Azure App Service hosten, hängt die Einrichtung von Front Door davon ab, wie viele Anwendungsinstanzen Sie haben:

• Bereitstellung in einer einzelnen Region: Erstellen Sie eine einzelne Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für die App Service-App. Ihre App Service-App kann über Worker hinweg skaliert werden, aber Front Door sieht einen Ursprung.
• Aktiv/Passiv-Bereitstellung in mehreren Regionen: Erstellen Sie eine einzelne Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für jede App Service-App. Legen Sie die Priorität der einzelnen Ursprünge fest, damit die Hauptanwendung eine höhere Priorität hat als die Sicherungsanwendung.
• Aktiv/Aktiv-Bereitstellung in mehreren Regionen: Erstellen Sie eine einzelne Ursprungsgruppe. Erstellen Sie in dieser Ursprungsgruppe einen Ursprung für jede App Service-App. Legen Sie für jeden Ursprung die gleiche Priorität fest. Legen Sie die Gewichtung jedes Ursprungs fest, um zu steuern, wie viele Anforderungen an diesen Ursprung gesendet werden.

Weitere Informationen finden Sie unter Origins und Ursprungsgruppen in Azure Front Door.

Azure Front Door ist ein Dienst, der eine schnelle und zuverlässige Webbereitstellung für Ihre Anwendungen bietet. Er bietet Features wie Zwischenspeichern, Lastenausgleich, Sicherheit und Routing. Sie müssen jedoch einige Timeouts und Grenzwerte beachten, die für Azure Front Door gelten. Zu diesen Timeouts und Grenzwerte zählen die maximale Anforderungsgröße, die maximale Antwortgröße, die maximale Headergröße, die maximale Anzahl von Headern, die maximale Anzahl von Regeln und die maximale Anzahl von Ursprungsgruppen. Ausführliche Informationen zu diesen Timeouts und Grenzwerten finden Sie in der Dokumentation Azure Front Door.

Die meisten Regelwerke aktualisieren ihre Konfigurationen in weniger als 15 Minuten. Die Regel gilt, sobald das Update abgeschlossen ist.

Azure Front Door hat eine 5-Sekunden-Timeout für den Empfang von Headern von einem Client. Wenn der Client nicht innerhalb von 5 Sekunden nach Aufbau einer TCP/TLS-Verbindung zu Azure Front Door Header sendet, wird die Verbindung beendet. Du kannst diese Auszeit nicht konfigurieren.

Azure Front Door verfügt über ein 90-Sekunden-HTTP-Keep-Alive-Timeout. Die Verbindung wird beendet, wenn der Client keine Daten für 90 Sekunden sendet, also das HTTP-Keep-Alive-Timeout für Azure Front Door. Dieser Timeoutwert kann nicht konfiguriert werden.

Sie können nicht dieselben Domänen für mehrere Front Door-Endpunkte verwenden, da Front Door zwischen den Routen (Kombination aus Protokoll, Host und Pfad) für jede Anforderung unterscheiden muss. Wenn Sie doppelte Routen über verschiedene Endpunkte hinweg haben, können Azure Front Door die Anforderungen nicht ordnungsgemäß verarbeiten.

Derzeit bieten wir nicht die Möglichkeit, Domänen ohne Dienstunterbrechung von einem Endpunkt zu einem anderen zu verschieben. Sie müssen etwas Downtime einplanen, wenn Sie Ihre Domänen zu einem anderen Endpunkt migrieren möchten.

Azure Front Door Private Link ist regionsunabhängig. Für die geringste Latenz wählen Sie beim Aktivieren eines Azure Front Door Private Link-Endpunkts die unterstützte Azure Region aus, die Ihrem Ursprung am nächsten liegt. Wenn die Region Ihres Ursprungs in der Liste der von Front Door Private Link unterstützten Regionen nicht enthalten ist, wählen Sie die nächstgelegene Region aus. Der Datenverkehr fließt vom Client zum Azure Front Door Private Link Endpunkt in der unterstützten Region und durchläuft dann das Microsoft Backbone-Netzwerk an Ihren Ursprung, wobei die private Konnektivität beibehalten wird. Diese Konfiguration führt zu zusätzlicher Latenz durch den zusätzlichen Netzwerk-Hop zwischen den Regionen. Sie können Azure-Netzwerk-Roundtrip-Latenzstatistiken verwenden, um die zusätzliche Latenz durch die Wahl der nächstnächsten Region zu bestimmen. Wenn eine neue Region unterstützt wird, können Sie diesen Anweisungen folgen, um den Datenverkehr schrittweise in die neue Region zu verlagern.

Azure Front Door ist eine Plattform, die weltweit Datenverkehr verteilt und sich an die Anforderungen Ihrer Anwendung anpassen kann. Es nutzt das globale Edge-Netzwerk von Microsoft, um globale Lastverteilung bereitzustellen, sodass Sie Ihre gesamte Anwendung oder spezifische Microservices im Falle eines Ausfalls in verschiedene Regionen oder Clouds verschieben können.

Um Fehler bei der Auslieferung großer Dateien zu vermeiden, stellen Sie sicher, dass Ihr Ursprungsserver den Header Content-Range in der Antwort enthält und dass der Headerwert mit der tatsächlichen Größe des Antwortkörpers übereinstimmt.

Weitere Informationen zum Konfigurieren Ihres Ursprungs und von Front Door für die Übermittlung großer Dateien finden Sie unter Übermittlung großer Dateien.

Domänen-Fronting ist eine Technik, mit der Angreifer*innen das tatsächliche Ziel einer schädlichen Anforderung verbergen können, indem sie einen anderen Domänennamen im TLS-Handshake und HTTP-Hostheader verwenden.

Für Azure Front Door-Ressourcen (Standard, Premium und Classic Tier) oder Azure CDN Standard von Microsoft (klassisch), die nach dem 8. November 2022 erstellt wurden, ist die Blockierung von Domain Fronting aktiviert. Anstatt eine Anfrage mit nicht übereinstimmenden SNI- und Host-Headern zu blockieren, lassen wir die Diskrepanz zu, wenn die beiden Domains zum selben Abonnement gehören und in die Routen- oder Routing-Regeln einbezogen sind. Die Durchsetzung der Blockierung von Domain-Fronting begann am 22. Januar 2024.

Wenn Front Door eine Anforderung aufgrund eines Konflikts blockiert, geschieht Folgendes:

• Der Client empfängt eine Antwort mit dem HTTP-Fehlercode 421 Misdirected Request.
• Azure Front Door zeichnet den Block in den Diagnoseprotokollen unter der Error Info-Eigenschaft mit dem Wert SSLMismatchedSNI auf.

Weitere Informationen zum Fronting von Domänen finden Sie unter Sicherung unseres Ansatzes zur Domänen-Fronting innerhalb von Azure und Verbot des Domänen-Frontings bei Azure Front Door und Azure CDN Standard von Microsoft (klassisch).

Front Door verwendet TLS 1.2 als Mindestversion für alle Profile, die nach September 2019 erstellt wurden.

Sie können TLS 1.2 oder 1.3 mit Azure Front Door verwenden. Weitere Informationen finden Sie im Artikel Azure Front Door End-to-End TLS.

Ab dem 15. August 2025 überstieg DigiCert auf eine neue Open-Source-Software(OSS) Domain Control Validation (DCV)-Plattform zur Verbesserung der Transparenz und Rechenschaftspflicht in Domänenüberprüfungsprozessen. DigiCert unterstützt nicht mehr den alten CNAME-Delegations-DCV-Workflow für die Validierung der Domänenkontrolle in den spezifizierten Azure-Diensten. Weitere Informationen

Die Abschaffung wirkt sich auf Dienste aus, die auf der Überprüfung mittels CNAME für die automatische Ausstellung und Erneuerung von Zertifikaten basieren, einschließlich:

• Azure Front Door (klassisch)
• Azure CDN aus Microsoft (klassisch)

Azure Front Door (klassisch) und Azure CDN aus Microsoft (klassisch):

• Ab dem 15. August 2025 gibt es keine Unterstützung mehr für das Onboarding neuer Domains, die Erstellung neuer Profile oder Azure-verwaltete Zertifikate.
• Ab dem 14. April 2026 werden vorhandene verwaltete Zertifikate eingestellt. Alle bestehenden verwalteten Zertifikate werden entweder vom Kunden oder vom AFD-Team auf Azure Front Door Standard oder Premium migriert. Verwenden Sie Azure Front Door Standard oder Premium für verwaltete Zertifikate.

In den meisten Fällen ist keine Aktion erforderlich. Nachdem Ihr Profil migriert wurde, versucht Azure Front Door automatisch, Ihr verwaltetes Zertifikat zu rotieren, wenn es innerhalb von 45 Tagen nach Ablaufdatum liegt.

• Wenn Ihre Domäne per CNAME Azure Front Door zugeordnet ist und die Anforderungen an CAA-Datensätze und den Domänenstatus erfüllt, wird das Zertifikat automatisch rotiert. Der Auftrag zur automatischen Rotation wird alle 6 bis 8 Stunden ausgeführt und dauert etwa 24 bis 48 Stunden. Wenn die automatische Rotation fehlschlägt, ändert sich der Status der Domain-Validierung zu 'Pending validation', und du kannst den Domainbesitz erneut validieren, um die Validierung manuell auszulösen.
• Wenn Ihre Domain diese Validierungsanforderungen nicht erfüllt oder HTTPS deaktiviert ist, ändert sich der Zertifikatszustand zu "Pending Revalidation" und Sie müssen das Domain-Eigentum erneut validieren.

Um das Zertifikat zu erneuern, ohne auf die automatische Rotation zu warten, validieren Sie den Domainbesitz manuell mit einer der folgenden Methoden:

• Hinzufügen des erforderlichen DNS-Überprüfungseintrags nach Schritt 3 für ausstehende Domänenüberprüfung
• Manuelles Auslösen der Validierung mit PowerShell oder Azure CLI (RefreshValidation).

Du kannst die Ressourcen von Azure Front Door nicht deaktivieren. Du kannst sie nur löschen. Variable Zähler wie Data Transfer Out, Data Transfer In und Anfragen werden nicht berechnet, wenn kein Verkehr vorhanden ist, aber die Grundgebühr wird auch dann berechnet, wenn kein Verkehr vorhanden ist. Die Grundgebühr wird berechnet, bis das Profil gelöscht wird. Für Azure Front Door (klassisch) werden WAF-Richtlinien und -Regeln unabhängig vom Status berechnet. Selbst wenn Sie eine WAF-Richtlinie oder -Regel deaktivieren, entstehen für Sie weiterhin Kosten.

Nein.

Nein.

Front Door unterstützt keine dynamische Kompression für Inhalte größer als 8 MB. Wenn der Ursprung den Inhalt jedoch bereits komprimiert, unterstützt Front Door die Bereitstellung statischer komprimierter Inhalte mit einer Größe von mehr als 8 MB, solange Bereichsanforderungen unterstützt werden und Chunked Transfer Encoding nicht aktiviert ist.

Nein.

Informationen zu Protokollen und anderen Diagnosefunktionen finden Sie unter Überwachen von Metriken und Protokollen für Front Door.

Sie können Diagnoseprotokolle im zugehörigen Speicherkonto speichern und festlegen, wie lange sie beibehalten werden sollen. Alternativ können Sie Diagnoseprotokolle an Event Hubs oder Azure Monitor-Logs senden. Weitere Informationen finden Sie unter Azure Front Door Diagnostics.

Um auf die Überwachungsprotokolle von Azure Front Door zuzugreifen, müssen Sie das Portal besuchen. Wählen Sie auf der Menüseite Ihre Front Door aus und wählen Sie Aktivitätsprotokoll aus. Das Aktivitätsprotokoll stellt Ihnen die Datensätze Ihrer "Azure Front Door"-Vorgänge zur Verfügung.

Sie können Warnungen für Azure Front Door basierend auf metrics oder logs einrichten. Auf diese Weise können Sie die Leistung und Integrität Ihrer Front-End-Hosts überwachen.

Informationen zum Erstellen von Warnungen für Azure Front Door Standard und Premium finden Sie unter Configure alerts.

Verwandte Inhalte

• Erstellen eines Azure Front Door-Profils
• Azure Front Door-Routingarchitektur