Proxy para agentes de IA: Playwright MCP e uso de navegador 2026

```html

O agente de IA que navega por sites — Claude com Playwright MCP, browser-use, Browserbase na nuvem — enfrenta a mesma barreira que um parser comum: algumas dezenas de requisições de um único endereço, e depois, em vez da página, aparece um desafio do Cloudflare. A diferença é que o agente não se ofende e simplesmente entra em um loop, queimando tokens em tentativas de "clicar em um botão que não existe".

Isso é resolvido com proxies. Mas conectar um proxy ao agente acaba sendo surpreendentemente não óbvio: metade das instruções na internet oferece uma sintaxe que o Chromium ignora silenciosamente. Abaixo estão as configurações funcionais para três das pilhas mais comuns de 2026 e uma análise das armadilhas nas quais todos tropeçam.

Quem precisa disso

Um guia para aqueles que já iniciaram o agente e apresentaram um dos sintomas:

o agente executa 10–20 passos, e depois cada passo seguinte retorna um captcha ou uma página "Verifique se você é humano";
o agente vê um conteúdo diferente do que você: preços, resultados e disponibilidade de produtos são mostrados de acordo com seu IP de servidor, e não com o país desejado;
o agente está rodando na nuvem (VPS, GitHub Actions, contêiner), e o endereço do datacenter do provedor já está marcado como bot;
você configurou o proxy com login e senha, mas o navegador inicia como se o proxy não existisse.

Se você ainda está na fase de "por que os agentes são bloqueados" — primeiro leia a análise sobre como os sistemas anti-bot distinguem um navegador de agente de um humano: lá está sobre os sinais de detecção, e aqui — a prática pura de conexão.

Armadilha nº 1: Chromium não aceita login e senha na string do proxy

O erro mais comum, e que custa horas de depuração para as pessoas. A forma clássica da string do provedor é user:pass@host:port. Você a insere na flag de inicialização do navegador:

--proxy-server="http://user:[email protected]:8080"

E nada funciona. O Chromium não suporta a passagem de credenciais dentro da flag --proxy-server: um erro de proxy não suportado aparece no console, e o tráfego passa direto. Se você remover as credenciais e deixar apenas host:port, o navegador em modo normal mostrará uma janela do sistema pedindo login e senha — e é aí que tudo para, porque em modo headless não há janela e não há ninguém para clicar nela.

Isso leva a três caminhos funcionais, e você deve escolher conscientemente:

Autenticação por IP (whitelist). A opção mais limpa para agentes. Você adiciona o endereço da máquina onde o agente está rodando à lista branca no painel do provedor — e então se conecta sem login e senha, apenas com a string host:port. A flag --proxy-server começa a funcionar como deveria, e o headless não pede mais nada. A ProxyCove suporta ambos os métodos — tanto login:senha quanto IP-whitelist, e ambos ao mesmo tempo, então você pode criar uma whitelist para o agente e deixar a senha para tarefas manuais.
Passar credenciais no nível da API, e não da flag. Playwright, Puppeteer e browser-use conseguem aceitar username e password como campos separados — este não é o mesmo mecanismo que a flag da linha de comando, e ele funciona. É adequado quando você escreve o código do agente você mesmo.
Relay local. Você configura um proxy sem senha que encaminha requisições para o upstream com senha, e indica ao agente o endereço local. Uma opção para casos em que a lista branca não está disponível: por exemplo, o IP da máquina muda.

Playwright MCP: configuração que realmente funciona

O Playwright MCP da Microsoft — hoje o padrão de fato para agentes que precisam de um navegador real. O proxy é definido pelos argumentos do servidor diretamente na configuração do cliente MCP:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

O que é importante aqui, ponto a ponto:

--proxy-server aceita tanto endereços HTTP quanto SOCKS5 na forma socks5://host:port. Sem credenciais — veja a armadilha acima.
--proxy-bypass — lista de domínios separados por vírgula que vão direto, sem passar pelo proxy. Não é uma opção decorativa: se o agente tem serviços internos ou uma API local, passar por um canal residencial gera tráfego desnecessário a um custo por gigabyte.
--isolated mantém o perfil na memória e não o grava no disco. Útil quando cada tarefa deve começar do zero. O lado negativo é que os cookies não sobrevivem a reinicializações, e cada sessão para o site parece um novo visitante.
--user-data-dir — ao contrário, um perfil permanente. Para cenários com autenticação, use este, e não a isolação, e sempre fixe o IP (veja a seção sobre sticky abaixo).
--storage-state permite injetar cookies e localStorage salvos em uma sessão isolada — um compromisso entre os dois anteriores.
--allowed-origins e --blocked-origins restringem para onde o agente pode realmente ir. Uma economia subestimada: um agente que se empolga com análises e domínios de publicidade facilmente triplica o consumo de tráfego.
--device (por exemplo, "iPhone 15") e --user-agent mudam como o agente se apresenta como navegador. Defina-os de acordo com o tipo de proxy: um User-Agent móvel sobre um IP de datacenter é uma contradição que o sistema anti-bot detecta instantaneamente.

Separadamente sobre --cdp-endpoint: ele conecta o MCP a um navegador já iniciado. Então o proxy é configurado não pelas flags MCP, mas na inicialização daquele navegador — uma razão típica pela qual "o proxy está configurado, mas o IP é o mesmo".

browser-use: proxy através de ProxySettings

Se o agente foi construído com browser-use, a configuração vai para um objeto de configurações, e aqui é possível passar login e senha — eles vão pela API, e não pela linha de comando:

from browser_use import Browser, ProxySettings proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1') browser = Browser(proxy=proxy)

O campo server é obrigatório, os outros são opcionais. O mesmo princípio se aplica no Playwright puro: o proxy é definido globalmente ao iniciar o navegador, ou separadamente para cada contexto através de browser.newContext({ proxy: { server: ... } }). O segundo é a chave para agentes paralelos: cada contexto recebe seu próprio endereço de saída, e dez tarefas não compartilham um único IP.

Navegadores na nuvem: proxy no nível da sessão

Nos serviços como Browserbase, o navegador vive na nuvem de terceiros, portanto, as flags de inicialização não estão disponíveis para você — o proxy é configurado nos parâmetros da sessão, geralmente como uma string do tipo http://login:senha@gateway:porta na variável de ambiente do servidor MCP. A limitação do Chromium aqui não atrapalha: o provedor de nuvem analisa a string e configura o navegador internamente.

Um detalhe prático: navegadores na nuvem têm seu próprio pool de proxies, e ele é compartilhado entre todos os clientes. Se a tarefa é sensível à reputação do endereço — login em uma conta, trabalho em uma plataforma onde você já é conhecido — seu canal é mais previsível do que o compartilhado.

Rotação ou fixação: escolha de acordo com o tipo de tarefa

Um erro comum de iniciantes é ativar a rotação em cada requisição e se surpreender por que o agente é desconectado. Os cenários de agentes têm dois modos, e eles não são intercambiáveis:

Rotação em cada requisição (na ProxyCove é a porta 824) — para exploração: contornar cem cartões de produto, coletar resultados, verificar preços em diferentes regiões. Cada requisição sai de um novo endereço, e é difícil conectá-las entre si.
Sessão fixada (portas 10000+, intervalo de troca de 1 a 120 minutos) — para tudo que consiste em etapas: login, carrinho, formulário de várias páginas, diálogo longo com a interface. Se o IP mudar no meio da cadeia, o site, na melhor das hipóteses, pedirá para reautenticar, na pior, marcará a sessão como suspeita.

O agente quase sempre opera no segundo modo: ele, por definição, executa uma sequência de passos, e não um único disparo. Os detalhes sobre a escolha do intervalo e erros típicos são discutidos no guia sobre quando usar sessões sticky e como configurá-las.

Cinco armadilhas

SOCKS5 com autenticação no Chromium. A sintaxe socks5:// está disponível no Playwright, mas a combinação "SOCKS5 mais login e senha" em navegadores baseados em Chromium historicamente apresenta problemas — a solicitação correspondente no rastreador do Playwright está aberta desde novembro de 2021. Se houver escolha, para agentes, escolha um canal HTTP(S), ele é mais previsível.
Vazamento de DNS e WebRTC. O tráfego passa pelo proxy, mas os nomes são resolvidos diretamente ou o WebRTC entrega o endereço real — e toda a camuflagem perde sentido. Isso deve ser verificado antes, e não depois, de iniciar o agente: como ocultar o WebRTC ao trabalhar através de proxy.
Desincronização de geolocalização e localidade. IP na Alemanha, fuso horário da máquina em Moscovo, idioma da interface em inglês — um conjunto que por si só parece automação. No Playwright, a localidade e o fuso horário são definidos pelos parâmetros do contexto, alinhe-os com o país do proxy.
Tráfego que você não solicitou. O agente abre a página inteira, junto com imagens, fontes e scripts publicitários. Em um canal residencial com pagamento por gigabyte, isso é uma despesa significativa — bloqueie domínios desnecessários e, onde possível, desative o carregamento de mídia.
Proxy não configurado onde o navegador inicia. Ao trabalhar através de --cdp-endpoint, através de um wrapper Docker ou através de um serviço em nuvem, as flags MCP não afetam a conexão real. A primeira coisa a fazer após a configuração é fazer o agente abrir qualquer serviço de verificação de IP e garantir que o endereço e o país estão corretos.

Qual tipo de proxy escolher para o agente

A regra é simples: quanto mais próxima a tarefa de um usuário real, mais "humano" deve ser o endereço.

Proxies residenciais — a base para agentes. Esses são endereços de provedores domésticos, e para o site, o agente parece um visitante comum. Necessários em qualquer lugar onde há Cloudflare, preços regionais e qualquer indício de anti-bot.
Proxies móveis — a artilharia pesada para redes sociais e plataformas onde as contas são tratadas com especial cuidado. Um único endereço móvel é compartilhado por milhares de assinantes reais, portanto, banir completamente é caro para a plataforma.
Proxies de datacenter — para APIs internas, ambientes de teste e fontes abertas sem proteção. Rápido e barato, mas em sites protegidos, o agente encontrará um desafio quase imediatamente.

Um detalhe útil para cenários de agentes: a troca de protocolo na ProxyCove é feita substituindo o prefixo na string de conexão — HTTP, HTTPS e SOCKS5 estão disponíveis no mesmo proxy, não é necessário reconfigurar o proxy. Há mais de 195 países no pool, então "mostrar ao agente resultados locais" é resolvido escolhendo o país na compra.

Conclusão

Conectar um proxy ao agente de IA não é uma única linha, mas três soluções consecutivas: como se autenticar (para um agente headless, quase sempre uma lista branca de IPs, e não uma senha), onde definir o proxy (flags MCP, objeto de configurações ou parâmetros de sessão na nuvem — mas sempre onde o navegador realmente inicia) e em que modo operar (para cenários de múltiplas etapas — um endereço fixo, e não rotação em cada requisição). Além disso, verificação obrigatória para vazamentos de DNS e WebRTC antes do lançamento operacional.

Faça isso uma vez com cuidado — e o agente deixará de gastar tokens em conversas com captchas. Proxies residenciais da ProxyCove se conectam ao Playwright MCP e browser-use em poucos minutos, pagamento por tráfego, e a lista branca de IPs para o modo headless é ativada no painel.