O erro 406 Não Aceitável no WordPress pode ser frustrante, especialmente quando interrompe o acesso do usuário ou a funcionalidade da API. No entanto, com uma abordagem sistemática, você pode identificar rapidamente a causa raiz e restaurar as operações normais. Este guia orienta você no diagnóstico e na resolução do problema, tanto no lado do cliente quanto no servidor, juntamente com etapas de depuração específicas do WordPress.
Resumo: Soluções rápidas para o erro 406 no WordPress
Se você estiver enfrentando um erro 406 Não Aceitável, aplique estas verificações rápidas para restaurar a funcionalidade:
- Limpe o cache e teste no modo anônimo para descartar problemas com o navegador.
- Verifique a estrutura da URL e remova as extensões de arquivo forçadas.
- Desative temporariamente todos os plugins, especialmente os de segurança.
- Mude para um tema padrão para eliminar conflitos de tema.
- Verifique os registros do servidor em busca de bloqueios relacionados ao ModSecurity ou ao MIME.
- Reverter atualizações recentes se o erro ocorreu após alterações.
Esses passos resolvem a maioria dos erros 406 de forma rápida e segura.
Visão geral rápida do erro HTTP 406 (Não Aceitável)
O código de status 406 Não Aceitável é definido na especificação HTTP como um erro de negociação de conteúdo.
Isso ocorre quando:
- O cliente envia um cabeçalho Accept especificando tipos de conteúdo particulares.
- O servidor não pode fornecer uma resposta que corresponda a esses tipos de conteúdo.
- Regras de segurança (como o ModSecurity ) bloqueiam a solicitação.
- Os tipos MIME ou as configurações do servidor estão incorretos.
No WordPress, esse erro geralmente é causado por:
- Regras .htaccess incorretas
- Configurações incorretas de negociação de conteúdo
- Temas ou plugins corrompidos
- Regras de firewall agressivas no nível de hospedagem
Compreender o contexto em que o erro ocorre (área administrativa, API REST , página específica, etc.) é crucial para um diagnóstico preciso.
Obtenha suporte especializado para corrigir erros do WordPress rapidamente
Nossos especialistas em WordPress diagnosticam problemas rapidamente para restaurar seu site. Entre em contato conosco hoje mesmo para uma solução de problemas rápida e confiável e coloque seu site online novamente com o mínimo de tempo de inatividade.
Como diagnosticar o erro 406 (Não Aceitável) no WordPress?
Antes de aplicar correções, é essencial diagnosticar corretamente o erro 406 Não Aceitável.
Como esse código de status HTTP geralmente está relacionado à negociação de conteúdo, filtragem de segurança ou cabeçalhos mal configurados, uma abordagem de diagnóstico estruturada ajuda a identificar a causa exata.
Em vez de tentar adivinhar, siga os métodos abaixo para identificar sistematicamente a causa raiz.
Inspecione a solicitação de rede do navegador
Abra as Ferramentas de Desenvolvedor do seu navegador e revise a solicitação com falha na aba Rede . Preste bastante atenção aos cabeçalhos Accept, aos cabeçalhos de resposta e aos detalhes do código de status. Isso ajuda a determinar se o problema é causado por uma negociação de tipo de conteúdo restritiva.
Faça o teste no modo anônimo ou em outro navegador
Em seguida, teste o mesmo URL em uma janela anônima/privada ou em um navegador diferente. Se o erro desaparecer, arquivos em cache, cookies ou extensões do navegador podem estar interferindo na solicitação.
Verifique a estrutura da URL solicitada
Analise cuidadosamente o URL em busca de erros de ortografia, caminhos incorretos ou extensões de arquivo forçadas, como .json ou .xml. Testar a página inicial também pode ajudar a identificar se o problema é específico do URL.
Analisar os registros de depuração do WordPress
Ative o WP_DEBUG e verifique o arquivo /wp-content/debug.log . Essa etapa revela conflitos relacionados a plugins, temas ou PHP que podem estar gerando a resposta 406.
Analisar os registros de acesso e erros do servidor
Ao diagnosticar um erro 406 Não Aceitável, os registros do servidor fornecem a evidência mais confiável.
Em vez de se basear em suposições, os arquivos de log revelam exatamente como o servidor processou a solicitação e por que ela foi rejeitada. Portanto, revisar os logs de acesso e de erro deve ser uma prioridade durante a resolução de problemas.
Abra os registros de acesso para entradas de status 406 : Primeiro, examine os registros de acesso do seu servidor web para confirmar quando e com que frequência o status 406 aparece.
- Para o Apache, verifique : /var/log/apache2/access.log
- Para o NGINX, verifique : /var/log/nginx/access.log
Pesquise especificamente por entradas HTTP 406. Isso ajuda a identificar URLs afetados, métodos de requisição, endereços IP e agentes de usuário.
Abra os logs de erro para verificar a correspondência de data e hora : Em seguida, compare essas entradas com seus logs de erro . Analise os logs de erro do Apache, do NGINX e do PHP. A correspondência de data e hora pode revelar se o problema decorre de uma configuração incorreta, falhas na execução de scripts ou da aplicação de regras de segurança.
Correlacione as entradas de log com as ações do plugin ou tema : Por fim, alinhe os registros de data e hora com as alterações recentes no site. Por exemplo , verifique se o erro começou após uma atualização de plugin, modificação do tema ou ativação de uma regra de segurança. Essa correlação geralmente identifica o componente exato responsável por gerar a resposta 406.
Verifique os registros de segurança e firewall
Por fim, inspecione os logs do ModSecurity, do firewall de aplicativos da web ou dos plugins de segurança. Em muitos casos, essas ferramentas bloqueiam solicitações suspeitas, acionando assim o erro 406.
Como resolver o erro 406 (Não Aceitável) no WordPress?
Após identificar as possíveis causas, inicie a resolução de problemas de forma metódica.
Correção 1: Solução de problemas no lado do cliente
Antes de modificar as configurações do servidor ou as configurações do WordPress , é importante descartar causas do lado do cliente.
Em muitos casos, o erro 406 Não Aceitável é causado pelo cache do navegador, cabeçalhos restritivos ou interferência na rede local.
Portanto, comece com as seguintes verificações para determinar se o problema se origina no ambiente do usuário e não no servidor.
- Primeiro, limpe o cache e os cookies do seu navegador . Arquivos armazenados ou dados de sessão desatualizados podem enviar cabeçalhos de solicitação incorretos, o que pode resultar em falhas na negociação de conteúdo. Depois de limpá-los, recarregue a página para verificar se o problema persiste.
- Em seguida, abra o URL afetado em uma janela anônima ou privada do navegador. Isso desativa a maioria das extensões e dados em cache. Se a página carregar corretamente, o problema pode estar relacionado a extensões do navegador ou credenciais armazenadas.
- Em seguida, abra as Ferramentas de Desenvolvedor do seu navegador e inspecione a solicitação com falha na guia Rede. Preste atenção aos valores do cabeçalho Accept. Se eles forem muito restritivos (por exemplo, exigindo apenas JSON), o servidor poderá rejeitar a resposta.
Por fim, tente trocar de rede ou reiniciar o roteador. Ocasionalmente, proxies, VPNs ou configurações de firewall podem modificar os cabeçalhos das solicitações, acionando inadvertidamente um erro 406.
Correção 2: Solução de problemas no lado do servidor
Se as verificações do lado do cliente não resolverem o problema, o próximo passo é examinar a configuração do servidor.
Como o erro 406 Não Aceitável geralmente está relacionado à negociação de conteúdo ou ao tratamento de respostas mal configurado, é essencial revisar as configurações do seu servidor web.
Ao inspecionar sistematicamente essas áreas, você pode identificar conflitos de configuração que bloqueiam solicitações válidas.
Inspecionar configurações de negociação de conteúdo do servidor web
Primeiro, analise como seu servidor lida com a negociação de conteúdo.
- Para o Apache , revise as configurações do módulo mod_negotiation. Em particular, verifique se a diretiva MultiViews está habilitada no seu arquivo .htaccess, pois ela pode forçar uma correspondência de conteúdo inesperada.
- Para o NGINX , verifique como os tipos de conteúdo são processados dentro do bloco `types`. Além disso, inspecione as regras de reescrita para garantir que elas não estejam interferindo no processamento das requisições.
Verificar os tipos MIME do servidor para os recursos solicitados
Em seguida, confirme se o seu servidor suporta todos os tipos MIME necessários. Por exemplo , verifique se a configuração para application/json, text/html e application/xml está correta.
Se esses tipos estiverem ausentes ou mapeados incorretamente, o servidor poderá rejeitar a solicitação e retornar um status 406.
Analise as regras personalizadas de reescrita ou redirecionamento
Examine as regras personalizadas de reescrita e redirecionamento. Procure por regras .htaccess excessivamente restritivas, regras de reescrita do NGINX incorretas ou possíveis loops de redirecionamento. Mesmo pequenas configurações incorretas podem interromper a negociação de respostas e acionar esse erro.
Ajuste as regras do ModSecurity no servidor
Analise os registros do ModSecurity para identificar o ID da regra específica que está causando o bloqueio. Uma vez identificada, você pode desativar essa regra seletivamente ou adicionar o URL ou parâmetro afetado à lista de permissões.
No entanto, evite desativar o ModSecurity completamente. Em vez disso, faça ajustes precisos para manter a segurança, permitindo, ao mesmo tempo, solicitações legítimas.
Remover restrições problemáticas do cabeçalho Accept dos clientes
Inspecione as solicitações do lado do cliente ou do nível do aplicativo em busca de cabeçalhos Accept restritivos.
Por exemplo , se um script solicitar apenas application/json, mas o servidor responder com text/html, a solicitação poderá ser rejeitada.
Modificar o cabeçalho para permitir tipos de conteúdo mais amplos geralmente resolve essa incompatibilidade.
Higienizar entradas de solicitação que acionam regras de segurança
Por fim, revise as strings de consulta, os campos de formulário ou os dados da API. Caracteres especiais, parâmetros não codificados ou padrões suspeitos podem ativar regras de firewall. A higienização e codificação adequadas dos dados de entrada reduzem os falsos positivos e previnem futuros erros 406.
Correção 3: Depurando o WordPress especificamente para um erro 406
Se os diagnósticos em nível de servidor não revelarem a causa, o problema pode estar originado no próprio WordPress.
Como plugins, temas ou código personalizado podem alterar cabeçalhos, reescrever regras ou lidar com solicitações, um processo de depuração estruturado é essencial.
Ao isolar os componentes metodicamente, você pode identificar o que está causando a resposta 406.
- Ative WP_DEBUG e WP_DEBUG_LOG no arquivo wp-config.php : Primeiro, ative a depuração do WordPress habilitando WP_DEBUG e WP_DEBUG_LOG no arquivo wp-config.php. Essa etapa permite que o WordPress registre avisos, alertas e erros do PHP no arquivo /wp-content/debug.log. A análise desse registro pode revelar conflitos, funções obsoletas ou problemas de saída que contribuíram para o erro.
- Desative todos os plugins temporariamente : Em seguida, desative todos os plugins de uma só vez. Depois, teste a página ou o endpoint afetado. Se o erro desaparecer, isso confirma que um plugin é o responsável. Plugins de segurança, firewall ou que modificam cabeçalhos são causas comuns.
- Mude para um tema padrão do WordPress : Depois disso, mude temporariamente para um tema padrão, como o Twenty Twenty-Four . Isso ajuda a determinar se as funções do tema, os modelos personalizados ou os scripts incorporados estão interferindo no processamento das solicitações.
- Reinstale os plugins um por um para isolar o culpado : Por fim, reative os plugins individualmente, testando a cada reativação. Essa abordagem controlada ajuda a identificar o plugin exato que está causando o erro 406 e a aplicar uma correção específica.
Correção 4: Reverter atualizações recentes
Se o erro 406 apareceu logo após uma atualização, é provável que as alterações recentes sejam a causa.
Como o núcleo do WordPress, os plugins e os temas frequentemente modificam o tratamento de requisições ou a lógica de segurança, reverter as atualizações pode restaurar rapidamente a estabilidade.
Portanto, revisar as atualizações recentes deve fazer parte do seu fluxo de trabalho de diagnóstico.
- Primeiro, verifique o painel do WordPress ou os registros de hospedagem em busca de atualizações recentes. Determine se o problema começou após uma alteração na versão de um plugin, tema ou núcleo do WordPress.
- Em seguida, faça o downgrade do plugin ou tema suspeito para uma versão estável anterior. Você pode fazer isso manualmente via FTP ou usando uma ferramenta de reversão.
- Por fim, se o downgrade não resolver o problema, restaure um backup completo do site de um ponto anterior à ocorrência do erro.
Verificação bem-sucedida e testes pós-correção
Após implementar as correções necessárias, é fundamental confirmar se o erro 406 Não Aceitável foi completamente resolvido.
Em vez de presumir que o problema foi resolvido, a validação estruturada garante a estabilidade a longo prazo. Portanto, realize testes abrangentes após a correção para verificar se não restam conflitos de configuração residuais.
Execute solicitações cURL para confirmar que não há respostas 406
Primeiro, use o curl para testar os URLs afetados diretamente da linha de comando. Esse método ignora as variáveis relacionadas ao navegador e fornece os cabeçalhos de resposta HTTP brutos.
Confirme se o servidor agora retorna o status 200 OK em vez de 406 Não Aceitável. Recomenda-se testar vários endpoints, incluindo rotas de API.
Testar páginas-chave do site em vários navegadores
Em seguida, abra páginas essenciais, como a página inicial, a página de contato, a tela de login e o painel de administração, em diferentes navegadores e dispositivos. Essa etapa garante um comportamento consistente, independentemente de as sessões serem armazenadas em cache ou de serem utilizadas configurações específicas do navegador.
Verifique se as mensagens "Verificação bem-sucedida" não aparecem mais
Por fim, revise os painéis de segurança e os registros para confirmar que nenhum aviso adicional de bloqueio ou verificação está sendo acionado. O monitoramento contínuo ajuda a evitar a recorrência do problema.
Dicas adicionais para prevenção e monitoramento
Após a resolução do erro 406 Não Aceitável, a próxima prioridade é a prevenção.
Como conflitos de configuração, regras de segurança e atualizações podem reintroduzir problemas semelhantes, o monitoramento e a manutenção proativos são essenciais.
Ao implementar medidas de segurança estruturadas, você reduz o tempo de inatividade e melhora a estabilidade do site a longo prazo.
- Agende backups regulares antes das atualizações : Em primeiro lugar, sempre crie backups completos antes de atualizar o núcleo do WordPress, plugins ou temas. Isso inclui tanto os arquivos quanto o banco de dados. Ao fazer isso, você garante que poderá restaurar rapidamente uma versão estável caso uma atualização cause erros 406 inesperados.
- Monitore os logs do servidor em busca de erros 406 recorrentes : Em seguida, revise rotineiramente os logs de acesso e de erros do servidor. Procure especificamente por códigos de status 406 recorrentes ou solicitações bloqueadas. Configurar alertas de monitoramento de logs pode ajudar a detectar padrões precocemente, permitindo que você resolva problemas antes que eles se agravem.
- Documente as alterações de configuração para reversão futura : Mantenha um registro dos ajustes do servidor, modificações nas regras de segurança e alterações de reescrita. A documentação adequada simplifica a resolução de problemas e permite uma reversão mais rápida quando necessário.
- Contate o suporte de hospedagem quando as causas principais não estiverem claras : Por fim, se os registros indicarem restrições no nível do servidor ou aplicação de firewall além do seu controle, entre em contato com seu provedor de hospedagem. Eles podem analisar as regras do ModSecurity, as configurações MIME ou os filtros de rede de forma mais abrangente.
Considerações finais
O erro 406 Não Aceitável no WordPress geralmente está relacionado a incompatibilidades na negociação de conteúdo, restrições de segurança ou configurações incorretas do servidor.
No entanto, seguindo um processo estruturado de resolução de problemas, começando com verificações no lado do cliente e progredindo para a depuração específica do servidor e do WordPress, você pode isolar e resolver o problema de forma eficiente.
O mais importante é sempre verificar os registros antes de fazer alterações. Com diagnósticos cuidadosos e monitoramento preventivo, você pode minimizar interrupções futuras e manter um ambiente WordPress estável.
Perguntas frequentes sobre o erro 406 no WordPress
O que significa um erro 406 no WordPress?
O erro 406 está entre as respostas de erro do servidor, acionadas quando o servidor não consegue gerar uma resposta aceitável com base nos valores aceitáveis definidos nos cabeçalhos da solicitação.
O erro 406 indica um problema no cliente ou no servidor?
Embora frequentemente agrupadas com respostas de erro do cliente, são comumente consideradas respostas de erro do servidor, pois geralmente decorrem de problemas no lado do servidor.
O que normalmente causa esse erro?
As causas comuns incluem plugins defeituosos, regras de segurança restritivas ou cabeçalhos mal configurados, como Accept-Language ou Accept-Encoding.
Como os cabeçalhos podem gerar uma resposta 406?
Se uma solicitação HTTP incluir valores estritamente aceitáveis para tipo ou formato de conteúdo, o servidor poderá não conseguir retornar uma resposta adequada.
As atualizações podem danificar um site?
Sim, após a última atualização, conflitos dentro do sistema de gerenciamento de conteúdo ou em seus componentes internos podem exigir a restauração de uma versão anterior.
Como posso confirmar a causa raiz?
Para confirmar a causa raiz, verifique novamente os logs do servidor para identificar solicitações HTTP bloqueadas e revise as sugestões de configuração do seu sistema de hospedagem.
O tipo de arquivo pode causar o erro?
Sim, um exemplo é quando um arquivo CSS é solicitado em um formato não suportado, o que leva a uma falha na negociação.
