Como corrigir um erro 400 Bad Request no WordPress (Causas e correções)

Principais conclusões

• Um erro 400 Bad Request normalmente afecta uma ação específica, não todo o site WordPress.
• A maioria dos erros 400 no WordPress é causada por URLs, cookies, cache ou problemas de solicitação relacionados a plugins.
• Seguir uma abordagem de resolução de problemas em camadas ajuda a isolar a fonte exacta mais rapidamente.
• Actualizações, testes e configuração do servidor adequados reduzem as hipóteses de erros 400 recorrentes.

Podes estar a abrir o painel de administração do WordPress, a submeter um formulário ou a carregar uma página que funcionou momentos antes. A página não carrega. Não aparece nenhum aviso. Apenas um erro 400 Bad Request sem qualquer explicação.

A mensagem em si oferece pouco contexto. Não sugere um site quebrado ou uma falha no servidor. No WordPress, o problema está muitas vezes relacionado com os dados do browser, ficheiros em cache, plugins, URLs ou tamanho do pedido, em vez de algo fundamentalmente errado com o site.

Essa diferença é importante. Muda o problema de “algo está em baixo” para “algo específico está a falhar”. Quando o vês dessa forma, os passos a dar tornam-se mais fáceis de definir.

O que é um erro 400 Bad Request?

Uma parte do sítio funciona. Outra não funciona.

As páginas ainda podem carregar, mas uma única ação continua a falhar. A área de administração recusa-se a abrir. Um formulário nunca é enviado. Uma ação de guardar fica parada sem feedback.

Essa ação falhada é o que desencadeia o erro 400 Bad Request.

No WordPress, as acções diárias enviam pedidos para o servidor. O login, o envio de formulários, o carregamento de ecrãs de administração e a atividade de plug-ins em segundo plano estão todos incluídos nesta categoria. Quando um pedido chega numa forma que o servidor não aceita, é rejeitado antes de qualquer coisa carregar.

O erro 400 Bad Request é do lado do cliente ou do lado do servidor?

A maior parte das vezes, começa no lado do cliente.

Isso inclui:

• cookies do browser ou dados armazenados em cache
• URLs malformados
• pedidos de grandes dimensões

O servidor impõe as regras, mas o pedido em si normalmente desencadeia a rejeição. Em casos raros, as regras a nível do servidor ou as definições de segurança desempenham um papel, que abordaremos mais tarde.

Variações comuns do erro 400 Bad Request que podes ver

Podes encontrar versões ligeiramente diferentes do mesmo erro, incluindo:

• 400 Bad Request
• 400 Bad Request – URL inválido
• 400 Bad Request – Cabeçalho do pedido ou cookie demasiado grande

A redação muda, mas a questão subjacente é a mesma. Um pedido chegou ao servidor e foi recusado.

Porque é que o erro 400 Bad Request ocorre no WordPress?

Um erro 400 bad request no WordPress raramente aponta para uma falha total do site. Na maioria dos casos, o site ainda carrega, mas uma ação específica continua falhando. Isso normalmente significa que um único pedido não está a ser aceite pelo servidor.

Os motivos abaixo abrangem as formas mais comuns que ocorrem no WordPress.

#1 URLs WordPress inválidos ou malformados

Os URLs podem falhar silenciosamente.

Caracteres extra, codificação quebrada ou links copiados com parâmetros adicionados podem causar problemas. Isto aparece frequentemente com URLs de início de sessão, links de redireccionamento ou páginas de administração marcadas.

Quando o WordPress envia um URL que o servidor não reconhece como válido, o pedido pára imediatamente.

#2 Cache do navegador ou cookies corrompidos

O WordPress depende muito dos cookies do browser, especialmente para sessões com sessão iniciada.

Com o tempo, os cookies e os dados armazenados em cache podem perder a sincronia. É por isso que o erro pode aparecer num browser mas não noutro, ou desaparecer no modo privado.

Limpar os dados do browser altera frequentemente o comportamento de imediato, o que é um forte sinal de que os dados armazenados estão envolvidos.

#3 Problemas de autenticação do WordPress ou de cookie de sessão

As acções de início de sessão dependem da validade dos cookies de sessão.

