Proxy para testes de carga no k6 e JMeter

Quando um teste de carga esbarra em rate-limit, WAF ou balanceamento geográfico, o primeiro pensamento é: "vou gerar tráfego de diferentes IPs". Isso parece lógico, mas na prática, proxies em k6 e JMeter resolvem um conjunto limitado de problemas, e o restante ainda precisa ser corrigido na arquitetura do teste. Neste artigo, vamos discutir como conectar tecnicamente proxies a ambas as ferramentas, quais tipos de IP são adequados para isso e onde termina a responsabilidade do servidor proxy.

Por que um teste de carga precisa de diferentes IPs

Por padrão, k6 e JMeter enviam todo o tráfego de um único endereço IP — o servidor onde o teste está sendo executado (ou uma máquina em nuvem no CI/CD). Isso é normal para 90% dos cenários, mas em alguns casos, um único IP não é suficiente:

Rate-limiting no nível de IP. Muitas APIs e balanceadores (nginx limit_req, AWS WAF, Cloudflare) limitam o número de solicitações de um único endereço por segundo. Usuários reais vêm de milhares de IPs diferentes, enquanto seu teste vem de um único — e esbarra no limite antes de atingir o verdadeiro gargalo do aplicativo.
Teste de lógica dependente de geolocalização. CDN, conteúdo direcionado, preços regionais, geo-bloqueios — tudo isso precisa ser verificado com IPs de países específicos, e não de um datacenter onde seu executor de teste está fisicamente localizado.
Verificação do balanceador e rede anycast. Se a infraestrutura distribui o tráfego por regiões com base no IP do cliente, um teste de um único endereço verificará apenas um caminho, e não toda a rede.
Simulação da distribuição real de tráfego. O tráfego de produção tem IPs distribuídos entre provedores, sub-redes, e às vezes entre operadoras móveis — isso afeta o comportamento de CDN, caches e lógica de edge.

É importante delimitar desde o início: se você está testando o desempenho do backend (quantos RPS seu API suportará), proxies quase nunca são necessários — o que importa é a carga pura, e não a diversidade de fontes. Proxies são necessários quando o cenário de teste depende especificamente do endereço IP do cliente.

Quais proxies são adequados: datacenter, residencial, móvel

A escolha do tipo de proxy afeta diretamente o que exatamente você está testando — a capacidade da infraestrutura ou o comportamento do sistema sob IPs "reais".

Tipo de Proxy	Latência e velocidade	Quando usar em testes de carga
Proxies de datacenter	Baixa latência, alta capacidade	Verificação de rate-limit, contorno do limite "N solicitações de um IP", geração de um grande volume de RPS de diferentes sub-redes
Proxies residenciais	Latência maior, velocidade limitada pela conexão do usuário real	Teste de lógica geográfica, verificação de CDN e sistemas anti-bot que confiam mais em faixas residenciais do que em datacenters
Proxies móveis	A maior latência, velocidade instável	Cenários de nicho: teste de API móvel, comportamento com troca frequente de IP (operadoras mudam o endereço do cliente dinamicamente)

Para uma verificação pura de RPS e rate-limit, quase sempre é suficiente usar proxies de datacenter — eles oferecem baixa latência estável e não distorcem os resultados do teste com instabilidade de rede externa. IPs residenciais e móveis adicionam realismo em testes geográficos, mas introduzem sua própria latência, que deve ser considerada na análise das métricas — caso contrário, é fácil confundir "a rede proxy está lenta" com "seu servidor está lento".

Configuração de proxies no k6

k6 é uma ferramenta em JavaScript (o motor é escrito em Go, os scripts são escritos em JS), e por padrão não há suporte embutido para proxies HTTP através das opções do script: proxies no k6 são definidos através de variáveis de ambiente ou configurações do sistema, porque por baixo dos panos o k6 usa o cliente HTTP do Go.

A maneira mais simples é através de variáveis de ambiente:

export HTTP_PROXY="http://login:senha@proxy-host:porta"
export HTTPS_PROXY="http://login:senha@proxy-host:porta"

