Azure Front Door vanliga frågor och svar

Azure Front Door är en molnbaserad tjänst som levererar dina program snabbare och mer tillförlitligt. Den använder layer 7-belastningsutjämning för att distribuera trafik över flera regioner och slutpunkter. Den erbjuder också dynamisk webbplatsacceleration (DSA) för att optimera webbprestanda och nästan realtids redundanshantering för att garantera hög tillgänglighet. Azure Front Door är en fullständigt hanterad tjänst, så du behöver inte bekymra dig om skalning eller underhåll.

Azure Front Door och Azure Application Gateway är båda lastbalanserare för HTTP/HTTPS-trafik, men de har olika omfång. Front Door är en global tjänst som kan distribuera begäranden mellan regioner, medan Application Gateway är en regional tjänst som kan balansera begäranden inom en region. Azure Front Door arbetar med skalenheter, kluster eller stämpelenheter, medan Azure Application Gateway arbetar med VM:ar, containrar eller andra resurser i samma skalenhet.

Du kan använda olika typer av ursprung för Azure Front Door, till exempel:

• Lagring (Azure Blob, klassiska, statiska webbplatser)
• Molntjänst
• App-tjänst
• Statisk webbapplikation
• API Management
• Application Gateway
• Offentlig IP-adress
• Azure Spring Apps
• Containerinstanser
• Containerapplikationer
• Alla anpassade värdnamn med offentlig åtkomst.

Ursprunget måste ha en offentlig IP-adress eller ett DNS-värdnamn som kan lösas offentligt. Du kan blanda och matcha serverdelar från olika zoner, regioner eller till och med utanför Azure, så länge de är offentligt tillgängliga.

Azure Front Door är inte begränsat till någon Azure region, utan fungerar globalt. Den enda plats du väljer när du skapar en Front Door är platsen för resursgruppen, som avgör var resursgruppens metadata lagras. Front Door-profilen är en global resurs och dess konfiguration distribueras till alla gränsplatser över hela världen.

En fullständig lista över närvaropunkter (POP:er) som tillhandahåller global belastningsutjämning och innehållsleverans för Azure Front Door finns i Azure Front Door POP-platser. Listan uppdateras regelbundet i takt med att nya långlivade organiska föroreningar läggs till eller tas bort. Du kan också använda api:et Azure Resource Manager för att köra frågor mot den aktuella listan över IP-adresser programmatiskt.

Azure Front Door är en tjänst som distribuerar ditt program globalt över flera regioner. Den använder en gemensam infrastruktur som alla dess kunder delar, men du kan anpassa din egen Front Door-profil för att konfigurera applikationens specifika krav. Andra kunders konfigurationer kan inte påverka din Front Door-konfiguration, som är isolerad från deras.

Front Door sorterar inte rutterna för din webbapplikation. I stället väljer den den väg som bäst passar begäran. Information om hur Front Door matchar begäranden till vägar finns i Hur Front Door matchar begäranden till en routningsregel.

För att säkerställa optimal prestanda för Front Doors funktioner, tillåt endast trafik som kommer från Azure Front Door att nå din ursprungsplats. Därför stöter obehöriga eller skadliga begäranden på säkerhets- och routningsprinciperna för Front Door och nekas åtkomst. Information om hur du skyddar dina källor finns i Skydda trafik till Azure Front Door källor.

Konfigurationsspridningstider för en enda skapa-, uppdaterings-, borttagnings- eller WAF-operation för Azure Front Door- och CDN-profiler kan ta upp till 15 minuter för ökad säkerhet. En enda cacherensningsoperation slutförs inom 10 minuter. Upprepade ändringar kan förlänga den totala utrullningstiden till cirka 30 minuter. Varje konfigurationsuppdatering, inklusive justeringar av regeluppsättningar, routningsändringar, uppdateringar av ursprung eller domän samt WAF-ändringar, behandlas som en global operation. Om du skickar ytterligare operationer medan den första operationen fortfarande propageras (inom dess cirka 15 minuter långa tidsfönster), lägger systemet dem i kö och påbörjar dem först när den föregående operationen har slutförts. I detta scenario slutförs den första operationen inom de första 15 minuterna, och efterföljande ändringar bearbetas i följande fönster. Pågående plattformsförbättringar kommer att ytterligare minska den här tiden.

