O cloaker server-side é um filtro que toma a decisão no servidor do seu site: a requisição do visitante chega à hospedagem, o código PHP pergunta ao serviço de filtragem quem está ali e só depois da resposta entrega ao navegador a oferta ou uma página neutra. O cloaker no navegador funciona de outro jeito: a página já está carregando, e a tag JS no <head> esconde o conteúdo, verifica a visita e mostra a versão certa.
Os dois esquemas resolvem a mesma tarefa — barrar bots, scanners, ferramentas spy e tráfego fora do público —, mas enxergam a visita de lados diferentes e quebram de formas diferentes. A instalação passo a passo está no artigo como instalar o cloaker no site; aqui o assunto é a arquitetura: o que acontece por dentro, onde cada método é forte e onde é fraco.
Cloaker server-side (server-side cloaking): o caminho da requisição
O trajeto da visita no esquema do servidor:
- O visitante clica no anúncio, e o navegador pede
seu-site.com. - A requisição chega ao seu servidor, e quem responde primeiro é o arquivo PHP, não a landing page.
- O arquivo envia ao serviço os dados da requisição: IP, cabeçalhos, parâmetros do link.
- O serviço verifica a visita e devolve a decisão.
- O servidor entrega ao navegador a oferta ou a White Page. Até esse momento o navegador não recebeu nem um byte da página.
A propriedade-chave: a página não vai para o visitante antes da decisão. O bot não tem o que salvar, o bloqueador de anúncios não tem o que cortar, a internet lenta não tem o que mostrar antes da hora.
Cloaker no navegador: como funciona a tag JS
No esquema do navegador, a ordem é inversa:
- O navegador pede a página, e sua hospedagem a entrega igual para todos.
- Na primeira linha do
<head>está a tag: ela carrega antes de todo o resto e esconde a página. - A tag coleta os sinais do navegador e os envia ao serviço.
- Chegou a decisão «oferta» — a página aparece. «White Page» ou nenhuma decisão — o visitante é levado para a página neutra.
A vantagem desse esquema é a simplicidade: a tag entra em qualquer página em que você tenha acesso ao <head>, mesmo num construtor sem servidor próprio. A desvantagem: o HTML da landing já está fisicamente no navegador. A tag o esconde, mas não pode «deixar de entregar».
O que cada cloaker enxerga da visita
A principal diferença entre as arquiteturas está no conjunto de sinais.
| Sinal | Servidor | Navegador |
|---|---|---|
| IP, provedor, rede, país pelo endereço | Sim | Sim, via serviço |
| User-Agent, idioma, referer, cabeçalhos da requisição | Sim | Sim |
| Parâmetros do link: fbclid, gclid, ttclid, UTM | Sim | Sim |
| Se o cliente executa JavaScript | Não | Sim |
| Fuso horário e idioma do navegador | Não | Sim |
| Sinais de automação (webdriver, headless) | Em parte, pelos cabeçalhos | Sim |
| Tela, plataforma, propriedades do navegador | Não | Sim |
| Movimentos do mouse e toques | Não | Sim |
| Tempo passado na página | Não | Sim |
O servidor vê a requisição; o navegador vê o ambiente em que ela é executada. Um bot simples de datacenter é pego pelos dois. Já um navegador automatizado em proxy residencial com User-Agent correto, o servidor não distingue de uma pessoa por uma única requisição — quem o entrega é o comportamento do JavaScript: fuso horário que não bate com o país do endereço, rastros de automação, ausência de movimentos. Sobre esses sinais, veja os artigos navegador headless e fingerprint e VPN, proxy e IPs de datacenter.
Híbrido: decisão no servidor mais página de verificação
Por isso, o esquema puramente no servidor aparece na prática menos do que parece. O filtro no servidor decide na hora quando tudo está claro pela requisição e, nos casos duvidosos, entrega uma página curta de verificação: ela executa JavaScript, coleta os sinais do navegador e pede a decisão de novo. Para a pessoa, são frações de segundo de espera; para o bot simples, um beco sem saída.
Na ArtisanClo, o arquivo PHP funciona exatamente assim: se as regras do fluxo exigem JavaScript ou um tempo mínimo na página, o visitante vê a página de espera e é verificado novamente. Já na conexão como filtro para o Keitaro ou como gateway para o Binom não há página de verificação — a decisão é tomada só pela rede e pelos sinais da requisição, então a checagem de JavaScript e o tempo na página não valem ali.
Velocidade: onde se perdem os milissegundos
Qualquer filtro acrescenta ao carregamento o tempo da decisão. A diferença está em onde exatamente.
- O esquema no servidor acrescenta uma requisição da sua hospedagem ao serviço antes do primeiro byte. A velocidade depende da conectividade de rede da hospedagem: um bom servidor em datacenter responde rápido; uma hospedagem compartilhada sobrecarregada deixa lentas tanto a landing quanto a verificação.
- O esquema no navegador acrescenta o carregamento do script e uma requisição a partir do navegador do visitante. Na internet móvel isso pesa mais, mas a página já está carregando em paralelo — depois da decisão, não precisa ser baixada de novo.
- A página de verificação acrescenta espera de propósito. Ative-a onde o rigor se justifica pela fonte, e não em todo lugar por padrão.
Na prática, uma landing com uma dezena de scripts de análise e imagens pesadas perde mais tempo do que qualquer um dos métodos de filtragem. Otimizar a página costuma render mais do que escolher a arquitetura.
Confiabilidade: como o cloaker se comporta em falhas
A tolerância a falhas é onde as arquiteturas mais divergem.
Se a tag JS não carregou
A tag é um script externo. Se a rede, um filtro corporativo ou um bloqueador no caminho não a deixou passar, a página simplesmente não se esconde, e todos a veem, inclusive bots e ferramentas spy. Aqui a falha é «aberta». Se a tag carregou, mas não há decisão, ela leva o visitante para a White Page — uma falha «fechada».
Se o serviço não respondeu ao servidor
O método no servidor espera a resposta por um tempo limitado. Na ArtisanClo, o arquivo PHP espera até 4 segundos e, se perder a conexão, atende as visitas por até um dia com base na última resposta recebida: visitantes com marca de clique de anúncio vão para a oferta, os demais para a White Page. Uma visita que chegar antes da primeira resposta recebe erro 503. No filtro para o Keitaro e no gateway para o Binom, o limite é de 3 segundos; depois disso, a visita vai para a White Page.
Se a hospedagem caiu
Aqui os dois esquemas empatam: a landing está com você, e o filtro não levanta um servidor fora do ar. O serviço responde pela decisão; você, pela disponibilidade da página e pelo certificado.
| Situação | Tag JS | Arquivo PHP |
|---|---|---|
| Script bloqueado no caminho | Todos veem a página | Não se aplica |
| Serviço não respondeu | White Page | Funciona com a última resposta por até um dia |
| Hospedagem sem conexões de saída | Não afeta | Erro 503, carregamento lento |
| Firewall da hospedagem (WAF) | Em geral não afeta | Pode cortar as requisições de verificação |
Cache, CDN e proxy: inimigos silenciosos do cloaker no servidor
O esquema no servidor conta com que cada requisição chegue ao arquivo PHP. Três coisas atrapalham.
- Cache de páginas. Um plugin de cache, o cache da hospedagem ou uma CDN entregam a cópia salva sem pedir decisão. Resultado: todos veem a mesma página — a que caiu no cache. A landing com filtro precisa ser excluída do cache. A tag sofre menos com o cache de HTML: o script dentro da cópia é executado no navegador de qualquer forma, se a cópia foi feita depois da instalação.
- Proxy na frente do site. Se a hospedagem coloca um proxy próprio na frente do servidor, o arquivo PHP vê o endereço do proxy em vez do endereço do visitante, e o filtro avalia o seu servidor, não as pessoas. O sintoma: todas as visitas no log com o mesmo IP. A correção é repassar o endereço real (configuração de real IP) ou usar o proxy do Cloudflare, cujos cabeçalhos o arquivo entende.
- Cache da decisão no navegador. Para não consultar o serviço a cada recarregamento, a decisão para um mesmo visitante pode ficar guardada por pouco tempo. Na ArtisanClo, com o arquivo PHP, até um minuto; por isso, depois de editar o fluxo, teste numa nova janela anônima.
Esses e outros defeitos estão no artigo cloaker não funciona.
O que só o esquema no servidor sabe fazer
Há recursos fisicamente indisponíveis para o código no navegador.
- Código de resposta em vez de página. O servidor pode responder 403 ou 404, como um endereço fechado. A tag não consegue mudar o código de resposta — no lugar fica uma página em branco.
- Modo sombra. Todos os visitantes vão para a oferta, e o log mostra quem o filtro teria barrado. É assim que se testa uma regra nova sem perder tráfego.
- Modo «Tracker». O filtro não barra ninguém; só conta cliques, conversões e dinheiro e marca os bots nos relatórios. Serve para o tráfego que precisa de contabilidade, não de filtragem — mais no artigo tracker para afiliados.
Na ArtisanClo, o modo sombra e o modo «Tracker» funcionam com conexão por arquivo PHP, filtro do Keitaro ou gateway do Binom; com a tag JS, o fluxo filtra como um cloaker comum.
Atualizações e manutenção
Outra diferença de que nem sempre se lembra logo: quem responde por manter o código do site atualizado.
- A tag JS é carregada do serviço a cada visita. Quando o serviço melhora as verificações do navegador, todos os sites com a tag recebem a nova versão automaticamente — do seu lado, nada muda.
- O arquivo PHP fica na sua hospedagem e não se atualiza sozinho. A lógica das verificações e as bases de bots vivem no serviço, então o trabalho principal do filtro melhora sem você, mas recursos novos do próprio arquivo exigem trocá-lo. Na ArtisanClo, um aviso de que você está usando um arquivo antigo mostra a lista do que a sua versão atual não sabe fazer.
Em ambos os casos, as configurações do fluxo ficam no painel, não no código do site. Mudou países, rigor ou White Page — as alterações valem a partir da próxima visita, sem reenviar o arquivo nem colar a tag de novo.
Vale lembrar também dos direitos de acesso. O arquivo PHP é executado no seu servidor, então pegue-o só no painel do serviço e não o edite à mão: um arquivo «melhorado» de um chat ou fórum pode fazer qualquer coisa na sua hospedagem.
Cloaker PHP ou tag JS: qual escolher
| Sua situação | O que serve |
|---|---|
| Construtor de sites sem acesso ao servidor | Tag JS |
| Hospedagem própria com PHP | Arquivo PHP |
| WordPress | Plugin que instala o mesmo método no servidor |
| Precisa de contabilidade sem filtragem ou teste de regras em sombra | Arquivo PHP |
| O tráfego já passa pelo Keitaro ou Binom | Filtro ou gateway do tracker — veja Keitaro e cloaker |
| A hospedagem proíbe conexões de saída | Tag JS |
Em resumo: a tag é mais rápida de instalar; o método no servidor é mais confiável e oferece mais modos. As configurações de filtragem não dependem da arquitetura — ficam no fluxo, e o método de conexão pode ser trocado sem mexer nas regras. A comparação com scripts caseiros, que também são chamados de «cloaker PHP», está no artigo cloaker em nuvem ou script.
Dica. Seja qual for o esquema, depois da instalação abra o link do anúncio numa janela anônima e encontre sua visita no log de cliques. O motivo da decisão mostra na hora se o filtro vê o IP real, se a verificação dispara e se o cache não está entregando uma cópia velha.
Filtragem no servidor e políticas das plataformas
A arquitetura não muda o lado das regras. As plataformas de anúncios proíbem mostrar ao sistema de revisão algo diferente do que o usuário vai ver — não importa se quem decide é o servidor ou o navegador. O benefício honesto de qualquer esquema é barrar bots, cliques fraudulentos, ferramentas spy e geo fora do alvo, ter estatísticas limpas e controlar o dinheiro. Mais sobre isso no artigo cloaker para afiliados.
Resumo
- O cloaker server-side decide antes de entregar a página: não depende de bloqueadores, sabe usar códigos de resposta, modo sombra e modo «Tracker», mas exige PHP, conexões de saída e cuidado com cache e proxy.
- O cloaker no navegador entra em qualquer
<head>e vê sinais indisponíveis para o servidor, mas o HTML da página já está no navegador, e um script que não carregou não esconde nada. - O melhor dos dois mundos é a decisão no servidor com página de verificação: a rede e a requisição ficam com o servidor; o comportamento e o ambiente, com um JavaScript curto no navegador.
- Condições, recursos e composição dos planos estão nas páginas de recursos e de planos.
