Codes de réponse HTTP dans Application Gateway

Résumé

Cet article explique pourquoi Azure Application Gateway retourne des codes de réponse HTTP spécifiques. Il fournit des causes courantes et des étapes de résolution des problèmes pour vous aider à déterminer la cause racine d’un code de réponse HTTP d’erreur. Application Gateway peut retourner des codes de réponse HTTP à une demande cliente si elle lance ou non une connexion à une cible back-end.

Note

Si une connexion cliente échoue avant qu’Application Gateway ne renvoie une réponse HTTP, il s'agit probablement d’un échec de handshake TLS (Transport Layer Security). Les causes courantes incluent des incompatibilités de version TLS (par exemple, le client utilise TLS 1.0 ou 1.1 pendant que la passerelle nécessite TLS 1.2 ou version ultérieure) et des suites de chiffrement non prises en charge. À compter du 31 août 2025, Azure Application Gateway interrompt la prise en charge de TLS 1.0 et 1.1. Pour plus d’informations, consultez la vue d’ensemble de la stratégie TLS Application Gateway et configurer les versions de stratégie TLS et les suites de chiffrement.

Codes de réponse 3XX (redirection)

Application Gateway retourne 300 à 399 réponses lorsqu’une demande cliente correspond à une règle de passerelle d’application qui a configuré des redirections. Vous pouvez configurer des redirections sur une règle as-is ou via une règle de mappage de chemin d’accès. Pour plus d’informations sur les redirections, consultez Vue d’ensemble de la redirection Application Gateway.

Redirection permanente 301

Application Gateway retourne des réponses HTTP 301 lorsque vous spécifiez une règle de redirection avec la valeur permanente .

302 Trouvé.

Application Gateway retourne des réponses HTTP 302 lorsque vous spécifiez une règle de redirection avec la valeur Trouvée .

303 Voir d’autres

Application Gateway retourne des réponses HTTP 303 lorsque vous spécifiez une règle de redirection avec la valeur See Other .

Redirection temporaire 307

Application Gateway retourne des réponses HTTP 307 lorsque vous spécifiez une règle de redirection avec la valeur temporaire .

Codes de réponse 4XX (erreur du client)

Les codes de réponse 400-499 indiquent un problème que le client lance. Ces problèmes peuvent aller du client initiant des requêtes vers un nom d’hôte non correspondant, à l'expiration de la requête, à une demande non authentifiée, à une demande malveillante, etc.

Application Gateway collecte des métriques qui capturent la distribution des codes d’état 4xx/5xx et disposent d’un mécanisme de journalisation qui capture des informations telles que l’adresse IP du client URI avec le code de réponse. Les métriques et la journalisation permettent d’effectuer une résolution des problèmes supplémentaire. Les clients peuvent également recevoir des réponses 4xx d’autres proxys entre l’appareil client et Application Gateway. Par exemple, CDN (Content Delivery Network) et d’autres fournisseurs d’authentification. Consultez les articles suivants pour plus d’informations.

400 – Demande incorrecte

Les codes de réponse HTTP 400 s’affichent généralement quand :

  • Vous lancez le trafic non HTTP ou HTTPS vers une passerelle d’application avec un écouteur HTTP ou HTTPS.
  • Vous lancez le trafic HTTP vers un écouteur avec HTTPS, sans redirection configurée.
  • Vous configurez l’authentification mutuelle, mais Application Gateway ne peut pas négocier correctement.
  • La demande n’est pas conforme à la RFC.

Voici quelques raisons courantes pour lesquelles la demande doit être non conforme à la RFC :

Catégorie Exemples
Hôte non valide dans la ligne de requête Hôte contenant deux signes deux-points (example.com:8090:8080)
En-tête de l’hôte manquant La requête n’a pas d’en-tête de l’hôte
Présence d’un caractère malformé ou illégal Les caractères réservés sont &,!. La solution de contournement consiste à les coder en pourcentages. Par exemple : %&
Version HTTP non valide GET /content.css HTTP/0.3
Le nom du champ d’en-tête et l’URI contiennent un caractère non ASCII GET /«úü¡»¿.doc HTTP/1.1
En-tête Content-Length manquant pour une requête POST Auto-explicatif
Méthode HTTP non valide GET123 /index.html HTTP/1.1
En-têtes dupliqués Autorisation : <contenu encodé en base64>, Autorisation : <contenu encodé en base64>
Valeur non valide dans Content-Length Content-Length : abc, Content-Length : -10

Lorsque vous configurez l’authentification mutuelle, plusieurs scénarios peuvent entraîner une réponse HTTP 400 renvoyée par le client, notamment :

  • Vous activez l’authentification mutuelle, mais le certificat client n’a pas été présenté.
  • Vous activez la validation de nom unique (DN) et le nom de domaine du certificat client ne correspond pas au nom de domaine de la chaîne de certificats spécifiée.
  • La chaîne du certificat client ne correspond pas à la chaîne de certificat configurée dans la stratégie SSL définie.
  • Le certificat client a expiré.
  • Vous activez la vérification de révocation du client OCSP (Online Certificate Status Protocol) et le certificat est révoqué.
  • Vous activez la vérification de révocation du client OCSP, mais Application Gateway ne peut pas contacter le répondeur OCSP.
  • Vous activez la vérification de révocation du client OCSP, mais le répondeur OCSP n’est pas fourni dans le certificat.

