Ordem dos Cabeçalhos para o CapMonster Cloud: Como Reproduzir Cabeçalhos do Navegador e Contornar a Proteção Anti-Bot

Ao testar sistemas de proteção em seus próprios sites e trabalhar com o serviço CapMonster Cloud, muitos desenvolvedores se deparam com a seguinte situação: o CAPTCHA é resolvido com sucesso, o token é obtido — mas o servidor ainda rejeita a solicitação.

Ao implementar mecanismos de CAPTCHA ou anti-bot, você precisa entender exatamente como o servidor toma sua decisão — e quais sinais ele usa para identificar automação. Muitas vezes, o motivo não está no CAPTCHA em si, mas na forma como a solicitação HTTP é enviada.

Um dos fatores-chave aqui é a ordem dos cabeçalhos. Neste artigo, você verá por que a ordem importa, como reproduzi-la corretamente e como integrar isso ao CapMonster Cloud.

Comece agora e automatize sua solução reCAPTCHA v2

Começar agora Demonstração

O que é a ordem dos cabeçalhos

Uma requisição HTTP consiste não apenas em uma URL e um corpo, mas também em um conjunto de cabeçalhos:

User-Agent
Accept
Accept-Language
Cookie
...

O servidor não lê apenas o conteúdo dos cabeçalhos — ele também vê a ordem deles.

Por que isso importa para a proteção anti-bot

Os sistemas modernos de proteção (Cloudflare, DataDome, Imperva e outros) analisam:

Fingerprint TLS (JA3/JA3S)
Fingerprint de HTTP/2 SETTINGS (fingerprint H2 da Akamai)
User-Agent
reputação do IP (ASN, IP de data center ou IP residencial)
fingerprint de JavaScript
ordem dos cabeçalhos
comportamento do cliente

Navegadores reais (Chrome, Firefox e outros) enviam os cabeçalhos:

em uma ordem estritamente definida
de forma consistente em cada requisição

Mas bibliotecas HTTP comuns — requests (Python) e axios (Node.js) — podem adicionar cabeçalhos padrão (User-Agent, Accept-Encoding, Connection) por cima dos definidos pelo usuário, ordenar os cabeçalhos ou enviá-los em ordem aleatória, o que quebra a sequência esperada e revela a automação.

Como isso se relaciona com o CapMonster Cloud

O CapMonster Cloud apenas resolve o CAPTCHA e não faz sua requisição “parecer um navegador”.

Ou seja:

Você recebeu um token válido
Adicionou esse token à requisição
Mas o servidor ainda responde com um erro

Por quê? Porque a sua requisição parece a de um bot.

Como o navegador envia os cabeçalhos (Chrome 146*)

Essa ordem se repete em um navegador real quase sempre:

* No momento da redação, a versão 146 do Chrome é a atual.

Pseudo-cabeçalhos HTTP/2

:method
:authority
:scheme
:path

Cabeçalhos normais (exemplo do Chrome)

sec-ch-ua
sec-ch-ua-mobile
sec-ch-ua-platform
upgrade-insecure-requests
user-agent
accept
sec-fetch-site
sec-fetch-mode
sec-fetch-user
sec-fetch-dest
accept-encoding
accept-language
priority

Um erro comum — copiar do DevTools

Muitos desenvolvedores fazem o seguinte:

Abrem o Chrome DevTools
Copiam os cabeçalhos
Colam no código

O problema:

O DevTools nem sempre mostra a ordem real e pode ordenar os cabeçalhos
Como resultado, a ordem no código difere da do navegador

Como obter a ordem correta

Use ferramentas que mostrem as requisições reais:

Charles Proxy
mitmproxy
powhttp

Elas mostram os cabeçalhos exatamente como o servidor os vê.

Por exemplo (capturado com o Charles Proxy):

