Por que seus arquivos não chegam pelo WhatsApp? A verdade por trás do erro 131053 que está afetando milhares de empresas no Brasil

Se você usa o Chatwoot, a Evolution API ou qualquer plataforma de atendimento integrada ao WhatsApp e, de repente, começou a receber o temido erro "131053: Media upload error" ao tentar enviar imagens, PDFs ou áudios para seus clientes, saiba que você não está sozinho. Desde o início de fevereiro de 2026, milhares de empresas brasileiras estão enfrentando o mesmo problema — e a causa não é o que você imagina.

Neste artigo, vou explicar em detalhes o que está acontecendo, por que está acontecendo, e o que você pode fazer para resolver. Vamos desde os conceitos mais básicos até a raiz técnica do problema.

O cenário: como funciona o envio de mensagens pelo WhatsApp Business

Antes de entender o problema, é importante entender como o WhatsApp Business API funciona nos bastidores.

Quando uma empresa quer se comunicar com seus clientes pelo WhatsApp de forma profissional e em escala, ela não usa o aplicativo do celular. Ela usa a WhatsApp Cloud API, uma interface técnica fornecida pela Meta (empresa dona do WhatsApp, Facebook e Instagram) que permite enviar e receber mensagens por meio de código e integrações com outros sistemas.

Para facilitar o uso dessa API, surgiram diversas plataformas de atendimento que fazem a ponte entre a equipe de suporte e o WhatsApp. No Brasil, as mais populares são:

Chatwoot: uma plataforma open-source de atendimento multicanal, que centraliza conversas de WhatsApp, e-mail, chat do site e redes sociais em um único painel.
Evolution API: um gateway que facilita a comunicação com o WhatsApp, permitindo enviar e receber mensagens de forma programática.
n8n: uma ferramenta de automação que conecta diferentes serviços e permite criar fluxos automatizados sem precisar programar do zero.

Essas três ferramentas, combinadas, formam uma stack poderosa e acessível que revolucionou o atendimento ao cliente de pequenas e médias empresas no Brasil.

O que é o erro 131053?

O código 131053 é um erro retornado pela API do WhatsApp que significa "Media upload error" — ou seja, o WhatsApp não conseguiu processar o arquivo de mídia que você tentou enviar.

Na prática, quando esse erro aparece, a mensagem de texto pode até ser entregue, mas qualquer anexo — foto, PDF, áudio, vídeo — falha. O mais intrigante é que o erro é intermitente: às vezes funciona, às vezes não, sem nenhuma mudança aparente na configuração.

Se você olhar os logs detalhados do erro, vai encontrar algo assim:

Error code: 131053
Title: Media upload error
Details: Downloading media from weblink failed with http code 429,
status message Too Many Requests, ratelimit reason: Request ratelimit
by fwdproxy. Details: [GlobalCountingRatelimiter] Request hit ratelimit
policy — destination matcher asn_list: 47583

Essa mensagem de erro contém todas as pistas para entender o que está acontecendo. Vamos decifrá-la passo a passo.

Entendendo o fluxo: como o Chatwoot envia arquivos pelo WhatsApp

Para compreender o problema, precisamos entender exatamente o que acontece quando você anexa um arquivo no Chatwoot e clica em enviar.

Passo 1: Upload do arquivo no seu servidor

Quando você seleciona um PDF ou uma imagem no Chatwoot, o arquivo é enviado para o storage do seu servidor. Pode ser o disco local, um MinIO (servidor de armazenamento compatível com S3) ou um serviço de nuvem como AWS S3. Até aqui, tudo funciona perfeitamente.

Passo 2: Chatwoot envia a URL para a API do WhatsApp

Depois de armazenar o arquivo, o Chatwoot não envia o arquivo em si para o WhatsApp. Em vez disso, ele envia uma URL — um endereço web onde o arquivo pode ser baixado. A mensagem para a API do WhatsApp é algo como:

{
  "type": "document",
  "document": {
    "link": "https://seuservidor.com.br/rails/active_storage/blobs/redirect/arquivo.pdf"
  }
}

O Chatwoot está dizendo: "WhatsApp, aqui está o link do arquivo. Vai lá e baixa."

Passo 3: O WhatsApp vai buscar o arquivo

É aqui que as coisas ficam interessantes. Quando a API do WhatsApp recebe essa URL, ela não repassa o link direto para o destinatário. Ela precisa primeiro baixar o arquivo do seu servidor, processá-lo, e depois entregá-lo ao contato.

Quem faz esse download é um serviço interno da Meta chamado fwdproxy (forward proxy). É essencialmente um servidor da Meta que sai pela internet, acessa a URL que você forneceu, baixa o arquivo e traz de volta para dentro da infraestrutura do WhatsApp.

Passo 4: Entrega (ou erro)

Se o fwdproxy conseguir baixar o arquivo com sucesso, o WhatsApp processa e entrega a mídia ao destinatário. Se algo der errado nesse download — o servidor estiver fora do ar, a URL for inválida, ou houver um rate limit — o WhatsApp retorna o erro 131053.

