Server Load Balancer:CLB listener FAQ

Prise en charge de la redirection de port par CLB

Oui.

CLB prend en charge la redirection de port. Pour un exemple, consultez Utiliser CLB pour rediriger les requêtes HTTP vers HTTPS.

Prise en charge des plages de ports pour les écouteurs de couche 4

Non. Pour écouter une plage de ports avec un écouteur TCP ou UDP, créez une instance Network Load Balancer (NLB) et activez la fonctionnalité All Ports pour l'écouteur. Pour plus d'informations, consultez Utiliser la fonctionnalité d'écouteur All Ports de NLB pour transférer le trafic sur plusieurs ports.

Considérations relatives à la configuration du port de l'écouteur

Certains opérateurs classent les ports tels que 25, 135, 139, 444, 445, 5800 et 5900 comme présentant un risque élevé et les bloquent par défaut. Même si vous autorisez ces ports dans les règles du groupe de sécurité, les utilisateurs situés dans des régions restreintes peuvent ne pas être en mesure d'accéder à vos services. Nous vous recommandons d'utiliser d'autres ports non considérés comme à haut risque.

• Pour obtenir des informations sur les ports utilisés par les applications sur les systèmes Windows Server, consultez la documentation Microsoft Service overview and network port requirements for Windows Server.

• Pour plus d'informations sur les ports courants, consultez Ports courants.

Configuration de l'écouteur pour WebSocket

• Si vos serveurs backend hébergent des services WebSocket, vous pouvez configurer un écouteur TCP ou un écouteur HTTP.

• Si vos serveurs backend hébergent des services WebSocket Secure, vous pouvez configurer un écouteur TCP ou un écouteur HTTPS.

Effet des modifications de configuration de l'écouteur

Les modifications prennent effet immédiatement et s'appliquent uniquement aux nouvelles requêtes. Les connexions existantes ne sont pas affectées.

Caractères spéciaux dans les règles de transfert d'URL

Vous devez encoder les caractères spéciaux d'une URL au format URL pour garantir un accès correct. Par exemple, le caractère dièse (#) est encodé sous la forme %23, de sorte que l'URL devient http://www.example.com/%23/. Pour connaître les règles d'encodage complètes, consultez la RFC 3986.

Gérer les serveurs backend pour les règles de transfert

Sur la page Forwarding Rule, cliquez sur le nom du groupe de serveurs virtuels cible dans la colonne Virtual Server Group. Sur la page Edit Virtual Server Group, vous pouvez ajouter ou supprimer des serveurs backend, et modifier leurs ports ou leurs poids.

CLB prend-il en charge la définition de limites de taille du corps de la requête ?

CLB ne prend pas en charge le paramètre client_max_body_size. La limite de taille du corps de la requête de 50 Go appartient à Application Load Balancer (ALB), et non à CLB.

Pour contrôler la taille du corps de la requête, utilisez un écouteur TCP de couche 4 et configurez client_max_body_size sur le serveur web de l'instance ECS backend (tel que Nginx) :

http {
    client_max_body_size 100m;
}

Avec un écouteur TCP, CLB transfère le trafic de couche 4 de manière transparente, et la limite de taille du corps de la requête est appliquée par l'instance ECS backend.

Comment la bande passante est-elle calculée pour les instances CLB à bande passante fixe ?

La bande passante sortante et entrante d'une instance CLB à bande passante fixe sont calculées indépendamment. Après avoir défini la valeur de la bande passante fixe, les bandes passantes sortante et entrante sont plafonnées individuellement à la valeur configurée. Vous n'avez pas besoin de les additionner. Par exemple, si la bande passante fixe est définie sur 80 Mbit/s, la bande passante sortante maximale est de 80 Mbit/s et la bande passante entrante maximale est également de 80 Mbit/s. Les deux valeurs sont calculées indépendamment et ne s'influencent pas mutuellement.

Vous pouvez consulter les données de surveillance en temps réel de la bande passante sortante et entrante sur la page de surveillance de la console CLB. Dans les métriques de surveillance, inBitsPS représente la bande passante entrante et outBitsPS représente la bande passante sortante. Nous vous recommandons d'utiliser les données de surveillance au niveau de la minute dans la console comme référence lors de l'ajustement de la bande passante.