:method: GET
:authority: example
:scheme: https
:path: /assets/js/example.js
sec-ch-ua-full-version-list: "Chromium";v="146.0.7680.178", "Not-A.Brand";v="24.0.0.0", "Google Chrome";v="146.0.7680.178"
sec-ch-ua-platform: "Windows"
sec-ch-ua: "Chromium";v="146", "Not-A.Brand";v="24", "Google Chrome";v="146"
sec-ch-ua-bitness: "64"
sec-ch-ua-model: ""
sec-ch-ua-mobile: ?0
sec-ch-ua-arch: "x86"
sec-ch-ua-full-version: "146.0.7680.178"
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
sec-ch-ua-platform-version: "19.0.0"
accept: */*
sec-fetch-site: same-origin
sec-fetch-mode: no-cors
sec-fetch-dest: script
referer: https://example.com/
accept-encoding: gzip, deflate, br, zstd
accept-language: en-US,en;q=0.9,ru;q=0.8
priority u=0, i

Como reproduzir a ordem dos cabeçalhos no código

Depois de obter a ordem real dos cabeçalhos, a próxima tarefa é reproduzi-la corretamente no seu cliente HTTP.

O principal problema é que a maioria das bibliotecas padrão não garante a ordem dos cabeçalhos.

Ferramenta	Controle de ordem	HTTP/2	Fingerprint TLS
requests	❌	❌	❌
axios	❌	parcialmente	❌
tls-client	✅	✅	✅
Playwright	✅ (navegador)	✅	✅

Para reproduzir com precisão o comportamento do navegador, recomenda-se usar soluções especializadas:

tls-client (Go / Python) — implementa o controle da ordem dos cabeçalhos por meio de header_order + pseudo_header_order no nível do binding Go bogdanfinn/tls-client, passando os parâmetros diretamente para a biblioteca nativa
clientes HTTP/2 personalizados
automação de navegador (por exemplo, Playwright) — se a sobrecarga for aceitável

Exemplo de configuração (Python + tls-client)

Abaixo está um exemplo que demonstra uma abordagem básica para reproduzir uma ordem de cabeçalhos semelhante à do Chrome.

Importante: chrome_146 é um perfil válido na biblioteca Go bogdanfinn/tls-client, documentado como “Latest”. No entanto, o pacote Python padrão FlorianREGAZ/Python-Tls-Client (pip install tls-client) está abandonado e contém perfis somente até chrome_120. Um leitor que instalar o pacote padrão receberá um erro. Use o fork atual do bogdanfinn/tls-client ou um binding Python compatível com suporte a chrome_146.

import tls_client

session = tls_client.Session(
    client_identifier="chrome_146",
    random_tls_extension_order=True
)

session.pseudo_header_order = [
    ":method",
    ":authority",
    ":scheme",
    ":path",
]

session.header_order = [
    "sec-ch-ua",
    "sec-ch-ua-mobile",
    "sec-ch-ua-platform",
    "upgrade-insecure-requests",
    "user-agent",
    "accept",
    "sec-fetch-site",
    "sec-fetch-mode",
    "sec-fetch-user",
    "sec-fetch-dest",
    "accept-encoding",
    "accept-language",
    "cookie",
    "priority",
]

headers = {
    "sec-ch-ua": '"Chromium";v="146", "Not-A.Brand";v="24", "Google Chrome";v="146"',
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": '"Windows"',
    "upgrade-insecure-requests": "1",
    "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/146.0.0.0 Safari/537.36",
    "accept": "*/*",
    "sec-fetch-site": "same-origin",
    "sec-fetch-mode": "no-cors",
    "sec-fetch-dest": "script",
    "accept-encoding": "gzip, deflate, br, zstd",
    "accept-language": "en-US,en;q=0.9",
    "priority": "u=0, i",
}

response = session.get("https://example.com", headers=headers)
print(response.status_code)

A ordem em session.header_order deve corresponder à que você obteve de um navegador real. Quaisquer desvios podem afetar o resultado.

Fingerprint de HTTP/2 SETTINGS

Os sistemas anti-bot analisam não apenas os cabeçalhos — eles verificam o fingerprint de HTTP/2 SETTINGS até antes de analisar os cabeçalhos. Cloudflare e DataDome usam o chamado fingerprint H2 da Akamai, que codifica os parâmetros em uma string no seguinte formato:

SETTINGS|WINDOW_UPDATE|PRIORITY|PSEUDO_HEADER_ORDER

Esse sinal permite detectar instantaneamente curl, requests e axios — sem analisar o conteúdo da requisição. O tls-client resolve esse problema automaticamente por meio de client_identifier: ele aplica o perfil correto de H2 SETTINGS para o navegador selecionado. É por isso que o parâmetro client_identifier="chrome_146" não é apenas uma “versão do Chrome”, mas um perfil completo de toda a pilha de rede.

Comece agora e automatize sua solução reCAPTCHA v2

Começar agora Demonstração

O Papel dos Cookies Após a Resolução do CAPTCHA

Após passar com sucesso por um CAPTCHA, os servidores frequentemente definem cookies adicionais. Dependendo do sistema de proteção em uso, eles podem incluir:

cf_clearance (Cloudflare)
datadome (DataDome)
visid_incap (Imperva)

Esses cookies passam a fazer parte da sessão subsequente e devem ser enviados nas requisições seguintes.

O cabeçalho cookie deve aparecer na posição correta dentro da ordem dos cabeçalhos. Se ele:

estiver ausente da lista de ordem dos cabeçalhos
ou for acrescentado automaticamente no final

isso pode quebrar a estrutura esperada da requisição e levar à rejeição.

Exemplo de envio de cookies via sessão em tls-client:

import tls_client

session = tls_client.Session(
    client_identifier="chrome_146",
    random_tls_extension_order=True,
)

# Após receber cf_clearance do CapMonster Cloud / manualmente — passe-o para a sessão
session.cookies.set(
    "cf_clearance",
    "received_value",
    domain=".example.com",
)

# Todas as requisições subsequentes incluirão automaticamente o cookie na posição correta
response = session.get(
    "https://example.com/protected-page",
    headers=headers,
)

print(response.status_code)

Erros Adicionais Que Afetam o Resultado