O que é um ASN e por que isso importa?

Para entender o rate limit, precisamos falar sobre um conceito de infraestrutura de internet: o ASN (Autonomous System Number).

Toda empresa que fornece serviços de internet — provedores de hospedagem, operadoras de telecom, empresas de cloud — possui um identificador único chamado ASN. É como um CPF da empresa no mundo da internet. Todos os endereços IP que pertencem a essa empresa estão agrupados sob o mesmo ASN.

Por exemplo:

Hostinger → ASN 47583
DigitalOcean → ASN 14061
AWS → ASN 16509
Hetzner → ASN 24940

Quando a Meta precisa controlar o tráfego que seus servidores fazem pela internet, ela não olha IP por IP individualmente. Seria inviável monitorar bilhões de IPs. Em vez disso, ela agrupa os IPs por ASN e aplica limites por bloco.

A causa real do problema: rate limit por ASN

Agora tudo se conecta.

Lembra do fwdproxy da Meta, que sai pela internet para baixar arquivos dos servidores dos clientes? A Meta implementou um sistema de proteção chamado GlobalCountingRatelimiter que funciona assim:

Toda vez que o fwdproxy precisa baixar algo de um endereço IP, ele verifica a qual ASN esse IP pertence.
Ele conta quantos downloads já foram feitos para aquele ASN em uma determinada janela de tempo.
Se o total ultrapassar um limite predefinido, todos os novos downloads para IPs daquele ASN são temporariamente bloqueados.
Resultado: erro 429 Too Many Requests.

O detalhe crucial é que esse rate limit não é por conta, não é por empresa, não é por servidor. É por ASN inteiro. Ou seja, se você está na Hostinger (ASN 47583), o limite é compartilhado com todos os outros clientes da Hostinger que também estão enviando mídia pelo WhatsApp.

Por que a Hostinger?

Aqui está o ponto-chave da história.

No Brasil, nos últimos dois anos, ocorreu uma explosão no uso de ferramentas de automação de WhatsApp. A stack Chatwoot + Evolution API + n8n + Typebot se tornou extremamente popular. Existem dezenas de cursos online, comunidades no Telegram e WhatsApp, e até plataformas que vendem instaladores com um clique para essa stack inteira.

E onde a maioria dessas pessoas hospeda seus servidores? Na Hostinger. Os motivos são simples: é barata, tem VPS no Brasil, a interface é amigável, e a própria Hostinger faz marketing pesado voltado para esse público — há inclusive tutoriais oficiais no site deles ensinando a integrar n8n com WhatsApp.

O resultado foi uma concentração massiva de instâncias de Chatwoot e Evolution API dentro de um único ASN. Milhares de empresas, todas enviando mídia pelo WhatsApp, todas pedindo para o fwdproxy da Meta baixar arquivos de IPs da Hostinger. O volume total atingiu o limite do GlobalCountingRatelimiter, e a Meta passou a bloquear intermitentemente os downloads para o ASN 47583 inteiro.

Por que o problema é intermitente?

O rate limit funciona por janela de tempo. Durante o horário comercial brasileiro (quando todos estão atendendo clientes e enviando documentos pelo WhatsApp), o volume de downloads do fwdproxy para a Hostinger atinge o pico e o rate limit é acionado com frequência. Resultado: muitas falhas.

De madrugada ou nos fins de semana, quando o volume é menor, o limite não é atingido e tudo funciona normalmente.

Por isso o erro parece aleatório: depende do momento exato em que você está tentando enviar e de quantos outros clientes da Hostinger estão fazendo a mesma coisa ao mesmo tempo.

Por que mensagens de texto funcionam e mídia não?

Essa é uma dúvida comum e a resposta é simples: mensagens de texto não envolvem o fwdproxy.

Quando você envia um texto pelo Chatwoot, o fluxo é direto:

Seu servidor → API do WhatsApp → Destinatário

O texto vai no corpo da requisição. Não há URL externa, não há download, não há fwdproxy envolvido. O rate limit simplesmente não se aplica.

Já no envio de mídia:

Seu servidor → API do WhatsApp: "baixa o arquivo nessa URL"
                    ↓
              fwdproxy da Meta → Seu servidor (Hostinger ASN 47583)
                    ↓
              RATE LIMIT! → Erro 131053

É exclusivamente o passo de download que é bloqueado.

O n8n tem culpa?

Não diretamente. E essa é uma distinção importante.

O n8n, quando envia mídia pelo WhatsApp usando seu node nativo, usa um fluxo diferente do Chatwoot. Ele faz o upload direto do arquivo para a API do WhatsApp, que retorna um identificador (media_id). Depois, ele envia a mensagem referenciando esse ID.

n8n → Upload do arquivo direto para a Meta → Meta retorna media_id
n8n → Envia mensagem com media_id → Meta entrega ao destinatário