Se os cookies de autenticação crescerem demasiado ou se tornarem inconsistentes, o WordPress pode enviar pedidos que o servidor se recusa a processar. Isto tende a afetar mais as páginas de administração, as submissões de formulários e as acções de guardar do que as páginas públicas.

O site tem bom aspeto, mas os pedidos autenticados falham.

#4 Conflitos de plugins ou temas

Os plugins e os temas enviam pedidos constantemente em segundo plano.

Os plug-ins de segurança, as ferramentas de cache, os criadores de formulários e os plug-ins de otimização interagem com os pedidos mais do que a maioria. Um único plugin que envie dados malformados ou inesperados é suficiente para desencadear um erro 400 bad request.

Os temas podem causar problemas semelhantes através de scripts do lado do administrador ou chamadas AJAX, especialmente durante actualizações ou personalizações.

#5 Limites de tamanho de upload de arquivos excedidos

Os carregamentos nem sempre falham de forma graciosa.

Imagens grandes, vídeos ou outros ficheiros podem exceder os limites do servidor sem mostrar um aviso claro. O carregamento chega ao servidor, mas o pedido é rejeitado antes de o processamento estar concluído.

Outras partes do sítio continuam a funcionar, o que torna o problema mais difícil de detetar.

#6 Problemas de resolução de DNS ou de dados de DNS em cache

Os problemas de DNS não acontecem com frequência, mas podem ser confusos quando acontecem.

Registros DNS desatualizados ou pesquisas em cache podem enviar solicitações para o destino errado. Isso às vezes aparece após alterações de domínio, atualizações de DNS ou ajustes de configuração de CDN.

Quando isso acontece, os pedidos falham antes que o WordPress possa responder adequadamente.

#7 Cabeçalhos de pedido incorrectos ou erros da API REST

Algumas funcionalidades do WordPress dependem de pedidos estruturados.

Chamadas de API REST, solicitações AJAX ou integrações que enviam cabeçalhos malformados ou JSON inválido podem disparar um erro 400. Estes problemas surgem frequentemente durante actualizações de plug-ins, desenvolvimento personalizado ou integrações de terceiros.

O erro aparece mesmo que o sítio em si pareça normal.

#8 Raros problemas de configuração de nível de servidor ou de segurança

Nalguns casos, o pedido em si é bom, mas as regras do servidor atrapalham.

As firewalls de aplicações Web, as regras ModSecurity ou as políticas de segurança rigorosas podem bloquear pedidos que pareçam invulgares. Estas situações são menos comuns, mas mais difíceis de diagnosticar sem acesso ao servidor.

#9 Como é que isto ajuda a limitar a correção

Cada causa aponta para uma solução diferente. Tratá-las como um problema genérico torna as coisas mais lentas. Identificar qual o padrão que corresponde ao que estás a ver torna a resolução de problemas mais rápida e previsível.

É aí que entram as correcções.

Como corrigir um erro 400 Bad Request no WordPress

Um erro 400 Bad Request geralmente indica uma falha em uma única solicitação, não uma interrupção em todo o site. A correção geralmente se resume à correção de dados armazenados, URLs ou respostas em cache.

Começa pelo básico. A maioria dos casos resolve-se cedo.

Passo 1 – Verifica os URLs do teu site WordPress

URLs de sites incorretos podem interromper pedidos de administração antes que o WordPress seja totalmente carregado.

O WordPress utiliza dois endereços principais:

• Endereço do WordPress (URL)
• Endereço do sítio (URL)

Ambos têm de corresponder ao domínio exato utilizado no browser. Mesmo pequenas inconsistências podem provocar erros 400 durante o início de sessão, redireccionamentos ou acções de guardar.

A partir do painel de controlo, vai a Definições → Geral e revê ambos os campos.

Devias:

• Começa com http:// ou https://
• Não contém caracteres extra ou espaços
• Faz corresponder exatamente o domínio ativo

Se a área de administração estiver inacessível, define os URLs manualmente em wp-config.php ou actualiza-os diretamente na base de dados. Para muitos sites, só isso restaura o acesso.

Tem cuidado com os URLs copiados. Os caracteres ocultos de e-mails ou documentos podem causar falhas silenciosas. Se algo parecer estranho, escreve o endereço manualmente.