Pertes de trafic sans dépassement de la limite de bande passante

Ce problème survient généralement pour les raisons suivantes :

• La surveillance de la bande passante d'Alibaba Cloud utilise des moyennes sur une minute. Si un pic de trafic instantané au cours d'une seconde dépasse la limite de bande passante de l'instance, le système supprime le trafic. Cela peut se produire même si la bande passante moyenne pour l'ensemble de la minute reste inférieure à la limite configurée. Par conséquent, le graphique de surveillance peut indiquer que l'utilisation globale de la bande passante est inférieure à la limite spécifiée.

• Les instances CLB s'exécutent sur un cluster de serveurs qui distribue uniformément les requêtes entrantes entre ses serveurs. La bande passante de crête configurée est également répartie entre les serveurs du cluster. Si les données téléchargées par une seule connexion client dépassent le seuil d'un serveur individuel, le système supprime le trafic. Pour plus d'informations sur le calcul du trafic de téléchargement maximal pour une seule connexion, consultez Pourquoi une connexion ne peut-elle pas atteindre la bande passante de crête dans certains scénarios ?.

Le trafic surveillé dépasse la limite configurée

Les instances CLB utilisent un cluster de serveurs pour la limitation de débit distribuée. La limite de débit de crête pour un seul nœud est calculée comme suit : Limite de débit de crête pour un seul nœud = Bande passante totale configurée / (N - 1), où N est le nombre de nœuds dans le cluster. Par conséquent, la limite de débit effective totale peut être légèrement supérieure à la valeur configurée.

La connexion n'atteint pas la bande passante de crête

• Scénario : Une seule connexion à une instance CLB orientée vers Internet utilisant la méthode de facturation pay-by-specification (bande passante fixe) peut ne pas atteindre la bande passante de crête configurée. Ce problème survient souvent lors de tests de charge à partir d'un seul client ou lors du transfert d'un paquet de données très volumineux.

• Cause :

  Les instances CLB s'exécutent sur un cluster de serveurs. Le cluster distribue uniformément toutes les requêtes entrantes entre ses serveurs.

  Le trafic de téléchargement maximal pour une seule connexion est calculé comme suit : Trafic de téléchargement de crête par connexion = Bande passante totale configurée / (N - 1), où N est le nombre de serveurs dans le cluster. N est égal à 4 pour un écouteur de couche 4 et à 8 pour un écouteur de couche 7. Par exemple, si vous définissez la limite de bande passante sur 10 Mbit/s dans la console, la bande passante totale peut atteindre 10 Mbit/s lorsque plusieurs clients sont utilisés simultanément. Cependant, le trafic maximal qu'un seul client peut télécharger est de 10 / (4 - 1) = 3,33 Mbit/s.

• Solution :

  • Utilisez la méthode de facturation pay-by-traffic pour l'instance CLB orientée vers Internet.

  • Utilisez une instance NLB ou ALB avec une EIP et une bande passante partagée. Cette configuration est plus élastique et permet d'éviter cette limitation.

L'instance CLB n'atteint pas le QPS de crête

• Scénario : Lors de l'utilisation d'un petit nombre de connexions persistantes, les connexions peuvent ne pas être distribuées à tous les serveurs du cluster de transfert. Par conséquent, l'instance CLB peut ne pas atteindre son QPS de crête.

• Cause :

  Les instances CLB sont déployées dans un cluster. Le système distribue uniformément les requêtes entrantes entre les serveurs du cluster. Par conséquent, le QPS de crête d'une instance CLB est également réparti entre ces serveurs.

  Le QPS maximal pour un seul serveur est calculé comme suit : QPS de crête par serveur = QPS total de l'instance / (N - 1), où N est le nombre de serveurs dans le cluster de transfert. Par exemple, si vous achetez une instance CLB de spécification slb.s1.small, qui prend en charge 1 000 QPS, le QPS total peut atteindre 1 000 lorsque plusieurs clients sont utilisés. Cependant, si le cluster comporte 8 serveurs, le QPS maximal pour un seul serveur est de 1000 / (8 - 1) = 142 QPS.

  Remarque

  Les nouveaux achats d'instances CLB pay-by-specification seront interrompus le 1er juin 2025 à 00:00:00 (UTC+8). Pour plus d'informations, consultez Fin de commercialisation des instances CLB pay-by-specification.

