Server Load Balancer:ALB FAQ

Spécifications des instances ALB

ALB ne vous impose pas de sélectionner une spécification d'instance. Après avoir mis à niveau une instance ALB, ALB utilise la fonctionnalité VIP automatic scaling pour atteindre 1 million de QPS par instance. Pour plus de détails sur les performances des instances, consultez les métriques des instances.

Conversion des instances IPv4 et double pile

Non.

Vous pouvez uniquement créer une nouvelle instance IPv4 ou une nouvelle instance double pile.

Désactiver les pings vers le VIP ALB

• Pour les instances ALB mises à niveau, gérez le trafic d'accès à l'aide d'un groupe de sécurité. Configurez une règle entrante dans le groupe de sécurité de l'instance pour refuser les requêtes ICMP.

• Pour les instances ALB non mises à niveau, ajoutez les EIP associées à l'instance au Cloud Firewall et configurez une politique entrante pour refuser les requêtes ICMP.

Augmenter la bande passante publique ALB

Si elle n'est pas ajoutée à une instance Shared Bandwidth, une instance ALB déployée sur deux zones de disponibilité dispose d'une bande passante publique maximale par défaut de 400 Mbit/s.

Utiliser un Data Transfer Plan avec ALB

• Si une instance ALB fournit des services publics via une Elastic IP Address (EIP), vous pouvez utiliser un Data Transfer Plan pour compenser les coûts de transfert de données publics générés par l'EIP.

• Si une instance ALB fournit des services publics via une Anycast Elastic IP Address (Anycast EIP), vous ne pouvez pas utiliser un Data Transfer Plan pour compenser les coûts de transfert de données publics générés par l'Anycast EIP.

Types d'EIP pris en charge

EIP pour les instances ALB privées

Oui.

Si vous devez associer une Elastic IP Address (EIP) à une instance ALB privée, convertissez l'instance ALB privée en instance ALB publique en modifiant le type de réseau de l'instance. Pour plus d'informations, consultez la rubrique Modifier le type de réseau d'une instance ALB.

La modification du type de réseau de privé à public associe une EIP à l'instance et engendre des frais pour le transfert de données Internet résultant. Pour plus d'informations, consultez la rubrique Facturation des EIP.

Remplacer une EIP par une EIP BGP (Multi-ISP) Pro

Remplacez l'EIP en modifiant le type de réseau de l'instance ALB :

1. Modifiez le type de réseau de l'instance ALB de public à privé pour dissocier l'EIP.

2. Remodifiez le type de réseau de l'instance ALB de privé à public. Au cours de cette opération, sélectionnez deux EIP BGP (Multi-ISP) Pro que vous avez déjà créées.

Distribution inégale du trafic entre les EIP

Ce problème peut avoir les causes suivantes :

• Le nom de domaine du service est incorrectement résolu vers une seule EIP associée à l'instance au lieu du nom DNS de l'instance ALB.

• Un proxy de couche 7, tel que Web Application Firewall (WAF) ou Anti-DDoS, est déployé devant l'instance ALB. L'algorithme de retour à l'origine du proxy, tel que le hachage IP, empêche une distribution équitable du trafic entre les EIP.

• Certains clients mettent en cache les enregistrements A issus de la résolution DNS, ce qui entraîne l'envoi constant d'un grand nombre de requêtes vers la même EIP.

Suppression DNS pour ALB

Les instances ALB mises à niveau prennent en charge par défaut les opérations de suppression et de récupération DNS.

Une fois la suppression DNS effectuée, les checks de santé pour le VIP dans cette zone de disponibilité s'arrêtent. Le VIP ou l'EIP (y compris les adresses IPv4 et IPv6) dans cette zone de disponibilité est également supprimé de la résolution de nom de domaine ALB. Vous ne pouvez pas supprimer uniquement l'adresse VIP IPv4 ou IPv6.

Trafic public élevé sur les instances ECS backend

Le trafic transféré par une instance ALB vers les instances Elastic Compute Service (ECS) backend circule sur un réseau interne Virtual Private Cloud (VPC) et ne consomme pas la bande passante publique des instances ECS. Si le trafic public de vos instances ECS reste élevé, cela est généralement dû à l'une des raisons suivantes :