Pour plus d’informations sur la résolution des problèmes d’authentification mutuelle, consultez Résolution des codes d’erreur.

401 - Non autorisé

Application Gateway retourne une réponse HTTP 401 non autorisée au client si le client n’est pas autorisé à accéder à la ressource. Il existe plusieurs raisons pour lesquelles 401 doit être retourné. La liste suivante fournit quelques raisons avec des correctifs potentiels.

  • Si le client a accès, il peut avoir un cache de navigateur obsolète. Effacez le cache du navigateur et essayez d’accéder à l’application à nouveau.

Application Gateway peut retourner une réponse HTTP 401 non autorisée à la requête de sonde AppGW si vous configurez le pool principal avec l’authentification NTLM . Dans ce scénario, Application Gateway marque le back-end comme sain. Résolvez ce problème à l’aide de l’une des méthodes suivantes :

  • Autorisez l’accès anonyme au pool de serveurs backend.
  • Configurez la sonde pour envoyer la demande vers un autre site « simulé » qui n’exige pas d’authentification NTLM.
  • Non recommandé, car cette solution ne nous indique pas si le site réel derrière la passerelle d’application est actif ou non.
  • Configurez la passerelle applicative de façon à autoriser les réponses 401 comme valides pour les sondes : Conditions de mise en correspondance de sondes.

403 - Interdit

Application Gateway affiche HTTP 403 Interdit lorsque vous utilisez des SKU WAF (Pare-feu d’applications web) et que WAF est configuré en mode prévention. Si les ensembles de règles WAF activés ou les règles waf de refus personnalisées correspondent aux caractéristiques d’une requête entrante, Application Gateway présente une réponse 403 interdite au client.

Pour résoudre les faux positifs WAF (demandes légitimes bloquées par les règles WAF) :

  1. Activez les journaux de diagnostic WAF et passez en revue le ruleId_s champ pour identifier la règle qui bloque la demande.
  2. Basculez temporairement le waf en mode détection pour journaliser les règles de correspondance sans bloquer le trafic. Cette approche vous aide à confirmer les faux positifs avant d’apporter des modifications de règle. Pour plus d’informations, consultez Paramètres de stratégie WAF.
  3. Créez des exclusions WAF pour des attributs de requête spécifiques (en-têtes, cookies ou arguments) qui déclenchent des faux positifs.
  4. Si une règle managée provoque constamment des faux positifs et des exclusions ne suffisent pas, désactivez la règle individuelle dans la stratégie WAF.

Pour obtenir des instructions détaillées, consultez Résoudre les problèmes de waf pour Application Gateway et les meilleures pratiques waf.

Voici d’autres raisons pour lesquelles les clients peuvent recevoir des réponses 403 :

  • Tentatives de mise à niveau du protocole h2c : Application Gateway retourne 403 erreurs lorsque les clients tentent de mettre à niveau HTTP/1.1 vers HTTP/2.0 à l’aide du protocole h2c (HTTP/2 Cleartext). Application Gateway prend uniquement en charge HTTP/2 sur TLS (écouteurs HTTPS). Il ne prend pas en charge les mises à niveau de protocole h2c sur les écouteurs HTTP. Ce comportement se produit indépendamment du mode WAF. Les clients doivent utiliser des connexions HTTP/2 natives via HTTPS ou rester sur HTTP/1.1 sans tentatives de mise à niveau.
  • Vous utilisez App Service comme back-end et vous l’avez configuré pour autoriser l’accès uniquement à partir d’Application Gateway. Cette configuration peut retourner une erreur 403 par App Services. Cette erreur se produit généralement en raison de redirections ou de liens href qui pointent directement vers App Services au lieu de pointer vers l’adresse IP d’Application Gateway.
  • Si vous accédez à un objet blob de stockage et que le point de terminaison Application Gateway et de stockage se trouvent dans différentes régions, une erreur 403 est retournée si l’adresse IP publique d’Application Gateway n’est pas autorisée. Consultez Accorder l’accès depuis une plage d'adresses IP Internet.

404 - Page introuvable

Une réponse HTTP 404 est générée lorsque vous effectuez une requête à Application Gateway (références SKU V2) avec un nom d’hôte qui ne correspond à aucun des écouteurs multis sites configurés, et il n’y a pas d’écouteur de base présent. Pour en savoir plus, consultez les types d’écouteurs.

408 – Délai d’expiration de la demande

Vous pouvez observer une réponse HTTP 408 lorsque les demandes clientes adressées à l’écouteur frontal d’Application Gateway ne répondent pas dans les 60 secondes. Vous pouvez observer cette erreur en raison de la congestion du trafic entre les réseaux locaux et Azure, lorsque l’appliance virtuelle inspecte le trafic, ou que le client lui-même devient submergé.

413 – Entité de requête trop volumineuse