• Solution :

  • Utilisez des connexions de courte durée à partir d'un seul client pour les tests de charge.

  • Réduisez la réutilisation des connexions en fonction de vos besoins métier réels.

  • Mettez à niveau la spécification de l'instance CLB. Pour plus d'informations, consultez Mettre à niveau ou rétrograder une instance pay-as-you-go (pay-by-specification).

  • Utilisez une instance ALB. Ce type d'instance offre une plus grande élasticité.

Le taux de nouvelles connexions n'atteint pas le pic

• Scénario : Lorsque vous utilisez une instance Classic Load Balancer (CLB) pay-by-specification, son taux de nouvelles connexions (CPS) peut ne pas atteindre le niveau spécifié, en particulier lors de tests de charge à partir d'un seul client ou lorsque le trafic provient d'une source unique.

  Remarque

  Les nouveaux achats d'instances CLB pay-by-specification seront interrompus le 1er juin 2025 à 00:00:00 (UTC+8). Pour plus d'informations, consultez Fin de commercialisation des instances CLB pay-by-specification.

• Cause :

  Le système d'équilibrage de charge utilise une architecture en cluster pour assurer une haute disponibilité et une évolutivité. Il distribue uniformément les demandes de connexion entrantes entre les serveurs du cluster. Par conséquent, le CPS de crête d'une instance CLB est également réparti entre ces serveurs.

  Le CPS de crête pour un seul serveur est calculé comme suit : CPS de crête par serveur = CPS total de l'instance / (N - 1), où N est le nombre de serveurs dans le cluster de transfert.

  Par exemple, si vous achetez une instance CLB de spécification slb.s1.small évaluée à 3 000 CPS, l'instance peut atteindre les 3 000 CPS complets avec des requêtes provenant de plusieurs clients. Cependant, si le cluster comporte 4 serveurs, le CPS maximal pour un seul serveur est de 3000 / (4 - 1) = 1 000 CPS.

• Solution :

  • Modifiez la méthode de facturation de l'instance de pay-by-specification à pay-by-usage. Les instances pay-by-usage ne sont pas liées à une spécification de performance spécifique et offrent des limites plus élevées, ce qui permet d'éviter les goulots d'étranglement.

  • Effectuez une mise à niveau vers un Network Load Balancer (NLB) pour les scénarios nécessitant une concurrence élevée et un taux élevé de nouvelles connexions. NLB offre des performances et une élasticité supérieures à celles de CLB. Une seule instance NLB prend en charge 100 millions de connexions simultanées, ce qui la rend idéale pour les applications à grande échelle et permet d'éviter les limitations de CPS de l'architecture en cluster de CLB.

Plages de délai d'inactivité de connexion prises en charge

• Délai d'inactivité de connexion pour l'écouteur TCP : 10 à 900 secondes.

• Écouteur HTTP :

  • Délai d'inactivité : 1 à 60 secondes.

  • Délai de requête : 1 à 180 secondes.

• Écouteur HTTPS :

  • Délai d'inactivité : 1 à 60 secondes.

  • Délai de requête : 1 à 180 secondes.

Causes des délais d'inactivité de connexion CLB

Les problèmes côté serveur suivants peuvent provoquer des délais d'inactivité de connexion vers l'adresse de service CLB :

• L'adresse de service est bloquée par des mesures de sécurité

  Cela inclut le nettoyage du trafic, le filtrage en trou noir ou la protection WAF. Par exemple, le WAF envoie des paquets RST au client et au cluster de serveurs après l'établissement d'une connexion.