Skicka flera rensningsbegäranden

Varje rensningsbegäran kan innehålla upp till 100 URL:er (kombination av domän och sökväg). Den första satsen bearbetas och verkar inom cirka 10 minuter.

Om du har mer än 100 URL:er att rensa måste du vänta och verifiera att den första omgången är klar innan du skickar in nästa omgång. Om du skickar in en ny rensningsbegäran innan föregående omgång är klar, avslås begäran.

Exempel: Rensa 256 URL:er

1. Skicka de första 100 URL:erna i den första rensningsbegäran.
2. Vänta ungefär 10 minuter och kontrollera att den första omgången slutförts framgångsrikt.
3. Skicka in nästa 101–200 URL:er i den andra begäran.
4. Vänta ungefär 10 minuter tills den andra satsen är klar.
5. Skicka de återstående URL:erna för 201–256 i den tredje begäran.

Uppdateringar av vägar eller ursprungsgrupper/serverdelspooler är sömlösa och orsakar inte driftstopp (förutsatt att den nya konfigurationen är korrekt). Certifikatuppdateringar görs också atomiskt, så det finns ingen stilleståndstid.

• Du kan flytta Front Door Standard/Premium och Azure CDN-profiler mellan resursgrupper eller prenumerationer utan någon driftstopp. Följ dessa instruktioner för att utföra flytten.
• Azure Front Door (klassiskt) stöder inte flytt mellan resursgrupper eller prenumerationer. Du kan istället migrera Azure Front Door (classic) profilen till Standard/Premium och sedan genomföra flytten.
• Om du associerar en WAF-policy med Azure Front Door Standard eller Premium misslyckas flyttoperationen. Du måste först ta bort associationen med WAF-policyn, slutföra flytten och sedan associera policyn igen.

Azure Front Door erbjuder många fördelar för dina webbapplikationer, såsom dynamisk webbplatsacceleration (DSA), som förbättrar prestandan och användarupplevelsen på dina webbplatser. Azure Front Door hanterar också TLS/SSL-avlastning och end-to-end TLS, vilket förbättrar säkerheten och krypteringen av din webbtrafik. Dessutom erbjuder Azure Front Door en brandvägg för webbapplikationer, cookiebaserad sessionsaffinitet, URL-vägsbaserad routing, gratis certifikat, hantering av flera domäner och mer. Mer information om funktionerna och kapaciteterna i Azure Front Door finns i nivåjämförelse.

Azure Front Door stöder HTTP, HTTPS och HTTP/2.

Azure Front Door stöder HTTP/2-protokoll för klientanslutningar. Kommunikationen i serverdelspoolen använder dock HTTP/1.1-protokollet. HTTP/2-stöd är aktiverat som standard.

Nej. För närvarande stöder Azure Front Door endast HTTP/1.1 från gränsen till ursprunget. För att gRPC ska fungera krävs HTTP/2.

Du kan omdirigera komponenterna värd, sökväg och frågesträng i en URL med Azure Front Door. För att lära dig hur man konfigurerar URL-omdirigering, se URL-omdirigering.

Ja. Se egenskapen MatchedRulesSetName under Åtkomstloggar.

Ja. Mer information finns i Microsoft svar på DDoS-attacker mot HTTP/2.

Nej. Azure Front Door kan inte tvinga klienttrafik till en specifik POP. Begäranden dirigeras till närmaste tillgängliga gränsplats för prestanda och tillförlitlighet. Om du behöver begränsa åtkomsten efter geografi använder du anpassade Azure Web Application Firewall(WAF) regler med GeoMatch villkor. Den här metoden tillåter eller blockerar begäranden baserat på klientland/region, men de omdirigeras inte till en annan POP i ett annat land/en annan region. Om du till exempel blockerar land/region A blockeras begäranden från klienter i land/region A oavsett vilken POP som skulle ha hanterat dem. Mer information finns i Geo-filtrering i Azure WAF för Azure Front Door.