• Le trafic entrant contourne l'instance ALB : le nom de domaine est toujours résolu vers une IP publique ECS, ou les clients accèdent directement à l'instance ECS via son IP publique. Par conséquent, l'instance ALB ne transfère pas le trafic.

• Requêtes sortantes depuis les instances ECS : les applications exécutées sur les instances ECS initient des requêtes externes, telles que des mises à jour logicielles, des téléchargements de journaux ou des appels API externes, qui génèrent du trafic public sortant.

Étapes de dépannage :

1. Vérifiez que votre nom de domaine de service se résout vers l'adresse ALB, et non vers une adresse IP publique ECS.

2. Vérifiez les règles de groupe de sécurité entrantes pour les instances ECS afin de vous assurer que les ports de service ne sont pas exposés au public.

3. Sur les instances ECS, utilisez iftop ou nethogs pour identifier les processus et les adresses de destination qui consomment de la bande passante publique.

Quelle adresse IP ajouter à la liste d'autorisation IP d'une plateforme tierce lors de l'utilisation d'ALB ?

Lorsque vous utilisez une instance ALB orientée Internet, les plateformes tierces (telles que WeChat Merchant Platform ou les rappels de paiement) doivent lier l'adresse IP élastique (EIP) de l'instance ALB, et non l'adresse IP d'une instance Elastic Compute Service (ECS) backend.

Une instance ALB orientée Internet fournit des services via son EIP. Tout le trafic externe, y compris les requêtes de rappel des plateformes tierces, entre par l'EIP de l'instance ALB, puis est transféré par ALB vers les serveurs backend. Les instances ECS backend utilisent des adresses IP privées au sein du Virtual Private Cloud (VPC), qui ne sont pas exposées aux appelants externes. Même s'il existe plusieurs instances ECS backend, vous devez uniquement lier l'EIP de l'instance ALB sur la plateforme tierce.

Le chemin du trafic d'une instance ALB orientée Internet est le suivant : requête client > EIP ALB (point d'entrée public) > transfert interne par ALB > adresse IP privée de l'instance ECS backend. Une fois qu'une requête de rappel d'une plateforme tierce arrive depuis Internet, elle atteint uniquement l'EIP de l'instance ALB, et ALB la transfère ensuite aux instances ECS backend. Tout au long du processus, la plateforme tierce communique uniquement avec l'EIP de l'instance ALB, et les adresses IP privées des instances ECS backend restent invisibles pour les appelants externes.

ALB prend-il en charge la mise en miroir du trafic ?

Oui. Pour plus d'informations, consultez la rubrique Utiliser la mise en miroir du trafic ALB pour les tests de charge.

Impossibilité d'atteindre la limite QPS du listener

• Fonctionnement : le système d'équilibrage de charge utilise un cluster de serveurs pour desservir chaque instance ALB. Ce cluster distribue uniformément les requêtes entrantes entre ses serveurs pour le transfert. Par conséquent, la limite QPS que vous définissez dans une règle de transfert est également répartie entre ces serveurs système.

  La limite QPS pour un seul serveur système est calculée à l'aide de la formule suivante : QPS limit per system server = Total QPS set / (N-1). N représente le nombre de serveurs système dans le groupe de transfert. Par exemple, si vous définissez la limite QPS d'une règle de transfert sur 1 000 QPS dans la console et qu'il y a 8 serveurs système, le QPS maximal pour un seul serveur système est 1000/(8-1) = 142 QPS.

• Cause : avec un petit nombre de connexions persistantes, certains serveurs système du groupe de transfert peuvent ne recevoir aucune connexion. Cela peut empêcher l'instance ALB d'atteindre la limite QPS.

• Recommandation : définissez une limite QPS raisonnable pour vos règles de transfert en fonction de vos besoins métier. Cela garantit que vos services restent disponibles et ne sont pas limités de manière inattendue. Pour plus d'informations sur la définition d'une limite QPS dans une règle de transfert de listener, consultez la rubrique Ajouter une règle de transfert.

Limites de longueur des requêtes

Portée du temps de traitement ALB

