Résoudre les problèmes courants d’Azure Front Door

  • Article

Cet article explique comment résoudre les problèmes de routage courants que vous pouvez rencontrer concernant votre configuration Azure Front Door.

Autres en-têtes HTTP de débogage

Vous pouvez demander à Azure Front Door de retourner des en-têtes de réponse HTTP de débogage supplémentaires. Pour plus d’informations, consultez En-têtes de réponse facultatifs.

Réponse 503 ou 504 d’Azure Front Door après quelques secondes

Symptôme

  • Les requêtes régulières envoyées à votre back-end sans passer par Azure Front Door s’effectuent correctement. Le transit via Azure Front Door génère des réponses d’erreur 503 ou 504.
  • L’échec avec Azure Front Door apparaît généralement après environ 30 secondes.
  • Les erreurs 503 intermittentes apparaissent avec « ErrorInfo : OriginInvalidResponse ».

Cause

Ce problème peut avoir pour origine l’une des trois causes suivantes :

  • Votre origine prend plus de temps que le délai d’expiration configuré pour recevoir la requête de l’instance Azure Front Door. Le délai d’expiration par défaut est de 30 secondes.
  • Le temps nécessaire pour envoyer une réponse à la requête provenant d’Azure Front Door prend plus de temps que la valeur du délai d’attente.
  • Le client a envoyé une demande de plage d’octets avec un en-tête Accept-Encoding, ce qui signifie que la compression est activée.

Étapes de dépannage

  • Envoyez la demande directement à votre origine, sans passer par Azure Front Door. Découvrez combien de temps il faut normalement à votre origine pour répondre.

  • Envoyez la demande via Azure Front Door et vérifiez si vous obtenez des réponses 503. Si ce n’est pas le cas, il est possible qu’il ne s’agisse pas d’un problème de délai d’expiration. Créez une demande de support pour poursuivre la résolution du problème.

  • Si les demandes transitant via Azure Front Door génèrent un code de réponse d’erreur 503, configurez le Délai d’attente de la réponse de l’origine pour Azure Front Door. Vous pouvez augmenter le délai d’attente par défaut jusqu’à 4 minutes (240 secondes). Pour configurer le paramètre, accédez à la page de vue d’ensemble du profil Front Door. Sélectionnez le délai de réponse d’origine et entrez une valeur comprise entre 16 et 240 secondes.

    Remarque

    La possibilité de configurer le délai d’expiration de la réponse d’origine est uniquement disponible dans Azure Front Door Standard/Premium.

    Screenshot of the origin timeout settings on the overview page of the Azure Front Door profile.

  • Si l’augmentation du délai d’attente ne résout pas le problème, utilisez un outil, comme Fiddler ou l’outil de développement de votre navigateur, pour vérifier si le client envoie des demandes de plages d’octets avec des en-têtes Accept-Encoding. L’utilisation de cette option conduit à l’origine qui répond avec des longueurs de contenu différentes.

    Si le client envoie des requêtes de plages d’octets avec des en-têtes Accept-Encoding, vous avez deux options. La première option consiste à désactiver la compression sur l’origine ou sur Azure Front Door. La deuxième option consiste à créer une règle de jeu de règles pour supprimer Accept-Encoding des demandes de plages d’octets.

    Screenshot that shows the Accept-Encoding rule in a rule set.

503 réponses d’Azure Front Door uniquement pour HTTPS

Symptôme

  • Toutes les réponses 503 sont retournées uniquement pour les points de terminaison HTTPS Azure Front Door.
  • Les requêtes régulières envoyées à votre back-end sans passer par Azure Front Door s’effectuent correctement. Le transit via Azure Front Door génère des réponses d’erreur 503.
  • Les erreurs 503 intermittentes apparaissent avec « ErrorInfo : OriginInvalidResponse ».

Cause

La cause de ce problème peut être lié à l’une des trois possibilités suivantes :

  • Le pool de back-ends est une adresse IP.
  • Le serveur back-end retourne un certificat qui ne correspond pas au nom de domaine complet du pool de back-ends Azure Front Door.
  • Le pool de back-ends est un serveur Azure Web Apps.

Étapes de dépannage

  • Le pool de back-ends est une adresse IP.

    EnforceCertificateNameCheck doit être désactivé.

    Azure Front Door a un commutateur appelé EnforceCertificateNameCheck. Par défaut ce paramètre est activé. Lorsqu’il est activé, Azure Front Door vérifie que le FQDN du nom d’hôte du pool de back-ends correspond au nom du certificat du serveur back-end ou à l’une des entrées de l’extension d’autres noms d’objet.

    • Comment désactiver EnforceCertificateNameCheck à partir du portail Azure :

      Dans le portail, utilisez un bouton bascule pour activer ou désactiver ce paramètre dans le volet Conception d’Azure Front Door (classique).

      Screenshot that shows the toggle button.

      Pour les niveaux Standard et Premium Azure Front Door, ce paramètre se trouve dans les paramètres d’origine lorsque vous ajoutez une origine à un groupe d’origines ou que vous configurez une route.

      Screenshot of the certificate subject name validation checkbox.

  • Le serveur back-end retourne un certificat qui ne correspond pas au nom de domaine complet du pool de back-ends Azure Front Door. Pour résoudre ce problème, vous avez deux options :

    • Le certificat retourné doit correspondre au FQDN.
    • EnforceCertificateNameCheck doit être désactivé.

  • Le pool de back-ends est un serveur Azure Web Apps :

    • Vérifiez si l’application web Azure est configurée avec le protocole SSL basé sur IP au lieu d’être basé sur SNI. Si l’application web est configurée comme étant basée sur IP, elle doit être remplacée par SNI.
    • Si le back-end n’est pas sain en raison d’un échec de certificat, un message d’erreur 503 est retourné. Vous pouvez vérifier l’intégrité des back-ends sur les ports 80 et 443. Si seul le port 443 n’est pas sain, il s’agit probablement d’un problème avec SSL. Parce que le back-end est configuré pour utiliser le FQDN, nous savons qu’il envoie SNI.

    Utilisez OPENSSL pour vérifier le certificat qui est retourné. Pour ce faire, connectez-vous au back-end en utilisant -servername. Il devrait retourner le SNI qui doit correspondre au FQDN du pool de back-ends :

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

