Frontdoor di Azure domande frequenti

Questo articolo fornisce le risposte alle domande più frequenti sulle caratteristiche e funzionalità di Frontdoor di Azure. Se non è presente la risposta a una domanda specifica, è possibile contattare Microsoft tramite i seguenti canali (in ordine di escalation):

1. La sezione di feedback di questo articolo.

2. Frontdoor di Azure commenti e suggerimenti.

3. supporto tecnico Microsoft: Per creare una nuova richiesta di supporto, nel portale di Azure, nella scheda Help selezionare il pulsante Help + support e quindi selezionare Nuova richiesta di supporto.

Generale

Che cos'è Frontdoor di Azure?

Frontdoor di Azure è un servizio basato sul cloud che offre le applicazioni in modo più rapido e affidabile. Usa il bilanciamento del carico di livello 7 per distribuire il traffico tra più aree ed endpoint. Offre anche la funzione DSA (Dynamic Site Acceleration) per ottimizzare le prestazioni Web e il failover near real-time per garantire la disponibilità elevata. Frontdoor di Azure è un servizio completamente gestito, quindi non è necessario preoccuparsi del ridimensionamento o della manutenzione.

Qual è la differenza tra Frontdoor di Azure e gateway applicazione di Azure?

Frontdoor di Azure e gateway applicazione di Azure sono entrambi servizi di bilanciamento del carico per il traffico HTTP/HTTPS, ma hanno ambiti diversi. Frontdoor è un servizio globale in grado di distribuire le richieste tra aree, mentre Gateway applicazione è un servizio a livello di area in grado di bilanciare le richieste all'interno di un'area. Frontdoor di Azure funziona con unità di scala, cluster o unità di stamp, mentre gateway applicazione di Azure funziona con macchine virtuali, contenitori o altre risorse nella stessa unità di scala.

Quale tipo di risorse è attualmente compatibile come origine?

È possibile usare diversi tipi di origini per Frontdoor di Azure, ad esempio:

• Archiviazione (Azure BLOB, classico, siti Web statici)
• Servizio cloud
• Servizio app
• App Web statica
• Gestione API
• Gateway delle applicazioni
• Indirizzo IP pubblico
• Azure Spring Apps
• Istanze di Container
• App contenitore
• Qualunque nome host personalizzato con accesso pubblico.

L'origine deve avere un indirizzo IP pubblico o un nome host DNS risolvibile pubblicamente. È possibile combinare e associare back-end da zone, aree o anche al di fuori di Azure, purché siano accessibili pubblicamente.

In quali aree è possibile distribuire Frontdoor di Azure servizi?

Frontdoor di Azure non è limitato ad alcuna area Azure, ma opera a livello globale. L'unica posizione che scegli quando crei una Porta Frontale è quella del gruppo risorse, che determina dove sono memorizzati i metadati del gruppo risorsa. Il profilo Frontdoor è una risorsa globale e la relativa configurazione viene distribuita in tutte le posizioni perimetrali in tutto il mondo.

Quali sono le posizioni dei POP di Frontdoor di Azure (punti di presenza)?

Per l'elenco completo dei punti di presenza (POP) che forniscono il bilanciamento del carico globale e la distribuzione di contenuti per Frontdoor di Azure, vedere Frontdoor di Azure percorsi POP. Questo elenco viene aggiornato regolarmente mano a mano che vengono aggiunti o rimossi nuovi POP. È anche possibile usare l'API Azure Resource Manager per eseguire query sull'elenco corrente di POP a livello di codice.

In che modo Frontdoor di Azure alloca le risorse tra clienti diversi?

Frontdoor di Azure è un servizio che distribuisce l'applicazione a livello globale in più aree. Utilizza un'infrastruttura comune che tutti i suoi clienti condividono, ma puoi personalizzare il tuo profilo Front Door per configurare i requisiti specifici della tua applicazione. Le configurazioni di altri clienti non possono influire sulla propria configurazione di Frontdoor, che è isolata dalle loro.

In che modo Frontdoor di Azure determina l'ordine delle regole di routing?

Frontdoor non ordina i percorsi per l'applicazione Web. Sceglie, invece, il percorso più adatto alla richiesta. Per informazioni su come Frontdoor abbina le richieste ai percorsi, vedere Modalità di corrispondenza delle richieste con una regola di gestione.

Quali sono i passaggi per limitare l'accesso al back-end solo a Frontdoor di Azure?

Per garantire prestazioni ottimali delle funzionalità di Front Door, permette solo al traffico proveniente da Frontdoor di Azure di raggiungere la tua origine. Di conseguenza, le richieste non autorizzate o dannose incontrano i criteri di sicurezza e routing di Frontdoor e viene loro negato l'accesso. Per sapere come proteggere l'origine, consulta Proteggere il traffico verso le origini di Frontdoor di Azure.

Qual è il tempo stimato per la distribuzione di un Frontdoor di Azure? Frontdoor rimane operativo durante il processo di aggiornamento?

I tempi di propagazione della configurazione per una singola operazione di creazione, aggiornamento, cancellazione o WAF per i profili Frontdoor di Azure e CDN possono richiedere fino a 15 minuti per maggiore sicurezza. Una singola operazione di purga della cache viene completata entro 10 minuti. Modifiche consecutive possono estendere il tempo totale di dispiegamento a circa 30 minuti. Ogni aggiornamento di configurazione, inclusi aggiustamenti del set di regole, modifiche di instradamento, aggiornamenti di origine o dominio e modifiche WAF, viene trattato come un'operazione globale. Se invii ulteriori operazioni mentre la prima operazione è ancora in corso (entro la sua finestra di ~15 minuti), il sistema le mette in coda e inizia solo dopo il completamento dell'operazione precedente. In questo scenario, la prima operazione si completa entro i primi 15 minuti e le modifiche successive vengono elaborate nella finestra successiva. Sono in corso miglioramenti della piattaforma che ridurranno ulteriormente questo tempo.

Annotazioni

Gli aggiornamenti personalizzati dei certificati TLS/SSL potrebbero richiedere più tempo, fino a un'ora, per essere distribuiti a livello globale.

Inviare più richieste di eliminazione

Ogni richiesta di eliminazione può includere fino a 100 URL (combinazione di dominio e percorso). Il primo lotto viene elaborato e diventa effettivo entro circa 10 minuti.

Se hai più di 100 URL da eliminare, devi aspettare e verificare che il primo lotto sia stato completato prima di inviare il prossimo lotto. Se invii una nuova richiesta di purga prima che il lotto precedente sia completato, la richiesta viene respinta.

Esempio: Eliminare 256 URL

1. Inviare i primi 100 URL nella richiesta iniziale di eliminazione.
2. Aspetta circa 10 minuti e verifica che il primo lotto sia stato completato con successo.
3. Inviare gli URL successivi 101-200 nella seconda richiesta.
4. Aspetta circa 10 minuti che il secondo lotto sia completato.
5. Inviare gli URL rimanenti da 201 a 256 nella terza richiesta.

Gli aggiornamenti ai percorsi o ai gruppi di origine/pool back-end sono facili e non causano tempi di inattività (presupponendo che la nuova configurazione sia corretta). Anche gli aggiornamenti dei certificati vengono eseguiti in modo atomico, quindi non è previsto alcun tempo di inattività.

È possibile spostare i profili Frontdoor e la rete CDN tra gruppi di risorse o sottoscrizioni senza tempi di inattività?

