DrissionPage com Proxies Residenciais: Guia Prático de Web Scraping

Se você já alternou entre requests e Selenium no mesmo projeto — copiando cookies de um para o outro, reescrevendo seletores, mantendo dois stacks de dependências — então DrissionPage foi feito para você. É um framework Python que unifica HTTP estilo requests e controle de Chromium via CDP num único objeto, compartilhando cookies e estado entre os dois modos. Neste guia mostramos como integrar DrissionPage com proxies residenciais da ProxyHat, do HTTP simples ao navegador headless, com rotação de IP por sessão e captura de XHR de fundo.

Nota legal: este guia cobre coleta de dados públicos. Raspar dados atrás de login ou em violação de Termos de Serviço pode infringir o CFAA nos EUA e o GDPR na UE. Respeite robots.txt, limites de taxa e prefira APIs oficiais quando existirem.

O que é DrissionPage e por que importa para quem usa proxies

DrissionPage é um framework de automação web em Python, open-source, mantido ativamente no GitHub. A premissa é simples: a maioria dos scrapers precisa de dois modos — HTTP rápido para páginas estáticas e navegador para conteúdo renderizado por JavaScript — e alternar entre eles não deveria exigir duas bibliotecas, dois objetos e cookies copiados à mão.

Para quem usa proxies, isso é especialmente relevante. Alvos difíceis (SERPs, e-commerce com anti-bot, redes sociais) exigem IPs residenciais que não pareçam datacenter. Mas nem toda página precisa de navegador: muitas respostas JSON podem ser capturadas em HTTP puro, economizando memória e tempo. Com DrissionPage você define o proxy uma vez, alterna entre modos conforme a página exige e mantém o mesmo IP de saída para a sessão inteira — o que evita disparar alertas de anti-bot por troca súbita de fingerprint.

O framework expõe três classes principais:

A economia é concreta: rodar 100 requisições HTTP consome uma fração da RAM de 100 abas de Chromium. Em fleet com 100 sessões concorrentes, a diferença entre sempre-browser e HTTP-quando-possível pode significar 8 GB versus 40 GB de RAM por node.

Contexto técnico: por que o problema existe

Stacks tradicionais de scraping em Python se dividem em dois mundos. O mundo HTTP (requests, httpx, aiohttp) é rápido, leve e fácil de proxificar — mas não executa JavaScript. O mundo browser (Selenium, Playwright, Puppeteer) renderiza tudo, mas pesa 10–20x mais por instância e exige gerenciamento de processo Chromium.

O problema aparece quando um único fluxo mistura os dois: você faz login via HTTP (rápido), mas a página pós-login é uma SPA que precisa de browser. Com ferramentas separadas, você copia cookies manualmente, recria headers e ora perde a sessão, ora dispara um novo fingerprint que o anti-bot detecta. DrissionPage resolve isso porque WebPage mantém cookies e storage compartilhados entre os dois motores num único objeto.

Para alvos com proteção avançada (Cloudflare, PerimeterX, Akamai Bot Manager), o navegador sozinho não basta — o IP de saída precisa ser residencial ou móvel. Datacenter IPs são bloqueados na camada de rede antes mesmo do challenge renderizar. É aí que proxies residenciais entram: cada requisição sai de um IP de ISP real, com ASN residencial, passando pela primeira camada de geofiltro.

A API idiomática do DrissionPage

Localizadores com ele() e eles()

DrissionPage usa uma sintaxe de locator própria, mais concisa que XPath puro. O método ele() retorna um elemento; eles() retorna uma lista.

from DrissionPage import WebPage

page = WebPage()
page.get('https://exemplo.com')

# Por atributo com sintaxe @
titulo = page.ele('@class=product-title')

# Por tag + atributo
input_busca = page.ele('tag:input@name=q')

# XPath completo quando necessário
precos = page.eles('xpath://div[@class="price"]//span')

# Texto do elemento
print(titulo.text)

A sintaxe tag:input@name=q é equivalente a //input[@name="q"] em XPath, mas mais legível. Para atributos parciais use @class~=price (contém) ou @text()=Comprar (texto exato).

ChromiumOptions para configurar o browser

