Proxy per il test di carico in k6 e JMeter

Quando un test di carico si scontra con un rate-limit, WAF o bilanciamento geografico, il primo pensiero è: "farò girare il traffico da diversi IP". Sembra logico, ma nella pratica i proxy in k6 e JMeter risolvono un insieme ristretto di problemi, mentre il resto deve comunque essere sistemato attraverso l'architettura del test. In questo articolo vedremo come collegare tecnicamente i proxy a entrambi gli strumenti, quali tipi di IP sono adatti e dove finisce la responsabilità del server proxy.

Perché un test di carico ha bisogno di diversi IP

Per impostazione predefinita, k6 e JMeter inviano tutto il traffico da un unico indirizzo IP — il server su cui è in esecuzione il test (o una macchina cloud in CI/CD). Questo va bene per il 90% degli scenari, ma in alcuni casi un solo IP non è sufficiente:

Rate-limiting a livello IP. Molti API e bilanciatori (nginx limit_req, AWS WAF, Cloudflare) limitano il numero di richieste da un singolo indirizzo al secondo. Gli utenti reali provengono da migliaia di IP diversi, mentre il tuo test proviene da uno solo — e si scontra con il limite prima di raggiungere il vero collo di bottiglia dell'applicazione.
Testing della logica geo-dipendente. CDN, contenuti mirati, prezzi regionali, geo-blocchi — tutto questo deve essere verificato con IP di paesi specifici, e non da un data center dove fisicamente si trova il tuo runner di test.
Verifica del bilanciatore e della rete anycast. Se l'infrastruttura distribuisce il traffico per regioni in base all'IP del cliente, un test da un unico indirizzo verificherà solo un percorso, e non l'intera rete.
Simulazione della reale distribuzione del traffico. Il traffico di produzione ha IP distribuiti tra fornitori, sottoreti e, a volte, operatori mobili — questo influisce sul comportamento di CDN, cache e logica edge.

È importante subito chiarire: se stai testando le prestazioni del backend (quanti RPS può gestire la tua API), i proxy quasi mai sono necessari — lì conta il carico puro, non la varietà delle fonti. I proxy sono necessari quando lo scenario di test dipende proprio dall'indirizzo IP del cliente.

Quali proxy sono adatti: datacenter, residenziali, mobili

La scelta del tipo di proxy influisce direttamente su cosa stai testando — la capacità dell'infrastruttura o il comportamento del sistema con IP "vivi".

