Proxy per tester QA: come verificare un'app web da 20 paesi senza viaggi di lavoro

Hai rilasciato una nuova versione e dopo un'ora ricevi un report di bug: “In Germania viene mostrata una versione errata della pagina”, “Negli Stati Uniti il pagamento non funziona”, “In Russia il contenuto è bloccato”. Riprodurre questo dalla macchina locale è impossibile. È qui che i proxy si trasformano da “strumento per arbitraggisti” a un vero e proprio strumento di lavoro per l'ingegnere QA.

In questo articolo esploreremo come utilizzare correttamente i proxy per testare il comportamento geo-dipendente delle applicazioni, quali tipi di proxy sono adatti per diverse attività di QA e mostreremo scenari passo-passo — dalla verifica del geo-contenuto al testing dei gateway di pagamento.

Perché un tester QA ha bisogno di proxy: scenari reali

Molti team testano ancora il comportamento “internazionale” dell'applicazione solo dalle macchine locali, collegandosi raramente a una VPN. Questo crea una grande zona cieca. La VPN cambia l'indirizzo IP, ma non simula la rete reale dell'utente di un determinato paese — fornitore, tipo di connessione, operatore mobile. I proxy, invece, offrono la possibilità di accedere a Internet tramite un vero indirizzo IP della regione o del tipo di rete desiderato.

Ecco alcune delle sfide specifiche che i tester QA affrontano ogni giorno:

• Geo-contenuto e localizzazione. L'app mostra contenuti diversi a seconda del paese dell'utente: prezzi nella valuta locale, promozioni regionali, sezioni bloccate. Senza proxy, non è possibile verificare questo.
• Sistemi di pagamento regionali. Stripe funziona in modo diverso nell'UE e negli Stati Uniti. PayPal in Brasile è un caso a parte. È necessario testare il flusso di pagamento proprio dal paese desiderato.
• CDN e caching. Una rete di distribuzione dei contenuti può fornire versioni diverse delle risorse da punti diversi. QA deve assicurarsi che la statica venga caricata correttamente per gli utenti in Asia, Europa e America.
• Bloccaggi e restrizioni. In alcuni paesi, alcune funzionalità dell'app sono legalmente inaccessibili. È necessario assicurarsi che il bloccaggio funzioni correttamente e che l'utente veda un messaggio chiaro.
• A/B test geo. Se l'esperimento è avviato solo per gli utenti del Regno Unito, QA deve accedere con un IP britannico e assicurarsi di vedere la variante corretta.
• SEO testing. Meta tag, hreflang, versioni regionali delle pagine — tutto questo deve essere verificato con un IP del paese corrispondente, altrimenti il motore di ricerca e l'utente reale vedranno cose diverse.
• Test della velocità da diverse regioni. Il tempo di caricamento della pagina da Singapore e Mosca può differire di 3-5 volte. I proxy consentono di riprodurre questo all'interno di un unico posto di lavoro.

Quali tipi di proxy sono adatti per il testing

Non tutti i proxy sono ugualmente utili per QA. La scelta del tipo dipende da cosa stai testando. Esaminiamo tre tipi principali e la loro applicabilità per le attività del tester.

Proxy residenziali

Questi sono indirizzi IP di veri utenti domestici provenienti da paesi e città specifici. Il sito li vede come persone normali, non come un data center o una rete aziendale. I proxy residenziali sono la scelta ottimale per la maggior parte delle attività di QA: test del geo-contenuto, A/B test, flussi di pagamento e verifica della localizzazione. Simulano in modo molto preciso un utente reale del paese desiderato.

Vantaggi per QA: alta fiducia da parte di siti e applicazioni, ampia copertura geografica (oltre 100 paesi), possibilità di scegliere una città o un fornitore specifico. Svantaggio — leggermente più lenti rispetto ai proxy dei data center, il che deve essere considerato durante il testing delle prestazioni.

Proxy mobili

Indirizzi IP di operatori mobili (3G/4G/5G). Sono critici quando testi il comportamento dell'app per utenti mobili. Molti siti e applicazioni si comportano in modo diverso quando si accede con un IP mobile: mostrano la versione mobile, contenuti diversi, elaborano diversamente la geolocalizzazione. I proxy mobili sono indispensabili quando si testano applicazioni mobili tramite emulatori o quando si verifica l'adattabilità della versione web.