• Nombre insuffisant de ports clients

  Ce problème est fréquent lors des tests de charge. Une pénurie de ports clients peut entraîner des échecs de connexion. Par défaut, CLB supprime l'option d'horodatage des connexions TCP, ce qui empêche la fonctionnalité tw_reuse du noyau Linux (réutilisation des connexions dans l'état TIME_WAIT) de prendre effet. Cela conduit à une accumulation de connexions dans l'état TIME_WAIT et à une pénurie de ports clients disponibles.

  Solution : Utilisez des connexions persistantes plutôt que des connexions éphémères. Déconnectez-vous en envoyant un paquet RST via l'option de socket SO_LINGER au lieu d'envoyer un paquet FIN.

• La file d'attente d'acceptation du serveur backend est pleine

  Si la file d'attente d'acceptation d'un serveur backend est pleine, celui-ci n'envoie pas de réponse SYN-ACK, ce qui provoque un délai d'inactivité côté client.

  Solution : La valeur par défaut de net.core.somaxconn est 128. Évaluez votre volume de trafic et ajustez cette valeur selon vos besoins. Exécutez ensuite sysctl -w net.core.somaxconn=<new_value> pour modifier le paramètre et redémarrez l'application sur le serveur backend.

• Un serveur backend de couche 4 accède à sa propre adresse de service d'équilibreur de charge

  Les écouteurs de couche 4 CLB (TCP/UDP) n'autorisent pas un serveur backend à agir simultanément en tant que client et serveur. Si un serveur backend tente d'accéder à l'adresse de service de l'instance CLB à laquelle il est associé, la connexion échouera. Les scénarios déclencheurs courants incluent une application backend qui redirige vers l'adresse de service CLB en construisant une URL, ainsi qu'une instance ECS dans un VPC qui accède à l'adresse de service de sa propre instance CLB via le réseau public, ce qui entraîne une boucle de trafic.

  Ce comportement est dû à la manière dont CLB transfère le trafic au niveau de la couche 4 (LVS). Lorsqu'une instance ECS backend envoie un paquet à l'instance CLB, CLB réécrit l'adresse IP de destination et transfère le paquet à un serveur backend. Si CLB renvoie la demande à la même instance ECS qui l'a envoyée, les adresses IP source et destination du paquet correspondent toutes deux à l'adresse IP de cette instance ECS. Par conséquent, la réponse est traitée localement sur l'instance ECS et ne repasse jamais par CLB, empêchant ainsi l'établissement de la connexion.

  • Si l'instance CLB ne dispose que d'un seul serveur backend, chaque demande provenant de ce serveur lui est renvoyée, entraînant un taux d'échec de connexion de 100 %.

  • Si l'instance CLB possède plusieurs serveurs backend, par exemple deux serveurs avec des poids égaux, CLB transfère environ 50 % des demandes à l'autre serveur backend (la connexion réussit). CLB renvoie environ 50 % des demandes au serveur backend d'origine (la connexion échoue). Le taux de réussite global est d'environ 50 %.

  Solution :

  • Utilisez un client différent pour accéder à l'adresse de service au lieu du serveur backend de couche 4.

  • Migrez vers une instance Network Load Balancer (NLB) et désactivez l'option client IP preservation dans le groupe de serveurs. Une fois cette fonctionnalité désactivée, une instance ECS du groupe de serveurs peut agir à la fois comme serveur backend et comme client de l'instance NLB. Pour obtenir l'adresse IP source du client, activez le Proxy Protocol. Pour plus d'informations, consultez How can an ECS instance act as both a backend server and a client of an NLB instance?.

  • Utilisez Alibaba Cloud DNS PrivateZone pour configurer la résolution de noms de domaine privés afin que le nom de domaine de service se résolve en l'adresse IP privée du serveur backend. Les demandes atteignent alors directement le serveur backend via le réseau interne sans passer par l'instance CLB, ce qui élimine la condition de bouclage. Cette approche s'applique lorsqu'un serveur backend accède au service de l'instance CLB à laquelle il est associé en utilisant un nom de domaine. Notez que les demandes contournent CLB dans ce cas et ne bénéficient plus de l'équilibrage de charge ni des contrôles d'intégrité. Utilisez cette approche uniquement pour les demandes initiées par les serveurs backend eux-mêmes.

  • Modifiez le fichier hosts sur le serveur où s'exécute le client afin que le nom de domaine de service pointe vers l'adresse IP privée du serveur backend. L'effet est identique à celui de PrivateZone, et cette approche convient aux scénarios où vous avez besoin de la solution de contournement sur seulement quelques serveurs individuels. Étant donné qu'un fichier hosts doit être maintenu sur chaque serveur, privilégiez PrivateZone lorsque vous disposez d'un grand nombre de serveurs backend.

• Gestion incorrecte des paquets RST lors du délai d'inactivité de connexion

  Après l'établissement d'une connexion TCP, si aucune activité n'est détectée pendant 900 secondes, CLB envoie des paquets RST au client et au serveur pour fermer la connexion. Certaines applications peuvent ne pas gérer correctement le paquet RST et tenter d'envoyer des données via la connexion fermée, provoquant ainsi un délai d'inactivité applicatif.

  Remarque

  Le délai par défaut est de 900 secondes, mais il peut être ajusté selon les besoins.

Délais d'inactivité de connexion HTTP et HTTPS

• Une connexion persistante HTTP prend en charge un maximum de 100 requêtes consécutives. Une fois cette limite atteinte, CLB ferme la connexion.

• Le délai d'inactivité entre deux requêtes HTTP ou HTTPS sur une connexion persistante est configurable de 1 à 60 secondes (avec une marge d'erreur de 1 à 2 secondes). Si ce délai est dépassé, la connexion TCP est fermée. Si votre application utilise des connexions persistantes, nous vous recommandons d'envoyer une requête de maintien actif (heartbeat) au moins toutes les 13 secondes.