• Puoi spostare i profili Front Door Standard/Premium e Rete CDN di Azure tra gruppi di risorse o abbonamenti senza alcun tempo di inattività. Per eseguire lo spostamento, seguire queste istruzioni.
• Frontdoor Classico non supporta lo spostamento tra gruppi di risorse o sottoscrizioni. È invece possibile eseguire la migrazione dal profilo Classico a Standard/Premium e quindi eseguire lo spostamento. - Se associ WAF a Front Door Standard o Premium, l'operazione di spostamento fallisce. Devi prima dissociare le politiche WAF, quindi spostarle e poi riassociarle.

Caratteristiche e protocolli

Quali funzionalità supportano Frontdoor di Azure?

Frontdoor di Azure offre molti vantaggi per le tue applicazioni web, come l'accelerazione dinamica del sito (DSA), che migliora le prestazioni e l'esperienza utente dei tuoi siti. Frontdoor di Azure gestisce anche lo scarico TLS/SSL e TLS end-to-end, migliorando così la sicurezza e la crittografia del traffico web. Inoltre, Frontdoor di Azure offre Web application firewall, affinità di sessione basata su cookie, routing basato su percorsi URL, certificati gratuiti, gestione di più domini e altro ancora. Per saperne di più sulle funzionalità e sulle capacità di Frontdoor di Azure, vedere il confronto livello.

Quali protocolli supportano Frontdoor di Azure?

Frontdoor di Azure supporta HTTP, HTTPS e HTTP/2.

In che modo Frontdoor di Azure supporta HTTP/2?

Frontdoor di Azure supporta il protocollo HTTP/2 per le connessioni client. La comunicazione del pool back-end, tuttavia, usa il protocollo HTTP/1.1. Il supporto per il protocollo HTTP/2 è attivo per impostazione predefinita.

Frontdoor di Azure supporta il gRPC?

No. Attualmente, Frontdoor di Azure supporta solo HTTP/1.1 dal bordo all'origine. Per il funzionamento di gRPC, è necessario HTTP/2.

Frontdoor di Azure supporta il reindirizzamento da HTTP a HTTPS?

È possibile reindirizzare componenti host, percorso e stringa di query di un URL con Frontdoor di Azure. Per imparare a configurare il reindirizzamento URL, vedi URL reindirizzamento.

Frontdoor fornisce dati di telemetria per mostrare quali norme del motore delle regole vengono elaborate da Frontdoor per ogni richiesta?

Sì. Consulta la MatchedRulesSetName proprietà nella sezione Log di accesso.

Frontdoor può fornire protezione dagli attacchi DDoS HTTP/2?

Sì. Per altre informazioni, vedere Microsoft risposta agli attacchi DDoS contro HTTP/2.

È possibile forzare il traffico da un paese o un'area geografica per usare un POP specifico Frontdoor di Azure in un altro paese o area geografica?

No. Frontdoor di Azure non può forzare il traffico client verso un POP specifico. Le richieste vengono instradate alla location perimetrale disponibile più vicina per garantire prestazioni e affidabilità. Se è necessario limitare l'accesso in base all'area geografica, usare regole personalizzate Web application firewall di Azure (WAF) con condizioni GeoMatch. Questo approccio consente o blocca le richieste in base al paese/area geografica client, ma non reindirizza tali client a un POP diverso in un altro paese o area geografica. Ad esempio, se si blocca il paese o l'area geografica A, le richieste dei client nel paese/area A vengono bloccate indipendentemente dal POP che li avrebbe serviti. Per altre informazioni, vedere Geo-filtering in Azure WAF per Frontdoor di Azure.

Frontdoor di Azure preserva le intestazioni “x-forwarded-for”?

Frontdoor di Azure supporta le intestazioni X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. Queste intestazioni consentono a Frontdoor di identificare il protocollo e l'IP client originali. Se X-Forwarded-For è già presente, Frontdoor aggiunge l'indirizzo IP del socket client alla fine dell'elenco. In caso contrario, crea l'intestazione con l'indirizzo IP del socket client come valore. Per X-Forwarded-Host e X-Forwarded-Proto, Frontdoor sostituisce i valori esistenti con i propri.

Per altre informazioni, vedere Intestazioni HTTP supportate da Frontdoor.

Frontdoor di Azure ha la possibilità di bilanciare il carico o instradare il traffico all'interno di una rete virtuale?

Per usare Frontdoor di Azure livello Standard o (classico), è necessario un indirizzo IP pubblico o un nome DNS che può essere risolto pubblicamente. Questo requisito di un indirizzo IP pubblico o di un nome DNS che può essere risolto pubblicamente consente a Frontdoor di Azure di instradare il traffico alle risorse back-end. È possibile usare risorse Azure come Application Gateway o Azure Load Balancer per instradare il traffico verso le risorse in una rete virtuale. Se si usa il livello Premium di Frontdoor, è possibile usare collegamento privato per connettersi alle origini dietro un servizio di bilanciamento del carico interno con un endpoint privato. Per altre informazioni, vedere Secure origins con collegamento privato.

È possibile usare collegamento privato per connettere Frontdoor di Azure ad Azure Key Vault?

No. Per la sicurezza, Frontdoor di Azure supporta solo l'autenticazione gestita basata su identità quando si accede ai certificati in Key Vault. Per altre informazioni, vedere Usare le identità gestite in Frontdoor di Azure.

Frontdoor di Azure supporta l'identità gestita con Hub eventi di Azure?

No. Frontdoor di Azure attualmente non supporta l'integrazione delle identità gestite con Hub eventi di Azure.

Frontdoor di Azure supporta pagine di errore personalizzate?

No. Frontdoor di Azure attualmente non supporta pagine di errore personalizzate.

Distribuzione di Frontdoor con altri servizi

Quando è necessario distribuire Gateway applicazione dietro Frontdoor?

Gateway applicazione dietro Frontdoor è utile in queste situazioni:

• Si desidera bilanciare il traffico non solo a livello globale, ma anche all'interno della rete virtuale. Frontdoor può eseguire solo il bilanciamento del carico basato sul percorso a livello globale, ma con Gateway applicazione è possibile anche all'interno della rete virtuale.
• È necessario lo svuotamento della connessione, non supportato da Frontdoor. Gateway applicazione può abilitare lo svuotamento della connessione per macchine virtuali o contenitori.
• Si desidera eseguire l'offload di tutta l'elaborazione TLS/SSL e usare le richieste HTTP solo nella propria rete virtuale. Con Gateway applicazione dietro Frontdoor è possibile ottenere questa configurazione.
• Si desidera usare l'affinità di sessione sia a livello di area che a livello di server. Frontdoor può inviare il traffico da una sessione utente allo stesso back-end in un'area, ma il gateway applicazione può inviarlo allo stesso server nel back-end.

È possibile distribuire un'altra rete CDN da un fornitore esterno dietro o davanti Frontdoor?

Concatenare due CDN generalmente non è un approccio consigliato. Può funzionare, ma comporta i seguenti contro:

1. L'accelerazione dell'ultimo miglio di una CDN funziona mantenendo il flusso di connessione con l'origine e trovando il percorso ottimale verso l'origine per ottenere i migliori risultati. Il concatenamento di due reti CDN in genere nega alcuni dei vantaggi dell'accelerazione dell'ultimo miglio.
2. I controlli di sicurezza diventano meno efficaci nella seconda rete CDN. Qualsiasi ACL basato su IP client non funziona sulla seconda CDN perché la seconda CDN vede il nodo di uscita della prima CDN come IP Client. Il contenuto del payload continua comunque a essere ispezionato.
3. Molte organizzazioni non sono in grado di gestire la complessità della risoluzione dei problemi di due reti CDN concatenate e quando si verifica un problema diventa difficile capire quale rete CDN sta riscontrando il problema.

È possibile distribuire Azure Load Balancer dietro Frontdoor?

