O esquema "levantei o Firecrawl no Docker, direcionei para uma lista de domínios, obtive markdown para RAG" funciona exatamente até a primeira milhar de páginas. Depois, vêm duas contas. A primeira — dos anti-bots: parte dos domínios começa a retornar 403 em vez de conteúdo, e surgem lacunas na base de conhecimento, que você descobre quando o assistente responde "não há informações nos materiais fornecidos". A segunda conta — pelo tráfego: o crawler honestamente puxa cada imagem e cada fonte, que no markdown final de qualquer forma não serão incluídas.
Vamos analisar como conectar um proxy aos três crawlers LLM mais populares de 2026 — Firecrawl, Crawl4AI e Crawlee — e como configurá-los para que o proxy funcione apenas onde é necessário, e não consuma gigabytes em cada página.
Para quem é este guia
Se você está coletando um corpus de documentos para RAG, preenchendo uma base de conhecimento interna, construindo um pipeline de dados para re-treinamento ou simplesmente baixando regularmente centenas de domínios — este é o seu caso. Todas as três ferramentas abaixo, na configuração padrão, operam com o IP do seu servidor e carregam a página inteira. Ambas as configurações padrão precisam ser alteradas.
A escala do problema é clara pelos números de popularidade: o Firecrawl, no momento da publicação, tem cerca de 170 mil estrelas no GitHub (licença AGPL-3.0), o Crawl4AI cerca de 79 mil, e o Crawlee da Apify cerca de 25 mil. Isso já não são experimentos de nicho, mas ferramentas padrão, e os sistemas anti-bots conhecem seu comportamento tão bem quanto você.
Conta um: 403 em vez de conteúdo
O erro chave ao coletar um corpus é achar que o crawler funcionou com sucesso se não caiu. O Firecrawl e o Crawl4AI em uma página bloqueada retornam não uma exceção, mas um resultado: uma página de bloqueio do anti-bot, uma página de verificação do navegador ou um breve texto de recusa de acesso. Formalmente, isso é um markdown válido, que se encaixa na base vetorial e permanece lá até o primeiro pedido do usuário.
Portanto, a primeira coisa a fazer antes de qualquer configuração de proxy é adicionar controle de qualidade ao resultado. A versão mínima: descartar documentos que sejam mais curtos que um certo limite (para uma página de conteúdo típica, é razoável 500–800 caracteres de texto) e capturar separadamente marcadores característicos no texto — menções à verificação de conexão, JavaScript ativado, "Acesso negado". Esses documentos não são enviados para a base, mas para uma fila de re-exploração — já através do proxy.
Conta dois: gigabytes que você está jogando fora
Aqui a aritmética ajuda. De acordo com o Web Almanac do HTTP Archive de 2025, a página principal mediana pesa cerca de 2,86 MB em desktop e 2,56 MB em dispositivos móveis. Desses, cerca de 1.059 KB são para imagens nas páginas principais e 911 KB nas internas, e para JavaScript — 697 KB e 632 KB, respectivamente. Ou seja, as imagens são a categoria mais pesada, representando cerca de um terço do peso da página.
E agora lembre-se do que você faz com o resultado. Você converte a página em markdown e corta em pedaços para embeddings. As imagens não entram nesse pipeline de forma alguma — na melhor das hipóteses, sobra apenas uma linha com o texto alt. Vídeos, fontes, scripts analíticos, pixels de anúncios — também ficam de fora.
Se você estiver fazendo a exploração através de um proxy residencial com pagamento por gigabyte, você literalmente está pagando pela entrega de dados que descarta na próxima etapa do pipeline. Em um corpus de 100 mil páginas, a diferença entre "baixar tudo" e "baixar apenas HTML e texto" é medida não em porcentagens, mas em vezes. A economia exata depende da temática dos sites: mídia e e-commerce são mais pesados que documentação e blogs.
Passo 1. Escalação em vez de "proxy para tudo"
A principal técnica arquitetônica que economiza mais: não deixar todo o tráfego passar pelo proxy. A maior parte dos domínios ao coletar a base de conhecimento — documentação, blogs, sites de referência, portais governamentais — entrega conteúdo diretamente e não bloqueia ninguém. O proxy é necessário para uma minoria.
A configuração correta é uma escalação em múltiplos níveis: primeiro um pedido direto, ao sinal de bloqueio — transição para o próximo nível. E isso não é um remendo caseiro, ambos os frameworks principais fazem isso de forma nativa.
No Crawlee, existe tieredProxyUrls para isso. Os níveis são listados do mais barato para o mais caro, e o crawler sobe automaticamente em caso de bloqueios, e depois tenta periodicamente voltar ao nível inferior:
const proxyConfiguration = new ProxyConfiguration({
tieredProxyUrls: [
[null],
['http://user:pass@datacenter-proxy:8080'],
['http://user:pass@residential-proxy:8000'],
]
});Um detalhe importante da documentação: tieredProxyUrls funciona apenas quando usado através de uma instância do crawler. Chamadas diretas a newUrl() resultarão em um resultado inesperado.
No Crawl4AI, um mecanismo semelhante apareceu na versão 0.8.5 e vive na branch atual (o último lançamento no momento da publicação — v0.9.2 de 15 de julho de 2026). É chamado de escalonamento de proxy e é configurado diretamente em CrawlerRunConfig: detecção de bloqueio em três níveis — fornecedores conhecidos de anti-bots, indicadores gerais de bloqueio e verificação da integridade estrutural da página — além de uma nova tentativa automática através da cadeia de proxies.
from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig
config = CrawlerRunConfig(
proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
max_retries=2,
)Note que ProxyConfig.DIRECT é o primeiro elemento — isso significa "primeiro tente sem proxy".
Passo 2. Conectando o proxy em cada ferramenta
Agora, vamos aos detalhes da configuração. A ordem das ações é a mesma: primeiro o proxy, depois a eliminação do tráfego desnecessário, depois a verificação.
- Firecrawl (auto-hospedado). O proxy é definido por três variáveis de ambiente, que são passadas para o Playwright:
PROXY_SERVER,PROXY_USERNAME,PROXY_PASSWORD. Elas são escritas em.envparaapps/api; nos comentários, os desenvolvedores afirmam que, em vez de um endereço estático, pode-se indicar um serviço de proxy que rotaciona IP a cada pedido. - Crawl4AI. O proxy vive em
BrowserConfig, no campoproxy_config— é um objetoProxyConfigou um dicionário com os camposserver,username,password. Uma configuração de navegador para toda a sessão de crawling; umCrawlerRunConfigseparado é passado para cada chamada dearun(). - Crawlee. A classe
ProxyConfigurationcom a opçãoproxyUrls— uma lista de endereços, que a biblioteca segue em um ciclo (round-robin). O valornullna lista significa "sem proxy". A integração é abrangente:HttpCrawler,CheerioCrawler,JSDOMCrawler,PlaywrightCrawler,PuppeteerCrawler. - Regras pontuais. Se você sabe quais domínios bloqueiam e quais não, no Crawlee existe
newUrlFunction— sua própria lógica de escolha de proxy com base na URL da solicitação. Para domínios brancos, você retornanull, para os demais — o endereço do proxy. Esta é a opção mais barata, quando a lista de alvos é estável. - Verificação. Antes do teste real, passe pela página configurada que retorna seu IP externo e verifique se você vê o endereço do proxy, e não do servidor. Três linhas que economizam um dia de investigações.
Passo 3. Cortar tudo que não se tornará texto
Quando o proxy estiver conectado, ative a economia de tráfego — caso contrário, a conta por gigabytes chegará mais rápido do que você consegue coletar o corpus.
No Firecrawl, isso é controlado pela variável BLOCK_MEDIA. No exemplo oficial de configuração, há um comentário literal: defina se quiser bloquear solicitações de mídia para economizar largura de banda do proxy. Esta é a maneira mais rápida de eliminar a principal despesa.
No Crawl4AI, alavancas semelhantes estão em BrowserConfig: text_mode desativa imagens e acelera a exploração de texto, light_mode desativa algumas funções de fundo do navegador, avoid_css bloqueia o carregamento de CSS. Elas podem ser combinadas. Para coletar um corpus para RAG, este é quase sempre o conjunto correto — você não precisa de layout, precisa de texto.
No Crawlee, a lógica é diferente: se o conteúdo é entregue em HTML, use CheerioCrawler ou HttpCrawler em vez de crawlers baseados em navegador. Uma solicitação HTTP normal em vez de uma renderização completa — isso não é apenas economia de tráfego, é uma ordem diferente de despesas. Reserve crawlers baseados em navegador (PlaywrightCrawler, PuppeteerCrawler) apenas para páginas que não podem ser coletadas sem JavaScript.
Armadilhas
Sessões contra rotação. Mudar o IP a cada solicitação parece suspeito e quebra cenários de múltiplas etapas — paginação, navegação dentro de um único domínio. No Crawlee, cada chamada a newUrl() vincula o proxy ao objeto Session, e eles são rotacionados junto com as impressões do navegador e cabeçalhos. Não quebre essa ligação manualmente.
Mídia desligada, mas o conteúdo desapareceu. Algumas páginas carregam de forma preguiçosa não apenas imagens, mas também texto. Após ativar text_mode ou BLOCK_MEDIA, sempre passe por uma amostra de controle de 20–30 páginas e compare o volume de texto com o padrão.
Retraies sem limite. A escalonamento por níveis de proxy significa que uma página teimosa pode ser baixada três vezes — e todas as três vezes pagas. Limite max_retries e crie uma lista de domínios que, após N tentativas malsucedidas, são excluídos da exploração completamente.
Robots.txt e estrutura legal. A coleta de dados para treinamento e RAG em 2026 é regulada mais rigidamente do que alguns anos atrás — desde requisitos de divulgação de fontes até mecanismos de recusa de text and data mining. Verifique se seu pipeline respeita esses sinais, antes que ele opere em centenas de milhares de páginas.
Que tipo de proxy escolher para o pipeline RAG
A resposta depende do nível de escalonamento em que você está.
- Nível zero — sem proxy. Documentação, projetos de código aberto, sites governamentais, a maioria dos blogs corporativos. Aqui, o IP do servidor funciona normalmente, e não há nada a pagar.
- Nível médio — proxies de datacenter. Rápidos e baratos, adequados contra simples rate limiting e restrições regionais. Ao coletar grandes corpora, este é o cavalo de batalha: quando o volume é medido em centenas de gigabytes, a diferença de preço por gigabyte se torna o principal fator.
- Nível superior — proxies residenciais. Para domínios com proteção anti-bot séria, onde sub-redes de datacenter são filtradas na entrada. É por isso que não podem ser configurados como nível padrão — o pagamento por gigabyte transforma cada imagem extra em uma linha de despesas.
Antes de construir o pipeline, vale a pena calcular a economia honestamente: analisamos o custo total de parsing de um milhão de páginas considerando o peso das páginas, retrai e despesas ocultas. E uma pergunta separada que é útil fazer antes de escrever a primeira linha de código: a exploração é realmente necessária — na análise de API oficial versus conjuntos de dados prontos e parsing é evidente que para algumas fontes, os dados prontos saem mais baratos do que um crawler próprio.
Conclusão
O proxy em um crawler LLM não é um interruptor "ligar/desligar", mas um esquema de três níveis. Um pedido direto como nível padrão, proxies de datacenter no nível médio, residenciais — apenas para domínios que não podem ser acessados de outra forma. Além disso, um corte rigoroso de mídia, porque você está coletando texto e pagando por bytes.
A ordem das operações é simples: primeiro controle de qualidade do resultado (caso contrário, você não saberá que metade do corpus são páginas de bloqueio), depois escalonamento de proxy usando os recursos do próprio framework, e por último, economia de tráfego. Nessa ordem — o corpus será completo e a conta previsível.
```