Azure Front Door stöder rubrikerna X-Forwarded-For, X-Forwarded-Host och X-Forwarded-Proto. Dessa huvuden hjälper Front Door att identifiera den ursprungliga klient-IP-adressen och protokollet. Om X-Forwarded-For redan finns lägger Front Door till klientsocket-IP-adressen i slutet av listan. Annars skapar den en rubrik med IP-adressen från klientens socket som värde. För X-Forwarded-Host och X-Forwarded-Proto ersätter Front Door de befintliga värdena med sina egna.

Mer information finns i HTTP-huvuden som stöds av Front Door.

För att använda Azure Front Door Standard eller Azure Front Door (klassiskt) behöver du en publik IP-adress eller ett offentligt upplösbart DNS-namn. Detta krav tillåter Azure Front Door att dirigera trafik till dina backend-resurser. Du kan använda Azure resurser som Application Gateways eller Azure Load Balancers för att dirigera trafik till resurser i ett virtuellt nätverk. Om du använder Azure Front Door Premium kan du använda Private Link för att ansluta till ursprung bakom en intern lastbalanserare via en privat endpoint. Mer information finns i Säkra ursprung med Private Link.

Nej. För säkerhet stöder Azure Front Door endast hanterad identitetsbaserad autentisering vid åtkomst till certifikat i Key Vault. Mer information finns i Använd hanterade identiteter i Azure Front Door.

Nej. Azure Front Door stöder för närvarande inte hanterad identitetsintegrering med Azure Event Hubs.

Nej. Azure Front Door stöder för närvarande inte anpassade felsidor.

Application Gateway bakom Front Door är användbart i följande situationer:

• Du vill balansera trafiken inte bara globalt, utan även i ditt virtuella nätverk. Front Door kan bara utföra sökvägsbaserad belastningsutjämning på global nivå, men Application Gateway kan göra det i ditt virtuella nätverk.
• Du behöver anslutningstömning, vilket Front Door inte stöder. Application Gateway kan aktivera anslutningstömning för dina virtuella datorer eller containrar.
• Du vill avlasta all TLS/SSL-bearbetning och endast använda HTTP-begäranden i ditt virtuella nätverk. Application Gateway bakom Front Door-tjänsten kan konfigurera den här inställningen.
• Du vill använda sessionstillhörighet på både regional nivå och servernivå. Front Door kan dirigera trafiken från en användarsession till samma backend i en region, medan Application Gateway kan skicka den till samma server inom backenden.

Att kedja ihop två CDN:er rekommenderas generellt inte. Även om det kan fungera har det följande nackdelar:

1. En CDN:s accelerering av sista milen fungerar genom att hålla anslutningen till ursprungsservern öppen och hitta den optimala vägen till ursprungsservern för bästa resultat. Att länka ihop två CDN:er förnekar vanligtvis några av fördelarna med acceleration på sista milen.
2. Säkerhetskontroller är mindre effektiva vid det andra CDN. Åtkomstkontroll baserad på klient-IP fungerar inte där eftersom det andra CDN:t identifierar den första CDN:s exitnod som klientens IP. Innehållslasten inspekteras fortfarande.
3. Att kedja ihop två CDN:er ökar felsökningskomplexiteten. När ett problem uppstår kan det vara svårt att avgöra vilket CDN som orsakar det.

Om du vill använda Azure Front Door måste du ha en offentlig VIP eller ett DNS-namn som är offentligt tillgängligt. Azure Front Door använder den offentliga IP-adressen för att dirigera trafiken till ditt ursprung. Ett vanligt scenario är att distribuera en "Azure Load Balancer" bakom "Front Door". Du kan också använda Private Link med Azure Front Door Premium för att ansluta till en intern lastbalanserare. Mer information finns i aktivera Private Link med intern lastbalanserare.

Azure Front Door och Azure CDN är två tjänster som ger snabb och tillförlitlig webbleverans för dina program. De är dock inte kompatibla med varandra eftersom de delar samma nätverk av Azure edge-webbplatser för att leverera innehåll till dina användare. Det här delade nätverket orsakar konflikter mellan deras routnings- och cachelagringsprinciper. Därför måste du välja antingen Azure Front Door eller Azure CDN för ditt program, beroende på dina prestanda- och säkerhetskrav.

