Proxy para pruebas de carga en k6 y JMeter

Cuando una prueba de carga se encuentra con un rate-limit, WAF o balanceo geográfico, el primer pensamiento es: "voy a lanzar tráfico desde diferentes IP". Suena lógico, pero en la práctica, los proxies en k6 y JMeter resuelven un conjunto limitado de tareas, y el resto aún necesita ser arreglado con la arquitectura de la prueba. En este artículo, analizaremos cómo conectar técnicamente proxies a ambas herramientas, qué tipos de IP son adecuados para esto y dónde termina la responsabilidad del servidor proxy.

¿Por qué necesita diferentes IP una prueba de carga?

Por defecto, k6 y JMeter envían todo el tráfico desde una sola dirección IP: el servidor donde se ejecuta la prueba (o una máquina en la nube en CI/CD). Esto es normal para el 90% de los escenarios, pero en algunos casos, una sola IP no es suficiente:

Rate-limiting a nivel de IP. Muchas API y balanceadores (nginx limit_req, AWS WAF, Cloudflare) limitan el número de solicitudes desde una sola dirección por segundo. Los usuarios reales provienen de miles de diferentes IP, mientras que su prueba proviene de una sola — y se encuentra con el límite antes de llegar al verdadero cuello de botella de la aplicación.
Pruebas de lógica geodependiente. CDN, contenido dirigido, precios regionales, geo-bloqueos — todo esto necesita ser verificado con IP de países específicos, no desde un centro de datos donde físicamente se encuentra su corredor de pruebas.
Verificación del balanceador y red anycast. Si la infraestructura distribuye el tráfico por regiones basándose en la IP del cliente, una prueba desde una sola dirección solo verificará una ruta, no toda la red.
Simulación de la distribución real del tráfico. El tráfico de producción tiene IP distribuidas entre proveedores, subredes, a veces entre operadores móviles — esto afecta el comportamiento de CDN, cachés y lógica de borde.

Es importante delimitar desde el principio: si está probando el rendimiento del backend (cuántos RPS puede soportar su API), los proxies casi nunca son necesarios — lo que importa es la carga pura, no la diversidad de fuentes. Los proxies son necesarios cuando el escenario de prueba depende específicamente de la dirección IP del cliente.

Qué proxies son adecuados: datacenter, residenciales, móviles

La elección del tipo de proxy afecta directamente a lo que está probando: la capacidad de la infraestructura o el comportamiento del sistema bajo IP "vivas".

Tipo de proxy	Latencia y velocidad	Cuándo usar en pruebas de carga
Proxies de datacenter	Baja latencia, alta capacidad	Verificación de rate-limit, eludir el límite de "N solicitudes desde IP", generar un gran volumen de RPS desde diferentes subredes
Proxies residenciales	Latencia más alta, velocidad limitada por el canal del usuario real	Prueba de lógica geográfica, verificación de CDN y sistemas anti-bot que confían más en rangos residenciales que en datacenter
Proxies móviles	La latencia más alta, velocidad inestable	Escenarios nicho: prueba de API móvil, comportamiento con cambios frecuentes de IP (los operadores cambian la dirección del cliente dinámicamente)

Para una verificación pura de RPS y rate-limit, casi siempre son suficientes los proxies de datacenter — ofrecen una latencia baja y estable y no distorsionan los resultados de la prueba con inestabilidad de red externa. Las IP residenciales y móviles añaden realismo en las pruebas geográficas, pero introducen su propia latencia, que deberá tenerse en cuenta al analizar las métricas — de lo contrario, es fácil confundir "la red proxy está lenta" con "su servidor está lento".

Configuración de proxies en k6

k6 es una herramienta en JavaScript (el motor está escrito en Go, los scripts se escriben en JS), y por defecto no hay soporte integrado para proxies HTTP a través de opciones de script: los proxies en k6 se configuran a través de variables de entorno o configuraciones del sistema, porque bajo el capó, k6 utiliza el cliente HTTP de Go.

La forma más sencilla es usar variables de entorno:

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

k6 run script.js

