Risolvere i problemi comuni di Frontdoor di Azure

Questo articolo descrive come risolvere i problemi comuni che possono verificarsi quando si usa il Frontdoor di Azure.

Riassunto

Risposta 503 o 504 da Frontdoor di Azure dopo alcuni secondi

Sintomo

• Le richieste regolari inviate al back-end senza passare attraverso Frontdoor di Azure hanno esito positivo. Se si passa attraverso il Frontdoor di Azure si ottengono 503 o 504 risposte di errore.
• L'errore di Frontdoor di Azure in genere viene visualizzato dopo circa 30 secondi.
• Vengono visualizzati errori intermittenti 503 con "ErrorInfo: OriginInvalidResponse".

Motivo

La causa di questo problema può essere una delle tre cose seguenti:

• Il tuo origin sta richiedendo più tempo del timeout configurato per ricevere la richiesta da Frontdoor di Azure. Il timeout predefinito è di 30 secondi.
• Il tempo necessario per inviare una risposta alla richiesta da Frontdoor di Azure richiede più tempo del valore di timeout.
• Il client ha inviato una richiesta di intervallo di byte con un'intestazione Accept-Encoding , ovvero la compressione è abilitata.

Procedura di risoluzione dei problemi

• Inviare la richiesta direttamente all'origine senza passare attraverso Frontdoor di Azure. Scopri quanto tempo la tua origine impiega solitamente per rispondere.

• Invia la richiesta tramite Frontdoor di Azure e verifica se stai ricevendo risposte 503. In caso contrario, il problema potrebbe non essere un problema di timeout. Creare una richiesta di supporto per risolvere ulteriormente il problema.

• Se le richieste che passano attraverso Frontdoor di Azure generano un codice di risposta di errore 503, configurare il timeout di risposta Origin per Frontdoor di Azure. È possibile aumentare il timeout predefinito fino a 4 minuti (240 secondi). Per configurare l'impostazione, passare alla pagina panoramica del profilo Front Door. Selezionare il timeout di risposta di origine e inserire un valore compreso tra 16 e 240 secondi.

  Annotazioni

  La possibilità di configurare il timeout della risposta di origine è disponibile solo in Frontdoor di Azure Standard/Premium.

  

• Se l'aumento del timeout non risolve il problema, usare uno strumento tipo Fiddler o lo strumento di sviluppo del browser per verificare se il client invia richieste di intervallo di byte con intestazioni Accept-Encoding. L'uso di questa opzione comporta la risposta dell'origine con lunghezze di contenuto diverse.

  Se il client invia richieste di intervalli di byte con intestazioni Accept-Encoding, sono disponibili due opzioni. La prima opzione consiste nel disabilitare la compressione nell'origine o nell'Frontdoor di Azure. La seconda opzione consiste nel creare una regola del set di regole per rimuovere Accept-Encoding dalla richiesta di richieste di intervallo di byte.

  Screenshot che mostra la regola Accept-Encoding in un set di regole.

503 risposte da Frontdoor di Azure solo per HTTPS

Sintomo

• Le risposte 503 vengono restituite solo per gli endpoint abilitati HTTPS di Frontdoor di Azure.
• Le richieste regolari inviate al back-end senza passare attraverso Frontdoor di Azure hanno esito positivo. Quando si utilizza Frontdoor di Azure, si verificano risposte di errore 503.
• Si verificano errori intermittenti 503 con "ErrorInfo: OriginInvalidResponse".

Motivo

La causa di questo problema può essere una delle tre cose seguenti:

• Il back-end è un indirizzo IP.
• Il server back-end restituisce un certificato che non corrisponde al nome di dominio completo (FQDN) del back-end Frontdoor di Azure.
• Il back-end è un server Azure App Web.

Procedura di risoluzione dei problemi

• Il back-end è un indirizzo IP.

  deve essere disabilitato.

  Frontdoor di Azure ha un'opzione denominata EnforceCertificateNameCheck. Questa impostazione è abilitata per impostazione predefinita. Se abilitato, Frontdoor di Azure verifica che il nome di dominio completo (FQDN) dell'host back-end corrisponda al nome del certificato del server back-end o a una delle voci nell'estensione dei nomi alternativi del soggetto.

  • Come disabilitare EnforceCertificateNameCheck dal portale di Azure:

    Nel portale usare un interruttore per attivare o disattivare questa impostazione nel riquadro Frontdoor di Azure (versione classica) Design.

    

    Per Frontdoor di Azure livello Standard e Premium, questa impostazione è disponibile nelle impostazioni di origine quando si aggiunge un'origine a un gruppo di origine o si configura una route.

    Screenshot della casella di controllo per la convalida del nome del soggetto del certificato.

• Il server back-end restituisce un certificato che non corrisponde al nome di dominio completo del back-end Frontdoor di Azure. Per risolvere questo problema, sono disponibili due opzioni:

  • Il certificato restituito deve corrispondere al nome di dominio completo.
  • deve essere disabilitato.