Oui, le temps de traitement ALB inclut le temps nécessaire pour recevoir les données du client et envoyer les données au client.

• Temps de réception des données client : il s'agit de read_request_time, soit le temps total que l'équilibreur de charge met pour lire une requête client. Il inclut le temps de lecture de l'en-tête de requête HTTP (read_header_time) et du corps de la requête (read_body_time).

• Temps d'envoi des données de réponse : cela inclut le temps nécessaire pour renvoyer les données de réponse au client.

Nombre maximal de requêtes par connexion persistante

Une seule connexion persistante prend en charge un maximum de 100 requêtes consécutives. Si cette limite est dépassée, la connexion est automatiquement fermée.

Cette limite passe à 1 000 si vous utilisez un listener HTTPS et activez HTTP/2.

Limite de longueur Client Hello pour les listeners QUIC

Lorsque vous utilisez un listener QUIC, ALB applique une longueur minimale pour le Client Hello du client. Le paquet doit avoir une longueur d'au moins 1 024 octets. Sinon, ALB renvoie une erreur « client hello too small » et ferme la connexion. Pour passer ce contrôle, complétez le paquet Client Hello avec des caractères nuls pour atteindre l'exigence de 1 024 octets.

Considérations pour ALB Ingress

Dans la plupart des cas, ne modifiez pas manuellement les instances ALB créées par ALB Ingress dans la console. Utilisez AlbConfig comme source de vérité pour les configurations ALB. Pour plus d'informations sur ALB Ingress, consultez les rubriques Présentation des Ingress ALB et Utiliser un Ingress ALB.

Si vous effectuez des modifications manuelles dans la console, elles ne seront pas reflétées dans la ressource AlbConfig. La prochaine synchronisation AlbConfig écrasera ces modifications manuelles. Cela peut entraîner des problèmes tels que la désactivation des journaux d'accès ou la suppression de règles de transfert.

FAQ sur le cross-origin ALB

Référencement des valeurs d'en-tête d'origine

Pour Key, saisissez le nom de l'en-tête que vous souhaitez écrire. Pour Value, sélectionnez la méthode de référence et saisissez le nom de l'en-tête d'origine dont vous souhaitez référencer la valeur. Dans l'exemple suivant, un nouvel en-tête nommé abc-abc est écrit, et il référence la valeur de l'en-tête d'origine abc. La règle de transfert extrait la valeur de l'en-tête d'origine abc et l'attribue au nouvel en-tête abc-abc.

La condition de cette règle de transfert est une correspondance de chemin exacte pour /. En plus de l'action d'écriture d'en-tête, la règle est également configurée pour Forward to un groupe de serveurs spécifique avec un poids de 100.

Client

Lorsque le client envoie une requête en utilisant curl, il inclut l'en-tête de requête personnalisé abc:123456 avec le paramètre -H. Le serveur renvoie 200 OK. Le code suivant montre un exemple de commande et sa sortie :

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

Serveur

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

Authentification mutuelle CA

Les instances ALB Basic Edition ne prennent pas en charge l'authentification mutuelle CA. Les instances ALB Standard Edition et WAF-enabled Edition prennent en charge l'authentification mutuelle CA lorsque vous ajoutez un listener HTTPS. Si vous devez utiliser la fonctionnalité d'authentification mutuelle CA pour une instance ALB Basic Edition, veuillez mettre à niveau l'édition de l'instance.

Règles pour les certificats wildcards

Téléchargement des certificats

Non.

ALB utilise les certificats du service Alibaba Cloud SSL Certificates Service. Par conséquent, vous devez télécharger les certificats dans la console SSL Certificate plutôt que dans la console ALB. Pour plus d'informations, consultez la rubrique Télécharger un certificat SSL.

Date d'expiration du certificat inchangée

Ce problème se produit généralement lorsque votre instance ALB est intégrée à WAF 2.0 en mode proxy transparent et que le certificat dans WAF n'a pas été mis à jour. WAF synchronise périodiquement les certificats depuis ALB. Pour déclencher une mise à jour immédiate, vous pouvez désactiver puis réactiver la redirection de trafic pour votre domaine dans la console WAF. Cette action force une actualisation du certificat. Notez que cette opération provoque une brève interruption de service de 1 à 2 secondes.