Este método dirigirá todo el tráfico de la prueba a través de un solo proxy — es adecuado si solo necesita salir con una IP "blanca" del servidor. Pero si la tarea es distribuir usuarios virtuales (VU) entre diferentes IP, se necesita una lista de proxies y lógica de selección a nivel de script. Directamente, k6 no soporta proxies por VU "de fábrica", por lo que una solución común es ejecutar múltiples procesos k6 en paralelo, cada uno con su propia variable de entorno y su propio proxy del grupo:

// 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

Este enfoque se escala bien en conjunto con k6 Cloud o orquestación a través de Kubernetes/Docker Compose — cada contenedor se inicia con su propia variable de proxy. Si se necesita rotación de IP dentro de una sola ejecución de script, es más lógico obtener proxies con rotación del propio proveedor de proxies (sesión pegajosa con TTL), en lugar de implementar la rotación dentro del código JS.

Configuración de proxies en JMeter

En JMeter, los proxies se configuran de manera nativa, sin variables de entorno, a través del elemento HTTP Request Defaults o directamente en la configuración del HTTP Request Sampler:

Agregue el elemento de configuración HTTP Request Defaults en el Thread Group.
En los campos Proxy Server, indique el host y el puerto del proxy.
Si el proxy requiere autenticación, agregue el elemento HTTP Authorization Manager con el nombre de usuario y la contraseña para este host.
Todos los HTTP Request Samplers dentro del Thread Group heredarán automáticamente la configuración del proxy.

Para distribuir la carga entre varios proxies en JMeter, es conveniente usar CSV Data Set Config — un archivo con la lista de proxies se inserta en las variables de host y puerto para cada hilo:

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

Conecte CSV Data Set Config al Thread Group, indique las variables ${proxy_host} y ${proxy_port} en los campos Proxy Server/Proxy Port del sampler — cada hilo de JMeter tomará su fila del archivo y pasará a través de su IP. Para ejecutar a través de la línea de comandos (modo sin cabeza, que se recomienda para ejecuciones de carga reales), los proxies también se pueden pasar como flags:

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

Este método establece un único proxy común para toda la prueba — para escenarios de múltiples proxies, aún será necesario utilizar CSV Data Set Config o Distributed Testing (varios esclavos de JMeter, cada uno con su propio proxy en la configuración).

Rotación de IP y distribución de carga

Hay dos enfoques fundamentalmente diferentes para la distribución de IP en una prueba de carga:

Asignación estática de IP a un hilo/VU. Cada usuario virtual recibe la misma IP durante toda la sesión — imita a un usuario real con una sola dirección. Se configura a través de un proxy de sesión pegajosa o simplemente una lista fija en CSV/variables de entorno.
Rotación de IP en cada solicitud. El proxy cambia la dirección de salida en cada solicitud HTTP — útil para verificar la protección contra rate-limit, pero refleja débilmente el comportamiento real de los usuarios, cuyos IP no cambian cada segundo.

Para una prueba de carga realista, en el 90% de los casos es más correcto asignar IP a VU/hilo durante toda la sesión — así, la prueba refleja honestamente el comportamiento de muchos usuarios independientes, en lugar de crear ruido artificial. La rotación en cada solicitud tiene sentido incluirla solo en escenarios específicos — por ejemplo, al verificar específicamente la activación de las reglas de rate-limit.

Lo que los proxies definitivamente no reemplazarán

Aquí está el punto clave del artículo: los proxies resuelven el problema de "desde qué IP llega la solicitud", pero no resuelven los problemas que realmente verifica la prueba de carga.

La capacidad de su corredor de pruebas. Si el generador de carga (la máquina misma con k6/JMeter) se encuentra con CPU, memoria o tarjeta de red — los proxies no lo solucionarán. Los proxies añaden un salto de red adicional y su propia latencia, en lugar de aliviar la carga del corredor.
La capacidad real del servidor que se está probando. El servidor o soporta la carga o no — la dirección IP del cliente no influye en esto, excepto en casos de rate-limit explícito por IP.
La validez de las métricas de tiempo de respuesta. Los proxies añaden su propia latencia (especialmente los residenciales y móviles), que aparecerá en sus informes como parte del tiempo de respuesta. Si no se resta la latencia del proxy por separado, el informe final de latencia estará distorsionado y no será adecuado para comparaciones con métricas de producción.
La escalabilidad de la infraestructura para tráfico real. Una prueba de carga con proxies muestra el comportamiento bajo un patrón específico de solicitudes, pero no reemplaza la planificación de capacidad, escalado automático y perfiles de carga construidos sobre registros de producción reales.
La verificación de la lógica de negocio correcta bajo carga. Condiciones de carrera, bloqueos en la base de datos, degradación de colas — esto se encuentra en pruebas de concurrencia y perfilado, no en cambiar la IP de salida.