Per usare Frontdoor di Azure, è necessario avere un indirizzo VIP pubblico o un nome DNS accessibile pubblicamente. Frontdoor di Azure usa l'indirizzo IP pubblico per instradare il traffico all'origine. Uno scenario comune consiste nel distribuire un Azure Load Balancer dietro Frontdoor. È anche possibile usare collegamento privato con Frontdoor di Azure Premium per connettersi a un servizio di bilanciamento del carico interno. Per ulteriori informazioni, vedere abilitare collegamento privato con bilanciatore di carico interno.

È possibile configurare Rete CDN di Azure dietro il profilo/endpoint Frontdoor o viceversa?

Frontdoor di Azure e Rete CDN di Azure sono due servizi che offrono un recapito Web rapido e affidabile per le applicazioni. Tuttavia, non sono compatibili tra loro, perché condividono la stessa rete di siti perimetrali di Azure per distribuire contenuti agli utenti. Questa rete condivisa causa conflitti tra i criteri di routing e di memorizzazione nella cache. Pertanto, è necessario scegliere Frontdoor di Azure o Rete CDN di Azure per l'applicazione, a seconda dei requisiti di prestazioni e sicurezza.

È possibile configurare un profilo o un endpoint di Frontdoor di Azure dietro un altro profilo o endpoint di Front Door, o viceversa?

Il fatto che entrambi i profili/endpoint utilizzino lo stesso Azure edge POP per gestire le richieste in arrivo crea una limitazione che impedisce di annidare un profilo/endpoint Frontdoor di Azure dietro un altro. Questa configurazione causerebbe conflitti di routing e problemi di prestazioni. Quindi, se devi usare più profili/endpoint per le tue applicazioni, dovresti assicurarti che i tuoi profili/endpoint di Frontdoor di Azure non siano concatenati insieme.

Indirizzi IP e tag di servizio di Frontdoor

Quale metodo di risoluzione e routing dei nomi viene usato da Frontdoor di Azure?

Frontdoor di Azure è in corso il passaggio da Anycast al routing unicast per la risoluzione dei nomi e il routing delle richieste alla posizione ottimale PoP. Questo cambiamento è avvenuto tra marzo e aprile 2026. Una volta completato il cambio, Unicast sostituisce Anycast per l'intera infrastruttura della porta principale.

In che modo Frontdoor di Azure usa il routing unicast?

Una richiesta di risoluzione dei nomi per un'origine dietro Frontdoor di Azure viene inserita nell'endpoint di Gestione traffico di Frontdoor. I profili di Gestione traffico di Front Door utilizzano numerosi segnali di integrità e disponibilità provenienti dai PoPs in tutto il mondo. Sulla base di questi segnali, viene restituito l'indirizzo IP unicast del Front Door PoP ottimale. La richiesta viene quindi effettuata direttamente all'indirizzo IP restituito, che segue l'architettura di routing di Frontdoor per restituire la risposta all'utente o all'applicazione.

Quali sono i tag del servizio di rete supportati da Frontdoor?

Frontdoor di Azure usa tre tag di servizio per gestire il traffico tra i client e le origini:

• Il tag del servizio AzureFrontDoor.Backend contiene gli indirizzi IP usati da Frontdoor di Azure per accedere alle origini. È possibile applicare questo tag del servizio quando si configura la sicurezza per le origini.
• Il tag del servizio AzureFrontDoor.Frontend contiene gli indirizzi IP usati dai client per raggiungere Frontdoor. È possibile applicare il tag del servizio AzureFrontDoor.Frontend quando si vuole controllare il traffico in uscita che può connettersi ai servizi dietro Frontdoor di Azure.
• Il tag di servizio AzureFrontDoor.FirstParty è riservato per un gruppo selezionato di servizi Microsoft ospitato in Frontdoor di Azure.

Per ulteriori informazioni sugli scenari relativi ai tag di servizio Frontdoor di Azure, vedere i tag di servizio disponibili. Per rimanere informati e intraprendere le azioni appropriate durante eventuali modifiche agli indirizzi IP, sviluppare l'automazione per recuperare regolarmente gli indirizzi IP più recenti utilizzando l'API Service Tag Discovery o il file JSON.

Configurazione

Quali sono le procedure consigliate per la creazione di origini e gruppi di origine per Frontdoor di Azure?

Un gruppo di origine è una raccolta di origini in grado di gestire tipi simili di richieste. È necessario un gruppo di origine diverso per ogni applicazione o carico di lavoro diverso.

In un gruppo di origine si crea un'origine per ogni server o servizio in grado di gestire le richieste. Se l'origine ha un servizio di bilanciamento del carico, ad esempio gateway applicazione di Azure, o è ospitato su un PaaS che ha un servizio di bilanciamento del carico, il gruppo di origine ha una sola origine. L'origine si occupa del failover e del bilanciamento del carico tra origini che Frontdoor non vede.

Ad esempio, se si ospita un'applicazione in Servizio app di Azure, la configurazione di Frontdoor dipende dal numero di istanze dell'applicazione disponibili:

• Distribuzione in una singola area: creare un solo gruppo di origine. In tale gruppo di origine, creare una sola origine per l'app Servizio app di Azure. L'app Servizio app di Azure potrebbe aumentare il numero di ruoli di lavoro, ma Frontdoor vede una sola origine.
• Distribuzione attiva/passiva in più aree: creare un solo gruppo di origine. In tale gruppo di origine, creare un’origine per ogni app Servizio app di Azure. Impostare la priorità di ogni origine in modo che l'applicazione principale abbia una priorità più alta rispetto all'applicazione di backup.
• Distribuzione attiva/attiva in più aree: creare un solo gruppo di origine. In tale gruppo di origine, creare un’origine per ogni app Servizio app di Azure. Impostare la stessa priorità per ogni origine. Impostare il peso di ogni origine per controllare il numero di richieste inviate a tale origine.

Per altre informazioni, vedere Origini e gruppi di origini in Frontdoor di Azure.

Quali sono i valori predefiniti e massimi per i timeout e i limiti di Frontdoor di Azure?

Frontdoor di Azure è un servizio che offre un recapito Web rapido e affidabile per le applicazioni. Offre funzionalità come la memorizzazione nella cache, il bilanciamento del carico, la sicurezza e il routing. Tuttavia, è necessario tenere presente alcuni timeout e limiti che si applicano alle Frontdoor di Azure. Questi timeout e limiti includono le dimensioni massime della richiesta, le dimensioni massime della risposta, le dimensioni massime dell'intestazione, il numero massimo di intestazioni, il numero massimo di regole e il numero massimo di gruppi di origine. Per informazioni dettagliate su questi timeout e limiti, vedere la documentazione di Frontdoor di Azure.

Quanto tempo impiega Frontdoor di Azure per applicare una nuova regola aggiunta al Rules Engine di Front Door?

La maggior parte dei set di regole aggiorna le configurazioni in meno di 15 minuti. La regola si applica non appena l'aggiornamento termina.

Qual è il valore del timeout dell'intestazione dal client a Frontdoor di Azure?

Frontdoor di Azure ha un timeout di 5 secondi per la ricezione delle intestazioni dal client. La connessione viene terminata se il client non invia intestazioni entro 5 secondi a Frontdoor di Azure dopo aver stabilito la connessione TCP/TLS. Il valore di questo timeout non può essere configurato.

Qual è il valore del timeout keep-alive HTTP per Frontdoor di Azure?

Frontdoor di Azure ha un timeout keep-alive HTTP di 90 secondi. La connessione viene terminata se il client non invia dati per 90 secondi, ovvero il timeout keep-alive HTTP per Frontdoor di Azure. Il valore di questo timeout non può essere configurato.