Modifier la configuration des health checks

1. Connectez-vous à la console Application Load Balancer (ALB).

2. Dans le volet de navigation de gauche, choisissez ALB > Server Groups.

3. Sur la page Server Groups, recherchez le groupe de serveurs cible et cliquez sur son ID.

4. Dans l'onglet Details, dans la section Health Check, cliquez sur Modify Health Check.

5. Dans la boîte de dialogue Modify Health Check, cliquez sur Edit à côté de Health Check Settings, modifiez les paramètres de health check, puis cliquez sur Save.

   Pour plus d'informations, consultez la rubrique Health check ALB.

Erreurs 502 malgré des health checks réussis

Cela est généralement dû à une charge trop élevée sur les serveurs backend de l'instance ALB. Lorsque la charge sur les serveurs backend de l'instance ALB est trop élevée, des incohérences peuvent survenir entre les résultats des health checks et les résultats des requêtes d'accès. Pour savoir comment vérifier la charge des serveurs backend, consultez la rubrique Dépannage et gestion des problèmes de charge élevée sur les instances Linux.

Transfert de requêtes en cas d'échec des health checks

L'instance ALB continue de transférer les requêtes en fonction de l'algorithme de planification configuré afin de minimiser les interruptions de service. Si les requêtes ne sont pas traitées comme prévu, vérifiez vos journaux pour détecter des erreurs sur les serveurs backend ou examinez votre configuration de health check pour identifier des problèmes. Pour plus d'informations, consultez la rubrique Dépanner les échecs de health check ALB.

Service inaccessible via ALB

Suivez ces étapes pour diagnostiquer le problème :

1. Vérifier la résolution du nom de domaine (CNAME) : vous ne pouvez pas accéder directement à une nouvelle instance ALB en utilisant son nom DNS. Vous devez mapper votre nom de domaine personnalisé au nom DNS de l'instance ALB à l'aide d'un enregistrement CNAME. Utilisez la commande nslookup ou dig pour vérifier la résolution. Pour plus d'informations, consultez la rubrique Noms DNS des instances ALB.

2. Vérifier le type de réseau de l'instance : une instance ALB de réseau privé ne peut être accessible qu'à partir de son Virtual Private Cloud (VPC). Pour activer l'accès public, modifiez le type de réseau de l'instance en public et associez une Elastic IP (EIP). Pour plus d'informations, consultez la rubrique Modifier le type de réseau d'une instance ALB.

3. Vérifier le listener et les règles de transfert : dans la console ALB, vérifiez qu'un listener a été créé avec le port et le protocole corrects. Confirmez également que les règles de transfert sont configurées pour correspondre au nom de domaine et au chemin des requêtes entrantes.

4. Vérifier l'état des health checks : dans la console ALB, vérifiez l'état des health checks de vos serveurs backend. Une instance ALB ne transférera pas de requêtes vers des serveurs backend non sains.

5. Confirmer que le service backend fonctionne correctement : connectez-vous à un serveur backend et exécutez la commande curl -I http://<backend_server_private_IP>:<port> pour confirmer que le service backend répond correctement.

6. Vérifier les paramètres de contrôle d'accès et de pare-feu : assurez-vous que les paramètres de contrôle d'accès ou les règles de groupe de sécurité de l'instance ALB autorisent la plage d'adresses IP source du client. Confirmez également que iptables ou les logiciels de sécurité tiers sur les instances Elastic Compute Service (ECS) backend autorisent la plage d'adresses IP locales de l'instance ALB.

Dépannage d'une latence élevée

ALB opère au niveau de la couche application, ce qui signifie que les requêtes sont transférées vers les serveurs backend. Ce processus introduit une légère latence supplémentaire par rapport à un accès direct aux serveurs backend. Il s'agit d'un comportement attendu.

Si vous rencontrez une latence significativement élevée, suivez ces étapes pour dépanner :

