Proxies para Testadores de QA: Como Testar Aplicativos Web de 20 Países Sem Viagens

Você lançou uma nova versão e, uma hora depois, chega um relatório de bug: “Na Alemanha, a versão da página está errada”, “Nos EUA, o pagamento não funciona”, “Na Rússia, o conteúdo está bloqueado”. Reproduzir isso a partir da máquina local é impossível. É aqui que os proxies se transformam de “ferramenta de arbitragem” em uma ferramenta de trabalho completa para o engenheiro de QA.

Neste artigo, vamos discutir como usar proxies corretamente para testar o comportamento geograficamente dependente de aplicativos, quais tipos de proxies são adequados para diferentes tarefas de QA, e apresentaremos cenários passo a passo — desde a verificação de geocontento até o teste de gateways de pagamento.

Por que um testador de QA precisa de proxies: cenários reais

Muitas equipes ainda testam o comportamento “internacional” do aplicativo apenas a partir de máquinas locais, ocasionalmente conectando-se a uma VPN. Isso cria uma enorme zona cega. A VPN muda o endereço IP, mas não simula a rede real do usuário de um país específico — provedor, tipo de conexão, operadora móvel. Já os proxies permitem acessar a internet através de um endereço IP real da região ou tipo de rede desejada.

Aqui estão algumas tarefas específicas que os testadores de QA enfrentam todos os dias:

• Geocontento e localização. O aplicativo exibe conteúdo diferente dependendo do país do usuário: preços na moeda local, promoções regionais, seções bloqueadas. Sem proxies, isso não pode ser verificado.
• Sistemas de pagamento regionais. O Stripe funciona de maneira diferente na UE e nos EUA. O PayPal no Brasil é um caso à parte. O fluxo de pagamento deve ser testado exatamente do país necessário.
• CDN e cache. A rede de entrega de conteúdo pode fornecer diferentes versões de recursos de diferentes locais. O QA deve garantir que a estática seja carregada corretamente para usuários na Ásia, Europa e América.
• Bloqueios e restrições. Em alguns países, parte das funções do aplicativo não está disponível por lei. É necessário garantir que o bloqueio funcione corretamente e que o usuário veja uma mensagem compreensível.
• A/B tests geográficos. Se o experimento foi lançado apenas para usuários do Reino Unido, o QA deve acessar com um IP britânico e garantir que veja a versão correta.
• Teste de SEO. Metatags, hreflang, versões regionais de páginas — tudo isso deve ser verificado com um IP do país correspondente, caso contrário, o mecanismo de busca e o usuário real verão coisas diferentes.
• Teste de velocidade de diferentes regiões. O tempo de carregamento da página de Cingapura e de Moscovo pode diferir em 3 a 5 vezes. Os proxies permitem reproduzir isso em um único local de trabalho.

Quais tipos de proxies são adequados para testes

Nem todos os proxies são igualmente úteis para QA. A escolha do tipo depende do que exatamente você está testando. Vamos discutir três tipos principais e sua aplicabilidade para as tarefas do testador.

Proxies residenciais

Esses são endereços IP de usuários reais em casa de países e cidades específicas. O site os vê como pessoas comuns, e não como um data center ou rede corporativa. Proxies residenciais são a escolha ideal para a maioria das tarefas de QA: teste de geocontento, A/B tests, fluxos de pagamento e verificação de localização. Eles imitam com precisão um usuário real do país desejado.

Vantagens para QA: alta confiança por parte de sites e aplicativos, ampla cobertura geográfica (mais de 100 países), possibilidade de escolher uma cidade ou provedor específico. Desvantagem — um pouco mais lentos que os proxies de data center, o que deve ser considerado ao testar desempenho.

Proxies móveis

Endereços IP de operadoras móveis (3G/4G/5G). São críticos quando você testa o comportamento do aplicativo para usuários móveis. Muitos sites e aplicativos se comportam de maneira diferente ao acessar com um IP móvel: mostram a versão móvel, conteúdo diferente, processam a geolocalização de maneira diferente. Proxies móveis são indispensáveis ao testar aplicativos móveis através de emuladores ou ao verificar a responsividade da versão web.