Det faktum att båda profilerna/endpointerna använder samma Azure Edge POP för att hantera inkommande förfrågningar orsakar en begränsning som hindrar dig från att bädda en Azure Front Door-profil/endpoint bakom en annan. Den här inställningen skulle orsaka routningskonflikter och prestandaproblem. Därför, om du behöver använda flera profiler/endpoints för dina applikationer, bör du se till att dina Azure Front Door-profiler/endpoints inte är kedjade ihop.

Azure Front Door använder unicast-routing för namnupplösning och dirigerar förfrågningar till den optimala närvaropunkten (POP). Unicast ersatte Anycast-routningsmetoden som Azure Front Door tidigare använde.

En begäran om namnupplösning för en ursprungsserver bakom Azure Front Door hamnar på Front Doors Traffic Manager-slutpunkt. Front Doors Traffic Manager-profiler tar emot många hälso- och tillgänglighetssignaler från PoPs över hela världen. Baserat på dessa signaler returneras unicast-IP-adressen för den optimala Front Door PoP. Begäran görs sedan direkt till ip-adressen som returneras, vilket följer frontdörrens routningsarkitektur för att returnera svaret tillbaka till användaren eller programmet.

Azure Front Door använder tre tjänsttaggar för att hantera trafiken mellan dina klienter och ditt ursprung:

• Tjänsttaggen AzureFrontDoor.Backend innehåller de IP-adresser som Front Door använder för att komma åt dina ursprung. Du kan tillämpa denna tjänstetag när du konfigurerar säkerheten för dina ursprung.
• Tjänsttaggen AzureFrontDoor.Frontend innehåller de IP-adresser som klienterna använder för att nå Front Door. Du kan använda tjänsttaggen AzureFrontDoor.Frontend när du vill styra den utgående trafik som kan ansluta till tjänster bakom Azure Front Door.
• Tjänsttaggen AzureFrontDoor.FirstParty är reserverad för en utvald grupp med Microsoft-tjänster som finns på Azure Front Door.

Mer information om scenarier med Azure Front Door tjänsttaggar finns i tillgängliga tjänsttaggar. Om du vill hålla dig informerad och vidta lämpliga åtgärder vid ändringar av IP-adresser kan du utveckla automatisering för att regelbundet hämta de senaste IP-adresserna med hjälp av API:et för identifiering av tjänsttaggar eller JSON-filen.

En ursprungsgrupp är en samling ursprung som kan hantera liknande typer av begäranden. Du behöver en annan ursprungsgrupp för varje program eller arbetsbelastning som är olika.

I en ursprungsgrupp skapar du ett ursprung för varje server eller tjänst som kan hantera begäranden. Om ditt ursprung har en lastbalanserare, till exempel Azure Application Gateway, eller finns på en PaaS som har en lastbalanserare, har ursprungsgruppen bara ett ursprung. Ditt ursprung tar hand om redundans och belastningsutjämning mellan ursprung som Front Door inte ser.

Om du till exempel är värd för ett program på Azure App Service beror hur du konfigurerar Front Door på hur många programinstanser du har:

• Distribution i en region: Skapa en ursprungsgrupp. I ursprungsgruppen skapar du ett ursprung för App Service-appen. Din App Service-app kan skalas ut horisontellt över instanser, men Front Door ser en ursprungspunkt.
• Aktiv/passiv distribution i flera regioner: Skapa en ursprungsgrupp. I ursprungsgruppen skapar du ett ursprung för varje App Service app. Ange varje ursprungss prioritet så att huvudprogrammet har högre prioritet än säkerhetskopieringsprogrammet.
• Aktiv/aktiv distribution i flera regioner: Skapa en ursprungsgrupp. I ursprungsgruppen skapar du ett ursprung för varje App Service app. Ange att prioriteten för varje ursprung ska vara densamma. Ange vikten för varje ursprung för att styra hur många begäranden som går till det ursprunget.

Mer information finns i Origins och ursprungsgrupper i Azure Front Door.

Azure Front Door är en tjänst som ger snabb och tillförlitlig webbleverans för dina program. Den erbjuder funktioner som cachelagring, lastbalansering, säkerhet och routing. Du måste dock vara medveten om vissa tidsgränser och begränsningar som gäller för Azure Front Door. Dessa tidsgränser och gränser omfattar den maximala storleken på begäran, den maximala svarsstorleken, den maximala huvudstorleken, det maximala antalet rubriker, det maximala antalet regler och det maximala antalet ursprungsgrupper. Du hittar detaljerad information om dessa tidsgränser och begränsningar i dokumentationen Azure Front Door.