1. Activer les journaux d'accès et analyser les champs de latence : activez les Journaux d'accès ALB et concentrez-vous sur les champs suivants :

   • request_time : le temps en secondes écoulé entre la réception du premier paquet de requête par l'équilibreur de charge et l'envoi de la réponse par l'équilibreur de charge.

   • upstream_response_time : le temps en secondes écoulé entre le début de la connexion de l'équilibreur de charge à un serveur backend et la réception de toutes les données suivie de la fermeture de la connexion.

2. Identifier la source de la latence :

   • Si upstream_response_time est élevé, les serveurs backend sont probablement la source de la latence. Vérifiez les performances de votre application backend, l'efficacité de vos requêtes de base de données et l'utilisation des ressources telles que le CPU et la mémoire. Vous pouvez également ajouter davantage de serveurs backend pour répartir la charge.

   • Si request_time est beaucoup plus élevé que upstream_response_time, la latence se situe probablement dans le chemin réseau entre le client et l'instance ALB. Depuis le client, exécutez des tests ping continus ou une trace MTR vers l'adresse de service ALB pour diagnostiquer les problèmes de lien réseau.

3. Prendre en compte les scénarios d'accès interrégional : si le client et l'instance ALB se trouvent dans des régions différentes, la latence réseau due à la distance physique est inévitable. Nous recommandons d'utiliser Global Accelerator (GA) pour optimiser l'expérience d'accès interrégional.

Service inaccessible via le nom de domaine

Après avoir mappé votre nom de domaine personnalisé au nom DNS de l'instance ALB avec un enregistrement CNAME, il se peut que vous ne puissiez toujours pas accéder au service. Si vous recevez une erreur HTTP 403 ou une réinitialisation de connexion, la cause est probablement un dépôt ICP incomplet pour votre nom de domaine.

Suivez ces étapes pour diagnostiquer le problème :

1. Vérifier la configuration de l'enregistrement CNAME : utilisez la commande nslookup ou dig pour vérifier que votre nom de domaine est correctement résolu vers le nom DNS de l'instance ALB. Pour plus d'informations, consultez la rubrique Configurer un enregistrement CNAME.

2. Vérifier l'état du dépôt ICP de votre nom de domaine : conformément à la réglementation, les noms de domaine utilisés pour l'accès public en Chine continentale doivent disposer d'un dépôt ICP valide. Sinon, l'accès sera bloqué. Connectez-vous au Système de dépôt ICP d'Alibaba Cloud pour vérifier l'état du dépôt de votre nom de domaine. S'il n'est pas déposé, effectuez d'abord la procédure de dépôt ICP. Pour plus d'informations, consultez la rubrique Procédure de dépôt ICP.

3. Déterminer si un transfert de dépôt ICP est requis : si votre nom de domaine a été déposé via un autre fournisseur de services cloud et que vous l'utilisez avec Alibaba Cloud pour la première fois, vous devez effectuer un transfert de dépôt ICP. Cette procédure enregistre vos informations de dépôt auprès d'Alibaba Cloud. L'accès peut être bloqué si le transfert n'est pas terminé.

500 (Internal Server Error)

Le serveur backend a rencontré une erreur interne et n'a pas pu traiter la requête.

• Le backend renvoie directement 500 : vérifiez le journal d'accès. Si upstream_status est 500, ALB a probablement transmis le code d'état provenant du backend. Examinez le service backend.

• Le serveur backend a fermé la connexion de manière inattendue : le serveur backend a fermé la connexion avant d'envoyer une réponse complète. Capturez les paquets sur le serveur backend pour identifier la cause de la fermeture inattendue de la connexion.

502 (Bad Gateway)

Cette erreur se produit lorsqu'un listener HTTP ou HTTPS reçoit une requête client, mais qu'ALB ne parvient pas à transférer la requête à un serveur backend ou à recevoir une réponse de celui-ci.

Approche de dépannage : vérifiez d'abord la valeur du champ upstream_status dans le journal d'accès pour déterminer les prochaines étapes.

• Si upstream_status = 502 : ALB a transmis le code d'état 502 du serveur backend. Le problème réside dans le service backend lui-même. Examinez votre service backend. Par exemple, vérifiez si un backend Nginx ou une couche de passerelle tente d'effectuer un reverse proxy vers un amont inaccessible.