Além disso, os IPs móveis são endereços dinâmicos, que um operador distribui para milhares de assinantes. Isso significa que seu tráfego de teste não parece suspeito, mesmo com solicitações intensas.

Proxies de data center

Os mais rápidos e baratos. Adequados para testes de carga, testes automatizados com um grande número de solicitações, verificação de endpoints de API. Proxies de data center são facilmente detectados como “não residenciais”, portanto, para testar a experiência do usuário, eles são menos adequados — mas para verificações técnicas e carga, essa é a escolha ideal.

Teste de conteúdo geograficamente dependente: passo a passo

O teste geograficamente dependente é o cenário mais comum de uso de proxies em QA. Veja como isso é feito na prática, sem escrever código, através de um navegador comum.

Passo 1. Obtenha os dados do proxy

Após se conectar ao serviço, você recebe os dados de conexão: host (IP ou domínio), porta, login e senha. Para proxies residenciais, geralmente é possível escolher o país e a cidade diretamente no painel do usuário ou através de parâmetros na string de conexão.

Um exemplo de string de conexão para um proxy residencial com escolha de país é assim: o host contém o parâmetro do país (por exemplo, country-de para a Alemanha), a porta é padrão, e o login e senha são suas credenciais.

Passo 2. Configure o proxy no navegador

Para testes manuais, é mais conveniente usar extensões para navegadores que permitem alternar rapidamente entre proxies sem alterar as configurações do sistema. Opções populares: Proxy SwitchyOmega (Chrome/Firefox), FoxyProxy (Firefox).

Configuração passo a passo através do Proxy SwitchyOmega:

1. Instale a extensão da Chrome Web Store.
2. Abra as configurações da extensão → clique em “Novo Perfil” → escolha “Perfil de Proxy”.
3. Insira os dados do proxy: Protocolo (SOCKS5 ou HTTP), Servidor (host), Porta (porta).
4. Se a autenticação for necessária — insira o login e a senha nos campos correspondentes.
5. Salve o perfil e ative-o através do ícone da extensão na barra do navegador.
6. Vá para o site whatismyip.com ou 2ip.ru — verifique se o IP da região desejada está sendo exibido.

Passo 3. Verifique os elementos geograficamente dependentes

Após conectar-se ao proxy com a geolocalização desejada, verifique:

• Idioma da interface (detecção automática pelo IP)
• Moeda dos preços e métodos de pagamento
• Disponibilidade/indisponibilidade de determinadas seções do site
• Banners e promoções para a região específica
• Corretude das tags hreflang (abra o código-fonte da página)
• Redirecionamentos para subdomínios regionais (por exemplo, de.site.com em vez de site.com)
• Banners de cookies (obrigatórios na UE de acordo com o GDPR)

Teste de diferentes tipos de redes

Além da geografia, é importante testar o comportamento do aplicativo dependendo do tipo de rede do usuário. Isso é especialmente crítico para produtos com uma audiência global, onde uma parte significativa dos usuários acessa de dispositivos móveis através de redes de operadoras.

Redes corporativas e firewalls

Usuários de redes corporativas frequentemente trabalham através de servidores proxy da empresa e firewalls que bloqueiam determinados tipos de solicitações, conexões WebSocket ou CDNs externas. Para simular tais condições, os testadores usam proxies de data center com configurações limitadas — isso permite reproduzir um ambiente corporativo “rigoroso”.

O que verificar nesse cenário: se as notificações push funcionam, se as fontes do Google Fonts são carregadas (frequentemente bloqueadas por firewalls corporativos), se a autenticação via OAuth funciona corretamente.

Redes móveis (3G/4G/5G)

Através de proxies móveis, o testador obtém não apenas um IP móvel, mas também as condições reais da rede móvel: diferentes latências, características de NAT, cabeçalhos específicos de solicitações de operadoras móveis. Alguns aplicativos tratam solicitações de IPs móveis de maneira diferente — por exemplo, oferecem baixar o aplicativo em vez de mostrar a versão web.