De flesta regeluppsättningar uppdaterar sina konfigurationer på mindre än 15 minuter. Regeln gäller så snart uppdateringen är klar.

Azure Front Door har en 5-sekunders timeout för att ta emot headers från en klient. Om klienten inte skickar headers inom 5 sekunder efter att en TCP/TLS-anslutning till Azure Front Door etablerats, avslutas anslutningen. Du kan inte konfigurera denna timeout.

Azure Front Door har en tidsgräns på 90 sekunder för HTTP keep-alive. Anslutningen avslutas om klienten inte skickar data på 90 sekunder, vilket är tidsgränsen för HTTP keep-alive för Azure Front Door. Du kan inte konfigurera det här tidsgränsvärdet.

Du kan inte använda samma domäner för mer än en Front Door-slutpunkt, eftersom Front Door måste särskilja vägen (kombination av protokoll + värd + sökväg) för varje begäran. Om du har duplicerade vägar över olika slutpunkter kan Azure Front Door inte bearbeta begäranden korrekt.

För närvarande erbjuder vi inte alternativet att flytta domäner från en slutpunkt till en annan utan avbrott i tjänsten. Du måste planera för viss stilleståndstid om du vill migrera dina domäner till en annan slutpunkt.

Azure Front Door Private Link är regionsoberogest. För lägst latens, välj den stödda Azure region närmast ditt ursprung när du aktiverar en Azure Front Door Private Link endpoint. Om ursprungsregionen inte stöds i listan över regioner som Front Door Private Link stöder väljer du nästa närmaste region. Trafiken flödar från klienten till Azure Front Door Private Link-slutpunkten i stödregionen, passerar sedan Microsofts stamnät till din ursprungsplats och upprätthåller privat anslutning. Denna konfiguration medför extra latens på grund av det extra nätverkshoppet mellan regioner. Du kan använda Azure-nätverkets tur-och-retur-latensstatistik för att avgöra den extra latensen som beror på att du väljer nästa närmaste region. När en ny region stöds kan du följa dessa instruktioner för att gradvis flytta trafiken till den nya regionen.

Azure Front Door är en plattform som distribuerar trafik över hela världen och kan skalas upp för att uppfylla programmets krav. Den använder Microsoft globala edge-nätverk för att tillhandahålla global lastbalansering, vilket gör att du kan flytta hela din applikation eller specifika mikrotjänster till olika regioner eller moln om ett fel inträffar.

För att undvika fel vid leverans av stora filer, se till att din ursprungsserver inkluderar Content-Range headern i svaret och att headervärdet matchar den faktiska storleken på svarskroppen.

Du hittar mer information om hur du konfigurerar ditt ursprung och Front Door för leverans av stora filer i Leverans av stora filer.

Domänfronting är en nätverksteknik som gör det möjligt för en angripare att dölja det faktiska målet för en skadlig begäran genom att använda ett annat domännamn i TLS-handskakningen och HTTP-värdhuvudet.

Azure Front Door (Standard, Premium och klassisk nivå) eller Azure CDN Standard från Microsoft (klassiska) resurser skapade efter den 8 november 2022 har domänfrontblockering aktiverat. Istället för att blockera en förfrågan med olika SNI- och värdheaders tillåter vi skillnaden om de två domänerna tillhör samma prenumeration och ingår i rutt- eller routningsreglerna. Kontroll av blockering av domänfronter startade den 22 januari 2024.

När Front Door blockerar en begäran på grund av ett matchningsfel:

• Klienten får ett HTTP-felkodssvar 421 Misdirected Request .
• Azure Front Door registrerar blocket i diagnostikloggarna under egenskapen Error Info med värdet SSLMismatchedSNI.

Mer information om domänfronting finns i Säkerställande av vår strategi för domänfronting inom Azure och Förbjudande av domänfronting på Azure Front Door och Azure CDN Standard från Microsoft (klassisk).

Front Door använder TLS 1.2 som lägsta version för alla profiler som skapats efter september 2019.