ChromiumOptions controla argumentos do Chromium, path do binário, proxy, user-agent e extensões. É por aqui que injetamos o proxy no modo browser.

from DrissionPage import ChromiumOptions, ChromiumPage

co = ChromiumOptions()
co.set_proxy('http://gate.proxyhat.com:8080')
co.set_argument('--no-sandbox')
co.set_argument('--disable-gpu')
co.set_user_agent('Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...')
co.headless(True)

page = ChromiumPage(co)

Captura de XHR/JSON com listen.start()

Um dos recursos mais poderosos do DrissionPage é o listen, que intercepta requisições de rede em background via CDP. Em vez de parsear HTML renderizado, você captura diretamente o JSON que a SPA carrega via XHR.

page.listen.start('api/produtos')  # filtra URLs que contêm esse trecho
page.get('https://loja.exemplo.com/catalogo')

# wait() bloqueia até o próximo pacote que casar
packet = page.listen.wait()
print(packet.url)       # URL completa
print(packet.request.body)   # corpo da requisição
print(packet.response.body)  # corpo da resposta (JSON decodificado)

page.listen.stop()

Isso transforma scraping de SPA: em vez de simular cliques e esperar renderização, você descobre o endpoint interno da API e captura a resposta JSON diretamente. Muitas vezes essa API é acessível também via HTTP puro — permitindo escalar para SessionPage depois.

Configurando proxies no DrissionPage

SessionPage: set_proxies()

No modo HTTP, o proxy é configurado via set_proxies() no objeto de sessão. O formato é o mesmo de requests.

from DrissionPage import SessionPage

page = SessionPage()
page.set.proxies('http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080')
page.get('https://httpbin.org/ip')
print(page.html)

ChromiumPage: ChromiumOptions.set_proxy()

No modo browser, o proxy é injetado nos argumentos do Chromium via set_proxy(). O Chromium aplica o proxy a todas as conexões, incluindo XHR de fundo.

from DrissionPage import ChromiumOptions, ChromiumPage

co = ChromiumOptions()
co.set_proxy('http://user-country-DE-city-berlin-session-sess01:pass@gate.proxyhat.com:8080')
page = ChromiumPage(co)
page.get('https://httpbin.org/ip')

Por que residencial e não datacenter? Alvos com anti-bot verificam o ASN do IP de saída. IPs de AWS, DigitalOcean ou OVH são classificados como datacenter e frequentemente bloqueados antes do challenge. IPs residenciais têm ASN de ISPs reais (Comcast, Deutsche Telekom, Vivo) e passam pela primeira camada de filtro. Veja locais disponíveis na ProxyHat.

Exemplo executável: WebPage com escalonamento HTTP → Chromium

O cenário: uma loja e-commerce tem uma página de listagem estática (HTML puro) e uma página de detalhe renderizada por React. Começamos em HTTP para a listagem, capturamos os links, e escalamos para Chromium apenas nos detalhes — tudo com o mesmo IP residencial de saída.

from DrissionPage import WebPage, ChromiumOptions
import uuid, time, random

# Helper para construir username ProxyHat com país + sessão fixa
def proxy_user(country='US', session=None):
    sid = session or uuid.uuid4().hex[:12]
    return f'user-country-{country}-session-{sid}', sid

username, sid = proxy_user(country='US', session='abc123')
password = 'SUA_SENHA_PROXYHAT'
proxy_url = f'http://{username}:{password}@gate.proxyhat.com:8080'

# WebPage inicia em modo HTTP por padrão
page = WebPage()
page.set.proxies(proxy_url)

# --- Fase 1: HTTP puro para a listagem (rápido, barato) ---
page.get('https://loja.exemplo.com/catalogo?page=1')
links = page.eles('xpath://a[@class="product-link"]/@href')
print(f'Encontrados {len(links)} produtos')

# --- Fase 2: escalar para Chromium para os detalhes em React ---
co = ChromiumOptions()
co.set_proxy(proxy_url)
co.headless(True)
co.set_argument('--disable-blink-features=AutomationControlled')

page.change_mode()  # alterna para ChromiumPage, cookies são preservados

