Risolvere i problemi comuni del servizio Frontdoor di Azure

Questo articolo descrive come risolvere i problemi di routing comuni che potrebbero verificarsi per la configurazione di Frontdoor di Azure.

Altre intestazioni HTTP di debug

È possibile richiedere a Frontdoor di Azure di restituire intestazioni di risposta HTTP aggiuntive di debug. Per altre informazioni, vedere intestazioni di risposta facoltative.

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. L'esecuzione di Frontdoor di Azure genera 503 o 504 risposte di errore.
• L'errore di Frontdoor di Azure viene in genere visualizzato dopo circa 30 secondi.
• Vengono visualizzati errori intermittenti 503 con "ErrorInfo: OriginInvalidResponse".

Causa

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

• L'origine richiede più tempo del timeout configurato per ricevere la richiesta da Frontdoor di Azure. Il timeout predefinito è 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.

Passaggi per la risoluzione dei problemi

• Inviare la richiesta direttamente all'origine senza passare da Frontdoor di Azure. Verificare quanto tempo l'origine richiede normalmente per rispondere.

• Inviare la richiesta tramite Frontdoor di Azure e verificare se si ricevono 503 risposte. 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 di panoramica del profilo frontdoor. Selezionare Origin response timeout (Timeout risposta origine) e immettere un valore compreso tra 16 e 240 secondi.

  Nota

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

  

• Se l'aumento del timeout non risolve il problema, usare uno strumento come 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 intervallo di byte con intestazioni Accept-Encoding , sono disponibili due opzioni. La prima opzione consiste nel disabilitare la compressione nell'origine o nella 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.

  

503 risposte da Frontdoor di Azure solo per HTTPS

Sintomo

• Tutte le 503 risposte vengono restituite solo per gli endpoint abilitati per HTTPS di Frontdoor di Azure.
• Le richieste regolari inviate al back-end senza passare attraverso Frontdoor di Azure hanno esito positivo. L'esecuzione tramite Frontdoor di Azure genera 503 risposte di errore.
• Vengono visualizzati errori intermittenti 503 con "ErrorInfo: OriginInvalidResponse".

Causa

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

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

Passaggi per la risoluzione dei problemi

• Il pool back-end è un indirizzo IP.

  EnforceCertificateNameCheck deve essere disabilitato.

  Frontdoor di Azure ha un commutatore denominato EnforceCertificateNameCheck. Questa impostazione è abilitata per impostazione predefinita. Se abilitata, Frontdoor di Azure verifica che il nome FQDN del pool 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 Progettazione di Frontdoor di Azure (versione classica).

    

    Per il livello Frontdoor di Azure 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.

    

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

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

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

  • Controllare se l'app Web di Azure è configurata con SSL basato su IP anziché basata su SNI. 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 -servername. 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.
• È stato creato un mapping DNS per un dominio personalizzato all'host front-end 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.

Causa

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.

Causa

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.

Passaggi per la risoluzione dei problemi

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

Sintomo

È stata creata un'istanza di Frontdoor di Azure Standard/Premium e sono state configurate le informazioni seguenti:

• Host front-end.
• Un gruppo di origine con almeno un'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 in blocchi o avere una lunghezza del contenuto".

Causa

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 POST richiesta inviata senza un'intestazione Content-Length o Transfer-Encoding . Un esempio è l'uso di curl -X POST https://example-front-door.domain.com. Questa richiesta non soddisfa i requisiti specificati in RFC 7230. Frontdoor di Azure lo blocca 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.

Passaggi per la 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 richiesta. Un corpo del messaggio spesso spiega esattamente come la richiesta non è conforme.

L'origine è configurata come indirizzo IP.

Sintomo

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

Causa

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

• Il controllo del nome del certificato è abilitato nella configurazione dell'origine frontdoor. È consigliabile lasciare abilitata questa impostazione. Il controllo del nome certificato richiede che il nome host di origine corrisponda al nome del certificato o a una delle voci nell'estensione dei nomi alternativi del soggetto.
• Se il controllo del nome del certificato è disabilitato, è probabile che la causa sia dovuta alla logica del certificato di origine che rifiuta le richieste che non hanno un'intestazione host valida nella richiesta corrispondente al certificato.

Passaggi per la 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.

Passaggi successivi

• Informazioni su come creare una Frontdoor.
• Informazioni su come Creare un profilo Frontdoor Standard/Premium.