Du kan välja att använda TLS 1.2 eller 1.3 med Azure Front Door. Mer information finns i artikeln Azure Front Door end-to-end TLS.

Från och med den 15 augusti 2025 övergick DigiCert till en ny domänkontrollverifieringsplattform med öppen källkod (OSS) som utformats för att öka transparensen och ansvarsskyldigheten i domänvalideringsprocesser. DigiCert stöder inte längre det äldre CNAME Delegation DCV-arbetsflödet för validering av domänkontroll i de specificerade Azure-tjänsterna. Läs mer

Utfasningen påverkar tjänster som förlitar sig på CNAME-baserad validering för automatiserad certifikatutfärdande och förnyelse, inklusive:

• Azure Front Door (klassisk)
• Azure CDN från Microsoft (klassisk)

Azure Front Door (klassisk) och Azure CDN från Microsoft (klassisk):

• Från och med den 15 augusti 2025 finns det inte längre stöd för onboarding av nya domäner, skapande av nya profiler eller Azure-hanterade certifikat.
• Från och med den 14 april 2026 dras befintliga hanterade certifikat tillbaka. Alla befintliga hanterade certifikat migreras antingen av kunden eller AFD-teamet till Azure Front Door-standard eller premium. Använd Azure Front Door Standard eller Premium för hanterat certifikat.

I de flesta fall krävs ingen åtgärd. Efter att din profil har migrerats försöker Azure Front Door automatiskt rotera ditt hanterade certifikat om det är inom 45 dagar från utgångsdatum.

• Om din domän är CNAME-mappad till Azure Front Door och uppfyller CAA:s krav på post- och domänstatus, roteras certifikatet automatiskt. Det automatiska rotationsjobbet körs var 6:e till 8:e timme och tar cirka 24 till 48 timmar att slutföra. Om automatisk rotation misslyckas ändras domänvalideringstillståndet till 'Väntar validering', och du kan validera domänägandet igen för att manuellt trigga valideringen.
• Om din domän inte uppfyller dessa valideringskrav eller har HTTPS inaktiverat, ändras certifikatets status till Väntande återvalidering, och du måste validera domänägandet igen.

För att förnya certifikatet utan att vänta på automatisk rotation, validera domänägandet manuellt genom att använda någon av följande metoder:

• Lägga till den nödvändiga DNS-verifieringsposten efter steg 3 för domäner som väntar på validering
• Utlösa validering manuellt med PowerShell eller Azure CLI (RefreshValidation).

Du kan inte inaktivera Azure Front Door-resurser. Du kan bara ta bort dem. Variabelmätare som Data Transfer Out, Data Transfer In och Requests debiteras inte när det inte finns någon trafik, men grundavgiften tas ut även om det inte finns någon trafik. Grundavgiften tas ut tills profilen raderas. För Azure Front Door (klassiskt) debiteras WAF-policyer och regler oavsett status. Även om du inaktiverar en WAF-princip eller regel medför det fortfarande kostnader för dig.

Nej.

Nej.

Front Door stöder inte dynamisk komprimering för innehåll som är större än 8 MB. Om ursprunget redan komprimerar innehållet stöder Front Door att servera statiskt komprimerat innehåll över 8 MB så länge räckviddsförfrågan stöds och chunked transfer-kodning inte är aktiverad.

Nej.

Information om loggar och andra diagnostikfunktioner finns i Övervaka mått och loggar för Front Door.

Du kan lagra diagnostikloggar i sitt eget lagringskonto och välja hur länge de ska behållas. Alternativt kan du skicka diagnostiska loggar till Event Hubs eller Azure Monitor-loggar. Mer information finns i Azure Front Door diagnostik.

Om du vill komma åt granskningsloggarna för Azure Front Door måste du gå till portalen. Välj din Front Door från menysidan och välj Aktivitetslogg. Aktivitetsloggen ger dig register över dina Azure Front Door-operationer.

Du kan konfigurera aviseringar för Azure Front Door baserat på metrics eller loggar. På så sätt kan du övervaka prestanda och hälsa för dina frontend-värdar.

Information om hur du skapar aviseringar för Azure Front Door Standard och Premium finns i konfigurera aviseringar.

Relaterat innehåll

• Skapa en Azure Front Door-profil
• Azure Front Door-routningsarkitektur