User agent (UA) é a string com que o navegador ou qualquer outro programa se apresenta ao servidor no cabeçalho de cada requisição: nome e versão do navegador, motor, sistema operacional e às vezes o modelo do aparelho. Filtro por user agent significa que o servidor lê essa string e decide por ela quem entra, a quem mostrar outra página e quem barrar como bot.
O método é simples e barato, por isso ainda aparece em scripts caseiros e plugins «antibot». Mas a string é escrita pelo próprio cliente e é mais fácil de falsificar do que qualquer outro sinal da visita. A seguir: o que exatamente vem no UA, quando dá para confiar nele, quando não dá e como usá-lo junto com outros sinais.
O que é user agent e o que vem escrito nele
Uma string típica do Chrome mobile no Android é assim:
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36
Fica mais fácil ler por partes:
| Trecho | O que significa |
|---|---|
Mozilla/5.0 |
Prefixo histórico de compatibilidade; quase todo navegador tem e não diz nada |
(Linux; Android 10; K) |
Plataforma e SO; nos navegadores atuais o modelo do aparelho costuma ser trocado por um marcador genérico |
AppleWebKit/537.36 (KHTML, like Gecko) |
Motor de renderização e mais uma herança de compatibilidade |
Chrome/130.0.0.0 |
Navegador e versão principal; os números menores já vêm zerados há tempos |
Mobile Safari/537.36 |
Indicador de layout mobile |
Dessa string o servidor costuma extrair quatro coisas: tipo de dispositivo (smartphone, tablet, computador, TV), sistema operacional, navegador e o indício de que do outro lado nem há navegador, e sim um programa ou robô.
Repare: quase não há informação única na string. Milhões de celulares enviam o mesmo UA — e é justamente por isso que os navegadores o «congelaram», para dificultar o rastreamento de pessoas por ele.
Client Hints: para onde vão os detalhes
Navegadores baseados em Chromium vêm reduzindo a string clássica e entregando os detalhes via Client Hints — um conjunto de cabeçalhos Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform e outros. Parte deles vem em toda requisição; parte, só se o servidor pedir explicitamente. Para a filtragem isso ajuda de duas formas: é mais difícil inventar dicas verossímeis do zero, e elas podem ser comparadas com a string principal. Um navegador que no UA se diz Chrome no Windows e nas dicas informa outra plataforma está se comportando de forma estranha.
Há também uma limitação: Safari e Firefox tratam as dicas de outra forma ou não as suportam, então a ausência de Client Hints, por si só, não diz nada.
Como funciona o filtro por user agent
Na forma mais simples, é uma lista de trechos: se o UA contém uma das palavras proibidas, o visitante vai para a página de bloqueio. Um pouco mais elaborado é um parser que decompõe a string em navegador, SO e dispositivo, com regras sobre o resultado: «só smartphones», «sem Smart TV», «só Android».
Aqui é importante separar duas tarefas diferentes:
- Segmentação — escolher o público-alvo: essa oferta precisa de desktop, iOS serve? A string UA funciona bem nisso, porque pessoas comuns não a falsificam e o erro custa pouco.
- Proteção contra bots — barrar a automação. Aqui o UA é quase inútil como sinal isolado: quem escreve um bot começa colocando a string de um navegador real.
Sobre filtros de público por dispositivo, SO e navegador, veja o artigo sobre filtro por GEO e dispositivo. Daqui em diante, o assunto é a segunda tarefa.
User agent de bot: quem se apresenta honestamente
Parte do tráfego automático realmente se apresenta como é. São duas classes diferentes.
Scripts brutos e utilitários. Bibliotecas de requisições HTTP, downloaders de linha de comando e scrapers enviam por padrão o próprio UA — com nome e versão da biblioteca — ou não enviam nenhum. UA vazio ou nome de biblioteca no lugar de navegador é um sinal confiável: uma pessoa vinda de anúncio não chega assim. Essas visitas são barradas na hora e quase sem risco.
Crawlers de busca e robôs «educados». Buscadores, serviços de pré-visualização de links e monitores de disponibilidade costumam indicar honestamente seu nome e um link para a descrição. Para um site comum são visitas úteis e não são bloqueadas. Mas aqui também há uma ressalva: a string de robôs de busca conhecidos é muito copiada por scrapers, para entrar onde o buscador entra. Por isso os próprios buscadores recomendam verificar o robô não pelo UA, e sim por DNS reverso do IP: o crawler verdadeiro vem da rede da sua empresa.
Conclusão: o filtro por UA pega bem quem não tenta se esconder. É uma parte considerável das requisições lixo, e barrá-la é barato. Mas não é a parte do tráfego de bots que come o orçamento de anúncios.
Falsificação de user agent: por que filtrar só por UA é fraco
Qualquer programa que se disfarce minimamente envia a string de um Chrome ou Safari recente. Isso se faz com uma linha de código e, no navegador, com uma opção nas ferramentas de desenvolvedor. Daí surgem três problemas.
A falsificação não aparece na própria string. O UA correto de um navegador real e o mesmo UA numa requisição de script são idênticos byte a byte. Não dá para verificar a string contra ela mesma — só compará-la com outros sinais.
As listas envelhecem. Uma lista negra de trechos precisa de atualização constante: surgem ferramentas novas, as antigas mudam de nome, e os navegadores reais mudam o formato da string. Uma lista que ninguém atualiza há seis meses pega sobretudo o que já nem aparece mais.
Falsos positivos com pessoas reais. Navegadores embutidos em apps, WebView, celulares antigos e builds corporativos de navegador enviam strings incomuns. A regra «é suspeito tudo que não parece um Chrome padrão» corta justamente o tráfego mobile das redes sociais — aquele pelo qual você paga. As particularidades dos navegadores embutidos estão no artigo sobre tráfego in-app e fraude.
Dica. Se uma regra por UA dispara numa parte visível do tráfego pago, provavelmente está cortando pessoas, não bots. Os bots contra os quais vale a pena montar proteção chegam com uma string perfeita.
Onde o filtro por user agent ainda é útil
Apesar de tudo isso, o UA é um sinal normal e necessário, desde que fique no seu lugar.
- Barrar automação grosseira. UA vazio, nome de biblioteca, de utilitário de linha de comando ou de framework de scraping é «não» na hora. Uma camada barata que alivia as demais verificações.
- Identificar o tipo de dispositivo para segmentação e roteamento. Smartphone ou computador, Android ou iOS — para distribuir o tráfego entre ofertas, a string UA costuma bastar.
- Reconhecer navegadores embutidos. Pelo UA se vê que a visita veio de um navegador dentro de um app. Isso importa não para bloquear, mas ao contrário: para não punir essa visita por sinais que no WebView costumam ser falsos.
- Comparação com outros sinais. O UA diz «iPhone», mas a tela, as fontes e o comportamento do script dizem outra coisa. A própria divergência já é o sinal.
- Análise. Recortes por navegador e SO nos relatórios mostram onde a conversão cai e de onde vem um pico suspeito.
Combinação com outros sinais: o UA como uma voz entre muitas
Uma boa proteção não pergunta «qual o UA da visita», pergunta «o UA bate com todo o resto?». Estes são os sinais com que ele costuma ser comparado:
| Sinal | Com o que o UA é comparado |
|---|---|
| Endereço IP e rede | Navegador mobile vindo de rede de hospedagem merece atenção; mais no artigo sobre VPN, proxy e IPs de datacenter |
| Cabeçalhos da requisição | O conjunto e a ordem dos cabeçalhos de um navegador real diferem dos de uma biblioteca, mesmo com a mesma string UA |
| Client Hints | Plataforma e marca do navegador nas dicas devem coincidir com a string |
| Execução de JavaScript | Um navegador que se diz Chrome moderno mas não executou o script não se comporta como navegador |
| Propriedades do navegador no script | Plataforma, tela, sinais de automação; detalhes no artigo sobre navegador headless e fingerprint |
| Comportamento | Tempo na página, movimento do mouse e toques |
Cada sinal isolado erra. Juntos, dão uma avaliação que erra bem menos. É assim que funciona qualquer filtro de tráfego inteligente moderno: um sinal isolado acrescenta um pouco de suspeita, e uma conclusão segura vem da coincidência de vários. O esquema geral de camadas de proteção está no artigo sobre como filtrar bots.
Como isso funciona na ArtisanClo
Na ArtisanClo, a string user agent é um dos sinais, não uma regra isolada «por lista». A decisão sobre a visita é feita em várias etapas, e o UA participa de cada uma de um jeito.
Rede e requisição. A primeira etapa olha endereço, rede, provedor, cabeçalhos, marca de clique e regras do fluxo — antes mesmo da verificação do navegador. Aqui são barrados programas no lugar de navegador e robôs das plataformas que geram pré-visualização de links: essas visitas sempre recebem a White Page, com qualquer configuração, e no log aparece o motivo «Um programa, não um navegador» ou «Crawler de busca ou de plataforma». É a etapa que menos atinge pessoas reais.
Públicos. Nas configurações de filtragem do fluxo há listas de «Dispositivos», «Sistemas operacionais» e «Navegadores» com as opções de permitir e bloquear. Entre os dispositivos aparecem à parte «Bot / crawler» e «Desconhecido». Isso é segmentação: o visitante que não passa na lista vê a White Page com um motivo claro.
Verificação do navegador. Quem enviou a string de um navegador real passa pela verificação por script, e é a resposta dela que mostra se a visita parece automação. O bloqueio de navegadores headless barra na hora quando há rastros claros de automação; sinais menos evidentes vão para a avaliação de confiança, junto com rede, VPN, presença de provedor e do site de origem.
Navegadores embutidos. Os navegadores embutidos do Facebook, Instagram e TikTok e o WebView em apps são reconhecidos à parte. Neles, um sinal de automação não barra a visita na hora; ele entra na avaliação de confiança junto com rede, tempo e referer, porque nesses navegadores costuma ser falso.
Transparência. Cada clique no log tem um motivo de decisão entre dezenas possíveis, e o link «Relatório da visita» mostra todos os sinais e conclusões de uma visita. Se você suspeita de erro do filtro, comece pelo artigo por que o clique foi para a White Page. Todos os recursos de filtragem estão na página de recursos.
Erros comuns no filtro por user agent
- Montar a proteção numa lista negra de trechos. Ela só pega quem não se esconde e exige atualização sem fim.
- Bloquear tudo que é «fora do padrão». Isso atinge os navegadores embutidos das redes sociais e aparelhos antigos — tráfego pago e vivo.
- Confiar numa string que parece correta. Um UA perfeito de navegador moderno é exatamente o que um bot bem feito envia.
- Confundir segmentação com proteção. Selecionar «só Android» é uma decisão sobre o público da oferta, não um jeito de se livrar de bots.
- Não olhar os motivos de bloqueio. Sem ver qual regra disparou, não dá para saber se o filtro corta bots ou pessoas. Os sinais pelos quais o tráfego de bots aparece nos relatórios estão no artigo sobre sinais de tráfego de bots.
Resumo
A string user agent é o que o cliente diz sobre si mesmo. Dá para confiar nela quando a aposta é baixa: identificar o dispositivo, distribuir o tráfego, fazer análise. Não dá para confiar nela como prova de que há uma pessoa do outro lado. O filtro por user agent remove bem scripts brutos e requisições vazias, mas a proteção de verdade começa quando o UA é comparado com rede, cabeçalhos, Client Hints, execução do script e comportamento. Aí a string falsificada não ajuda o bot, e uma string incomum não prejudica o visitante real.