k6 run script.js

Este método direcionará todo o tráfego do teste através de um único proxy — adequado se você apenas precisa sair com um IP "branco" do servidor. Mas se a tarefa é distribuir usuários virtuais (VU) por diferentes IPs, você precisará de uma lista de proxies e lógica de seleção no nível do script. O k6 não suporta diretamente proxies por VU "pronto para uso", então uma abordagem comum é executar vários processos k6 em paralelo, cada um com sua própria variável de ambiente e seu proxy de um pool:

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

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

Essa abordagem escala bem em conjunto com o k6 Cloud ou orquestração via Kubernetes/Docker Compose — cada contêiner é iniciado com sua própria variável de proxy. Se você precisar de rotação de IP dentro de uma única execução de script, é mais lógico usar proxies com rotação do lado do próprio provedor de proxy (sessão sticky com TTL), em vez de implementar a rotação dentro do código JS.

Configuração de proxies no JMeter

No JMeter, proxies são configurados de forma nativa, sem variáveis de ambiente, através do elemento HTTP Request Defaults ou diretamente nas configurações do HTTP Request Sampler:

Adicione o elemento de configuração HTTP Request Defaults no Thread Group.
Nos campos Proxy Server, insira o host e a porta do proxy.
Se o proxy exigir autenticação — adicione o elemento HTTP Authorization Manager com o login e a senha para esse host.
Todos os HTTP Request Samplers dentro do Thread Group herdarão automaticamente as configurações do proxy.

Para distribuir a carga entre vários proxies no JMeter, é conveniente usar CSV Data Set Config — um arquivo com a lista de proxies é inserido nas variáveis de host e porta para cada 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

Conecte o CSV Data Set Config ao Thread Group, insira as variáveis ${proxy_host} e ${proxy_port} nos campos Proxy Server/Proxy Port do sampler — cada thread do JMeter pegará sua linha do arquivo e irá através de seu IP. Para executar via linha de comando (modo headless, o que é recomendado para execuções reais de carga), os proxies também podem ser passados como flags:

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

Este método define um proxy comum para todo o teste — para cenários com múltiplos proxies, você ainda precisará usar CSV Data Set Config ou Distributed Testing (vários escravos do JMeter, cada um com seu proxy na configuração).

Rotação de IP e distribuição de carga

Existem duas abordagens fundamentalmente diferentes para a distribuição de IP em um teste de carga:

Fixação estática de IP para a thread/VU. Cada usuário virtual recebe o mesmo IP durante toda a sessão — imita um usuário real com um único endereço. É configurado através de sessão sticky do proxy ou simplesmente uma lista fixa em CSV/variáveis de ambiente.
Rotação de IP a cada solicitação. O proxy muda o endereço de saída a cada solicitação HTTP — útil para verificar proteção contra rate-limit, mas reflete mal o comportamento real dos usuários, cujos IPs não mudam a cada segundo.

Para um teste de carga realista, em 90% dos casos, é mais correto fixar o IP para VU/thread durante toda a sessão — assim, o teste reflete honestamente o comportamento de muitos usuários independentes, em vez de criar um ruído artificial. A rotação a cada solicitação deve ser incluída apenas em cenários específicos — por exemplo, ao verificar especificamente a ativação de regras de rate-limit.

O que os proxies definitivamente não substituem

Aqui está o ponto chave do artigo: proxies resolvem o problema de "de qual IP vem a solicitação", mas não resolvem os problemas que o teste de carga realmente verifica.