È possibile usare lo stesso dominio per due endpoint Frontdoor diversi?

Non è possibile usare gli stessi domini per più di un endpoint Frontdoor perché Frontdoor deve distinguere il percorso (protocollo + host + combinazione percorso) per ogni richiesta. Se sono presenti route duplicate tra endpoint diversi, Frontdoor di Azure non è in grado di elaborare correttamente le richieste.

È possibile eseguire la migrazione di un dominio da un endpoint Frontdoor a un altro endpoint Frontdoor senza tempi di inattività?

Al momento, non è possibile spostare i domini da un endpoint a un altro senza interruzioni nel servizio. È necessario pianificare alcuni tempi di inattività se si vuole eseguire la migrazione dei domini a un endpoint diverso.

L'integrazione Privatelink di Frontdoor di Azure non è supportata nell'area in cui si trova l'origine. Cosa faccio?

La funzionalità Frontdoor di Azure collegamento privato è indipendente dall'area, ma per la migliore latenza è consigliabile scegliere sempre un'area Azure più vicina all'origine quando si sceglie di abilitare Frontdoor di Azure collegamento privato endpoint. Se l'area dell'origine non è supportata nell'elenco delle aree supportate da Frontdoor collegamento privato, selezionare l'area più vicina successiva. Il traffico passa dal client all'endpoint Frontdoor di Azure collegamento privato nell'area supportata, quindi attraversa la rete backbone Microsoft all'origine, mantenendo la connettività privata. Tenere presente che questa configurazione introduce una latenza aggiuntiva a causa dell'hop di rete aggiuntivo tra aree. È possibile utilizzare le statistiche di latenza di rete round-trip di Azure per determinare la latenza aggiuntiva dovuta alla scelta della regione successiva più vicina. Appena una nuova area geografica è supportata, è possibile seguire queste istruzioni per spostare gradualmente il traffico verso la nuova area geografica.

Prestazioni

In che modo Frontdoor di Azure garantisce un'alta disponibilità e scalabilità per i suoi servizi?

Frontdoor di Azure è una piattaforma che distribuisce il traffico in tutto il mondo e può aumentare le prestazioni per soddisfare le esigenze dell'applicazione. Usa la rete perimetrale globale di Microsoft per offrire funzionalità di bilanciamento del carico globale che consentono di spostare l'intera applicazione o microservizi specifici in aree o cloud diversi in caso di errore.

Quali sono le condizioni per la memorizzazione nella cache delle risposte con intervalli dall'origine?

Per evitare errori durante il recapito di file di grandi dimensioni, accertarsi che il server di origine includa l'intestazione Content-Range nella risposta e che il valore dell'intestazione corrisponda alle dimensioni effettive del corpo della risposta.

Per altre informazioni su come configurare l'origine e Frontdoor per il recapito di file di grandi dimensioni, vedere Recapito di file di grandi dimensioni.

Configurazione TLS

In che modo Frontdoor di Azure blocca il fronting del dominio?

Il fronting del dominio è una tecnica di rete che consente a un utente malintenzionato di nascondere la destinazione effettiva di una richiesta dannosa usando un nome di dominio diverso nell'handshake TLS e nell'intestazione host HTTP.

Frontdoor di Azure (livello Standard, Premium e Classico) o Rete CDN di Azure Standard di Microsoft (versione classica) creati dopo l'8 novembre 2022 hanno l'opzione di blocco del fronting del dominio abilitata. Invece di bloccare una richiesta con intestazioni SNI e host non corrispondenti, si consente la discrepanza se i due domini appartengono alla stessa sottoscrizione e sono inclusi nelle regole di gestione/percorsi. L'imposizione del blocco del fronting del dominio inizierà il 22 gennaio 2024 per tutti i domini esistenti. La propagazione dell'imposizione in tutte le aree può richiedere fino a due settimane.

Quando Frontdoor blocca una richiesta a causa di una mancata corrispondenza:

• Il client riceve una risposta con codice di errore HTTP 421 Misdirected Request.
• Frontdoor di Azure registra il blocco nei log di diagnostica nella proprietà Error Info con il valore SSSLMismatchedSNI.

Per ulteriori informazioni sul fronting del dominio, vedere Proteggere il nostro approccio al fronting del dominio in Azure e Proibire il fronting del dominio su Frontdoor di Azure e Rete CDN di Azure Standard di Microsoft (classico).

Quali versioni di TLS sono supportate con Frontdoor di Azure?

Frontdoor usa TLS 1.2 come versione minima per tutti i profili creati dopo settembre 2019.

È possibile scegliere di usare TLS 1.2 o 1.3 con Frontdoor di Azure. Per altre informazioni, vedere l'articolo Frontdoor di Azure end-to-end TLS.

Gestione dei certificati e deprecazione del workflow DCV di DigiCert

Che cosa accade con il flusso di lavoro DCV della delega CNAME di DigiCert?

A partire dal 15 agosto 2025, DigiCert è passato a una nuova piattaforma di convalida del controllo di dominio (OSS) software open source progettata per migliorare la trasparenza e la responsabilità nei processi di convalida del dominio. DigiCert non supporta più il flusso di lavoro legado CNAME Delegation DCV per la validazione del controllo del dominio nei servizi Azure specificati. Ulteriori informazioni

Quali livelli di Frontdoor di Azure sono interessati da questo cambiamento?

La deprecazione influisce sui servizi che si basano sulla convalida basata su CNAME per il rilascio e il rinnovo automatizzati dei certificati, tra cui:

• Frontdoor di Azure (versione classica)
• Rete CDN di Azure da Microsoft (versione classica)

Qual è lo stato corrente?

Frontdoor di Azure (versione classica) e Rete CDN di Azure da Microsoft (versione classica):

• A partire dal 15 agosto 2025, non è più disponibile il supporto per l'onboarding di nuovi domini, la creazione di nuovi profili o i certificati gestiti da Azure.
• A partire dal 14 aprile 2026, i certificati gestiti esistenti vengono ritirati. Tutti i certificati gestiti esistenti vengono migrati dal cliente o dal team AFD allo standard Frontdoor di Azure o premium. Usare Frontdoor di Azure Standard o Premium per il certificato gestito.

È necessario eseguire qualsiasi azione per rinnovare il certificato gestito dopo la migrazione?

Nella maggior parte dei casi non è necessaria alcuna azione. Dopo la migrazione del profilo, Frontdoor di Azure tenta automaticamente di ruotare il certificato gestito se è entro 45 giorni dalla scadenza.

• Se il dominio è mappato tramite CNAME ad Frontdoor di Azure e soddisfa i requisiti per lo stato del dominio e i record CAA, il certificato viene ruotato automaticamente. Il processo di rotazione automatica viene eseguito ogni 6-8 ore e il completamento richiede circa 24-48 ore. Se l'autorotazione non riesce, lo stato di convalida del dominio passa a "Convalida in sospeso" ed è possibile riconvalidare la proprietà del dominio per attivare manualmente la convalida.
• Se il tuo dominio non soddisfa i requisiti di validazione sopra menzionati o ha HTTPS disabilitato, lo stato del certificato passa a Pending revalidation e devi rivalidare la proprietà del dominio.

Se non si vuole attendere la rotazione automatica, è possibile riconvalidare manualmente la proprietà del dominio per il rinnovo:

• Aggiunta del record di convalida DNS necessario dopo il passaggio 3 per i domini in attesa di convalida
• Oppure attivare la convalida manualmente tramite PowerShell o interfaccia della riga di comando di Azure (RefreshValidation).

Fatturazione

Ricevo una fattura per le risorse di Frontdoor di Azure che sono disabilitate?