Combine proxies móveis com um emulador de dispositivos no Chrome DevTools (modo Device Toolbar) — assim você obterá um ambiente o mais próximo possível do usuário real.

Provedores com acesso restrito

Em alguns países, provedores de internet bloqueiam determinados recursos ou diminuem o tráfego para concorrentes. Se seu produto opera em mercados com internet restrita (China, Irã, Rússia), testar através de proxies residenciais desses países mostrará a verdadeira disponibilidade do serviço.

Teste de gateways de pagamento e funções regionais

O teste de pagamento é uma das áreas mais desafiadoras para QA em produtos internacionais. Sistemas de pagamento utilizam ativamente a geolocalização para verificação de fraudes: se o IP do usuário não coincide com seu endereço de pagamento ou país do cartão, a transação pode ser rejeitada ou marcada como suspeita.

O testador de QA deve reproduzir exatamente esse cenário: acessar com um IP do país onde o cartão de teste foi emitido e passar por todo o fluxo de pagamento. Sem proxies, isso não pode ser feito a partir de uma única máquina para várias regiões.

O que verificar através de proxies no teste de pagamento

• Exibição dos métodos de pagamento disponíveis (PayPal, Stripe, Klarna, SEPA, PIX — cada região tem os seus)
• Corretude da conversão de moeda e exibição de taxas
• Funcionamento da verificação 3DS de diferentes países
• Comportamento ao haver discrepância entre IP e país do cartão (deve haver uma mensagem de erro correta)
• Impostos regionais (IVA na UE, GST na Austrália) — estão sendo calculados corretamente?
• Funcionamento de métodos de pagamento regionais: iDEAL na Holanda, Sofort na Alemanha, Boleto no Brasil

Teste de funções regionais (GDPR, CCPA e outros)

Os requisitos legais para produtos variam de acordo com o país do usuário. Para QA, é importante garantir que o aplicativo identifique corretamente a jurisdição e aplique as regras necessárias:

• UE (GDPR): ao acessar com um IP europeu, deve aparecer um banner de cookies com a opção de recusar o rastreamento
• Califórnia (CCPA): o link “Não Venda Minhas Informações Pessoais” deve ser exibido para usuários da Califórnia
• Rússia: se os dados dos usuários russos devem ser armazenados em servidores na Rússia — verifique se a localização funciona corretamente
• China: serviços externos (Google Analytics, Facebook Pixel) estão bloqueados ao acessar com um IP chinês, e a página não quebra por causa disso?

Ferramentas para QA com suporte a proxies

Proxies podem ser usados não apenas manualmente no navegador, mas também integrados em testes automatizados e ferramentas de QA. Vamos considerar as principais opções.

Postman

Para testar APIs através de proxies no Postman: vá para Configurações → Proxy → ative Usar Proxy do Sistema ou especifique o proxy manualmente. Isso permite verificar como os endpoints da API respondem a solicitações de diferentes países — relevante para APIs geograficamente dependentes que retornam conteúdo diferente dependendo do IP.

Charles Proxy / Fiddler

Essas ferramentas interceptam o tráfego HTTP/HTTPS e são, elas próprias, proxies. Elas podem ser configuradas para passar o tráfego através de um servidor proxy externo (upstream proxy). Isso permite interceptar e analisar solicitações ao mesmo tempo em que testa com o IP geolocalizado desejado.

No Charles: Proxy → Configurações de Proxy Externo → ative Usar proxy externo e insira os dados do seu servidor proxy.

Playwright e Selenium

Para testes automatizados, o proxy é conectado no nível de configuração do navegador. No Playwright, isso é feito através do parâmetro proxy ao criar o contexto do navegador. No Selenium — através das opções do ChromeDriver, especificando o servidor proxy. Isso permite executar suítes de teste de dezenas de países em modo paralelo, sem configurações manuais.

BrowserStack e Sauce Labs