Inoltre, gli IP mobili sono indirizzi dinamici che un operatore distribuisce a migliaia di abbonati. Ciò significa che il tuo traffico di test non appare sospetto anche con richieste intensive.

Proxy dei data center

I più veloci e economici. Adatti per test di carico, test automatizzati con un gran numero di richieste, verifica degli endpoint API. I proxy dei data center vengono facilmente identificati come “non domestici”, quindi per il testing dell'esperienza utente non sono i migliori — ma per verifiche tecniche e carichi sono la scelta ottimale.

Testare contenuti geo-dipendenti: passo dopo passo

Il testing geo-dipendente è il più comune scenario di utilizzo dei proxy in QA. Ecco come si fa nella pratica, senza scrivere codice, tramite un normale browser.

Passo 1. Ottieni i dati del proxy

Dopo esserti connesso al servizio, ricevi i dati per la connessione: host (IP o dominio), porta, nome utente e password. Per i proxy residenziali, di solito puoi scegliere il paese e la città direttamente nel tuo account o tramite le impostazioni nella stringa di connessione.

Un esempio di stringa di connessione per un proxy residenziale con scelta del paese appare così: l'host contiene il parametro del paese (ad esempio, country-de per la Germania), la porta è standard, nome utente e password sono le tue credenziali.

Passo 2. Configura il proxy nel browser

Per il testing manuale, è più comodo utilizzare estensioni per il browser che consentono di cambiare rapidamente i proxy senza modificare le impostazioni di sistema. Opzioni popolari: Proxy SwitchyOmega (Chrome/Firefox), FoxyProxy (Firefox).

Impostazione passo-passo tramite Proxy SwitchyOmega:

1. Installa l'estensione dal Chrome Web Store.
2. Apri le impostazioni dell'estensione → clicca su “New Profile” → scegli “Proxy Profile”.
3. Inserisci i dati del proxy: Protocol (SOCKS5 o HTTP), Server (host), Port (porta).
4. Se è necessaria l'autenticazione — inserisci nome utente e password nei campi corrispondenti.
5. Salva il profilo e attivalo tramite l'icona dell'estensione nella barra del browser.
6. Visita il sito whatismyip.com o 2ip.ru — assicurati che venga visualizzato l'IP del paese desiderato.

Passo 3. Controlla gli elementi geo-dipendenti

Dopo aver connesso il proxy con la geolocalizzazione desiderata, controlla:

• Lingua dell'interfaccia (determinazione automatica tramite IP)
• Valuta dei prezzi e metodi di pagamento
• Presenza/assenza di determinate sezioni del sito
• Banner e promozioni per una regione specifica
• Correttezza dei tag hreflang (apri il codice sorgente della pagina)
• Redirect ai sottodomini regionali (ad esempio, de.site.com invece di site.com)
• Banner dei cookie (nell'UE obbligatori secondo il GDPR)

Testare da diversi tipi di reti

Oltre alla geografia, è importante testare il comportamento dell'app a seconda del tipo di rete dell'utente. Questo è particolarmente critico per i prodotti con un pubblico globale, dove una parte significativa degli utenti accede tramite dispositivi mobili attraverso reti di operatori.

Reti aziendali e firewall

Gli utenti delle reti aziendali spesso lavorano tramite server proxy aziendali e firewall che bloccano determinati tipi di richieste, connessioni WebSocket o CDN esterni. Per simulare tali condizioni, i tester utilizzano proxy dei data center con impostazioni limitate — questo consente di riprodurre un ambiente aziendale “rigido”.

Cosa controllare in questo scenario: funzionano le notifiche push, i font vengono caricati da Google Fonts (spesso bloccati dai firewall aziendali), l'autenticazione tramite OAuth funziona correttamente.

Reti mobili (3G/4G/5G)

Attraverso i proxy mobili, il tester ottiene non solo un IP mobile, ma anche le reali condizioni della rete mobile: latenza diversa, caratteristiche del NAT, intestazioni specifiche delle richieste dagli operatori mobili. Alcune applicazioni trattano in modo diverso le richieste provenienti da IP mobili — ad esempio, offrono di scaricare l'app invece di mostrare la versione web.

Combina i proxy mobili con un emulatore di dispositivi in Chrome DevTools (modalità Device Toolbar) — in questo modo otterrai un ambiente il più vicino possibile a quello di un utente reale.

Fornitori con accesso limitato

In alcuni paesi, i fornitori di servizi Internet bloccano determinate risorse o rallentano il traffico verso i concorrenti. Se il tuo prodotto opera in mercati con accesso limitato a Internet (Cina, Iran, Russia), il testing tramite proxy residenziali di questi paesi mostrerà la reale disponibilità del servizio.

Testare gateway di pagamento e funzionalità regionali

Il testing dei pagamenti è una delle aree più problematiche per QA nei prodotti internazionali. I sistemi di pagamento utilizzano attivamente la geolocalizzazione per il controllo delle frodi: se l'IP dell'utente non corrisponde al suo indirizzo di pagamento o al paese della carta, la transazione può essere rifiutata o contrassegnata come sospetta.

Il tester QA deve riprodurre proprio tale scenario: accedere con un IP del paese in cui è stata emessa la carta di test e completare l'intero flusso di pagamento. Senza proxy, non è possibile farlo da una sola macchina per più regioni.

Cosa controllare tramite proxy nel testing dei pagamenti

• Visualizzazione dei metodi di pagamento disponibili (PayPal, Stripe, Klarna, SEPA, PIX — ognuno ha i propri per regione)
• Correttezza della conversione della valuta e visualizzazione delle commissioni
• Funzionamento della verifica 3DS da diversi paesi
• Comportamento in caso di non corrispondenza tra IP e paese della carta (deve esserci un messaggio di errore corretto)
• Tasse regionali (IVA nell'UE, GST in Australia) — vengono calcolate correttamente
• Funzionamento dei metodi di pagamento regionali: iDEAL nei Paesi Bassi, Sofort in Germania, Boleto in Brasile

Testare funzionalità regionali (GDPR, CCPA e altri)

I requisiti legali per i prodotti variano a seconda del paese dell'utente. Per QA è importante assicurarsi che l'app riconosca correttamente la giurisdizione e applichi le regole necessarie:

• UE (GDPR): quando si accede da un IP europeo deve apparire un banner sui cookie con la possibilità di rifiutare il tracciamento
• California (CCPA): il link “Do Not Sell My Personal Information” deve essere visualizzato per gli utenti della California
• Russia: se i dati degli utenti russi devono essere memorizzati su server in RF — verifica che la localizzazione funzioni correttamente
• Cina: i servizi esterni (Google Analytics, Facebook Pixel) vengono bloccati quando si accede da un IP cinese e la pagina non si rompe a causa di ciò

Strumenti per QA con supporto proxy

I proxy possono essere utilizzati non solo manualmente nel browser, ma anche integrati in test automatizzati e strumenti QA. Esaminiamo le opzioni principali.

Postman

Per testare l'API tramite proxy in Postman: vai su Impostazioni → Proxy → attiva Usa proxy di sistema o specifica il proxy manualmente. Questo consente di verificare come gli endpoint API rispondono a richieste provenienti da diversi paesi — rilevante per API geo-dipendenti che restituiscono contenuti diversi a seconda dell'IP.

Charles Proxy / Fiddler

Questi strumenti intercettano il traffico HTTP/HTTPS e sono essi stessi proxy. Possono essere configurati per instradare il traffico attraverso un server proxy esterno (upstream proxy). Questo consente di intercettare e analizzare le richieste e testare con l'IP geo-localizzato desiderato.

In Charles: Proxy → Impostazioni proxy esterne → attiva Usa proxy esterno e inserisci i dati del tuo server proxy.

Playwright e Selenium

Per il testing automatizzato, il proxy viene connesso a livello di configurazione del browser. In Playwright questo avviene tramite il parametro proxy durante la creazione del contesto del browser. In Selenium — tramite le opzioni di ChromeDriver specificando il server proxy. Questo consente di eseguire suite di test da decine di paesi in modalità parallela senza impostazioni manuali.

BrowserStack e Sauce Labs

Le piattaforme cloud per il testing hanno strumenti integrati per testare da diverse regioni. Tuttavia, le loro possibilità di scelta di un fornitore specifico o di un tipo di rete (mobile/domestico) sono limitate. I proxy offrono maggiore flessibilità: puoi scegliere paese, città, tipo di IP e fornitore.

k6 e JMeter (test di carico)

Per i test di carico da diverse regioni, i proxy dei data center vengono connessi tramite la configurazione del client HTTP. Questo consente di simulare il carico da utenti reali di diversi paesi e verificare come CDN e bilanciatori di carico gestiscono il traffico distribuito geograficamente.

Checklist: cosa controllare tramite proxy prima del rilascio

Utilizza questa checklist per ogni rilascio che coinvolge un pubblico internazionale. Si consiglia di controllare almeno 3-5 regioni chiave del tuo prodotto.

Errori comuni durante il testing tramite proxy

Anche i tester esperti commettono errori quando lavorano con i proxy. Esaminiamo i più comuni.

Errore 1: Non controllare che il proxy funzioni davvero

Prima di iniziare il testing, controlla sempre l'IP attuale su una risorsa indipendente (whatismyip.com, 2ip.ru, ipleak.net). A volte il proxy è configurato, ma il browser continua a utilizzare la connessione diretta — soprattutto se l'estensione non è attivata o c'è un conflitto con le impostazioni di sistema.

Errore 2: Ignorare le perdite DNS

Le richieste DNS possono bypassare il proxy, rivelando il vero IP del tester. Questo è particolarmente importante quando si testano geo-blocchi — il sito può determinare il paese reale tramite DNS, anche se l'indirizzo IP è stato sostituito. Controlla le perdite DNS tramite ipleak.net o dnsleaktest.com.

Errore 3: Utilizzare un solo proxy per tutte le attività

I proxy dei data center non sono adatti per testare l'esperienza utente — il sito potrebbe mostrare un captcha o una pagina bloccata che un utente reale non vedrà mai. Utilizza il tipo di proxy corretto per ogni attività (vedi tabella sopra).

Errore 4: Dimenticare la cache del browser

Quando si passa tra le geolocalizzazioni, il browser potrebbe restituire contenuti memorizzati nella cache dalla sessione precedente. Pulisci sempre la cache e i cookie prima di passare a un nuovo proxy, oppure utilizza la modalità incognito per ogni nuovo test geo.

Errore 5: Non documentare le sessioni di test

Quando trovi un bug tramite proxy, assicurati di registrare: paese e città del proxy, tipo di proxy (residenziale/mobile), ora del test, versione del browser. Senza questi dati, sarà difficile per lo sviluppatore riprodurre il problema. Aggiungi uno screenshot con la conferma dell'IP nel report del bug.

Errore 6: Confondere proxy e VPN nella documentazione

Nei team si scrive spesso nei report di bug “riprodotto tramite VPN dalla Germania” — ma VPN e proxy funzionano in modo diverso. La VPN cripta tutto il traffico e cambia l'IP a livello di OS, il proxy funziona a livello di applicazione. Per alcuni bug, questa è una differenza fondamentale. Utilizza formulazioni precise nella documentazione.

Conclusione

I proxy per il tester QA non sono un'eccezione, ma uno strumento di base per qualsiasi prodotto con un pubblico internazionale. Consentono di riprodurre le reali condizioni degli utenti di diversi paesi, verificare il contenuto geo-dipendente, i gateway di pagamento, i requisiti legali e il comportamento dei CDN — tutto questo direttamente dal posto di lavoro, senza viaggi di lavoro e macchine remote.

Conclusioni chiave: per testare l'esperienza utente utilizza proxy residenziali, per scenari mobili — proxy mobili, per test di carico e API sono adatti i proxy dei data center. Controlla sempre l'IP prima di iniziare il test, fai attenzione alle perdite DNS e documenta le sessioni di test specificando i parametri geo.

Se desideri iniziare a testare il comportamento geo-dipendente della tua applicazione, ti consigliamo di provare proxy residenziali — offrono la massima precisione nella riproduzione di un utente reale del paese desiderato e supportano una scelta flessibile della geolocalizzazione fino alla città e al fornitore.