• La poignée de main TCP en trois étapes entre une instance CLB et une instance ECS backend expire après 5 secondes. En cas d'expiration, CLB essaie l'instance ECS suivante. Vous pouvez identifier ce problème en vérifiant le temps de réponse amont dans le journal d'accès.

• Le délai de requête (le temps qu'une instance CLB attend une réponse d'une instance ECS) est configurable de 1 à 180 secondes. Si ce délai est dépassé, CLB renvoie généralement un code d'état 504 ou 408 au client. Vous pouvez identifier ce problème en vérifiant le temps de réponse amont dans le journal d'accès.

• Le délai de réutilisation de session HTTPS est de 300 secondes. Après cette période, le même client doit effectuer à nouveau une poignée de main SSL complète.

CLB relance-t-il automatiquement les requêtes après un délai d'attente ?

Non. Si une requête dépasse le délai de requête configuré de l'écouteur (par exemple, la valeur par défaut de 60 secondes), CLB met fin à la connexion et renvoie un code d'erreur 504 au client. CLB ne relance pas automatiquement la requête. Pour mettre en œuvre des relances de requêtes, vous devez implémenter la logique de relance côté client.

Mécanisme de relance implicite pour les écouteurs HTTPS de couche 7 CLB

Lorsqu'un serveur backend ne répond pas ou renvoie une erreur sur un écouteur HTTPS de couche 7 CLB, CLB déclenche automatiquement un mécanisme de relance implicite. CLB essaie séquentiellement d'autres serveurs backend sains. La relance est initiée par CLB lui-même et ne dépend pas du client. En cas de délai d'attente, CLB enregistre une erreur 504 et effectue une nouvelle tentative vers un autre nœud backend. Seul le résultat de la dernière tentative est renvoyé au client.

Afficher les enregistrements de relance : La console CLB ne fournit pas d'interface dédiée pour interroger les journaux de relance. Vous pouvez consulter les enregistrements de relance dans les journaux d'accès CLB. Plusieurs valeurs dans le champ upstream_addr (séparées par des virgules) constituent la preuve d'une relance. Les multiples valeurs dans upstream_response_time correspondent aux temps de réponse de chaque tentative. Par exemple, upstream_addr: 10.0.0.1:80, 10.0.0.2:80 indique que CLB a tenté deux serveurs backend séquentiellement.

Comportement de CLB en cas de déconnexion anticipée du client

Non. CLB ne ferme pas la connexion au serveur backend pendant les opérations de lecture et d'écriture.

Activer les connexions persistantes backend pour CLB

Les instances CLB ne prennent pas en charge les connexions persistantes backend. Pour utiliser cette fonctionnalité, créez une instance ALB, configurez un écouteur HTTP ou HTTPS et activez les connexions persistantes backend pour le groupe de serveurs ALB correspondant. Pour plus d'informations, consultez Create and manage a server group.

Dépanner une latence élevée de CLB