Non puoi disabilitare le risorse di Frontdoor di Azure. Puoi solo cancellarli. I contatori variabili come Data Transfer Out, Data Transfer In e Request non vengono addebitati quando non c'è traffico, ma la tariffa base viene addebitata anche se non c'è traffico. La tariffa base viene applicata fino alla cancellazione del profilo. Per Frontdoor classico, i criteri e le regole WAF vengono addebitati indipendentemente dal relativo stato. Anche se si disabilita un criterio o una regola WAF, vengono comunque addebitati i costi.

Memorizzazione nella cache

È possibile utilizzare l'intestazione della richiesta HTTP come chiave della cache?

No.

Frontdoor supporta ETag?

No.

È possibile supportare la compressione per file di dimensioni superiori a 8 MB?

Front Door non supporta la compressione dinamica per contenuti superiori a 8 MB. Tuttavia, se l'origine già comprime il contenuto, Front Door supporta la diffusione di contenuti compressi statici su 8 MB purché la richiesta di intervallo sia supportata e la codifica a trasferimento a blocchi non sia abilitata.

Frontdoor supporta l'impostazione dell'intestazione di autorizzazione nella richiesta HTTP se la memorizzazione nella cache è abilitata?

No.

Diagnostica e registrazione

Quali sono le metriche e i log forniti Frontdoor di Azure?

Per informazioni sui log e altre funzionalità di diagnostica, vedere Monitoraggio di metriche e log in Frontdoor di Azure.

Per quanto tempo vengono conservati i log di diagnostica?

È possibile archiviare i log di diagnostica nel proprio account di archiviazione e scegliere per quanto tempo mantenerli. In alternativa, puoi inviare i log diagnostici agli Event Hub o ai log di Monitoraggio di Azure. Per altre informazioni, vedere Frontdoor di Azure diagnostics.

Quali sono i passaggi per accedere ai log di controllo per Frontdoor di Azure?

Per accedere ai log di controllo di Frontdoor di Azure, è necessario visitare il portale. Seleziona la tua porta d'ingresso dalla pagina del menu e seleziona Registro attività. Il Log Attività fornisce i record delle operazioni di Frontdoor di Azure.

Come è possibile configurare gli avvisi per Frontdoor di Azure?

È possibile configurare avvisi per Frontdoor di Azure in base a metriche o log. In questo modo, è possibile monitorare le prestazioni e l'integrità degli host front-end.

Per informazioni su come creare avvisi per Frontdoor di Azure Standard e Premium, vedere configurare gli avvisi.

Contenuto correlato

• Creare un profilo frontdoor di Azure
• Architettura di routing di Frontdoor di Azure

Questo articolo fornisce le risposte alle domande più frequenti sulle caratteristiche e funzionalità di Frontdoor di Azure. Se non è presente la risposta a una domanda specifica, è possibile contattare Microsoft tramite i seguenti canali (in ordine di escalation):

1. La sezione di feedback di questo articolo.

2. Frontdoor di Azure commenti e suggerimenti.

3. supporto tecnico Microsoft: Per creare una nuova richiesta di supporto, nel portale di Azure, nella scheda Help selezionare il pulsante Help + support e quindi selezionare Nuova richiesta di supporto.

Frontdoor di Azure è un servizio basato sul cloud che offre le applicazioni in modo più rapido e affidabile. Usa il bilanciamento del carico di livello 7 per distribuire il traffico tra più aree ed endpoint. Offre anche la funzione DSA (Dynamic Site Acceleration) per ottimizzare le prestazioni Web e il failover near real-time per garantire la disponibilità elevata. Frontdoor di Azure è un servizio completamente gestito, quindi non è necessario preoccuparsi del ridimensionamento o della manutenzione.

Frontdoor di Azure e gateway applicazione di Azure sono entrambi servizi di bilanciamento del carico per il traffico HTTP/HTTPS, ma hanno ambiti diversi. Frontdoor è un servizio globale in grado di distribuire le richieste tra aree, mentre Gateway applicazione è un servizio a livello di area in grado di bilanciare le richieste all'interno di un'area. Frontdoor di Azure funziona con unità di scala, cluster o unità di stamp, mentre gateway applicazione di Azure funziona con macchine virtuali, contenitori o altre risorse nella stessa unità di scala.

È possibile usare diversi tipi di origini per Frontdoor di Azure, ad esempio:

• Archiviazione (Azure BLOB, classico, siti Web statici)
• Servizio cloud
• Servizio app
• App Web statica
• Gestione API
• Gateway delle applicazioni
• Indirizzo IP pubblico
• Azure Spring Apps
• Istanze di Container
• App contenitore
• Qualunque nome host personalizzato con accesso pubblico.

L'origine deve avere un indirizzo IP pubblico o un nome host DNS risolvibile pubblicamente. È possibile combinare e associare back-end da zone, aree o anche al di fuori di Azure, purché siano accessibili pubblicamente.

Frontdoor di Azure non è limitato ad alcuna area Azure, ma opera a livello globale. L'unica posizione che scegli quando crei una Porta Frontale è quella del gruppo risorse, che determina dove sono memorizzati i metadati del gruppo risorsa. Il profilo Frontdoor è una risorsa globale e la relativa configurazione viene distribuita in tutte le posizioni perimetrali in tutto il mondo.

Per l'elenco completo dei punti di presenza (POP) che forniscono il bilanciamento del carico globale e la distribuzione di contenuti per Frontdoor di Azure, vedere Frontdoor di Azure percorsi POP. Questo elenco viene aggiornato regolarmente mano a mano che vengono aggiunti o rimossi nuovi POP. È anche possibile usare l'API Azure Resource Manager per eseguire query sull'elenco corrente di POP a livello di codice.

Frontdoor di Azure è un servizio che distribuisce l'applicazione a livello globale in più aree. Utilizza un'infrastruttura comune che tutti i suoi clienti condividono, ma puoi personalizzare il tuo profilo Front Door per configurare i requisiti specifici della tua applicazione. Le configurazioni di altri clienti non possono influire sulla propria configurazione di Frontdoor, che è isolata dalle loro.

Frontdoor non ordina i percorsi per l'applicazione Web. Sceglie, invece, il percorso più adatto alla richiesta. Per informazioni su come Frontdoor abbina le richieste ai percorsi, vedere Modalità di corrispondenza delle richieste con una regola di gestione.

Per garantire prestazioni ottimali delle funzionalità di Front Door, permette solo al traffico proveniente da Frontdoor di Azure di raggiungere la tua origine. Di conseguenza, le richieste non autorizzate o dannose incontrano i criteri di sicurezza e routing di Frontdoor e viene loro negato l'accesso. Per sapere come proteggere l'origine, consulta Proteggere il traffico verso le origini di Frontdoor di Azure.

I tempi di propagazione della configurazione per una singola operazione di creazione, aggiornamento, cancellazione o WAF per i profili Frontdoor di Azure e CDN possono richiedere fino a 15 minuti per maggiore sicurezza. Una singola operazione di purga della cache viene completata entro 10 minuti. Modifiche consecutive possono estendere il tempo totale di dispiegamento a circa 30 minuti. Ogni aggiornamento di configurazione, inclusi aggiustamenti del set di regole, modifiche di instradamento, aggiornamenti di origine o dominio e modifiche WAF, viene trattato come un'operazione globale. Se invii ulteriori operazioni mentre la prima operazione è ancora in corso (entro la sua finestra di ~15 minuti), il sistema le mette in coda e inizia solo dopo il completamento dell'operazione precedente. In questo scenario, la prima operazione si completa entro i primi 15 minuti e le modifiche successive vengono elaborate nella finestra successiva. Sono in corso miglioramenti della piattaforma che ridurranno ulteriormente questo tempo.