Passo 2 – Limpa a cache do navegador e os cookies

Se o erro aparecer num browser mas não noutro, é provável que os dados armazenados do browser estejam envolvidos.

As sessões de administração do WordPress dependem de cookies. Quando esses cookies ficam fora de sincronia, o browser continua a enviar pedidos que o servidor se recusa a processar.

Não te preocupes:

• Cookies ligados ao domínio do teu site
• Ficheiros em cache relacionados com o WordPress

Não precisas de reiniciar totalmente o browser.

Uma forma rápida de confirmar isto é abrir a mesma página numa janela privada ou anónima. Se funcionar aí, o problema são os cookies ou a cache.

As páginas de administração desencadeiam isto mais frequentemente porque enviam mais cookies do que as páginas públicas. Os plug-ins de segurança, os criadores de páginas e as ferramentas de otimização aumentam o tamanho do pedido, o que aumenta a probabilidade de rejeição.

Passo 3 – Limpa a cache do WordPress e da CDN

Quando os dados do browser não são a causa, as respostas do servidor em cache são o próximo local a procurar.

A cache do WordPress pode existir em vários níveis:

• Plug-ins de cache
• Cache de objectos
• Cache CDN
• Cache ao nível do alojamento

Limpa todas as caches activas, não apenas URLs individuais. As limpezas parciais muitas vezes deixam para trás cabeçalhos ou redireccionamentos problemáticos.

Se o site for executado por trás de um CDN, limpa também o cache completo do CDN. Os dados de solicitação armazenados em cache no nível da rede podem continuar a causar erros 400 mesmo depois que o cache do WordPress for limpo.

Em plataformas gerenciadas como a Cloudways, usa o painel de hospedagem para limpar o cache no nível do aplicativo ou do servidor antes de testar novamente.

Passo 4 – Desactiva todos os plug-ins do WordPress

Os plug-ins alteram a forma como o WordPress envia os pedidos.

Desativa todos os plug-ins e repete a ação que estava falhando.

Se a área de administração não estiver acessível, renomeia a pasta dos plug-ins utilizando o FTP ou um gestor de ficheiros. O WordPress será carregado sem plug-ins.

Se o erro desaparecer, reativa os plugins um a um até que ele volte. O plugin ativado imediatamente antes de o erro reaparecer é a fonte.

Passo 5 – Muda para um tema WordPress predefinido

Os temas podem afetar o comportamento do lado do administrador.

• Muda temporariamente para umtema WordPress predefinido , como o Twenty Twenty-Five, e repete a mesma ação.

Se o erro já não aparecer, o tema ativo está envolvido.

Passo 6 – Verifica os limites de tamanho de carregamento de ficheiros

Os carregamentos podem falhar sem erros visíveis.

Os ficheiros grandes podem ser bloqueados antes de o WordPress os tratar, enquanto o resto do site continua a funcionar.

Verifica:

• upload_max_filesize
• post_max_size

Ambos os valores têm de suportar o ficheiro que está a ser carregado.

Passo 7 – Limpa a cache DNS

Verifica o DNS apenas se algo mudou recentemente.

• Atualização do domínio
• Migração de servidores
• CDN adicionada ou modificada

Limpa a cache DNS na tua máquina local.

Recarrega a página e tenta novamente a mesma ação.

Se o site foi movido para um novo servidor, confirma se o domínio está resolvido para o IP correto.

Passo 8 – Regenera o ficheiro .htaccess do WordPress

Um ficheiro .htaccess danificado pode bloquear os pedidos antes de o WordPress ser executado.

Normalmente, isto acontece depois:

• Alterações ao plugin
• Actualizações do URL
• Edições manuais

No painel de controlo, vai a Definições → Permalinks e clica em Guardar alterações sem modificar nada.

O WordPress irá regenerar o ficheiro.

Se a área de administração não estiver acessível, substitui manualmente o ficheiro .htaccess por uma versão predefinida do WordPress e guarda as hiperligações permanentes assim que o acesso for restabelecido.

Recarrega a página e tenta novamente a ação que falhou.

Passo 9 – Verifica a API REST e os pedidos AJAX