Plataformas de teste em nuvem têm ferramentas integradas para testar de diferentes regiões. No entanto, suas opções para escolher um provedor ou tipo de rede específico (móvel/residencial) são limitadas. Proxies oferecem mais flexibilidade: você escolhe o país, cidade, tipo de IP e provedor.

k6 e JMeter (teste de carga)

Para testes de carga de diferentes regiões, proxies de data center são conectados através da configuração do cliente HTTP. Isso permite simular a carga de usuários reais de diferentes países e verificar como CDNs e balanceadores de carga lidam com tráfego geograficamente distribuído.

Checklist: o que verificar através de proxies antes do lançamento

Use este checklist para cada lançamento que afete uma audiência internacional. Recomendamos verificar pelo menos 3 a 5 regiões-chave do seu produto.

Erros comuns ao testar através de proxies

Mesmo testadores experientes cometem erros ao trabalhar com proxies. Vamos discutir os mais comuns.

Erro 1: Não verificar se o proxy realmente funciona

Antes de começar o teste, sempre verifique o IP atual em um recurso independente (whatismyip.com, 2ip.ru, ipleak.net). Às vezes, o proxy está configurado, mas o navegador continua usando a conexão direta — especialmente se a extensão não estiver ativada ou houver conflito com as configurações do sistema.

Erro 2: Ignorar vazamentos de DNS

Consultas DNS podem passar pelo proxy, revelando o IP real do testador. Isso é especialmente importante ao testar bloqueios geográficos — o site pode determinar o país real pelo DNS, mesmo que o endereço IP tenha sido alterado. Verifique vazamentos de DNS através de ipleak.net ou dnsleaktest.com.

Erro 3: Usar um único proxy para todas as tarefas

Proxies de data center não são adequados para testar a experiência do usuário — o site pode mostrar um captcha ou uma página bloqueada que um usuário real nunca veria. Use o tipo correto de proxy para cada tarefa (veja a tabela acima).

Erro 4: Esquecer o cache do navegador

Ao alternar entre geolocalizações, o navegador pode entregar conteúdo em cache da sessão anterior. Sempre limpe o cache e os cookies antes de mudar para um novo proxy, ou use o modo incógnito para cada novo teste geográfico.

Erro 5: Não documentar as sessões de teste

Ao encontrar um bug através de um proxy, sempre registre: o país e a cidade do proxy, o tipo de proxy (residencial/móvel), o horário do teste, a versão do navegador. Sem esses dados, será difícil para o desenvolvedor reproduzir o problema. Adicione uma captura de tela com a confirmação do IP no relatório de bug.

Erro 6: Confundir proxies e VPN na documentação

Nas equipes, é comum escrever em relatórios de bugs “reproduzido através de VPN da Alemanha” — mas VPN e proxies funcionam de maneira diferente. A VPN criptografa todo o tráfego e muda o IP no nível do sistema operacional, enquanto o proxy opera no nível do aplicativo. Para alguns bugs, essa é uma diferença crucial. Use formulações precisas na documentação.

Conclusão

Proxies para o testador de QA não são uma excentricidade, mas uma ferramenta básica para qualquer produto com uma audiência internacional. Eles permitem reproduzir as condições reais de usuários de diferentes países, verificar conteúdo geograficamente dependente, gateways de pagamento, requisitos legais e o comportamento de CDNs — tudo isso diretamente do local de trabalho, sem viagens e máquinas remotas.

Principais conclusões: para testar a experiência do usuário, use proxies residenciais; para cenários móveis, use proxies móveis; para testes de carga e API, proxies de data center são adequados. Sempre verifique o IP antes de iniciar o teste, fique atento a vazamentos de DNS e documente as sessões de teste com os parâmetros geográficos.

Se você deseja começar a testar o comportamento geograficamente dependente do seu aplicativo, recomendamos experimentar proxies residenciais — eles garantem a reprodução mais precisa de um usuário real do país desejado e suportam uma escolha flexível de geolocalização até a cidade e provedor.