Les requêtes envoyées au domaine personnalisé retournent un code d’état 400

Symptôme

  • Vous avez créé une instance Azure Front Door. Une requête auprès du domaine ou de l’hôte front-end retourne un code d’état HTTP 400.
  • Vous avez créé un mappage DNS pour un domaine personnalisé vers l’hôte front-end que vous avez configuré. L’envoi d’une requête auprès du nom d’hôte du domaine personnalisé retourne un code d’état HTTP 400. L’opération ne semble pas router vers le back-end que vous avez configuré.

Cause

Le problème se produit si vous n’avez pas configuré de règle de routage pour le domaine personnalisé qui a été ajouté en tant qu’hôte front-end. Une règle de routage doit être explicitement ajoutée pour cet hôte front-end. Vous devez créer la règle même si une de règle d’acheminement a déjà été configurée pour l’hôte front-end sous le sous-domaine Azure Front Door, qui est *.azurefd.net.

Étape de dépannage

Ajoutez une règle de routage pour le domaine personnalisé, afin de diriger le trafic vers le groupe d’origines sélectionné.

Azure Front Door ne redirige pas HTTP vers HTTPS

Symptôme

Azure Front Door comporte une règle de routage qui redirige le trafic HTTP vers HTTPS, mais l’accès au domaine conserve toujours HTTP comme protocole.

Cause

Ce comportement peut se produire si vous n’avez pas configuré les règles de routage correctement pour Azure Front Door. Votre configuration actuelle n’est pas spécifique et a peut-être des règles en conflit.

Étapes de dépannage

Une requête au nom d’hôte front-end retourne un code d’état 411

Symptôme

Vous avez créé une instance Azure Front Door Standard/Premium et configuré :

  • Un hôte front-end.
  • Un groupe d’origines avec au moins une origine.
  • Une règle de routage qui connecte l’hôte front-end au groupe d’origines.

Votre contenu ne semble pas être disponible quand une requête est envoyée à l’hôte front-end configuré, car un code d’état HTTP 411 est retourné.

Les réponses à ces demandes peuvent également contenir une page d’erreur HTML dans le corps de la réponse, qui inclut une déclaration d’explication. Par exemple : « Erreur HTTP 411. La requête doit être segmentée ou avoir une longueur de contenu. »

Cause

Ce symptôme peut avoir plusieurs causes. La raison générale est que votre requête HTTP n’est pas entièrement conforme à la norme RFC.

Un exemple de non-conformité est une requête POST envoyée sans en-tête Content-Length ou Transfer-Encoding. Un exemple pourrait utiliser curl -X POST https://example-front-door.domain.com. Cette requête ne répond pas aux exigences définies dans RFC 7230. Azure Front Door la bloque avec une réponse HTTP 411. Ces demandes ne sont pas journalisées.

Ce comportement est indépendant de la fonctionnalité Pare-feu d’applications web (WAF) d’Azure Front Door. Actuellement, il n’existe aucun moyen de désactiver ce comportement. Toutes les requêtes HTTP doivent répondre aux exigences, même si la fonctionnalité WAF n’est pas utilisée.

Étapes de dépannage

  • Vérifiez que vos demandes sont conformes aux exigences des RFC applicables.
  • Prenez note du corps du message HTML renvoyé en réponse à votre requête. Un corps de message explique souvent la raison pour laquelle votre requête n’est pas conforme.

Mon origine est configurée en tant qu’adresse IP.

Symptôme

L’origine est configurée en tant qu’adresse IP. L’origine est saine, mais rejette les requêtes d’Azure Front Door.

Cause

Azure Front Door utilise le nom d’hôte d’origine comme en-tête SNI pendant l’établissement d’une liaison SSL. Étant donné que l’origine est configurée en tant qu’adresse IP, l’échec peut être dû à l’une des raisons suivantes :

  • La case du nom du certificat est activée dans la configuration d’origine Front Door. Il est recommandé de conserver ce paramètre activé. La case du nom du certificat nécessite que le nom d’hôte d’origine corresponde au nom du certificat ou à l’une des entrées de l’extension des autres noms d’objet.
  • Si la case du nom du certificat est désactivée, cela est probablement dû au fait que la logique du certificat d’origine rejette toutes les requêtes qui n’ont pas d’en-tête d’hôte valide dans la requête qui correspond au certificat.

Étapes de dépannage

Remplacez l’origine d’une adresse IP par un nom de domaine complet pour lequel un certificat valide correspondant au certificat d’origine est émis.

Étapes suivantes