Proxies pour les tests de charge dans k6 et JMeter

Lorsque le test de charge rencontre une limitation de taux, un WAF ou un équilibrage géographique, la première pensée est « je vais lancer le trafic depuis différentes IP ». Cela semble logique, mais en pratique, les proxies dans k6 et JMeter résolvent un ensemble limité de tâches, et tout le reste doit quand même être corrigé par l'architecture du test. Dans cet article, nous allons examiner comment techniquement connecter des proxies aux deux outils, quels types d'IP conviennent et où se termine la zone de responsabilité du serveur proxy.

Pourquoi les tests de charge ont besoin de différentes IP

Par défaut, k6 et JMeter envoient tout le trafic depuis une seule adresse IP — le serveur sur lequel le test est exécuté (ou une machine cloud dans CI/CD). Cela est normal pour 90 % des scénarios, mais dans certains cas, une seule IP n'est pas suffisante :

Limitation de taux au niveau de l'IP. De nombreuses API et équilibreurs (nginx limit_req, AWS WAF, Cloudflare) limitent le nombre de requêtes depuis une seule adresse par seconde. Les utilisateurs réels viennent de milliers d'IP différentes, tandis que votre test provient d'une seule — et atteint la limite plus tôt que le véritable goulot d'étranglement de l'application.
Test de la logique dépendante de la géographie. CDN, contenu ciblé, prix régionaux, blocages géographiques — tout cela doit être vérifié avec des IP de pays spécifiques, et non depuis le datacenter où se trouve physiquement votre exécuteur de test.
Vérification de l'équilibreur et du réseau anycast. Si l'infrastructure répartit le trafic par région en fonction de l'IP du client, un test depuis une seule adresse ne vérifiera qu'un seul itinéraire, et non l'ensemble du réseau.
Imitation de la répartition réelle du trafic. Le trafic de production est réparti entre les fournisseurs, les sous-réseaux, parfois même entre les opérateurs mobiles — cela influence le comportement des CDN, des caches et de la logique edge.

Il est important de délimiter immédiatement : si vous testez les performances du backend (combien de RPS votre API peut supporter), les proxies ne sont presque jamais nécessaires — ce qui est important, c'est la charge pure, et non la diversité des sources. Les proxies sont nécessaires lorsque le scénario de test dépend précisément de l'adresse IP du client.

Quels proxies conviennent : datacenter, résidentiels, mobiles

Le choix du type de proxy influence directement ce que vous testez — la bande passante de l'infrastructure ou le comportement du système sous des IP « vivantes ».

