O que há de novo
Alternar saídas de proxy é a parte que todo mundo automatiza. A assinatura do navegador por baixo delas geralmente nunca muda.
Single e Proxy Finder agora aceitam quatro campos opcionais que definem qual navegador a sua request apresenta: browser, os, version e profile. O catálogo por trás deles é público em GET /api/profiles e não precisa de API key. No momento, ele contém 79 perfis em Chrome, Edge, Safari, Firefox e Tor, no Windows, macOS, Android e iOS.
E quando você não define um, o Proxy Finder altera isso para você. Mas apenas após um site provar duas vezes que não aceita o perfil enviado.
Como funciona
Três dos campos são para humanos e um é para máquinas.
browser, os e version filtram o catálogo, e você pode enviar qualquer subconjunto deles. os busca pela família, portanto solicitar macOS aceita todas as versões de macOS da lista, enquanto solicitar o nome exato da versão filtra apenas para aquela. Quando vários perfis ainda forem compatíveis, a versão mais recente vence, já que estar atualizado é o objetivo principal. Versões principais antigas são exatamente o que as blocklists usam para bloqueio.
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://example.com/listing/42",
"browser": "Safari",
"os": "iOS"
}'
Isso resolve para o Safari mais recente no iOS dentro do catálogo, e envia o User-Agent, os client hints e a ordem de headers correspondentes, nessa ordem. A ordem dos headers é por si só um sinal, portanto nada é reordenado no envio.
profile é o quarto campo: um ID exato do catálogo, para código que precisa continuar enviando o mesmo cliente após o lançamento de uma versão mais nova. O Proxy Finder aceita todos os quatro dentro de seu objeto request. A lista completa de parâmetros está na referência da API, e o Playground lê o mesmo catálogo, de modo que seus menus suspensos só podem oferecer o que seu código pode solicitar. Os mesmos quatro campos são enviados dentro de foura_single e foura_proxy no servidor MCP, permitindo que um agente tente novamente como outro navegador em vez de retornar um 403 puro.
Duas coisas que isso se recusa deliberadamente a fazer.
Uma combinação que o catálogo não pode fornecer resulta em um erro que lista o que está disponível para aquele navegador. Fazer fallback para um padrão enviaria um cliente que você não escolheu e não pode ver na resposta. Uma escolha de perfil com unblocker: false também é recusada, porque essa flag é o que transporta os headers (o que essa flag realmente faz). Meio perfil é pior do que nenhum.
O próprio catálogo é medido, não digitado manualmente. Um script executa cada perfil pelo caminho real de request e registra o que de fato trafegou na rede. Isso importa mais do que parece: entre duas versões principais recentes de um navegador, a string de marca do placeholder mudou e a ordem das marcas se inverteu, e esse é exatamente o tipo de detalhe que um serviço de detecção analisa.
Impacto
Esta é a parte que não esperávamos.
Um padrão é um padrão compartilhado. O cliente que seu request apresenta quando você não especifica nada é o mesmo que todo request sem especificação apresenta, e uma defesa que busca um identificador simples foca exatamente nisso. A falha ocorre de uma forma única: um site que recusa um navegador o recusa em todos os pontos de saída que você possui. Você gasta todo o orçamento de tentativas provando que o mesmo cliente não é bem-vindo.
Medimos isso três vezes, em três fornecedores, e o comportamento foi idêntico em todas.
Um portal imobiliário protegido pela PerimeterX recusou nove tentativas no padrão. Alterar apenas a plataforma declarada pelo request (mantendo todo o resto idêntico, no mesmo pool) retornou a página seis vezes em seis tentativas. Uma loja de suplementos protegida pela Akamai recusou o padrão e atendeu a duas outras famílias de navegadores sem problemas. Um site de notícias financeiras protegido pelo DataDome respondeu ao padrão com um 401 e uma página intermediária de 774 bytes, enquanto outros três perfis carregaram a página real, com cerca de 760 KB, doze vezes cada. Executamos esse teste em ordem direta e inversa para garantir que a sequência não estava influenciando o resultado.
Portanto, o Proxy Finder agora alterna a família do navegador, não apenas a saída. Duas saídas independentes precisam recusar antes que ele mude, porque uma recusa é apenas a opinião de uma saída. Em seguida, ele avança por uma escala que começa com a menor alteração possível, a plataforma, e só então tenta outras famílias.
Isso não custa nada. A rotação altera o que uma nova tentativa envia, nunca se ela acontece, de modo que as requisições e os créditos por tarefa permanecem exatamente os mesmos.
Para Usuários Avançados
A rotação não interfere no seu fluxo, e vale a pena conhecer as regras para isso.
Ela nunca é acionada quando você mesmo define um perfil. Também nunca é acionada quando você envia seu próprio header user-agent ou cookie, e este último é o mais importante: um cookie de liberação está vinculado ao cliente que o obteve, portanto, alternar a assinatura durante a repetição de uma sessão ativa quebraria uma requisição que estava funcionando. Fixe o que você quiser e isso permanecerá fixado.
Nem toda falha conta como evidência para alterar o perfil. Um fornecedor de proteção reconhecido conta. Um status de recusa direto (401, 403, 429, 503) sem nenhum fornecedor identificado também conta, e isso se mostrou importante. Uma tarefa retornou com oito rejeições de status e nada identificado em nenhuma delas: recusas reais que a rotação estava ignorando porque confiava apenas no detector. Uma página inexistente ou um bloqueio por país não contam. Essas são respostas sobre a sua URL e a sua geografia, não sobre o seu cliente.
Você pode ver tudo isso. Uma resposta bem-sucedida do Proxy Finder inclui profile apenas quando nós o escolhemos, nunca quando você o fez. Uma tarefa com falha inclui attemptReport.profilesTried: as famílias enviadas, na ordem do primeiro uso, com default para uma requisição enviada sem alterações. Sem esse campo, "tentamos quatro navegadores e todos foram recusados" e "nunca alteramos o navegador" parecem idênticos do lado de fora.
Um hábito que vale a pena adotar: ao testar se um perfil ajuda, mantenha todo o resto inalterado. O resumo de 2026 sobre ferramentas de teste de fingerprint da Scrapfly resume bem isso: alterar três variáveis entre execuções indica que algo funcionou, mas não qual mudança fez a diferença. Mesmo alvo, mesma saída, apenas um campo diferente. Foi assim também que cada número acima foi obtido.
O Que Vem a Seguir
A lista de candidatos só cresce por meio de medições, um alvo por vez. Uma família é adicionada depois de comprovarmos que ela acessou um alvo que o padrão não conseguiu, não porque parecia uma boa aposta, e o catálogo é remedido a cada atualização da engine em vez de ser simplesmente mantido.
Essa é a natureza complexa desse problema. A melhor assinatura de cliente é um alvo em movimento, monitorá-la é um trabalho contínuo em vez de algo que você lança uma única vez, e o que funcionava no trimestre passado já está na lista de bloqueio de alguém agora. É por isso que este é um campo que você define e um catálogo que você pode consultar, em vez de um número que escolhemos para você.