Annotazioni

Gli aggiornamenti personalizzati dei certificati TLS/SSL potrebbero richiedere più tempo, fino a un'ora, per essere distribuiti a livello globale.

Inviare più richieste di eliminazione

Ogni richiesta di eliminazione può includere fino a 100 URL (combinazione di dominio e percorso). Il primo lotto viene elaborato e diventa effettivo entro circa 10 minuti.

Se hai più di 100 URL da eliminare, devi aspettare e verificare che il primo lotto sia stato completato prima di inviare il prossimo lotto. Se invii una nuova richiesta di purga prima che il lotto precedente sia completato, la richiesta viene respinta.

Esempio: Eliminare 256 URL

1. Inviare i primi 100 URL nella richiesta iniziale di eliminazione.
2. Aspetta circa 10 minuti e verifica che il primo lotto sia stato completato con successo.
3. Inviare gli URL successivi 101-200 nella seconda richiesta.
4. Aspetta circa 10 minuti che il secondo lotto sia completato.
5. Inviare gli URL rimanenti da 201 a 256 nella terza richiesta.

Gli aggiornamenti ai percorsi o ai gruppi di origine/pool back-end sono facili e non causano tempi di inattività (presupponendo che la nuova configurazione sia corretta). Anche gli aggiornamenti dei certificati vengono eseguiti in modo atomico, quindi non è previsto alcun tempo di inattività.

• Puoi spostare i profili Front Door Standard/Premium e Rete CDN di Azure tra gruppi di risorse o abbonamenti senza alcun tempo di inattività. Per eseguire lo spostamento, seguire queste istruzioni.
• Frontdoor Classico non supporta lo spostamento tra gruppi di risorse o sottoscrizioni. È invece possibile eseguire la migrazione dal profilo Classico a Standard/Premium e quindi eseguire lo spostamento. - Se associ WAF a Front Door Standard o Premium, l'operazione di spostamento fallisce. Devi prima dissociare le politiche WAF, quindi spostarle e poi riassociarle.

Frontdoor di Azure offre molti vantaggi per le tue applicazioni web, come l'accelerazione dinamica del sito (DSA), che migliora le prestazioni e l'esperienza utente dei tuoi siti. Frontdoor di Azure gestisce anche lo scarico TLS/SSL e TLS end-to-end, migliorando così la sicurezza e la crittografia del traffico web. Inoltre, Frontdoor di Azure offre Web application firewall, affinità di sessione basata su cookie, routing basato su percorsi URL, certificati gratuiti, gestione di più domini e altro ancora. Per saperne di più sulle funzionalità e sulle capacità di Frontdoor di Azure, vedere il confronto livello.

Frontdoor di Azure supporta HTTP, HTTPS e HTTP/2.

Frontdoor di Azure supporta il protocollo HTTP/2 per le connessioni client. La comunicazione del pool back-end, tuttavia, usa il protocollo HTTP/1.1. Il supporto per il protocollo HTTP/2 è attivo per impostazione predefinita.

No. Attualmente, Frontdoor di Azure supporta solo HTTP/1.1 dal bordo all'origine. Per il funzionamento di gRPC, è necessario HTTP/2.

È possibile reindirizzare componenti host, percorso e stringa di query di un URL con Frontdoor di Azure. Per imparare a configurare il reindirizzamento URL, vedi URL reindirizzamento.

Sì. Consulta la MatchedRulesSetName proprietà nella sezione Log di accesso.

Sì. Per altre informazioni, vedere Microsoft risposta agli attacchi DDoS contro HTTP/2.

No. Frontdoor di Azure non può forzare il traffico client verso un POP specifico. Le richieste vengono instradate alla location perimetrale disponibile più vicina per garantire prestazioni e affidabilità. Se è necessario limitare l'accesso in base all'area geografica, usare regole personalizzate Web application firewall di Azure (WAF) con condizioni GeoMatch. Questo approccio consente o blocca le richieste in base al paese/area geografica client, ma non reindirizza tali client a un POP diverso in un altro paese o area geografica. Ad esempio, se si blocca il paese o l'area geografica A, le richieste dei client nel paese/area A vengono bloccate indipendentemente dal POP che li avrebbe serviti. Per altre informazioni, vedere Geo-filtering in Azure WAF per Frontdoor di Azure.

Frontdoor di Azure supporta le intestazioni X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. Queste intestazioni consentono a Frontdoor di identificare il protocollo e l'IP client originali. Se X-Forwarded-For è già presente, Frontdoor aggiunge l'indirizzo IP del socket client alla fine dell'elenco. In caso contrario, crea l'intestazione con l'indirizzo IP del socket client come valore. Per X-Forwarded-Host e X-Forwarded-Proto, Frontdoor sostituisce i valori esistenti con i propri.

Per altre informazioni, vedere Intestazioni HTTP supportate da Frontdoor.

Per usare Frontdoor di Azure livello Standard o (classico), è necessario un indirizzo IP pubblico o un nome DNS che può essere risolto pubblicamente. Questo requisito di un indirizzo IP pubblico o di un nome DNS che può essere risolto pubblicamente consente a Frontdoor di Azure di instradare il traffico alle risorse back-end. È possibile usare risorse Azure come Application Gateway o Azure Load Balancer per instradare il traffico verso le risorse in una rete virtuale. Se si usa il livello Premium di Frontdoor, è possibile usare collegamento privato per connettersi alle origini dietro un servizio di bilanciamento del carico interno con un endpoint privato. Per altre informazioni, vedere Secure origins con collegamento privato.

No. Per la sicurezza, Frontdoor di Azure supporta solo l'autenticazione gestita basata su identità quando si accede ai certificati in Key Vault. Per altre informazioni, vedere Usare le identità gestite in Frontdoor di Azure.

No. Frontdoor di Azure attualmente non supporta l'integrazione delle identità gestite con Hub eventi di Azure.

No. Frontdoor di Azure attualmente non supporta pagine di errore personalizzate.

Gateway applicazione dietro Frontdoor è utile in queste situazioni:

• Si desidera bilanciare il traffico non solo a livello globale, ma anche all'interno della rete virtuale. Frontdoor può eseguire solo il bilanciamento del carico basato sul percorso a livello globale, ma con Gateway applicazione è possibile anche all'interno della rete virtuale.
• È necessario lo svuotamento della connessione, non supportato da Frontdoor. Gateway applicazione può abilitare lo svuotamento della connessione per macchine virtuali o contenitori.
• Si desidera eseguire l'offload di tutta l'elaborazione TLS/SSL e usare le richieste HTTP solo nella propria rete virtuale. Con Gateway applicazione dietro Frontdoor è possibile ottenere questa configurazione.
• Si desidera usare l'affinità di sessione sia a livello di area che a livello di server. Frontdoor può inviare il traffico da una sessione utente allo stesso back-end in un'area, ma il gateway applicazione può inviarlo allo stesso server nel back-end.

Concatenare due CDN generalmente non è un approccio consigliato. Può funzionare, ma comporta i seguenti contro:

1. L'accelerazione dell'ultimo miglio di una CDN funziona mantenendo il flusso di connessione con l'origine e trovando il percorso ottimale verso l'origine per ottenere i migliori risultati. Il concatenamento di due reti CDN in genere nega alcuni dei vantaggi dell'accelerazione dell'ultimo miglio.
2. I controlli di sicurezza diventano meno efficaci nella seconda rete CDN. Qualsiasi ACL basato su IP client non funziona sulla seconda CDN perché la seconda CDN vede il nodo di uscita della prima CDN come IP Client. Il contenuto del payload continua comunque a essere ispezionato.
3. Molte organizzazioni non sono in grado di gestire la complessità della risoluzione dei problemi di due reti CDN concatenate e quando si verifica un problema diventa difficile capire quale rete CDN sta riscontrando il problema.