Tipo di proxy	Ritardo e velocità	Quando utilizzare nei test di carico
Proxy datacenter	Basso ritardo, alta capacità	Verifica del rate-limit, bypass del limite "N richieste da IP", generazione di un alto volume di RPS da diverse sottoreti
Proxy residenziali	Ritardo maggiore, velocità limitata dalla connessione dell'utente reale	Test della logica geo, verifica di CDN e sistemi anti-bot che si fidano di più degli IP residenziali rispetto ai datacenter
Proxy mobili	Ritardo più alto, velocità instabile	Scenari di nicchia: test di API mobili, comportamento con frequenti cambi di IP (gli operatori cambiano dinamicamente l'indirizzo del cliente)

Per una verifica pura di RPS e rate-limit, i proxy datacenter sono quasi sempre sufficienti — offrono un ritardo stabile e basso e non distorcono i risultati del test con instabilità di rete esterne. Gli IP residenziali e mobili aggiungono realismo nei test geo, ma introducono un proprio ritardo che dovrà essere considerato nell'analisi delle metriche — altrimenti è facile confondere "la rete proxy rallenta" con "il tuo server rallenta".

Configurazione del proxy in k6

k6 è uno strumento basato su JavaScript (il motore è scritto in Go, gli script sono scritti in JS), e per impostazione predefinita non c'è supporto integrato per i proxy HTTP tramite le opzioni dello script: i proxy in k6 vengono impostati tramite variabili d'ambiente o impostazioni di sistema, perché sotto il cofano k6 utilizza il client HTTP di Go.

Il modo più semplice è utilizzare le variabili d'ambiente:

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

k6 run script.js

Questo metodo indirizzerà tutto il traffico del test attraverso un unico proxy — va bene se hai solo bisogno di uscire con un IP "bianco" del server. Ma se l'obiettivo è distribuire gli utenti virtuali (VU) su diversi IP, è necessaria una lista di proxy e una logica di selezione a livello di script. k6 non supporta direttamente i proxy per VU "out of the box", quindi una soluzione comune è eseguire più processi k6 in parallelo, ognuno con la propria variabile d'ambiente e il proprio proxy dal 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

Questo approccio si scala bene in combinazione con k6 Cloud o orchestrazione tramite Kubernetes/Docker Compose — ogni contenitore viene avviato con la propria variabile proxy. Se è necessaria la rotazione degli IP all'interno di un'unica esecuzione dello script, è più logico utilizzare proxy con rotazione fornita dal provider di proxy stesso (sessione sticky con TTL), piuttosto che implementare la rotazione all'interno del codice JS.

Configurazione del proxy in JMeter

In JMeter il proxy viene configurato nativamente, senza variabili d'ambiente, tramite l'elemento HTTP Request Defaults o direttamente nelle impostazioni dell'HTTP Request Sampler:

Aggiungi l'elemento di configurazione HTTP Request Defaults nel Thread Group.
Nei campi Proxy Server specifica l'host e la porta del proxy.
Se il proxy richiede autenticazione, aggiungi l'elemento HTTP Authorization Manager con il nome utente e la password per questo host.
Tutti gli HTTP Request Samplers all'interno del Thread Group erediteranno automaticamente le impostazioni del proxy.

Per distribuire il carico su più proxy in JMeter, è comodo utilizzare CSV Data Set Config — un file con l'elenco dei proxy viene inserito nelle variabili dell'host e della porta per ogni 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

Collega il CSV Data Set Config al Thread Group, specifica le variabili ${proxy_host} e ${proxy_port} nei campi Proxy Server/Proxy Port del campionatore — ogni thread di JMeter prenderà la propria riga dal file e andrà attraverso il proprio IP. Per eseguire tramite la riga di comando (modalità headless, consigliata per esecuzioni di carico reali) è possibile anche passare i proxy come flag:

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

Questo metodo imposta un proxy comune per l'intero test — per scenari multi-proxy sarà comunque necessario utilizzare CSV Data Set Config o Distributed Testing (più slave JMeter, ognuno con il proprio proxy nella configurazione).

Rotazione IP e distribuzione del carico

Ci sono due approcci fondamentalmente diversi per la distribuzione degli IP in un test di carico:

Fissazione statica dell'IP al thread/VU. Ogni utente virtuale riceve lo stesso IP per tutta la sessione — simula un utente reale con un solo indirizzo. Si configura tramite sessioni sticky del proxy o semplicemente una lista fissa in CSV/variabili d'ambiente.
Rotazione IP per ogni richiesta. Il proxy cambia l'indirizzo in uscita per ogni richiesta HTTP — utile per testare la protezione contro il rate-limit, ma riflette poco il comportamento reale degli utenti, i cui IP non cambiano ogni secondo.

Per un test di carico realistico, nel 90% dei casi è più corretto fissare l'IP al VU/thread per tutta la sessione — in questo modo il test riflette onestamente il comportamento di molti utenti indipendenti, e non crea rumore artificiale. La rotazione per ogni richiesta ha senso includerla solo in scenari ristretti — ad esempio, durante un controllo mirato dell'attivazione delle regole di rate-limit.

Cosa i proxy non sostituiranno mai

Qui c'è il punto chiave dell'articolo: i proxy risolvono il problema "da quale IP arriva la richiesta", ma non risolvono i problemi che il testing di carico verifica realmente.

La capacità del tuo runner di test. Se il generatore di carico (la macchina stessa con k6/JMeter) si scontra con CPU, memoria o scheda di rete — i proxy non lo risolveranno. I proxy aggiungono un ulteriore salto di rete e il proprio ritardo, e non alleggeriscono il carico dal runner.
La reale capacità del server testato. Il server o regge il carico o non lo regge — l'indirizzo IP del cliente non influisce su questo, tranne nei casi di esplicito rate-limit per IP.
La veridicità delle metriche di tempo di risposta. I proxy aggiungono il proprio ritardo (soprattutto residenziali e mobili), che finirà nei tuoi report come parte del tempo di risposta. Se non si sottrae il ritardo del proxy separatamente, il report finale sulla latenza sarà distorto e non utilizzabile per il confronto con le metriche di produzione.
La scalabilità dell'infrastruttura per il traffico reale. Un test di carico con proxy mostra il comportamento sotto un certo schema di richieste, ma non sostituisce la pianificazione della capacità, l'auto-scaling e i profili di carico costruiti su log di produzione reali.
La verifica della correttezza della logica di business sotto carico. Condizioni di gara, blocchi nel DB, degrado delle code — questo è ciò che si trova nei test di concorrenza e profiling, non cambiando l'IP in uscita.

I proxy sono uno strumento per un compito specifico "emulare il traffico da diversi IP", e non un amplificatore universale per il test di carico. Se l'obiettivo è capire quanti RPS può gestire il backend, i proxy nella maggior parte dei casi non sono affatto necessari: bastano alcuni runner di test senza proxy, con il keep-alive e il pool di connessioni correttamente configurati.

Errori comuni durante il testing tramite proxy

Nella pratica, la maggior parte dei problemi con i proxy nei test di carico si riduce a alcuni errori ricorrenti.

Mescolare il ritardo del proxy con il ritardo del servizio testato. Senza una misurazione baseline (richiesta diretta senza proxy) è impossibile capire quanti millisecondi aggiunge il server proxy stesso.
Utilizzare proxy mobili o residenziali dove è necessaria una pura capacità. Questi proxy sono limitati dalla reale connessione del dispositivo finale e fisicamente non reggeranno decine di migliaia di RPS — per un carico puro sono necessari proxy datacenter.
Pool di IP insufficiente per un alto numero di VU. Se su 5000 utenti virtuali ci sono 10 indirizzi proxy, il test si scontrerà comunque con lo stesso rate-limit, semplicemente con un ritardo — il servizio vedrà rapidamente il pattern "10 IP, migliaia di richieste".
Ignorare i timeout sul lato proxy. Con un carico concorrente elevato, il server proxy potrebbe iniziare a rifiutare le connessioni — è importante chiarire in anticipo i limiti delle sessioni simultanee con il provider di proxy.
Avviare il test senza controllare il whitelisting/autenticazione. Se il proxy richiede autenticazione per IP, e il test viene avviato da CI/CD con un indirizzo dinamico del runner — le richieste falliranno con 407 Proxy Authentication Required, e i risultati del test risulteranno privi di significato.

Checklist prima di avviare il test

Hai determinato se il compito richiede davvero diversi IP, o se è sufficiente un test da un solo indirizzo.
Hai scelto il tipo di proxy adatto al compito: datacenter per RPS e rate-limit, residenziali/mobili per la logica geo.
Hai effettuato una misurazione baseline senza proxy, per separare il ritardo della rete dal ritardo del proxy.
Hai controllato i limiti delle connessioni simultanee con il provider di proxy per il livello di VU necessario.
Hai configurato l'autenticazione del proxy (nome utente/password o whitelisting dell'IP del runner).
Hai deciso se è necessaria una sessione sticky per VU o rotazione per ogni richiesta.
Hai eseguito un test su un breve intervallo (1-2 minuti) prima della corsa completa, per verificare la configurazione.

Conclusione

I proxy in k6 e JMeter sono un modo efficace per emulare il traffico da diversi indirizzi IP, verificare il comportamento del rate-limit e della logica geo-dipendente. Ma non sono un sostituto per una pianificazione adeguata del test di carico: non verificano né migliorano la capacità del server, la stabilità del backend sotto carico concorrente e la pianificazione della capacità reale. Usali in modo mirato — dove il test dipende davvero dall'indirizzo IP del cliente, e non come strumento universale "per correttezza".

Se l'obiettivo è verificare i limiti per IP e simulare un traffico massiccio con alta capacità, è ragionevole iniziare con proxy datacenter — offrono il minimo ritardo e supportano un alto numero di sessioni simultanee. Per test legati alla logica geo e alla fiducia dei sistemi anti-bot nell'origine del traffico, i proxy residenziali sono più adatti, mentre per scenari di nicchia con traffico mobile, sono più indicati gli IP mobili.