for href in links[:5]:
    page.get(href)
    # Captura o XHR de preço dinâmico
    page.listen.start('api/price')
    packet = page.listen.wait(timeout=10)
    if packet:
        print(f'{href} -> {packet.response.body}')
    page.listen.stop()
    time.sleep(random.uniform(1.5, 3.0))  # rate limiting humano

page.close()

Pontos-chave deste exemplo:

• Sessão fixa: session-abc123 garante o mesmo IP de saída durante todo o fluxo. Sem isso, cada requisição rotaria para um IP novo e o anti-bot detectaria a troca.
• Escalonamento consciente: HTTP para a listagem (50ms por página), Chromium só para os 5 detalhes que precisam de JS. Economia de RAM e tempo.
• Rate limiting: random.uniform(1.5, 3.0) simula pausa humana. Constantes de 0.1s entre requisições são um sinal clássico de bot.
• change_mode(): preserva cookies e storage entre HTTP e Chromium — sem copiar nada manualmente.

Padrões de produção

Pinamento de proxy por sessão

Para fluxos multi-etapa (login → navegação → checkout simulado), cada sessão lógica deve ter um ID estável. Construa o username com session-{id} e reutilize o mesmo ID em todas as requisições daquela sessão. Se precisar de IP novo (ex.: após um 403), troque o ID — o gateway atribui um novo IP residencial.

def new_session(country='US'):
    sid = uuid.uuid4().hex[:12]
    user = f'user-country-{country}-session-{sid}'
    proxy = f'http://{user}:PASS@gate.proxyhat.com:8080'
    return sid, proxy

Retries com backoff exponencial

Requisições falham por timeout, 502 ou CAPTCHA intermitente. Implemente retry com backoff e, ao atingir um limite, rotacione a sessão (novo IP).

def fetch_with_retry(page, url, max_retries=3):
    for attempt in range(max_retries):
        try:
            resp = page.get(url, timeout=15)
            if resp.status == 200:
                return resp
            if resp.status in (403, 429):
                # Rotaciona sessão: novo IP residencial
                sid, proxy = new_session()
                page.set.proxies(proxy)
        except Exception as e:
            print(f'Tentativa {attempt+1} falhou: {e}')
        time.sleep(2 ** attempt + random.uniform(0, 1))
    return None

Descoberta de APIs ocultas via listen

Muitas SPAs carregam dados via endpoints JSON não documentados. Use listen.start() sem filtro de URL para capturar tudo, depois inspecione os pacotes para identificar endpoints reutilizáveis em HTTP puro.

page.listen.start()  # sem filtro = captura tudo
page.get('https://alvo.com/dashboard')
for _ in range(20):
    pkt = page.listen.wait(timeout=5)
    if pkt and 'json' in (pkt.response.headers.get('content-type','')):
        print(pkt.url, pkt.response.body[:200])
page.listen.stop()

Depois de identificar o endpoint (ex.: /api/v2/items?page=1), muitas vezes você pode chamá-lo diretamente via SessionPage — 10x mais rápido e sem overhead de browser.

Limites de concorrência

Chromium é pesado: cada aba consome ~150–300 MB de RAM. Para fleet em produção, limite concorrência por node. Um node com 8 GB de RAM suporta confortavelmente 20–25 sessões Chromium concorrentes; HTTP puro suporta 200+ conexões no mesmo hardware. Combine com containers Docker para escalar horizontalmente — um container por sessão pinada a um proxy residencial distinto.

Veja preços da ProxyHat para planejar custo por sessão concorrente.

Quando NÃO escalar para o browser

O navegador é caro e nem sempre necessário. Antes de abrir Chromium, verifique:

1. A página retorna HTML completo no HTTP? Use curl -s URL | grep 'dado' ou SessionPage. Se o dado está no HTML, não precisa de browser.
2. Existe uma API JSON acessível? Inspecione o Network tab do DevTools ou use listen uma vez para descobrir. APIs JSON via HTTP são 10–50x mais baratas de raspar.
3. O alvo tem anti-bot de fingerprint? Se sim, browser + residencial é necessário. Se não, HTTP puro com residencial basta.
4. Precisa de interação (click, scroll, login)? Só aqui o browser é justificado.

