Impressão de proxy TCP/IP: como verificar se o seu sistema operacional não está te expondo para o anti-bot

Você configurou um navegador anti-detect para Windows e Chrome, escolheu um IP limpo, ajustou o fuso horário e o idioma, mas o site ainda coloca um captcha ou corta a conta. Uma causa comum está abaixo do navegador, no nível TCP/IP. O servidor vê o primeiro pacote de conexão (SYN), e pelos seus campos é possível identificar qual sistema operacional enviou esse pacote. Se for um proxy Linux e o User-Agent declarar Windows, o sistema anti-bot recebe uma contradição que não pode ser corrigida apenas com cabeçalhos.

O tema deixou de ser exótico. Em 13 de outubro de 2026, segundo dados da Proxyway, o provedor britânico Byteful lançou em beta aberto a substituição do fingerprint TCP/IP para proxies de data center e ISP: eles podem se passar por Windows, macOS, Linux, Android e iOS. A explicação da Proxyway é simples: os sistemas anti-bot estão cada vez mais atentos ao fingerprint TCP/IP. Abaixo, vamos analisar como essa verificação funciona, como verificar seu proxy em cinco minutos e o que fazer em caso de discrepância.

O que é fingerprint TCP/IP e por que o proxy o altera

Cada sistema operacional coleta o pacote SYN de maneira diferente: seu TTL inicial, tamanho da janela TCP, fator de escalonamento da janela, MSS e, o mais importante, o conjunto e a ordem das opções TCP. O fingerprinting passivo (a clássica ferramenta p0f, as versões modernas são chamadas Zardaxt e JA4T) lê esses campos e adivinha o sistema operacional, sem enviar nada ao cliente em resposta.

Ponto chave para quem trabalha através de proxies: o site vê a pilha TCP da máquina que abre a última conexão com ele. Um proxy comum (HTTP CONNECT ou SOCKS5) aceita sua conexão e abre uma nova para o site, em seu nome. Portanto, o TTL e as opções TCP no pacote pertencem ao proxy, e não ao seu computador. Você pode mudar o User-Agent, o fingerprint TLS ou os cabeçalhos, mas o SYN já foi coletado pelo núcleo da máquina pela qual você está se conectando.

Valores típicos por sistema operacional

Referências do análise da Scrapfly e da documentação do pydoll (em versões específicas do núcleo e redes, os valores podem variar):

• Windows 10/11: TTL inicial 128, janela 64240–65535, ordem das opções MSS, NOP, WSCALE, NOP, NOP, SACK (sem timestamp por padrão).
• Linux: TTL 64, janela 29200 em núcleos 3.x+ (em alguns núcleos 5.x/6.x 64240), ordem MSS, SACK, TIMESTAMP, NOP, WSCALE.
• macOS e iOS: TTL 64, janela 65535, ordem MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
• Android: TTL 64, a ordem das opções é semelhante à do Linux, o que faz sentido, já que possui núcleo Linux.

Daqui vem a principal armadilha: quase todos os proxies de data center funcionam em Linux. O perfil "Windows + Chrome" sobre um proxy desse tipo carrega no SYN características do Linux, e essa contradição se destaca mais.

Quão precisamente os anti-bots detectam discrepâncias

Números estão disponíveis no projeto aberto Zardaxt: são versões reescritas do p0f e satori.py, que buscam especificamente retransmissores, ou seja, proxies HTTP e SOCKS, atrás dos quais o navegador se apresenta como outra máquina. Segundo o README da compilação de 21 de setembro de 2026 (base de 1.453 impressões de cerca de 23 mil sessões):

• o modelo com limite de 0,8 captura 94,4% das conexões através de proxies e marca erroneamente apenas 0,1% das conexões diretas;
• se o navegador declara Windows, o proxy é detectado em 96% dos casos, se Mac, em 99%;
• o ponto fraco é Android e Linux: eles compartilham uma classe, portanto tais retransmissores são capturados em 74% dos casos;
• VPNs de túnel quase não são detectadas pelo modelo (6,1%): através do túnel com o site, a pilha do seu próprio dispositivo é vista.

A ordem das opções TCP é o que mais revela o sistema operacional: na análise fatorial do projeto, esse campo adivinha o SO em 99,1% dos casos. A flag DF é quase inútil (0,362). Esta é uma ferramenta aberta de um pesquisador, os detalhes dos anti-bots comerciais não são publicados, mas o princípio é o mesmo: comparar o SO do SYN com o SO do User-Agent.

Como verificar seu proxy: passo a passo

1. Capture o "padrão" sem proxy. Abra em um navegador comum browserleaks.com/tcp. Anote o TTL, MSS, ordem das opções, a adivinhação do p0f e as avaliações do Zardaxt por SO. Esta é sua pilha real.
2. Verifique o proxy a partir do console. Execute uma solicitação através do proxy para um classificador aberto:
   curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
   No retorno, haverá um campo avg_score_os_class com pontuações para Linux, Windows, Mac OS e iOS. O vencedor aqui é o SO do nó de saída do proxy, e não o do seu computador.