Inconsistência de Cabeçalhos Entre Requisições

Navegadores reais usam um conjunto estável de cabeçalhos. Se o seu script:

envia cabeçalhos diferentes em etapas diferentes
altera a ordem deles
adiciona ou remove cabeçalhos sem lógica

isso é percebido como uma anomalia.

Referer Incorreto

O cabeçalho referer desempenha um papel importante no contexto de navegação. Sua ausência ou incompatibilidade pode parecer suspeita.

Por exemplo, se você solicita um recurso que normalmente é carregado a partir de uma página, mas não especifica um referer, isso pode acionar uma verificação adicional.

Incompatibilidade nos Cabeçalhos sec-fetch

Os cabeçalhos Sec-Fetch-Site, Sec-Fetch-Mode e Sec-Fetch-Dest devem corresponder ao contexto real da requisição. Sec-Fetch-Site mostra a relação entre o iniciador e o recurso de destino, Sec-Fetch-Mode indica o modo da requisição, e Sec-Fetch-Dest indica o destino do recurso carregado.

Valores incorretos ou inconsistentes podem contradizer o restante dos dados da requisição HTTP e ser usados pelo servidor como um sinal para rejeitar a requisição. Os erros são especialmente comuns quando none é usado para um clique normal em um link ou quando cross-origin é confundido com cross-site.

Tabela de valores corretos dependendo do tipo de requisição:

Cenário	sec-fetch-site	sec-fetch-mode	sec-fetch-dest
Entrada direta de URL na barra de endereços / abertura de um favorito	none	navigate	document
Seguir um link para uma página na mesma origem	same-origin	navigate	document
Seguir um link para uma página no mesmo site, mas em uma origem diferente	same-site	navigate	document
Seguir um link para outro site	cross-site	navigate	document
fetch() / XHR para a mesma origem	same-origin	cors	empty
fetch() / XHR para o mesmo site, mas com uma origem diferente	same-site	cors	empty
fetch() / XHR para outro site	cross-site	cors	empty
Carregamento de uma imagem da mesma origem	same-origin	no-cors	image
Carregamento de uma imagem de outro site	cross-site	no-cors	image

Uso de HTTP/1.1 em Vez de HTTP/2

Navegadores modernos, incluindo o Chrome, usam HTTP/2 por padrão.

Se o seu cliente funciona com HTTP/1.1, isso já cria uma diferença perceptível. Em combinação com outros fatores, isso pode afetar a decisão do sistema anti-bot.

sec-ch-ua-full-version-list Fixado no Código

O cabeçalho sec-ch-ua-full-version-list aparece somente em resposta ao Accept-CH do servidor (Client Hints API) — não automaticamente em toda requisição. Ele não deve estar presente em “requisições frias”.

Fixar esse cabeçalho no código pode levar a uma incompatibilidade entre User-Agent, sec-ch-ua e o perfil TLS real. Como resultado, a requisição parece inconsistente e pode ser rejeitada pelo sistema anti-bot.

Em alguns casos (por exemplo, ao trabalhar com DataDome), é mais seguro obtê-lo a partir de tráfego real ou não defini-lo manualmente, a menos que seja necessário.

Cookies Duplicados

Outro erro comum é enviar vários cookies com o mesmo nome, mas com valores diferentes. Por exemplo:

Essa situação pode ocorrer se:

os cookies forem gerenciados manualmente sem usar um cookie jar
a biblioteca mesclar cookies incorretamente
os valores forem definidos repetidamente

A abordagem correta:

usar mecanismos integrados de gerenciamento de cookies (cookie jar)
verificar o cabeçalho cookie final antes do envio
evitar nomes duplicados

Uma Abordagem Prática de Depuração

A forma mais confiável de diagnosticar problemas é comparar uma requisição real do navegador com a sua.

Processo recomendado:

Capture a requisição do navegador usando ferramentas como Charles Proxy ou mitmproxy
Execute a mesma requisição no seu código
Compare as duas linha por linha

Atenção especial deve ser dada a:

ordem dos cabeçalhos
presença ou ausência de cabeçalhos específicos
valores dos cabeçalhos
cookies

Mesmo pequenas diferenças podem importar.

Conclusão

O serviço CapMonster Cloud ajuda a obter uma solução correta de CAPTCHA, mas o processamento posterior e o uso dessa solução na sua aplicação continuam sendo sua responsabilidade.

Por exemplo, o Cloudflare Bot Management verifica TLS, H2 SETTINGS e cabeçalhos simultaneamente — falhar em uma única camada já é suficiente para acionar um bloqueio. Para interagir com sucesso com sistemas protegidos, você precisa:

reproduzir o comportamento do navegador no nível HTTP
manter a ordem exata dos cabeçalhos
usar o perfil TLS correto e H2 SETTINGS corretos por meio de client_identifier
manter consistência entre as requisições
lidar corretamente com cookies por meio de um cookie jar

Somente a combinação desses fatores torna possível alcançar resultados estáveis ao testar e trabalhar com proteções anti-bot.