"Erro HTTP" ao enviar imagem no WordPress: a árvore de decisão que realmente acha a causa

“Erro HTTP” não é uma causa. É o enviador de mídia admitindo que mandou seu arquivo para o servidor e recebeu de volta uma resposta que não conseguiu interpretar como sucesso — e pelo menos seis falhas sem relação entre si produzem exatamente essas duas palavras. Chutar entre elas é o motivo de tanta gente passar a tarde aumentando o upload_max_filesize num site cujo problema real é uma regra de firewall.

O caminho mais rápido para sair disso é uma única observação que divide as seis causas em dois grupos, seguida de uma checagem por ramo.

Primeiro: leia a resposta de verdade

Abra as ferramentas de desenvolvedor do navegador, vá até a aba Rede e envie o arquivo de novo. Fique de olho na requisição para async-upload.php. O que voltar de lá é o seu diagnóstico.

O que você vê	O que significa	Vá para
403 ou 406, corpo em HTML	Firewall ou mod_security recusou a requisição	Ramo A
500, resposta vazia ou corpo cortado no meio	PHP quebrou ou ficou sem memória no meio do processo	Ramo B
413	O corpo da requisição passou de um limite do servidor	Ramo C
200, mas o corpo não é JSON limpo	Um plugin ou tema imprimiu algo antes da resposta	Ramo D
A requisição nunca termina / dá timeout	Limite de tempo de execução, normalmente com arquivos grandes	Ramo B

Essa única olhada já elimina para você a maior parte dos conselhos que circulam por aí. Se você não conseguir chegar às ferramentas do navegador, ligue o registro de erros no wp-config.php antes:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduza o envio e leia o wp-content/debug.log. Uma linha de erro fatal já entrega o ramo. Se a linha estiver difícil de decifrar, cole no decodificador de log de erros — ele traduz as assinaturas de erro fatal mais comuns para o que realmente quebrou.

Ramo A — uma regra de firewall ou do mod_security

Um 403 com uma página HTML no corpo significa que a requisição nunca chegou ao WordPress. Alguma coisa na frente dele — mod_security, Cloudflare, Wordfence, Sucuri ou o conjunto de regras da própria hospedagem — decidiu que aquele POST tinha cara de ataque.

A checagem: desative temporariamente qualquer plugin de segurança e envie de novo. Se nada mudar, a regra está no nível do servidor, e você vai precisar que a hospedagem consulte o log de auditoria do mod_security no horário do envio que falhou. Eles conseguem liberar o ID exato da regra.

Aqui vale ser sincero sobre os conselhos que você vai encontrar. Aqueles trechos mandando você jogar isto no .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

servem para o mod_security 1.x, que está praticamente extinto. Num servidor moderno essas diretivas ou não fazem nada, ou geram um 500 que deixa o site pior. O mod_security atual usa SecRuleEngine, e a maioria das hospedagens gerenciadas bloqueia sobrescrever isso por diretório de qualquer forma. Peça para a hospedagem; não saia colando.

Ramo B — limites de memória ou de execução do PHP

Este é o ramo mais comum e o que tem o sinal mais claro: é intermitente. O mesmo arquivo sobe na terceira tentativa, ou uma foto de 2MB falha enquanto um PDF de 6MB passa liso. Limites rígidos de configuração falham do mesmo jeito sempre. Falhas de memória não, porque a quantidade disponível depende do que mais o servidor está fazendo naquele momento.

Por que isso pega imagens especificamente: o WordPress não só guarda o arquivo, ele descomprime tudo em pixels crus para gerar cada tamanho intermediário — medium_large, qualquer tamanho registrado com add_image_size, woocommerce_thumbnail se você tem uma loja, além de uma cópia -scaled se a imagem passar do big_image_size_threshold. Um JPEG de 12 megapixels tem alguns MB em disco e uns 48MB em memória, antes do buffer do redimensionamento. Um limite de 128MB some rápido.

Aumente no wp-config.php, acima da linha do “stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

O custo real: o WP_MEMORY_LIMIT não consegue passar do que o próprio PHP permite. Se a sua hospedagem trava o memory_limit em 128M, essa constante é pura decoração. Confira o valor verdadeiro em Ferramentas → Saúde do site → Informações → Servidor, e não no que você escreveu. Se o teto é o limite do PHP, só a hospedagem consegue mexer nele.

Ramo C — tamanho de arquivo e limites de POST

Veja os números reais em Ferramentas → Saúde do site → Informações → Manipulação de mídia. Duas configurações importam e as pessoas só mexem em uma:

• upload_max_filesize — o teto de um arquivo individual.
• post_max_size — o teto do corpo inteiro da requisição.

Se o POST completo ultrapassa o post_max_size, o PHP descarta a requisição antes de o WordPress executar qualquer código. Não existe nada para devolver, então o enviador recebe uma resposta ilegível e diz “Erro HTTP”. O post_max_size deve ser sempre confortavelmente maior que o upload_max_filesize.

Um detalhe que vale conhecer: quando um arquivo estoura apenas o upload_max_filesize, o enviador normalmente barra ainda no navegador e avisa que o arquivo passa do tamanho máximo permitido — uma mensagem bem mais clara. Ou seja, um “Erro HTTP” sozinho aponta com mais frequência para o post_max_size ou para o Ramo B do que para a configuração que todo mundo aumenta primeiro.

Onde alterar depende da sua stack. No Apache com mod_php, o .htaccess funciona:

php_value upload_max_filesize 64M
php_value post_max_size 128M

No PHP-FPM, no LiteSpeed ou no NGINX — que é a maioria da hospedagem moderna — essas linhas não fazem nada e ainda podem gerar um 500. Use o painel de configurações de PHP da hospedagem ou um arquivo .user.ini. O NGINX também aplica o próprio client_max_body_size, que só a hospedagem consegue aumentar.

Ramo D — a biblioteca de edição de imagem (Imagick vs GD)

O WordPress prefere o ImageMagick quando a extensão do PHP está presente e cai para o GD quando não está. Em hospedagem compartilhada, o ImageMagick é problema com frequência: o arquivo de política dele restringe memória, disco e área por operação, e quando um redimensionamento esbarra em um desses limites o processo morre sem mensagem útil. Isso costuma aparecer em imagens grandes enquanto as pequenas funcionam — o que parece Ramo B, mas não é.

Force o GD para testar a hipótese:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

Coloque isso no functions.php ou num mu-plugin pequeno, tente o envio de novo e remova se nada mudar.

O outro lado da moeda: o GD não é simplesmente melhor. Ele mantém o bitmap descomprimido inteiro na memória do PHP, então em arquivos muito grandes pode bater no memory_limit justo onde o ImageMagick — que trabalha em parte fora da alocação do PHP — teria dado conta. A troca pode substituir uma falha por outra. Trate como diagnóstico primeiro e correção depois.

Ramo E — permissões da pasta de uploads

Raro em hospedagem gerenciada, comum logo depois de uma migração ou de uma mudança manual de servidor. Se wp-content/uploads não tem permissão de escrita para o usuário do servidor web, ou se uma subpasta de ano/mês recém-criada herdou o dono errado, a gravação falha.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Diretórios normalmente devem ficar em 755 e pertencer ao usuário sob o qual o PHP roda. Não coloque 777 só porque um fórum mandou — isso resolve o sintoma tornando a pasta gravável por qualquer conta do servidor, o que em hospedagem compartilhada é uma exposição de verdade.

Ramo F — o nome do arquivo

É a checagem mais barata da lista, então faça cedo mesmo sendo a menos provável. Renomeie o arquivo usando só letras minúsculas, números e hífens — sem acentos, apóstrofos, e comercial, # ou caracteres fora do alfabeto latino — e envie de novo. Caracteres especiais eventualmente disparam uma regra de segurança ou quebram num sistema de arquivos com codificação incompatível. Dez segundos para descartar.

O que não fazer

Não comece desativando todos os plugins. É invasivo e só testa o Ramo A e o Ramo D. A resposta de rede conta mais em cinco segundos.

Não saia adicionando uma linha de handler qualquer no .htaccess. Os trechos que circulam por aí com diretivas SetHandler ou AddHandler assumem a configuração de PHP de uma hospedagem específica. Na stack errada, derrubam o site inteiro com um 500.

Não aceite “funcionou na segunda tentativa” como resolvido. Sucesso intermitente é a assinatura do Ramo B, e ele volta no minuto em que o servidor ficar cheio ou alguém enviar algo maior.

Ainda travado?

Se a resposta é um 200 limpo com JSON válido e o envio mesmo assim falha, a quebra acontece depois que o arquivo chega — normalmente um plugin ligado à cadeia de processamento de anexos gerando um erro fatal, ou um plugin de otimização que dispara a própria requisição para um serviço externo e estoura o tempo. Ligue o WP_DEBUG_LOG, reproduza e passe o erro fatal resultante pelo decodificador de log de erros para ver qual arquivo e qual hook são de fato os responsáveis.