Per usare Frontdoor di Azure, è necessario avere un indirizzo VIP pubblico o un nome DNS accessibile pubblicamente. Frontdoor di Azure usa l'indirizzo IP pubblico per instradare il traffico all'origine. Uno scenario comune consiste nel distribuire un Azure Load Balancer dietro Frontdoor. È anche possibile usare collegamento privato con Frontdoor di Azure Premium per connettersi a un servizio di bilanciamento del carico interno. Per ulteriori informazioni, vedere abilitare collegamento privato con bilanciatore di carico interno.

Frontdoor di Azure e Rete CDN di Azure sono due servizi che offrono un recapito Web rapido e affidabile per le applicazioni. Tuttavia, non sono compatibili tra loro, perché condividono la stessa rete di siti perimetrali di Azure per distribuire contenuti agli utenti. Questa rete condivisa causa conflitti tra i criteri di routing e di memorizzazione nella cache. Pertanto, è necessario scegliere Frontdoor di Azure o Rete CDN di Azure per l'applicazione, a seconda dei requisiti di prestazioni e sicurezza.

Il fatto che entrambi i profili/endpoint utilizzino lo stesso Azure edge POP per gestire le richieste in arrivo crea una limitazione che impedisce di annidare un profilo/endpoint Frontdoor di Azure dietro un altro. Questa configurazione causerebbe conflitti di routing e problemi di prestazioni. Quindi, se devi usare più profili/endpoint per le tue applicazioni, dovresti assicurarti che i tuoi profili/endpoint di Frontdoor di Azure non siano concatenati insieme.

Frontdoor di Azure è in corso il passaggio da Anycast al routing unicast per la risoluzione dei nomi e il routing delle richieste alla posizione ottimale PoP. Questo cambiamento è avvenuto tra marzo e aprile 2026. Una volta completato il cambio, Unicast sostituisce Anycast per l'intera infrastruttura della porta principale.

Una richiesta di risoluzione dei nomi per un'origine dietro Frontdoor di Azure viene inserita nell'endpoint di Gestione traffico di Frontdoor. I profili di Gestione traffico di Front Door utilizzano numerosi segnali di integrità e disponibilità provenienti dai PoPs in tutto il mondo. Sulla base di questi segnali, viene restituito l'indirizzo IP unicast del Front Door PoP ottimale. La richiesta viene quindi effettuata direttamente all'indirizzo IP restituito, che segue l'architettura di routing di Frontdoor per restituire la risposta all'utente o all'applicazione.

Frontdoor di Azure usa tre tag di servizio per gestire il traffico tra i client e le origini:

• Il tag del servizio AzureFrontDoor.Backend contiene gli indirizzi IP usati da Frontdoor di Azure per accedere alle origini. È possibile applicare questo tag del servizio quando si configura la sicurezza per le origini.
• Il tag del servizio AzureFrontDoor.Frontend contiene gli indirizzi IP usati dai client per raggiungere Frontdoor. È possibile applicare il tag del servizio AzureFrontDoor.Frontend quando si vuole controllare il traffico in uscita che può connettersi ai servizi dietro Frontdoor di Azure.
• Il tag di servizio AzureFrontDoor.FirstParty è riservato per un gruppo selezionato di servizi Microsoft ospitato in Frontdoor di Azure.

Per ulteriori informazioni sugli scenari relativi ai tag di servizio Frontdoor di Azure, vedere i tag di servizio disponibili. Per rimanere informati e intraprendere le azioni appropriate durante eventuali modifiche agli indirizzi IP, sviluppare l'automazione per recuperare regolarmente gli indirizzi IP più recenti utilizzando l'API Service Tag Discovery o il file JSON.

Un gruppo di origine è una raccolta di origini in grado di gestire tipi simili di richieste. È necessario un gruppo di origine diverso per ogni applicazione o carico di lavoro diverso.

In un gruppo di origine si crea un'origine per ogni server o servizio in grado di gestire le richieste. Se l'origine ha un servizio di bilanciamento del carico, ad esempio gateway applicazione di Azure, o è ospitato su un PaaS che ha un servizio di bilanciamento del carico, il gruppo di origine ha una sola origine. L'origine si occupa del failover e del bilanciamento del carico tra origini che Frontdoor non vede.

Ad esempio, se si ospita un'applicazione in Servizio app di Azure, la configurazione di Frontdoor dipende dal numero di istanze dell'applicazione disponibili:

• Distribuzione in una singola area: creare un solo gruppo di origine. In tale gruppo di origine, creare una sola origine per l'app Servizio app di Azure. L'app Servizio app di Azure potrebbe aumentare il numero di ruoli di lavoro, ma Frontdoor vede una sola origine.
• Distribuzione attiva/passiva in più aree: creare un solo gruppo di origine. In tale gruppo di origine, creare un’origine per ogni app Servizio app di Azure. Impostare la priorità di ogni origine in modo che l'applicazione principale abbia una priorità più alta rispetto all'applicazione di backup.
• Distribuzione attiva/attiva in più aree: creare un solo gruppo di origine. In tale gruppo di origine, creare un’origine per ogni app Servizio app di Azure. Impostare la stessa priorità per ogni origine. Impostare il peso di ogni origine per controllare il numero di richieste inviate a tale origine.

Per altre informazioni, vedere Origini e gruppi di origini in Frontdoor di Azure.

Frontdoor di Azure è un servizio che offre un recapito Web rapido e affidabile per le applicazioni. Offre funzionalità come la memorizzazione nella cache, il bilanciamento del carico, la sicurezza e il routing. Tuttavia, è necessario tenere presente alcuni timeout e limiti che si applicano alle Frontdoor di Azure. Questi timeout e limiti includono le dimensioni massime della richiesta, le dimensioni massime della risposta, le dimensioni massime dell'intestazione, il numero massimo di intestazioni, il numero massimo di regole e il numero massimo di gruppi di origine. Per informazioni dettagliate su questi timeout e limiti, vedere la documentazione di Frontdoor di Azure.

La maggior parte dei set di regole aggiorna le configurazioni in meno di 15 minuti. La regola si applica non appena l'aggiornamento termina.

Frontdoor di Azure ha un timeout di 5 secondi per la ricezione delle intestazioni dal client. La connessione viene terminata se il client non invia intestazioni entro 5 secondi a Frontdoor di Azure dopo aver stabilito la connessione TCP/TLS. Il valore di questo timeout non può essere configurato.

Frontdoor di Azure ha un timeout keep-alive HTTP di 90 secondi. La connessione viene terminata se il client non invia dati per 90 secondi, ovvero il timeout keep-alive HTTP per Frontdoor di Azure. Il valore di questo timeout non può essere configurato.

Non è possibile usare gli stessi domini per più di un endpoint Frontdoor perché Frontdoor deve distinguere il percorso (protocollo + host + combinazione percorso) per ogni richiesta. Se sono presenti route duplicate tra endpoint diversi, Frontdoor di Azure non è in grado di elaborare correttamente le richieste.

Al momento, non è possibile spostare i domini da un endpoint a un altro senza interruzioni nel servizio. È necessario pianificare alcuni tempi di inattività se si vuole eseguire la migrazione dei domini a un endpoint diverso.