L'accès à un service backend via une instance CLB introduit une petite quantité de latence supplémentaire par rapport à l'accès direct au serveur backend. Ceci est normal. Les écouteurs de couche 7 CLB utilisent une architecture de proxy inverse (Tengine), qui ajoute un saut réseau supplémentaire et un temps de traitement de protocole. La latence supplémentaire pour les écouteurs de couche 4, qui utilisent LVS pour le transfert, est généralement plus faible.

Si vous constatez une latence significativement élevée, suivez ces étapes pour résoudre le problème :

1. Activez les journaux d'accès et analysez les champs de latence : Activez les journaux d'accès CLB et concentrez-vous sur les champs suivants :

   • request_time : L'intervalle, en secondes, entre le moment où CLB reçoit le premier paquet de requête et le moment où il renvoie la réponse.

   • upstream_response_time : L'intervalle, en secondes, entre l'établissement d'une connexion avec un serveur backend et la réception complète des données suivie de la fermeture de la connexion.

2. Identifiez la source de la latence :

   • Si upstream_response_time est élevé : La latence est probablement causée par un traitement lent sur le serveur backend. Vérifiez les performances de l'application backend, l'efficacité des requêtes de base de données et l'utilisation des ressources (CPU/mémoire), ou ajoutez davantage de serveurs backend pour répartir la charge.

   • Si request_time est bien supérieur à upstream_response_time, la latence peut se situer dans le lien réseau entre le client et CLB. Vous pouvez exécuter un test ping continu ou effectuer un traçage de route MTR depuis le client vers l'adresse de service CLB pour résoudre les problèmes de lien réseau.

3. Accès interrégional : Si le client et l'instance CLB se trouvent dans différentes régions, la latence réseau due à la distance physique est inévitable. Nous vous recommandons d'utiliser Global Accelerator (GA) pour optimiser l'expérience d'accès interrégional.

Dépanner les erreurs 502, 503 ou 504

Lorsque vous accédez à un service backend via une instance CLB, les codes d'erreur 502, 503 ou 504 indiquent généralement que la requête n'a pas été traitée correctement par le serveur backend. Voici la signification de ces codes d'erreur :

• 502 Bad Gateway : CLB n'a pas pu transférer la requête à un serveur backend ou recevoir une réponse de celui-ci. Les causes courantes incluent des services backend inaccessibles ou l'échec de tous les contrôles d'intégrité.

• 503 Service Temporarily Unavailable : Cela est généralement causé par un trafic dépassant les limites ou par un serveur backend indisponible. Cette erreur est renvoyée lorsque le trafic instantané dépasse les limites de la spécification de l'instance CLB.

• 504 Gateway Timeout : Le serveur backend a expiré. Les causes courantes incluent des temps de traitement longs côté backend ou un délai d'attente lors de l'établissement d'une connexion avec le serveur backend.

Première étape : Vérifiez les journaux d'accès