• Si upstream_status est une autre valeur (telle que 504, 444 ou 500) : le status qu'ALB renvoie au client diffère de upstream_status, ce qui signifie qu'ALB a modifié le code d'état. Examinez pourquoi le service backend renvoie ce code d'état spécifique en vérifiant les journaux du backend Nginx, de la passerelle ou de l'application.

• Si upstream_status est - ou vide : ALB n'a reçu aucune réponse du backend. Cela signifie que la requête n'a jamais atteint le backend, ou que la connexion backend a été anormalement interrompue avant l'envoi d'une réponse. Vérifiez les causes suivantes dans l'ordre :

  • La communication TCP entre ALB et le serveur backend échoue. Vérifiez que le service backend est en cours d'exécution, que le port de service écoute correctement et qu'aucune règle iptables ou logiciel de sécurité tiers sur l'ECS backend ne bloque le bloc CIDR du VSwitch où se trouve l'instance ALB. ALB communique avec les serveurs backend en utilisant une Local IP attribuée par le VSwitch. Vous pouvez capturer les paquets pour vérifier si le handshake TCP est réussi.

  • Le backlog du serveur backend est plein. Cela amène le serveur à rejeter les nouvelles demandes de connexion. Exécutez netstat -s | grep -i listen sur le serveur backend et vérifiez s'il existe un compteur drop.

  • Le serveur backend n'a pas pu traiter la requête à temps. Vérifiez les journaux du serveur backend et examinez l'utilisation du CPU et de la mémoire pour identifier les goulots d'étranglement de performance.

  • La taille des paquets de la requête client dépasse le MTU du serveur backend. Cela peut entraîner la réussite des paquets courts (tels que les health checks) tandis que les paquets longs échouent. Capturez les paquets sur le serveur backend pour analyser si la longueur des paquets respecte les limites requises.

  • La réponse du serveur backend a un format invalide ou contient des en-têtes HTTP invalides. Capturez les paquets sur le serveur backend pour analyser si le format de la réponse est conforme aux normes.

503 (Service Temporarily Unavailable)

Le serveur est temporairement indisponible, généralement en raison d'un trafic dépassant les limites ou d'un service backend indisponible.

• Le backend renvoie directement 503 : vérifiez le journal d'accès. Si upstream_status est 503, ALB a probablement transmis le code d'état provenant du backend. Examinez le service backend.

• La requête client déclenche une limitation de débit ALB :

  • Dans Cloud Monitor, vérifiez la métrique Requests per second.

  • Cloud Monitor affiche des données au niveau de la minute et peut ne pas refléter les pics au niveau de la seconde. Vérifiez le journal d'accès. Si le champ upstream_status est -, la requête n'a pas atteint le serveur backend.

  • Vérifiez l'en-tête du paquet de réponse. S'il contient le champ ALB-QPS-Limited:Limited, la requête a déclenché une limitation de débit ALB.

• Accès direct par IP ou résolution DNS anormale : cela peut concentrer le trafic sur seulement quelques adresses IP et déclencher une limitation de débit. Accédez à ALB via son nom de domaine (consultez Configurer un CNAME pour une instance ALB) et vérifiez que la résolution DNS fonctionne comme prévu.

• Le listener ne dispose d'aucun serveur backend configuré, ou les serveurs backend configurés ont un poids de 0.

• La règle de transfert par défaut d'ALB Ingress provoque une erreur 503 : lorsque vous installez le contrôleur ALB Ingress dans ACK, le contrôleur crée automatiquement une règle de transfert par défaut et un groupe de serveurs par défaut associé sur l'instance ALB. Le groupe de serveurs par défaut est initialement vide. Lorsque le trafic entrant ne correspond à aucune des règles de transfert Ingress configurées, ALB route la requête vers la règle de transfert par défaut. Étant donné que le groupe de serveurs par défaut est vide, ALB renvoie une erreur 503. Il s'agit d'un comportement attendu. Vous n'avez pas besoin de supprimer manuellement la règle de transfert par défaut. Pour résoudre ce problème, configurez les règles de transfert basées sur le domaine correctes pour router le trafic vers les groupes de serveurs backend correspondants.

  Remarque

  Une erreur 503 indique qu'aucun serveur backend n'est disponible pour traiter la requête (le groupe de serveurs est vide), ce qui est différent d'une erreur 502, où des serveurs backend existent mais sont indisponibles.