Los proxies son una herramienta para la tarea específica de "emular tráfico desde diferentes IP", no un amplificador universal de pruebas de carga. Si el objetivo es entender cuántos RPS puede soportar el backend, los proxies en la mayoría de los casos no son necesarios: basta con unos pocos corredores de pruebas sin proxies, con keep-alive y un grupo de conexiones correctamente configurados.

Errores comunes al probar a través de proxies

En la práctica, la mayoría de los problemas con proxies en pruebas de carga se reducen a algunos errores recurrentes.

Mezclar la latencia del proxy con la latencia del servicio que se está probando. Sin una medición de referencia (solicitud directa sin proxy), es imposible entender cuántos milisegundos añade el propio servidor proxy.
Usar proxies móviles o residenciales donde se necesita capacidad pura. Tales proxies están limitados por el canal real del dispositivo final y físicamente no soportarán decenas de miles de RPS — para carga pura se necesitan proxies de datacenter.
Poca cantidad de IP para un gran número de VU. Si hay 10 direcciones proxy para 5000 usuarios virtuales, la prueba se encontrará con el mismo rate-limit, solo que con retraso — el servicio verá rápidamente el patrón "10 IP, miles de solicitudes".
Ignorar los tiempos de espera del lado del proxy. Con una alta carga concurrente, el servidor proxy puede comenzar a rechazar conexiones — es importante aclarar de antemano los límites de sesiones simultáneas con el proveedor de proxies.
Ejecutar la prueba sin verificar whitelisting/autenticación. Si el proxy requiere autenticación por IP, y la prueba se ejecuta desde CI/CD con una dirección dinámica del corredor — las solicitudes fallarán con 407 Proxy Authentication Required, y los resultados de la prueba serán inútiles.

Lista de verificación antes de ejecutar la prueba

Determinar si la tarea realmente requiere diferentes IP, o si es suficiente con una prueba desde una sola dirección.
Elegir el tipo de proxy adecuado para la tarea: datacenter para RPS y rate-limit, residencial/móvil para lógica geográfica.
Realizar una medición de referencia sin proxy, para separar la latencia de la red de la latencia del proxy.
Verificar los límites de conexiones simultáneas con el proveedor de proxies para el nivel de VU requerido.
Configurar la autenticación del proxy (nombre de usuario/contraseña o whitelisting de la IP del corredor).
Decidir si se necesita una sesión pegajosa en VU o rotación en cada solicitud.
Ejecutar la prueba en un intervalo corto (1-2 minutos) antes de la ejecución completa, para verificar la configuración.

Conclusión

Los proxies en k6 y JMeter son una forma efectiva de emular tráfico desde diferentes direcciones IP, verificar el comportamiento del rate-limit y la lógica geodependiente. Pero esto no reemplaza una planificación adecuada de la prueba de carga: los proxies no verifican ni mejoran la capacidad del servidor, la estabilidad del backend bajo carga concurrente y la planificación de capacidad real. Úselos de manera puntual — donde la prueba realmente dependa de la dirección IP del cliente, y no como una herramienta universal "para la honestidad".

Si la tarea es verificar los límites por IP y simular tráfico masivo con alta capacidad, es razonable comenzar con proxies de datacenter — ofrecen la mínima latencia y soportan un gran número de sesiones simultáneas. Para pruebas que dependen de la lógica geográfica y la confianza de los sistemas anti-bot en el origen del tráfico, son más adecuados los proxies residenciales, y para escenarios nicho con tráfico móvil — IP móviles.