Commencez par activer les journaux d'accès CLB et vérifiez les champs status (code d'état renvoyé par CLB au client) et upstream_status (code d'état renvoyé par le serveur backend à CLB) dans les journaux :

• Si status et upstream_status sont identiques, CLB a probablement transmis directement le code d'erreur du serveur backend. Recherchez la raison pour laquelle le serveur backend renvoie cette erreur.

• Si upstream_status est « - » ou différent de status, l'erreur a été renvoyée par CLB. Reportez-vous aux points suivants pour résoudre le problème.

Dépannage des erreurs 502

• Échec de tous les contrôles d'intégrité des serveurs backend : Lorsque tous les serveurs backend associés à un écouteur échouent aux contrôles d'intégrité, CLB ne peut pas transférer les requêtes et renvoie à la place une erreur 502. Vérifiez l'état des contrôles d'intégrité dans la console et résolvez la cause de l'échec, telle que iptables ou un logiciel de sécurité tiers bloquant le bloc CIDR système CLB 100.64.0.0/10, un code d'état de contrôle d'intégrité non correspondant ou un chemin de contrôle d'intégrité inexistant. Pour plus d'informations, consultez CLB Health Check FAQ.

• Le backend renvoie un code d'erreur que CLB convertit en 502 : Si un serveur backend renvoie certains codes d'erreur (tels que 504 ou 444), CLB peut renvoyer une erreur 502 au client. Vérifiez le champ upstream_status dans le journal d'accès pour confirmer le code d'état réel renvoyé par le backend et recherchez la cause de l'erreur backend.

• Erreurs de service backend : Une charge élevée, des réponses mal formées ou des fermetures de connexion inattendues sur le serveur backend peuvent également provoquer des erreurs 502. Vérifiez les journaux du serveur backend et l'utilisation des ressources, telles que le CPU et la mémoire.

Dépannage des erreurs 503

• Le trafic dépasse les limites de spécification de l'instance : CLB renvoie une erreur 503 si les QPS, la bande passante ou le taux de nouvelles connexions du trafic entrant dépassent les limites de la spécification actuelle de l'instance CLB. Vous pouvez récupérer ces métriques depuis Cloud Monitor.

• Le trafic instantané dépasse les limites mais n'apparaît pas dans la surveillance : Cloud Monitor affiche les données avec une granularité à la minute et peut ne pas montrer les pics à la seconde. Vérifiez le nombre de requêtes à la seconde dans le journal d'accès. Si upstream_status est « - », cela indique que la requête n'a pas été envoyée au serveur backend.

Dépannage des erreurs 504

• Délai d'attente de réponse backend : Si le serveur backend ne répond pas dans le délai de requête configuré pour l'écouteur, CLB renvoie une erreur 504. Vérifiez le champ upstream_response_time dans le journal d'accès pour confirmer le temps de réponse réel du backend et ajustez le délai de requête de l'écouteur en conséquence.

• Délai d'attente de connexion backend : Le délai pour qu'une instance CLB termine une poignée de main TCP en trois étapes avec une instance ECS backend est de 5 secondes. Si upstream_response_time dans le journal d'accès est trop long, cela peut indiquer un problème de connexion avec le serveur backend. Nous vous recommandons de capturer les paquets pour enquêter sur la cause.

• Charge backend élevée : Une utilisation élevée des ressources (CPU, mémoire, etc.) sur le serveur backend peut entraîner des temps de réponse dépassant le délai d'attente. Enquêtez et optimisez les performances du service backend, ou ajoutez davantage de serveurs backend pour répartir la charge.

Dépanner les problèmes d'accès CLB

Si vous ne pouvez pas accéder à votre service après avoir configuré une instance CLB, suivez ces étapes pour résoudre le problème couche par couche :

1. Vérifiez la résolution de nom de domaine : Si vous accédez au service en utilisant un nom de domaine, assurez-vous que le nom de domaine se résout correctement en l'adresse de service de l'instance CLB. Vous pouvez utiliser les commandes nslookup ou dig pour vérifier la résolution. Une résolution de nom de domaine incorrecte est une cause fréquente d'échecs d'accès.

2. Vérifiez la configuration de l'écouteur : Dans la console CLB, vérifiez si un écouteur a été créé et confirmez que le port et le protocole de l'écouteur sont correctement configurés. Si un écouteur est manquant ou mal configuré, CLB ne peut pas transférer les requêtes.

3. Vérifiez l'état des contrôles d'intégrité : Dans la console CLB, vérifiez l'état des contrôles d'intégrité des serveurs backend. Si tous les serveurs backend échouent aux contrôles d'intégrité, CLB ne peut pas transférer les requêtes.

4. Vérifiez les paramètres du pare-feu : Vérifiez si iptables ou un logiciel de sécurité tiers sur le serveur backend autorise le port de service backend et le bloc CIDR système CLB 100.64.0.0/10.

5. Vérifiez que le service backend fonctionne correctement : Connectez-vous directement au serveur backend et confirmez que le service backend lui-même est réactif en exécutant telnet <private IP address of the backend server> <port> (couche 4) ou curl -I http://<private IP address of the backend server> (couche 7).

6. Résolvez les problèmes de lien réseau : Testez l'accès à l'adresse de service CLB depuis différents environnements réseau. Si seul votre réseau local est affecté, vous pouvez exécuter un test ping continu ou utiliser le traçage de route MTR pour une enquête plus approfondie.

Accès par IP mais pas par nom de domaine

La raison la plus courante est que le nom de domaine n'a pas terminé son dépôt ICP.

Conformément à la réglementation, lorsqu'un nom de domaine est utilisé pour un accès public en Chine continentale, il doit disposer d'un dépôt ICP valide. L'accès aux domaines sans dépôt ICP est bloqué, ce qui entraîne un code d'état 403 ou une réinitialisation de connexion.

Nous vous recommandons de suivre ces étapes pour résoudre le problème :

1. Vérifiez l'état du dépôt ICP : Connectez-vous au Système de dépôt ICP Alibaba Cloud pour vérifier si votre nom de domaine a terminé son dépôt ICP. Si ce n'est pas le cas, terminez d'abord le processus. Pour plus d'informations, consultez Processus de dépôt ICP.

2. Vérifiez si vous devez transférer votre dépôt ICP : Si votre nom de domaine possède un dépôt ICP auprès d'un autre fournisseur de services cloud mais que vous l'utilisez avec Alibaba Cloud pour la première fois, vous devez également effectuer un transfert de dépôt ICP pour associer les informations de dépôt à Alibaba Cloud. L'absence de ce transfert peut également entraîner un blocage de l'accès.

3. Écartez les autres causes : Si le nom de domaine possède un dépôt ICP et que le transfert de dépôt ICP est également terminé, vérifiez si la résolution de nom de domaine pointe correctement vers l'adresse de service de CLB (vous pouvez utiliser la commande nslookup ou dig pour vérifier), et si la configuration du port et du protocole de l'écouteur CLB correspond à la méthode d'accès par nom de domaine.

Impact du contrôle d'accès sur le trafic interne

Oui. Le contrôle d'accès s'applique au niveau de l'écouteur et affecte à la fois le trafic interne et public. Si vous configurez une liste d'autorisation qui n'autorise que des adresses IP publiques spécifiques, les requêtes provenant d'adresses IP internes ne figurant pas sur la liste d'autorisation seront bloquées. Pour éviter de perturber les services internes, nous vous recommandons d'ajouter les blocs CIDR internes pertinents à la liste d'autorisation ou d'utiliser Cloud Firewall pour restreindre l'accès public à l'EIP.

Dépanner les délais d'attente de requête lors des tests de charge

Lorsque vous effectuez un test de charge sur un CLB de couche 7, si vous recevez des codes d'état 504 ou des délais d'attente de requête, et que upstream_response_time dans les journaux est regroupé autour de 5 secondes, le problème est généralement un délai d'attente de connexion causé par l'échec de la poignée de main TCP en trois étapes entre le CLB et le serveur backend. Une raison courante est que la table de suivi de connexion (nf_conntrack) sur le serveur backend est pleine, ce qui amène le serveur à abandonner les paquets pour les nouvelles connexions.

Connectez-vous au serveur backend et vérifiez le journal /var/log/messages . Vous pouvez confirmer le problème si le message d'erreur suivant apparaît :

nf_conntrack: table full, dropping packet

Solution : Ajustez les valeurs des paramètres nf_conntrack suivants en fonction de vos exigences de service réelles :

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Remarque : La commande précédente prend effet uniquement temporairement. Les modifications sont perdues après le redémarrage de l'instance. Pour rendre les modifications permanentes, écrivez les paramètres dans /etc/sysctl.conf.

Impact des défaillances backend sur les écouteurs partagés

Scénario : Vous disposez de plusieurs sites web, tels qu'un site statique www.example.com et un site dynamique app.example.com, associés au même écouteur CLB. Lorsque la base de données backend du site dynamique tombe en panne, le site statique devient également inaccessible et renvoie une erreur HTTP 502 .

Cause : Les deux sites partagent le même écouteur, et le Health Check Domain Name de l'écouteur est configuré avec le nom de domaine du site dynamique. Lorsque le backend du site dynamique tombe en panne, tous les serveurs backend échouent aux contrôles d'intégrité. Par conséquent, CLB cesse de transférer le trafic vers le backend, ce qui affecte tous les sites configurés sous cet écouteur.

Solution : Utilisez des instances CLB distinctes pour fournir l'équilibrage de charge aux sites dynamiques et statiques afin d'assurer l'isolation métier. De cette façon, une défaillance du site dynamique n'affectera pas le site statique.

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}