Nesse fluxo, o arquivo sai do seu servidor para a Meta. A Meta recebe o arquivo direto, sem precisar ir buscá-lo. O fwdproxy não é acionado, e o rate limit por ASN não se aplica.

Então, embora a popularidade do n8n tenha contribuído para a concentração de servidores de automação na Hostinger, ele não é o causador direto do rate limit. Quem causa são as aplicações que mandam URLs para o WhatsApp baixar — principalmente o Chatwoot e a Evolution API.

O que a Hostinger pode fazer?

Na prática, muito pouco. O rate limit é uma decisão da Meta, aplicado na infraestrutura interna deles. A Hostinger não tem controle sobre como a Meta classifica seu tráfego.

A Hostinger poderia tentar negociar com a Meta para aumentar os limites do ASN 47583, mas isso é improvável por vários motivos:

Para a Meta, volume alto de downloads de um único ASN parece tráfego automatizado potencialmente abusivo.
A Meta não tem incentivo comercial para resolver o problema de um provedor de hospedagem barato.
A Hostinger não pode controlar o que seus clientes rodam nas VPS.

A própria Hostinger, quando acionada sobre o problema, sugeriu aos clientes que mudassem a localização da VPS para outro data center — uma admissão implícita de que não tem solução para o bloqueio do ASN.

Quais são as soluções?

1. Migrar para outro provedor de hospedagem

A solução mais definitiva é mover seu servidor para um provedor cujo ASN não esteja sendo limitado pela Meta. As opções mais recomendadas pela comunidade são:

Hetzner: popular entre quem migrou da Hostinger, preços competitivos, e até o momento sem relatos de rate limit.
DigitalOcean: infraestrutura robusta, boa documentação, e droplets prontos para Chatwoot.
Vultr, AWS, Google Cloud: alternativas mais enterprise.

Quem migrou reporta que o problema desaparece completamente.

2. Mover apenas o storage para fora da Hostinger

Se migrar o servidor inteiro é muito complexo no momento, uma alternativa menos invasiva é mover apenas o armazenamento de arquivos para outro provedor. O Chatwoot pode continuar rodando na Hostinger, mas os arquivos ficam, por exemplo, em um Cloudflare R2 ou AWS S3.

Quando o WhatsApp for baixar o arquivo, ele vai buscar no Cloudflare ou na AWS (ASN diferente), e o rate limit da Hostinger não se aplica.

3. Workaround via webhook (upload direto)

Uma solução criativa que surgiu na comunidade é interceptar o erro e reenviar a mídia de outra forma. O fluxo funciona assim:

Criar um webhook no Chatwoot que escuta o evento message.updated.
Quando detecta o erro 131053, um workflow no n8n baixa o arquivo do storage do Chatwoot.
O n8n faz upload direto do arquivo na API do WhatsApp (gerando um media_id).
O n8n envia a mensagem diretamente pela API usando o media_id.
Uma nota privada é registrada no Chatwoot informando que a mídia foi reenviada.

Essa abordagem replica o comportamento do n8n (upload direto) para contornar o problema do Chatwoot (envio por URL). É um paliativo, mas funciona.

4. Aguardar uma correção no Chatwoot

A solução ideal seria o Chatwoot mudar sua arquitetura para fazer upload direto via media_id em vez de enviar URLs para o WhatsApp baixar. Isso eliminaria completamente a dependência do fwdproxy e tornaria o envio de mídia imune a rate limits por ASN.

Até o momento, não há indicação oficial de que essa mudança está planejada, mas a discussão está ativa na comunidade.

Conclusão

O erro 131053 que está afetando milhares de empresas brasileiras não é um bug no Chatwoot, não é um problema de configuração do seu servidor, e não é uma instabilidade do WhatsApp. É o resultado de uma combinação de fatores:

A popularização massiva de ferramentas open-source de automação de WhatsApp no Brasil.
A concentração dessas ferramentas em um único provedor de hospedagem barato (Hostinger).
A forma como o Chatwoot e a Evolution API enviam mídia (por URL, não por upload direto).
O sistema de rate limit por ASN da Meta, que bloqueia provedores inteiros quando o volume é alto demais.

A lição mais importante é que infraestrutura importa. Escolher um provedor de hospedagem apenas pelo preço pode parecer vantajoso no curto prazo, mas quando milhares de empresas fazem a mesma escolha, os problemas de concentração aparecem.

Se você está enfrentando esse problema agora, a recomendação é: migre para um provedor com ASN diferente, ou implemente o workaround de upload direto via webhook. E se estiver planejando montar uma nova infraestrutura de atendimento via WhatsApp, considere desde o início um provedor de cloud mais robusto. O custo mensal pode ser um pouco maior, mas a estabilidade do seu atendimento ao cliente não tem preço.

Artigo publicado em fevereiro de 2026. As informações refletem o cenário atual e podem mudar conforme a Meta, a Hostinger e os desenvolvedores do Chatwoot tomem medidas para resolver o problema.