504 (Gateway Time-out)

ALB a expiré en attendant une réponse du serveur backend.

• Le backend renvoie directement 504 : vérifiez le journal d'accès. Si upstream_status est 504, ALB a probablement transmis le code d'état provenant du backend. Examinez le service backend.

• La tentative de connexion d'ALB au serveur backend expire : ce délai d'expiration est de 5 secondes par défaut et ne peut pas être modifié. Capturez les paquets pour identifier pourquoi le serveur backend ne répond pas à temps.

• Expiration de la réponse backend : le délai d'expiration de la demande de connexion est de 60 secondes par défaut. Vous pouvez vérifier la métrique UpstreamResponseTime dans Cloud Monitor et le champ upstream_response_time dans le journal d'accès pour déterminer si la réponse du serveur backend a expiré.

Intégration transparente WAF 2.0 vs intégration basée sur le service WAF 3.0

Pour plus d'informations, consultez la rubrique Comparaison entre WAF 3.0 et WAF 2.0.

Intégration ALB et WAF

• Nous vous recommandons d'activer la protection WAF 3.0 pour une instance ALB en utilisant l'intégration basée sur le service WAF 3.0. Cela signifie utiliser une instance ALB améliorée par WAF.

  • Régions prises en charge :

    Zone	Région
    Chine	Chine (Chengdu), Chine (Qingdao), Chine (Pékin), Chine (Guangzhou), Chine (Hangzhou), Chine (Ulanqab), Chine (Shanghai), Chine (Shenzhen), Chine (Zhangjiakou), Chine (Hong Kong), et Chine (Heyuan)
    Asie-Pacifique	Philippines (Manille), Indonésie (Jakarta), Japon (Tokyo), Malaisie (Kuala Lumpur), Singapour, Thaïlande (Bangkok) et Corée du Sud (Séoul)
    Europe et Amériques	Allemagne (Francfort), États-Unis (Silicon Valley), États-Unis (Virginie) et Mexique
    Moyen-Orient	SAU (Riyad - Région partenaire) et EAU (Dubaï)

  • Les instances ALB activées pour WAF utilisent le modèle d'intégration SDK WAF 3.0. Si vous disposez d'une instance WAF 2.0 dans votre compte, vous devez d'abord libérer l'instance WAF 2.0 ou la migrer vers WAF 3.0.

    Par défaut, ALB n'ajoute pas l'en-tête X-Forwarded-Proto aux requêtes. Après avoir libéré une instance WAF 2.0, l'accès direct à l'instance ALB peut provoquer des problèmes de service tels que des redirections infinies, car les serveurs backend ne peuvent pas identifier le protocole d'origine (HTTP ou HTTPS). Pour éviter ce problème, vous devez activer manuellement l'en-tête de requête X-Forwarded-Proto dans la configuration du listener ALB.

  • Les instances ALB activées pour WAF ne prennent pas en charge la fonctionnalité de prévention des fuites de données de WAF.

• Si vous souhaitez utiliser une instance WAF 2.0 existante, les instances ALB Basic et Standard orientées Internet prennent en charge l'intégration transparente WAF 2.0 dans les régions suivantes : Chine (Hangzhou), Chine (Shanghai), Chine (Shenzhen), Chine (Chengdu), Chine (Pékin) et Chine (Zhangjiakou). Les instances ALB internes ne prennent pas en charge l'intégration transparente WAF 2.0.

Prise en charge de l'intégration WAF pour CLB et ALB

Problèmes d'intégration transparente WAF 2.0

Dans une intégration transparente WAF 2.0, les requêtes client passent par WAF pour inspection avant d'être envoyées à une instance ALB ou CLB. Ce chemin à deux passerelles vous oblige à synchroniser plusieurs configurations entre WAF et l'équilibreur de charge. Les modifications des délais d'expiration et des certificats sont particulièrement sujettes à des retards de synchronisation de configuration.