A capacidade do seu executor de teste. Se o gerador de carga (a própria máquina com k6/JMeter) esbarra na CPU, memória ou placa de rede — proxies não resolverão isso. Proxies adicionam um salto de rede extra e sua própria latência, em vez de aliviar a carga do executor.
A verdadeira capacidade do servidor testado. O servidor ou suporta a carga ou não — o endereço IP do cliente não influencia isso, exceto em casos de rate-limit explícito por IP.
A precisão das métricas de tempo de resposta. Proxies adicionam sua própria latência (especialmente residenciais e móveis), que será incluída em seus relatórios como parte do tempo de resposta. Se a latência do proxy não for subtraída separadamente, o relatório final de latência será distorcido e inadequado para comparação com métricas de produção.
Escalonamento da infraestrutura para tráfego real. Um teste de carga com proxies mostra o comportamento sob um padrão específico de solicitações, mas não substitui o planejamento de capacidade, autoescalonamento e perfis de carga baseados em logs de produção reais.
Verificação da correção da lógica de negócios sob carga. Condições de corrida, bloqueios em bancos de dados, degradação de filas — isso é abordado por testes de concorrência e profiling, e não pela troca do IP de saída.

Proxies são uma ferramenta para uma tarefa específica: "emular tráfego de diferentes IPs", e não um amplificador universal para testes de carga. Se o objetivo é entender quantos RPS o backend suportará, proxies na maioria dos casos não são necessários: basta alguns executores de teste sem proxies, com keep-alive e pool de conexões configurados corretamente.

Erros típicos ao testar através de proxies

Na prática, a maioria dos problemas com proxies em testes de carga se resume a alguns erros recorrentes.

Confundir a latência do proxy com a latência do serviço testado. Sem uma medição de baseline (solicitação direta sem proxy), é impossível entender quantos milissegundos o próprio servidor proxy adiciona.
Usar proxies móveis ou residenciais onde é necessária capacidade pura. Esses proxies são limitados pela conexão real do dispositivo final e fisicamente não suportarão dezenas de milhares de RPS — para carga pura, proxies de datacenter são necessários.
Piscina de IPs insuficiente para um grande número de VUs. Se 5000 usuários virtuais têm apenas 10 endereços de proxy, o teste ainda esbarrará no mesmo rate-limit, apenas com latência — o serviço rapidamente verá o padrão "10 IPs, milhares de solicitações".
Ignorar os timeouts do lado do proxy. Sob alta carga concorrente, o servidor proxy pode começar a rejeitar conexões — é importante esclarecer previamente os limites de sessões simultâneas com o provedor de proxy.
Executar o teste sem verificar whitelisting/autenticação. Se o proxy requer autenticação por IP, e o teste é iniciado a partir de CI/CD com um endereço dinâmico do executor — as solicitações falharão com 407 Proxy Authentication Required, e os resultados do teste se tornarão sem sentido.

Checklist antes de iniciar o teste

Definimos se a tarefa realmente requer diferentes IPs, ou se um teste de um único endereço é suficiente.
Escolhemos o tipo de proxy para a tarefa: datacenter para RPS e rate-limit, residencial/móvel para lógica geográfica.
Fizemos uma medição de baseline sem proxy, para separar a latência da rede da latência do proxy.
Verificamos os limites de conexões simultâneas com o provedor de proxy para o nível desejado de VUs.
Configuramos a autenticação do proxy (login/senha ou whitelisting do IP do executor).
Decidimos se uma sessão sticky é necessária para VUs ou rotação a cada solicitação.
Executamos um teste em um intervalo curto (1-2 minutos) antes do teste completo, para verificar a configuração.

Conclusão

Proxies em k6 e JMeter são uma maneira eficaz de emular tráfego de diferentes endereços IP, verificar o comportamento de rate-limit e lógica dependente de geolocalização. Mas isso não substitui um planejamento adequado de testes de carga: a capacidade do servidor, a estabilidade do backend sob carga concorrente e o verdadeiro planejamento de capacidade não são verificados ou melhorados por proxies. Use-os de forma pontual — onde o teste realmente depende do endereço IP do cliente, e não como uma ferramenta universal "para honestidade".

Se a tarefa é verificar limites por IP e simular tráfego em massa com alta capacidade, é razoável começar com proxies de datacenter — eles oferecem a menor latência e suportam um grande número de sessões simultâneas. Para testes que dependem de lógica geográfica e confiança de sistemas anti-bot na origem do tráfego, é melhor usar proxies residenciais, e para cenários de nicho com tráfego móvel — IPs móveis.