Type de proxy	Latence et vitesse	Quand utiliser dans les tests de charge
Proxies de datacenter	Latence faible, bande passante élevée	Vérification de la limitation de taux, contournement de la limite « N requêtes par IP », génération d'un grand volume de RPS depuis différents sous-réseaux
Proxies résidentiels	Latence plus élevée, vitesse limitée par le canal de l'utilisateur réel	Test de la logique géographique, vérification des CDN et des systèmes anti-bot qui font plus confiance aux plages résidentielles qu'aux datacenters
Proxies mobiles	Latence la plus élevée, vitesse instable	Scénarios de niche : test d'API mobile, comportement lors du changement fréquent d'IP (les opérateurs changent dynamiquement l'adresse du client)

Pour une vérification pure de RPS et de limitation de taux, les proxies de datacenter sont presque toujours suffisants — ils offrent une latence stable et faible et ne faussent pas les résultats du test par une instabilité réseau externe. Les IP résidentielles et mobiles ajoutent du réalisme dans les tests géographiques, mais introduisent leur propre latence, qu'il faudra prendre en compte lors de l'analyse des métriques — sinon, il est facile de confondre « le réseau proxy ralentit » avec « votre serveur ralentit ».

Configuration des proxies dans k6

k6 est un outil basé sur JavaScript (le moteur est écrit en Go, les scripts sont écrits en JS), et par défaut, il n'y a pas de support intégré pour les proxies HTTP via les options de script : les proxies dans k6 sont définis via des variables d'environnement ou des paramètres système, car sous le capot, k6 utilise le client HTTP de Go.

La méthode la plus simple est d'utiliser des variables d'environnement :

export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"

k6 run script.js

Cette méthode dirigera tout le trafic du test à travers un seul proxy — cela convient si vous avez simplement besoin de sortir d'une IP « blanche » du serveur. Mais si l'objectif est de répartir les utilisateurs virtuels (VU) sur différentes IP, une liste de proxies et une logique de sélection au niveau du script sont nécessaires. Directement, k6 ne prend pas en charge les proxies par VU « par défaut », donc une méthode courante consiste à exécuter plusieurs processus k6 en parallèle, chacun avec sa propre variable d'environnement et son propre proxy du pool :

// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")

for proxy in "${PROXIES[@]}"; do
  HTTP_PROXY="http://user:pass@$proxy" \
  HTTPS_PROXY="http://user:pass@$proxy" \
  k6 run --vus 50 --duration 5m script.js &
done
wait

Cette approche se scale bien en association avec k6 Cloud ou l'orchestration via Kubernetes/Docker Compose — chaque conteneur est lancé avec sa propre variable proxy. Si une rotation IP est nécessaire à l'intérieur d'un seul lancement de script, il est plus logique de prendre des proxies avec rotation du côté du fournisseur de proxy lui-même (session collante avec TTL), plutôt que de créer une rotation à l'intérieur du code JS.

Configuration des proxies dans JMeter

Dans JMeter, les proxies sont configurés nativement, sans variables d'environnement, via l'élément HTTP Request Defaults ou directement dans les paramètres de l'échantillonneur HTTP Request :

Ajoutez un élément de configuration HTTP Request Defaults dans le Thread Group.
Dans les champs Proxy Server, indiquez l'hôte et le port du proxy.
Si le proxy nécessite une authentification — ajoutez un élément HTTP Authorization Manager avec le nom d'utilisateur et le mot de passe pour cet hôte.
Tous les échantillonneurs HTTP Request à l'intérieur du Thread Group hériteront automatiquement des paramètres du proxy.

Pour répartir la charge sur plusieurs proxies dans JMeter, il est pratique d'utiliser CSV Data Set Config — un fichier avec une liste de proxies est inséré dans les variables d'hôte et de port pour chaque thread :

proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3

Connectez CSV Data Set Config au Thread Group, spécifiez les variables ${proxy_host} et ${proxy_port} dans les champs Proxy Server/Proxy Port de l'échantillonneur — chaque thread JMeter prendra sa ligne du fichier et passera par sa propre IP. Pour lancer via la ligne de commande (mode headless, ce qui est recommandé pour les véritables exécutions de charge), les proxies peuvent également être passés en tant que flags :

jmeter -n -t test_plan.jmx -l results.jtl \
  -H proxy-host -P port \
  -u username -a password

Cette méthode définit un proxy commun pour tout le test — pour les scénarios multi-proxy, il faudra quand même utiliser CSV Data Set Config ou le test distribué (plusieurs esclaves JMeter, chacun avec son propre proxy dans la configuration).

Rotation IP et répartition de la charge

Il existe deux approches fondamentalement différentes pour la répartition des IP dans un test de charge :

Fixation statique d'IP à un thread/VU. Chaque utilisateur virtuel reçoit la même IP pour toute la session — imite un utilisateur réel avec une seule adresse. Cela se configure via un proxy à session collante ou simplement une liste fixe dans un fichier CSV ou des variables d'environnement.
Rotation IP à chaque requête. Le proxy change l'adresse sortante à chaque requête HTTP — utile pour tester la protection contre la limitation de taux, mais ne reflète pas bien le comportement réel des utilisateurs, dont l'IP ne change pas chaque seconde.

Pour un test de charge réaliste, dans 90 % des cas, il est plus correct de fixer l'IP à un VU/thread pour toute la session — ainsi, le test reflète honnêtement le comportement de nombreux utilisateurs indépendants, plutôt que de créer un bruit artificiel. La rotation à chaque requête a du sens uniquement dans des scénarios étroits — par exemple, lors d'une vérification ciblée de l'activation des règles de limitation de taux.

Ce que les proxies ne remplaceront certainement pas

Voici le point clé de l'article : les proxies résolvent le problème « depuis quelle IP la requête arrive », mais ne résolvent pas les problèmes que les tests de charge vérifient réellement.

La bande passante de votre exécuteur de test. Si le générateur de charge (la machine elle-même avec k6/JMeter) atteint ses limites CPU, mémoire ou carte réseau — les proxies ne corrigeront pas cela. Les proxies ajoutent un saut réseau supplémentaire et leur propre latence, et ne soulagent pas la charge de l'exécuteur.
La véritable bande passante du serveur testé. Le serveur supporte ou non la charge — l'adresse IP du client n'influence pas cela, sauf en cas de limitation de taux explicite par IP.
La fiabilité des métriques de temps de réponse. Les proxies ajoutent leur propre latence (surtout résidentiels et mobiles), qui apparaîtra dans vos rapports comme une partie du temps de réponse. Si vous ne soustrayez pas la latence du proxy séparément, le rapport final sur la latence sera faussé et inutilisable pour la comparaison avec les métriques de production.
La mise à l'échelle de l'infrastructure pour le trafic réel. Un test de charge avec des proxies montre le comportement sous un certain modèle de requêtes, mais ne remplace pas la planification de capacité, l'auto-scaling et les profils de charge basés sur de véritables journaux de production.
La vérification de la validité de la logique métier sous charge. Conditions de concurrence, blocages en base de données, dégradation des files d'attente — cela relève des tests de concurrence et du profilage, et non du changement d'IP sortante.

Les proxies sont un outil pour une tâche spécifique « émuler le trafic depuis différentes IP », et non un amplificateur universel pour les tests de charge. Si l'objectif est de comprendre combien de RPS le backend peut supporter, les proxies ne sont dans la plupart des cas pas nécessaires : quelques exécuteurs de test sans proxies, avec un keep-alive correctement configuré et un pool de connexions suffisent.

Erreurs typiques lors des tests via des proxies

En pratique, la plupart des problèmes avec les proxies dans les tests de charge se résument à quelques erreurs récurrentes.

Mélange de la latence du proxy avec la latence du service testé. Sans mesure de référence (requête directe sans proxy), il est impossible de comprendre combien de millisecondes le serveur proxy ajoute.
Utilisation de proxies mobiles ou résidentiels là où une bande passante pure est nécessaire. Ces proxies sont limités par le canal réel de l'appareil final et ne supporteront physiquement pas des dizaines de milliers de RPS — pour une charge pure, des proxies de datacenter sont nécessaires.
Piscine d'IP insuffisante pour un grand nombre de VU. Si 5000 utilisateurs virtuels sont répartis sur 10 adresses proxy, le test atteindra quand même la même limitation de taux, simplement avec un délai — le service verra rapidement le modèle « 10 IP, des milliers de requêtes ».
Ignorer les délais d'attente du côté du proxy. Lors d'une charge concurrente élevée, le serveur proxy peut commencer à rejeter les connexions — il est important de vérifier à l'avance les limites des sessions simultanées auprès du fournisseur de proxy.
Lancement du test sans vérification de la liste blanche/authentification. Si le proxy nécessite une authentification par IP, et que le test est lancé depuis CI/CD avec une adresse dynamique de l'exécuteur — les requêtes échoueront avec 407 Proxy Authentication Required, et les résultats du test seront sans signification.

Liste de contrôle avant de lancer le test

Déterminé si la tâche nécessite vraiment différentes IP, ou si un test depuis une seule adresse est suffisant.
Choisi le type de proxy pour la tâche : datacenter pour RPS et limitation de taux, résidentiel/mobile pour la logique géographique.
Effectué une mesure de référence sans proxy, pour séparer la latence réseau de la latence du proxy.
Vérifié les limites des connexions simultanées auprès du fournisseur de proxy pour le niveau de VU requis.
Configuré l'authentification du proxy (nom d'utilisateur/mot de passe ou liste blanche de l'IP de l'exécuteur).
Déterminé si une session collante est nécessaire pour le VU ou une rotation à chaque requête.
Lancé le test sur un court intervalle (1-2 minutes) avant l'exécution complète, pour vérifier la configuration.

Conclusion

Les proxies dans k6 et JMeter sont un moyen efficace d'émuler le trafic depuis différentes adresses IP, de vérifier le comportement de la limitation de taux et de la logique dépendante de la géographie. Mais cela ne remplace pas une planification adéquate des tests de charge : les proxies ne vérifient ni n'améliorent la bande passante du serveur, la stabilité du backend sous charge concurrente, ni la planification de capacité réelle. Utilisez-les de manière ciblée — là où le test dépend réellement de l'adresse IP du client, et non comme un outil universel « pour l'honnêteté ».

Si l'objectif est de tester les limites par IP et d'émuler un trafic massif avec une bande passante élevée, il est raisonnable de commencer par des proxies de datacenter — ils offrent une latence minimale et supportent un grand nombre de sessions simultanées. Pour les tests liés à la logique géographique et à la confiance des systèmes anti-bot dans l'origine du trafic, les proxies résidentiels seront plus adaptés, et pour des scénarios de niche avec du trafic mobile — des IP mobiles.