Regra prática: comece em HTTP. Só escale para Chromium quando o HTTP não retornar os dados. Isso reduz custo de infraestrutura em 60–80% na maioria dos projetos. Para casos de uso específicos, veja web scraping e SERP tracking.

Considerações éticas e legais

Scraping não é ilegal por definição, mas operar fora de limites éticos pode ser. Princípios que seguimos:

• Respeite robots.txt: verifique antes de raspar. Mesmo que não seja juridicamente vinculativo em todas as jurisdições, é um sinal de boa-fé.
• Rate limiting: mantenha <1 req/s por domínio para não impactar o servidor alvo. Picos de 100 req/s são DoS de fato.
• Dados públicos apenas: não raspe dados pessoais protegidos por GDPR sem base legal. Dados atrás de login geralmente são regidos por ToS.
• Prefira APIs oficiais: se o site oferece uma API (mesmo paga), use-a. É mais estável, legalmente segura e frequentemente mais barata que infra de scraping.
• Atribuição e cache: se republicar dados, cite a fonte e não armazene dados sensíveis por mais tempo que o necessário.

Documentação oficial de proxies e configurações avançadas está em docs.proxyhat.com.

Key Takeaways

• DrissionPage unifica HTTP e browser num único objeto (WebPage), compartilhando cookies entre modos — sem copiar estado manualmente.
• Use SessionPage primeiro: HTTP puro é 10–50x mais barato que Chromium. Escale para browser só quando JS rendering for necessário.
• Proxies residenciais são obrigatórios para alvos com anti-bot: datacenter IPs são bloqueados na camada de ASN antes do challenge.
• Pinamento de sessão (session-{id}) mantém o mesmo IP durante fluxos multi-etapa, evitando detecção por troca de fingerprint.
• listen.start() descobre APIs ocultas: capture XHR em background e muitas vezes elimine a necessidade de browser por completo.
• Concorrência limitada por RAM: ~25 sessões Chromium por node de 8 GB; 200+ conexões HTTP no mesmo hardware.

FAQ

O que é DrissionPage?

DrissionPage é um framework Python de automação web que unifica HTTP (estilo requests) e controle de Chromium via CDP num único objeto. Ele permite alternar entre modo HTTP rápido e modo browser renderizado sem reescrever código ou copiar cookies, reduzindo custo de infraestrutura em projetos de scraping que misturam páginas estáticas e SPAs.

Por que o DrissionPage importa para quem usa proxies?

Porque o proxy é configurado uma vez e compartilhado entre os dois modos (HTTP e browser). Isso mantém o mesmo IP de saída durante todo o fluxo — essencial para sessões multi-etapa em alvos com anti-bot. Com ferramentas separadas (requests + Selenium), cada stack teria seu próprio proxy e cookies copiados manualmente, aumentando o risco de detecção.

Qual tipo de proxy funciona melhor com DrissionPage?

Proxies residenciais são os mais eficazes para alvos com proteção anti-bot, porque o IP de saída tem ASN de ISP real (Comcast, Deutsche Telekom, Vivo) e passa pela primeira camada de geofiltro. Datacenter IPs (AWS, OVH) são bloqueados antes mesmo do challenge renderizar. Para alvos sem anti-bot, datacenter proxies funcionam e são mais baratos. Móveis são úteis para alvos que exigem IPs de operadora.

Como evitar bloqueios ao implementar DrissionPage?

Use proxies residenciais com sessão pinada (mesmo IP durante o fluxo), respeite rate limits (menos de 1 req/s por domínio), adicione pausas aleatórias entre requisições, configure um user-agent realista, desative sinais de automação (--disable-blink-features=AutomationControlled) e implemente retries com backoff exponencial rotacionando o IP ao encontrar 403/429. Sempre verifique robots.txt antes de raspar.

DrissionPage é melhor que Selenium ou Playwright?

Depende do caso. DrissionPage brilha quando você precisa alternar entre HTTP e browser no mesmo fluxo, compartilhando estado. Selenium e Playwright são mais maduros para automação pura de browser e têm ecossistema maior. Para scraping que mistura páginas estáticas e SPAs, DrissionPage reduz código e custo. Para testes E2E complexos, Playwright pode ser mais adequado.