Proxy para testes automatizados com Selenium, Playwright e Puppeteer

Testes end-to-end que abrem um navegador de verdade (não headless simulado, mas motor de browser real) enfrentam um problema que testes unitários não têm: o site de destino vê a requisição vindo de algum lugar, e esse lugar pode estar na lista de bloqueio antes do teste nem começar.

Configurando proxy em cada ferramenta

Selenium (Python):

from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument('--proxy-server=http://usuario:[email protected]:8080')
driver = webdriver.Chrome(options=options)

Playwright:

browser = playwright.chromium.launch(
    proxy={"server": "http://proxy.exemplo.com:8080", "username": "usuario", "password": "senha"}
)

Puppeteer:

const browser = await puppeteer.launch({
  args: ['--proxy-server=proxy.exemplo.com:8080']
});
const page = await browser.newPage();
await page.authenticate({ username: 'usuario', password: 'senha' });

Por que isso resolve o "funciona em dev, falha em produção"

O cenário clássico: seu ambiente de CI roda em servidor de nuvem (GitHub Actions, GitLab CI, Jenkins em AWS). O site de destino tem proteção anti-bot que bloqueia range de datacenter. O teste falha no CI mas passa no seu notebook (que sai de IP residencial de verdade). Configurar proxy móvel no ambiente de CI iguala a origem de rede entre os dois ambientes — o teste passa a validar o comportamento real, não o comportamento "do jeito que o servidor de CI permite".

Cuidado com timeout

Proxy adiciona latência. Testes com timeout muito apertado (herdados de quando rodavam sem proxy) podem começar a falhar por timing, não por bloqueio. Ajuste o timeout de espera de elemento antes de assumir que o proxy não funcionou.

Próximos passos

Se seu pipeline de CI já tem testes E2E falhando de forma intermitente contra sites com proteção, teste rodar o mesmo suite localmente com e sem proxy — a diferença de taxa de sucesso aparece rápido.