• Il back-end è un server Azure App Web:

  • Controllare se l'app Web Azure è configurata con SSL basato su IP invece di essere basata su SNI (indicazione del nome del server). Se l'app Web è configurata come basata su IP, deve essere modificata in SNI.
  • Se il back-end non è integro a causa di un errore del certificato, viene restituito un messaggio di errore 503. È possibile verificare l'integrità dei back-end sulle porte 80 e 443. Se solo 443 non è integro, è probabile che si verifichi un problema con SSL. Poiché il back-end è configurato per l'uso del nome di dominio completo, è noto che sta inviando SNI.

  Usare OPENSSL per verificare il certificato restituito. A tale scopo, connettersi al back-end usando . Deve restituire l'SNI, che deve corrispondere al nome di dominio completo del pool back-end:

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

Le richieste inviate al dominio personalizzato restituiscono un codice di stato 400

Sintomo

• È stata creata un'istanza di Frontdoor di Azure. Una richiesta all'host di dominio o front-end restituisce un codice di stato HTTP 400.
• Hai creato un mapping DNS (server dei nomi di dominio) per un dominio personalizzato sull'host front-end che hai configurato. L'invio di una richiesta al nome host di dominio personalizzato restituisce un codice di stato HTTP 400. Non sembra instradare al back-end configurato.

Motivo

Il problema si verifica se non è stata configurata una regola di routing per il dominio personalizzato aggiunto come host front-end. È necessario aggiungere in modo esplicito una regola di routing per l'host front-end. È necessario creare la regola anche se una regola di routing è già stata configurata per l'host front-end nel sottodominio Frontdoor di Azure, ovvero .azurefd.net.

Passaggio per la risoluzione dei problemi

Aggiungere una regola di routing per il dominio personalizzato per indirizzare il traffico al gruppo di origine selezionato.

Frontdoor di Azure non reindirizza HTTP a HTTPS

Sintomo

Frontdoor di Azure ha una regola di routing che reindirizza HTTP a HTTPS, ma l'accesso al dominio mantiene comunque HTTP come protocollo.

Motivo

Questo comportamento può verificarsi se non sono state configurate correttamente le regole di routing per Frontdoor di Azure. La configurazione corrente non è specifica e potrebbe avere regole in conflitto.

Procedura di risoluzione dei problemi

La richiesta al nome host front-end restituisce un codice di stato 411

Sintomo

Hai creato un'istanza Frontdoor di Azure Standard/Premium e configurata:

• Host front-end.
• Un gruppo di origine con almeno un punto d'origine.
• Regola di routing che connette l'host front-end al gruppo di origine.

Il contenuto non sembra essere disponibile quando una richiesta passa all'host front-end configurato perché viene restituito un codice di stato HTTP 411.

Le risposte a queste richieste possono contenere anche una pagina di errore HTML nel corpo della risposta che include un'istruzione esplicativa. Un esempio è "Errore HTTP 411. La richiesta deve essere segmentata o avere una lunghezza specificata del contenuto.

Motivo

Ci sono diverse possibili cause per questo sintomo. Il motivo generale è che la richiesta HTTP non è completamente conforme a RFC.

Un esempio di non conformità è una richiesta inviata senza un'intestazione Content-Length o Transfer-Encoding . Un esempio è l'uso di . Questa richiesta non soddisfa i requisiti specificati in RFC 7230. Frontdoor di Azure lo bloccherebbe con una risposta HTTP 411. Tali richieste non vengono registrate.

Questo comportamento è separato dalla funzionalità web application firewall (WAF) di Frontdoor di Azure. Attualmente, non è possibile disabilitare questo comportamento. Tutte le richieste HTTP devono soddisfare i requisiti, anche se la funzionalità WAF non è in uso.

Procedura di risoluzione dei problemi

• Verificare che le richieste siano conformi ai requisiti stabiliti nelle RFC necessarie.
• Prendere nota di qualsiasi corpo del messaggio HTML restituito in risposta alla tua richiesta. Un corpo del messaggio spesso spiega esattamente come la richiesta non è conforme alle norme.

La mia origine è configurata come un indirizzo IP.

Sintomo

L'origine è configurata come indirizzo IP. L'origine è in buona salute, ma rifiuta le richieste da Frontdoor di Azure.

Motivo

Frontdoor di Azure usa il nome host di origine come header SNI durante l'handshake SSL. Poiché l'origine è configurata come indirizzo IP, l'errore può essere uno dei motivi seguenti:

• Se il controllo del nome del certificato è disabilitato, è possibile che la causa del problema si trovi nella logica del certificato di origine. Questa logica potrebbe rifiutare le richieste che non dispongono di un'intestazione host valida corrispondente al certificato.

Procedura di risoluzione dei problemi

Modificare l'origine da un indirizzo IP a un FQDN in cui viene emesso un certificato valido corrispondente al certificato di origine.

429 risposte da Frontdoor di Azure

Sintomo

• Una percentuale di richieste inizia a visualizzare gli errori con la risposta 429: Troppe richieste.

Motivo

• Frontdoor di Azure ha limiti di frequenza della piattaforma predefiniti. Se il traffico supera il limite, Frontdoor inizierà a limitare il traffico e restituirà 429 risposte.

Procedura di risoluzione dei problemi

• Se inizi a vedere risposte 429 per il traffico legittimo ed è necessario un limite di quota maggiore, crea una richiesta di supporto Azure.

Contenuti correlati

• Informazioni su come creare una Frontdoor.
• Scopri come creare un Front Door Standard/Premium.