La funzionalità Frontdoor di Azure collegamento privato è indipendente dall'area, ma per la migliore latenza è consigliabile scegliere sempre un'area Azure più vicina all'origine quando si sceglie di abilitare Frontdoor di Azure collegamento privato endpoint. Se l'area dell'origine non è supportata nell'elenco delle aree supportate da Frontdoor collegamento privato, selezionare l'area più vicina successiva. Il traffico passa dal client all'endpoint Frontdoor di Azure collegamento privato nell'area supportata, quindi attraversa la rete backbone Microsoft all'origine, mantenendo la connettività privata. Tenere presente che questa configurazione introduce una latenza aggiuntiva a causa dell'hop di rete aggiuntivo tra aree. È possibile utilizzare le statistiche di latenza di rete round-trip di Azure per determinare la latenza aggiuntiva dovuta alla scelta della regione successiva più vicina. Appena una nuova area geografica è supportata, è possibile seguire queste istruzioni per spostare gradualmente il traffico verso la nuova area geografica.

Frontdoor di Azure è una piattaforma che distribuisce il traffico in tutto il mondo e può aumentare le prestazioni per soddisfare le esigenze dell'applicazione. Usa la rete perimetrale globale di Microsoft per offrire funzionalità di bilanciamento del carico globale che consentono di spostare l'intera applicazione o microservizi specifici in aree o cloud diversi in caso di errore.

Per evitare errori durante il recapito di file di grandi dimensioni, accertarsi che il server di origine includa l'intestazione Content-Range nella risposta e che il valore dell'intestazione corrisponda alle dimensioni effettive del corpo della risposta.

Per altre informazioni su come configurare l'origine e Frontdoor per il recapito di file di grandi dimensioni, vedere Recapito di file di grandi dimensioni.

Il fronting del dominio è una tecnica di rete che consente a un utente malintenzionato di nascondere la destinazione effettiva di una richiesta dannosa usando un nome di dominio diverso nell'handshake TLS e nell'intestazione host HTTP.

Frontdoor di Azure (livello Standard, Premium e Classico) o Rete CDN di Azure Standard di Microsoft (versione classica) creati dopo l'8 novembre 2022 hanno l'opzione di blocco del fronting del dominio abilitata. Invece di bloccare una richiesta con intestazioni SNI e host non corrispondenti, si consente la discrepanza se i due domini appartengono alla stessa sottoscrizione e sono inclusi nelle regole di gestione/percorsi. L'imposizione del blocco del fronting del dominio inizierà il 22 gennaio 2024 per tutti i domini esistenti. La propagazione dell'imposizione in tutte le aree può richiedere fino a due settimane.

Quando Frontdoor blocca una richiesta a causa di una mancata corrispondenza:

• Il client riceve una risposta con codice di errore HTTP 421 Misdirected Request.
• Frontdoor di Azure registra il blocco nei log di diagnostica nella proprietà Error Info con il valore SSSLMismatchedSNI.

Per ulteriori informazioni sul fronting del dominio, vedere Proteggere il nostro approccio al fronting del dominio in Azure e Proibire il fronting del dominio su Frontdoor di Azure e Rete CDN di Azure Standard di Microsoft (classico).

Frontdoor usa TLS 1.2 come versione minima per tutti i profili creati dopo settembre 2019.

È possibile scegliere di usare TLS 1.2 o 1.3 con Frontdoor di Azure. Per altre informazioni, vedere l'articolo Frontdoor di Azure end-to-end TLS.

A partire dal 15 agosto 2025, DigiCert è passato a una nuova piattaforma di convalida del controllo di dominio (OSS) software open source progettata per migliorare la trasparenza e la responsabilità nei processi di convalida del dominio. DigiCert non supporta più il flusso di lavoro legado CNAME Delegation DCV per la validazione del controllo del dominio nei servizi Azure specificati. Ulteriori informazioni

La deprecazione influisce sui servizi che si basano sulla convalida basata su CNAME per il rilascio e il rinnovo automatizzati dei certificati, tra cui:

• Frontdoor di Azure (versione classica)
• Rete CDN di Azure da Microsoft (versione classica)

Frontdoor di Azure (versione classica) e Rete CDN di Azure da Microsoft (versione classica):

• A partire dal 15 agosto 2025, non è più disponibile il supporto per l'onboarding di nuovi domini, la creazione di nuovi profili o i certificati gestiti da Azure.
• A partire dal 14 aprile 2026, i certificati gestiti esistenti vengono ritirati. Tutti i certificati gestiti esistenti vengono migrati dal cliente o dal team AFD allo standard Frontdoor di Azure o premium. Usare Frontdoor di Azure Standard o Premium per il certificato gestito.

Nella maggior parte dei casi non è necessaria alcuna azione. Dopo la migrazione del profilo, Frontdoor di Azure tenta automaticamente di ruotare il certificato gestito se è entro 45 giorni dalla scadenza.

• Se il dominio è mappato tramite CNAME ad Frontdoor di Azure e soddisfa i requisiti per lo stato del dominio e i record CAA, il certificato viene ruotato automaticamente. Il processo di rotazione automatica viene eseguito ogni 6-8 ore e il completamento richiede circa 24-48 ore. Se l'autorotazione non riesce, lo stato di convalida del dominio passa a "Convalida in sospeso" ed è possibile riconvalidare la proprietà del dominio per attivare manualmente la convalida.
• Se il tuo dominio non soddisfa i requisiti di validazione sopra menzionati o ha HTTPS disabilitato, lo stato del certificato passa a Pending revalidation e devi rivalidare la proprietà del dominio.

Se non si vuole attendere la rotazione automatica, è possibile riconvalidare manualmente la proprietà del dominio per il rinnovo:

• Aggiunta del record di convalida DNS necessario dopo il passaggio 3 per i domini in attesa di convalida
• Oppure attivare la convalida manualmente tramite PowerShell o interfaccia della riga di comando di Azure (RefreshValidation).

Non puoi disabilitare le risorse di Frontdoor di Azure. Puoi solo cancellarli. I contatori variabili come Data Transfer Out, Data Transfer In e Request non vengono addebitati quando non c'è traffico, ma la tariffa base viene addebitata anche se non c'è traffico. La tariffa base viene applicata fino alla cancellazione del profilo. Per Frontdoor classico, i criteri e le regole WAF vengono addebitati indipendentemente dal relativo stato. Anche se si disabilita un criterio o una regola WAF, vengono comunque addebitati i costi.

No.

No.

Front Door non supporta la compressione dinamica per contenuti superiori a 8 MB. Tuttavia, se l'origine già comprime il contenuto, Front Door supporta la diffusione di contenuti compressi statici su 8 MB purché la richiesta di intervallo sia supportata e la codifica a trasferimento a blocchi non sia abilitata.

No.

Per informazioni sui log e altre funzionalità di diagnostica, vedere Monitoraggio di metriche e log in Frontdoor di Azure.

È possibile archiviare i log di diagnostica nel proprio account di archiviazione e scegliere per quanto tempo mantenerli. In alternativa, puoi inviare i log diagnostici agli Event Hub o ai log di Monitoraggio di Azure. Per altre informazioni, vedere Frontdoor di Azure diagnostics.

Per accedere ai log di controllo di Frontdoor di Azure, è necessario visitare il portale. Seleziona la tua porta d'ingresso dalla pagina del menu e seleziona Registro attività. Il Log Attività fornisce i record delle operazioni di Frontdoor di Azure.

È possibile configurare avvisi per Frontdoor di Azure in base a metriche o log. In questo modo, è possibile monitorare le prestazioni e l'integrità degli host front-end.

Per informazioni su come creare avvisi per Frontdoor di Azure Standard e Premium, vedere configurare gli avvisi.

Contenuto correlato

• Creare un profilo frontdoor di Azure
• Architettura di routing di Frontdoor di Azure