Vous pouvez observer une réponse HTTP 413 lors de l’utilisation du pare-feu d’applications web Azure sur Application Gateway et la taille de la demande cliente dépasse la limite maximale de taille du corps de la requête. Le champ de taille maximale du corps de la demande contrôle la limite totale de la taille de la demande, à l'exclusion de tout téléchargement de fichier. La valeur par défaut pour la taille du corps de la demande est de 128 Ko. Pour plus d’informations, consultez Web Application Firewall limites de taille de requête.

499 - Le client a fermé la connexion

Une réponse HTTP 499 est présentée si une demande cliente que vous avez envoyée aux passerelles d’application à l’aide de la référence sKU v2 est fermée avant que le serveur ne réponde. Vous pouvez observer cette erreur dans deux scénarios. Le premier scénario est lorsqu’une réponse volumineuse est retournée au client et celui-ci a peut-être fermé ou actualisé l’application avant que le serveur n’ait terminé l’envoi d’une réponse volumineuse. Le deuxième scénario est le moment où le délai d’attente côté client est faible et n’attend pas suffisamment longtemps pour recevoir la réponse du serveur. Dans ce cas, il est préférable d’augmenter le délai d’attente côté client. Dans les passerelles d’application utilisant la référence sku v1, un code de réponse HTTP 0 peut être déclenché pour le client fermant la connexion avant la fin de la réponse du serveur.

Codes de réponse 5XX (erreur du serveur)

Les codes de réponse 500-599 indiquent un problème avec la passerelle d’application ou le serveur principal lors de l’exécution de la requête.

500 – Erreur interne du serveur

La passerelle d'application Azure ne doit pas retourner de codes de réponse 500. Ouvrez une demande d’assistance si vous voyez ce code, car il s’agit d’une erreur interne au service. Pour plus d’informations sur l’ouverture d’un cas de support, consultez Créer une demande de Azure support.

502 – Passerelle défectueuse

Les erreurs HTTP 502 peuvent avoir plusieurs causes racines, notamment :

Pour plus d’informations sur les scénarios où les erreurs 502 se produisent et comment les résoudre, consultez Résoudre les erreurs de passerelle incorrecte.

503 – Service indisponible

Les réponses HTTP 503 indiquent qu’Application Gateway ou un serveur principal ne peut pas gérer temporairement la requête. Les causes courantes sont les suivantes :

  • Tous les membres du pool principal ne sont pas sains, comme déterminé par les sondes d’intégrité et aucun serveur sain n’est disponible pour traiter les demandes.
  • Le serveur principal est surchargé ou en cours de maintenance et retourne 503 directement à Application Gateway.
  • La mise à l’échelle automatique d’Application Gateway V2 est en cours et les nouvelles instances ne sont pas encore prêtes à servir le trafic.
  • Les limites de connexion sont atteintes sur Application Gateway ou sur le serveur principal.

Pour résoudre les erreurs 503 :

  1. Vérifiez le volet d’intégrité du serveur principal dans le portail Azure pour vérifier l’état du membre du pool principal.
  2. Passez en revue la configuration de la sonde d’intégrité pour vous assurer que les sondes ne marquent pas incorrectement les back-ends sains comme non sains. Pour plus d’informations, consultez la vue d’ensemble de la sonde d’intégrité.
  3. Vérifiez que l’application back-end est opérationnelle en y accédant directement, en contournant Application Gateway.
  4. Vérifiez les métriques Application Gateway pour connaître le nombre de connexions et l’utilisation de l’unité de capacité dans Azure Monitor.
  5. Pour les références SKU V2, passez en revue les paramètres de mise à l’échelle automatique pour garantir un nombre d’instances minimal suffisant pendant les pics de trafic.

Pour plus d’informations, consultez Résoudre les problèmes de santé du backend.

504 – Délai d’attente de la passerelle dépassé

La référence SKU Azure Application Gateway V2 envoie des erreurs HTTP 504 si le temps de réponse du back-end dépasse la valeur de délai d’attente que vous configurez dans le paramètre principal.

IIS (serveur web de Internet Information Services)

Si votre serveur principal est IIS, consultez Les limites par défaut des sites web pour définir la valeur de délai d’attente. Pour plus d’informations, reportez-vous à l’attribut connectionTimeout. Vérifiez que le délai d’attente de connexion dans IIS correspond ou ne dépasse pas le délai d’attente défini dans le paramètre back-end.

Nginx

Si le serveur principal est Nginx ou Nginx Ingress Controller et s’il dispose de serveurs en amont, assurez-vous que la valeur de nginx:proxy_read_timeout corresponde ou ne dépasse pas le délai d’attente défini dans le paramètre du serveur principal.

Scénarios de résolution des problèmes

Erreur « ERRORINFO_INVALID_HEADER » dans les journaux d’accès

Problème : le journal d’accès affiche une erreur « ERRORINFO_INVALID_HEADER » pour une requête, même si le code de réponse back-end (serverStatus) est 200. Dans d’autres cas, le serveur principal retourne 500.

Cause : le client envoie un en-tête qui contient des caractères CR LF.

Solution : remplacez les caractères CR LF par sp (espace blanc) et renvoyez la requête à Application Gateway.

  • Last updated on