Alguns erros só aparecem durante os pedidos em segundo plano.

Inclui:

• O administrador salva
• Envio de formulários
• Actualizações das definições do plugin
• Acções do editor

Se o erro aparecer durante uma ação específica, verifica se esta se baseia na API REST ou em chamadas AJAX.

Cargas malformadas, JSON inválido ou cabeçalhos inesperados podem fazer com que esses pedidos falhem enquanto o resto do site continua a funcionar.

Se o problema tiver começado depois de uma atualização de um plug-in ou de uma alteração personalizada, concentra-te primeiro nisso.

Resolução de problemas avançada para erros persistentes 400 Bad Request

Quando as correcções básicas não resolvem a questão, o problema é normalmente mais profundo na cadeia de pedidos.

Estes casos envolvem frequentemente regras do servidor, camadas de segurança ou limites de pedidos que não são visíveis a partir do painel de controlo do WordPress.

Verifica os registos do servidor e da aplicação

Os registos fornecem contexto quando o browser não o faz.

Procura 400 erros em:

• Registos de acesso ao servidor Web
• Registos de erros
• Registos ao nível da aplicação

Falhas repetidas associadas a pontos de extremidade, tipos de pedidos ou carimbos de data/hora específicos apontam rapidamente para a fonte.

Se tiveres um alojamento gerido, os registos estão normalmente acessíveis a partir do painel de controlo do alojamento.

Revê os cabeçalhos dos pedidos e os limites de tamanho dos cookies

Alguns servidores impõem limites rigorosos aos cabeçalhos e cookies.

Quando esses limites são ultrapassados, os pedidos são rejeitados antes de o WordPress os processar. Isto afecta frequentemente os utilizadores com sessão iniciada e as acções do administrador.

Os cookies grandes, especialmente os de segurança ou de scripts de rastreio, são um fator comum.

Desativar temporariamente a Firewall de Aplicação Web ou as Regras de Segurança

As camadas de segurança podem bloquear pedidos válidos.

As firewalls de aplicações Web ou as regras ModSecurity podem assinalar certos pedidos como suspeitos, mesmo quando são legítimos.

Desativar temporariamente essas proteções pode ajudar a confirmar se elas estão envolvidas. Se o erro desaparecer, ajusta as regras em vez de deixar a proteção desactivada.

Verifica a configuração da CDN e as regras de cache

As CDNs podem armazenar em cache mais do que páginas.

Cabeçalhos em cache, redirecionamentos ou regras de solicitação podem continuar causando erros 400 mesmo depois que as alterações são feitas no servidor de origem.

Limpa a cache da CDN e revê todas as regras personalizadas que modificam os pedidos antes de chegarem ao WordPress.

Confirma a compatibilidade da versão PHP e da pilha de servidores

As incompatibilidades ao nível do servidor podem surgir como falhas nos pedidos.

Verifica:

• Versão PHP
• Configuração do servidor Web
• Actualizações recentes do servidor

Isto é mais comum depois de actualizações ou migrações, especialmente quando ainda estão a ser utilizados plugins ou temas mais antigos.

Quando o erro 400 Bad Request não é causado pelo WordPress

Nem todos os erros 400 começam no WordPress.

Se o código do site for verificado e o erro persistir em todos os navegadores, dispositivos ou utilizadores, o problema está frequentemente fora da aplicação.

Problemas de configuração do nível de alojamento ou do servidor

Alguns erros 400 têm origem no nível do servidor.

Limites de pedidos, restrições de tamanho de cabeçalho ou regras de análise rigorosas podem rejeitar pedidos antes de o WordPress ser alcançado. Isto pode acontecer depois de:

• Migrações de servidores
• Alterações na pilha
• Reforço da segurança

Se vários sites WordPress no mesmo servidor apresentarem um comportamento semelhante, a configuração do alojamento deve ser revista.

Problemas com o fornecedor de DNS ou com o serviço CDN

Os serviços DNS e CDN ficam à frente do WordPress.

Se devolverem informações de encaminhamento incorrectas ou aplicarem regras de pedido restritivas, os pedidos válidos podem nunca chegar ao servidor de origem.

É mais provável que o faças depois:

• Actualizações de registos DNS
• Integração de CDN
• Altera a regra ou a cache

Nestes casos, o erro pode parecer incoerente ou dependente da localização.

API de terceiros ou falhas de serviços externos

Algumas acções do WordPress dependem de serviços externos.

Os gateways de pagamento, os manipuladores de formulários, as ferramentas de análise e os fornecedores de autenticação enviam e recebem pedidos fora do teu servidor. Se esses serviços devolverem respostas malformadas ou rejeitarem pedidos, o WordPress pode apresentar um erro 400.

Estes problemas afectam frequentemente acções específicas e não todo o sítio.

Como o Managed WordPress Hosting ajuda a reduzir estes erros

O alojamento gerido reduz a exposição a muitos destes problemas.

O tratamento de pedidos, o armazenamento em cache, as regras de segurança e as atualizações do servidor são ajustados para os padrões de tráfego do WordPress. Quando algo corre mal, os registos e os controlos são centralizados em vez de estarem dispersos por várias camadas.

Isto não elimina totalmente os 400 erros, mas reduz o tempo gasto a isolá-los.

Como evitar erros 400 Bad Request no WordPress

A maioria dos erros 400 resulta de pequenas discrepâncias que se acumulam ao longo do tempo. A prevenção tem menos a ver com uma definição e mais com manter o tratamento de pedidos previsível.

1. Mantém o núcleo, os temas e os plug-ins do WordPress actualizados

O código desatualizado tem maior probabilidade de enviar pedidos que o WordPress já não espera.

As actualizações incluem frequentemente correcções para o tratamento de pedidos, autenticação e compatibilidade com PHP mais recente ou regras do servidor. Atrasá-las aumenta a possibilidade de falhas silenciosas.

Aplica actualizações regularmente, especialmente após alterações no servidor ou no PHP.

2. Limita o tamanho dos cookies e os scripts de terceiros

Os biscoitos crescem em silêncio.

As ferramentas de segurança, os scripts de análise, os rastreadores de anúncios e os serviços incorporados adicionam dados aos pedidos. Com o tempo, os cabeçalhos podem exceder os limites do servidor sem qualquer aviso visível.

Revê os plug-ins instalados e remove tudo o que for desnecessário, especialmente as ferramentas que carregam nas páginas de administração.

3. Testa as alterações em um ambiente de preparação

Pequenas mudanças podem ter grandes efeitos.

As actualizações de plug-ins, as edições de temas e as alterações de configuração devem ser testadas na fase de teste antes de chegarem à produção. É aqui que os problemas relacionados com os pedidos normalmente surgem primeiro.

Apanhá-los cedo evita a depuração num site em funcionamento.

4. Monitoriza os registos e os erros de forma proactiva

A maioria dos 400 erros deixa um rasto.

Os registos do servidor, os registos de aplicações e os registos de segurança mostram frequentemente falhas repetidas muito antes de os utilizadores as comunicarem. A revisão periódica dos registos ajuda a detetar padrões precocemente.

Isto é especialmente útil após actualizações ou alterações na infraestrutura.

5. Usa uma plataforma de hospedagem gerenciada com desempenho otimizado

O tratamento de pedidos melhora quando a pilha é ajustada para o WordPress.

As plataformas geridas tratam das camadas de cache, das regras de segurança e das actualizações do servidor de uma forma que se alinha com a forma como o WordPress envia pedidos. Isso reduz o atrito entre a aplicação e o servidor.

Não elimina todos os riscos, mas reduz a base de referência.

Considerações finais

Um erro 400 Bad Request raramente significa que o WordPress está avariado.

Normalmente, aponta para a falha de um pedido devido a dados armazenados, incompatibilidades de configuração ou limites de pedido. Quando abordado metodicamente, a causa é frequentemente encontrada mais cedo do que o esperado.

Começa com URLs, dados do navegador e cache. Passa para os plug-ins, temas e camadas do servidor apenas quando necessário. Essa estrutura mantém a solução de problemas focada em vez de reativa.

Uma infraestrutura fiável ajuda, mas um isolamento claro é mais importante. Quando cada camada é verificada por ordem, até os erros vagos se tornam previsíveis e corrigíveis.