3. Repita no perfil anti-detect. Abra browserleaks.com/tcp ou proxydetect.live/tcpip.html já no perfil com proxy. Agora compare duas coisas: o SO do TCP/IP e o SO do User-Agent do perfil.
4. Observe o MSS. Uma linha Ethernet limpa dá um MSS de 1460. Valores como 1380 (WireGuard), 1360 (IPsec) ou 1240 indicam um túnel no caminho. Isso por si só não é um ban, redes móveis também costumam dar um MSS menor, mas em conjunto com outros sinais aumenta as suspeitas.
5. Faça de 5 a 10 medições em rotação. Em proxies residenciais e móveis, cada novo IP pode ser de outro dispositivo com outro SO. Uma medição não diz nada, observe a distribuição.
6. Compile em uma tabela: tipo de proxy → SO por TCP → SO do perfil → correspondência sim/não. Essa é a resposta sobre qual perfil executar em qual proxy.

Um único TTL como prova não é suficiente: o valor visível diminui em cada roteador, e o site avalia apenas o inicial (64 ou 128) pela potência mais próxima. A combinação de campos é o que importa, principalmente a ordem das opções.

O que fazer em caso de discrepância

1. Ajuste o perfil para o proxy, e não o contrário

A maneira mais barata: escolha o SO do perfil para que corresponda ao que o nó de saída mostra. Se o proxy fornece Linux, é mais honesto iniciar um perfil Linux do que tentar convencer o site de que você é Windows. Para tarefas onde o SO do perfil não é importante (raspagem de páginas públicas, monitoramento de preços), isso resolve o problema completamente.

2. Escolha o tipo de proxy para o SO necessário

• Proxies de data center quase sempre mostram um servidor Linux de um ASN em nuvem. Isso é normal para raspagem a partir de um cliente Linux (Python, Go, curl no servidor): a pilha e o User-Agent do seu script estão em conformidade. Para perfis "usuário Windows", isso é um ponto fraco. Proxies de data center devem ser escolhidos onde a velocidade e o preço por gigabyte são importantes, e não a lenda de um "humano real".
• Proxies residenciais se conectam através de dispositivos e gateways domésticos reais, portanto o site vê a pilha do nó de usuário real. O SO em um IP específico não é garantido, mas é a pilha de um dispositivo real, e não de um servidor em nuvem. Para multi-contas e anti-bots complexos, proxies residenciais oferecem a imagem mais natural, se você verificar a distribuição do SO na rotação.
• Proxies móveis mostram caminhos semelhantes ao Android ou iOS. Para perfis móveis (redes sociais, aplicativos, versão móvel de sites), isso é uma correspondência ideal em todos os níveis. Para mais informações sobre como distinguir um IP celular real de uma falsificação, consulte nosso guia de verificação de proxies móveis. Para essas tarefas, são adequados proxies móveis 4G/5G.

3. Não confunda a camada TCP com a camada TLS

Ferramentas como curl-impersonate ou curl_cffi falsificam o handshake TLS e HTTP/2 sob Chrome, mas não tocam na pilha TCP: o SYN ainda é coletado pelo núcleo da máquina de onde a conexão é feita. Um bom fingerprint TLS sobre um TCP contraditório não salva a situação; ambas as camadas são necessárias. Como alinhar a parte TLS é discutido no artigo sobre como contornar JA4 através do curl_cffi.

4. Substituição do SO do lado do proxy e túneis

Os provedores estão começando a vender a substituição do fingerprint TCP/IP em seus servidores, como o exemplo do Byteful acima, mas isso ainda é raro e uma beta. Há também o caminho inverso: VPNs de túnel quase não são detectadas pelo modelo Zardaxt como retransmissores, porque o site vê sua própria pilha. Os contras também são conhecidos: um MSS reduzido indica um túnel, e o IP da própria VPN frequentemente aparece em bases de dados como um host.

Erros comuns

• Verificar apenas com checadores de IP. Os serviços de reputação de IP observam o endereço e o ASN, e não o SYN. Um IP limpo com pilha Linux sob um perfil Windows passa pelo checador e falha no anti-bot.
• Fazer conclusões com uma única medição na rotação. Em um pool residencial, o próximo IP pode ser de outro SO.
• Corrigir com cabeçalhos. Nenhum cabeçalho reescreve o SYN depois que o núcleo o enviou.
• Ignorar perfis Android em proxies Linux. Para modelos abertos, essa é uma zona de incerteza (74% de captura), mas os anti-bots comerciais podem adicionar outros sinais, como temporizações e ASN móvel. Um perfil móvel parece mais natural em um IP móvel.

Conclusão

O fingerprint TCP/IP é uma camada que não pode ser corrigida a partir do navegador: ele é determinado pela máquina que abre a conexão com o site. A verificação leva cinco minutos: browserleaks.com/tcp sem proxy e com proxy, além de curl para um classificador aberto. A partir daí, uma regra simples: o SO do perfil deve corresponder ao SO do nó de saída. Data centers são adequados para scripts Linux, proxies residenciais para perfis de desktop "vivos", e móveis para cenários móveis. Escolha o tipo de proxy para o seu perfil, faça de 5 a 10 medições em rotação, e o anti-bot perderá uma das pistas mais confiáveis.