500 Internal Server Error

RESPOSTA DIRETA

Um 500 Internal Server Error significa que o servidor encontrou um problema inesperado ao processar a solicitação. Normalmente, o navegador não consegue identificar a causa; por isso, comece comparando o horário da falha com os logs do PHP, da aplicação e do web server. Alterações recentes em código, plugins ou temas, regras do `.htaccess`, permissões, limites de recursos e configurações de deployment são causas comuns.

Pontos principais

HTTP 500 é uma resposta genérica do lado do servidor; a mensagem do navegador raramente identifica a causa raiz.
Compare o horário exato da falha com as entradas dos logs do PHP, da aplicação e do web server antes de alterar arquivos.
Alterações recentes em plugins, temas, módulos, código, deployment e .htaccess são suspeitas prioritárias.
Teste uma alteração direcionada por vez e verifique a URL exata que falhou após cada alteração.
Mantenha erros detalhados do PHP e da aplicação nos logs do servidor, em vez de exibi-los aos visitantes em um site de produção.

Atualizado em 2026-09-24 · Revisão editorial pendente Erros de HTTP e do servidor

Site Administrator

O que este erro significa e como reconhecê-lo

O navegador exibe uma página em branco, genérica ou personalizada com a mensagem 500 Internal Server Error.
Uma página que funcionava anteriormente falha após uma edição de código, instalação, atualização ou deployment de plugin ou tema, ou após uma alteração de configuração.
Apenas determinadas URLs, formulários, telas administrativas ou recursos do site falham, enquanto o restante do site continua disponível.
Um log do PHP, da aplicação ou do web server registra um erro fatal, erro de sintaxe, problema de permissão, dependência ausente ou falha por limite de recursos no mesmo momento.
Repetir a solicitação produz a mesma resposta 500, embora falhas intermitentes possam ocorrer quando há envolvimento de um limite de recursos ou de uma dependência da aplicação.

Causas principais, por probabilidade

Falha no código da aplicação, plugin, tema ou módulo — Um erro de sintaxe, erro fatal, atualização incompatível ou condição não tratada pode impedir a conclusão da solicitação.
Configuração inválida do Apache — Uma diretiva malformada ou não compatível no .htaccess, ou uma regra que exige um módulo desativado, pode disparar uma resposta 500. O .htaccess se aplica a configurações baseadas em Apache, não a todos os web servers.
Permissões ou propriedade incorretas de arquivos ou diretórios — Uploads manuais, migrações e deployments podem deixar o processo do web server sem conseguir ler os arquivos necessários.
Esgotamento da memória ou do tempo de execução do PHP — Importações grandes, consultas caras ou extensões que consomem muitos recursos podem exceder os limites configurados; alguns ambientes retornam 500 quando isso acontece.
Configuração ou dependências ausentes no deployment — Uma credencial de banco de dados alterada, uma variável de ambiente ausente, um pacote indisponível ou um runtime incompatível pode interromper a aplicação.
Arquivos incompletos ou corrompidos da aplicação ou do CMS — Uma atualização interrompida pode deixar arquivos essenciais do core ausentes ou danificados.

Como corrigir

Diagnostic flow at a glance — full detail in the steps below.

1. Confirme o escopo e o horário

Recarregue a URL exata que retorna 500 e registre o horário, incluindo o fuso horário. Verifique se o site inteiro falha ou apenas uma rota, formulário, tela administrativa, recurso de plugin ou tipo de solicitação. Uma falha específica de um recurso torna o código e as dependências recentes desse recurso mais prováveis; uma falha no site inteiro aponta mais fortemente para configuração do servidor, deployment ou arquivos do core.

2. Verifique primeiro os logs relevantes

Consulte o error_log do PHP, o log de erros do web server e o log da aplicação ou do CMS disponível no host. Locais comuns incluem /var/log/apache2/error.log para Apache e /var/log/nginx/error.log para Nginx, mas a estrutura varia conforme a hospedagem. Compare as entradas com o horário da falha e registre o arquivo, número da linha, exceção, mensagem do upstream ou diretiva de configuração. A página genérica exibida pelo navegador, sozinha, não é suficiente para identificar a causa.

3. Isole uma alteração recente no código ou em uma extensão

Se o log identificar um arquivo, plugin, tema, módulo ou alteração de deployment, reverta essa alteração ou desative o componente identificado em um ambiente testável. Em um CMS, use a área administrativa quando ela estiver disponível. Se a área administrativa estiver inacessível, o SFTP ou o gerenciador de arquivos da hospedagem pode permitir renomear o diretório do componente relevante. Altere um componente por vez e teste novamente a URL que falhou. Se o erro desaparecer, investigue a compatibilidade, a configuração e as atualizações disponíveis antes de reativá-lo.

4. Teste o `.htaccess` somente no Apache

Se o log apontar para um erro de análise do .htaccess ou se a falha tiver começado após uma alteração em uma regra do Apache, faça um backup e renomeie temporariamente .htaccess para .htaccess.bak usando SFTP ou o gerenciador de arquivos da hospedagem. Teste a página novamente. Se ela funcionar, restaure ou recrie o arquivo com cuidado e adicione as diretivas personalizadas gradualmente. Uma diretiva não compatível ou um módulo do Apache ausente pode ser o problema subjacente. Não aplique esta etapa a uma configuração somente com Nginx, na qual o .htaccess não é usado para configurar solicitações.

5. Corrija permissões e propriedade com cuidado

Quando o log indicar uma falha de permissão ou propriedade, compare o caminho afetado com um arquivo funcional ou com as configurações documentadas pelo provedor de hospedagem. 644 para arquivos e 755 para diretórios são configurações comuns, mas os valores corretos dependem do host e do modelo de deployment. Corrija o caminho afetado por SFTP, SSH ou pelo gerenciador de arquivos da hospedagem e não torne arquivos ou diretórios graváveis globalmente como atalho.

6. Investigue os limites de recursos do PHP e da aplicação

Se o log mencionar esgotamento de memória, tempo máximo de execução ou um limite semelhante, identifique a operação que está consumindo o recurso, como uma importação grande ou uma tarefa cara de um plugin. Ajuste memory_limit ou max_execution_time no php.ini, .user.ini, na configuração da hospedagem ou na configuração do deployment aplicável somente se o host permitir. Reduza também a carga de trabalho ou corrija a operação ineficiente; aumentar um limite sozinho pode apenas adiar a falha.

7. Compare as configurações do deployment e os arquivos necessários

Para falhas que começaram após um deployment ou migração, compare as variáveis de ambiente, credenciais do banco de dados, versões do runtime, dependências instaladas, caminhos de arquivos e configurações geradas com o ambiente funcional. Confirme se os arquivos necessários estão presentes e se a aplicação consegue acessar o banco de dados ou serviço configurado. Use a variável, o pacote ou o erro de conexão ausente identificado no log como ponto de partida, em vez de alterar configurações não relacionadas.

8. Restaure arquivos danificados somente após preservar as evidências

Se houver indicação de uma atualização incompleta ou de um arquivo do core corrompido, salve o log relevante e uma cópia dos arquivos atuais antes de fazer reparos. Em seguida, restaure arquivos conhecidos como íntegros ou execute novamente o processo de atualização compatível com a plataforma, usando um backup quando disponível. Teste novamente a URL original e verifique se nenhum novo erro correspondente está sendo gravado no log.

Prevenção e como verificar a correção

Faça backup dos arquivos e do banco de dados antes de instalar ou atualizar um plugin, tema, módulo ou componente do CMS.
Teste alterações no código e no .htaccess em uma cópia de staging quando possível e mantenha uma configuração conhecida como funcional para rollback.
Faça o deployment de variáveis de configuração e dependências de forma consistente entre os ambientes e verifique os arquivos necessários após as migrações.
Monitore os logs de erros do PHP, da aplicação e do web server, em vez de depender apenas de verificações externas de disponibilidade.
Faça uma alteração por vez, registre o que mudou e teste novamente a URL exata que falhou.
Mantenha diagnósticos detalhados nos logs do servidor, em vez de exibi-los aos visitantes em um site de produção.

Quando buscar ajuda externa

Entre em contato com o provedor de hospedagem ou com o desenvolvedor da aplicação quando não conseguir acessar os logs relevantes, quando o erro continuar após reverter a última alteração conhecida ou quando o log indicar um problema de módulo no host, permissão, runtime do PHP, banco de dados ou recurso que você não consegue alterar. Forneça a URL exata, o horário e o fuso da falha, as alterações recentes e a entrada relevante do log. Não envie senhas, chaves de API ou outros valores confidenciais do ambiente. Se a falha começou após uma migração ou deployment, peça ao responsável para comparar os ambientes funcional e com falha.

Verificar um site

Perguntas frequentes

O que significa 500 Internal Server Error?

Significa que o servidor encontrou uma condição inesperada ao processar a solicitação e não conseguiu fornecer uma resposta mais específica ao navegador. O código de status não identifica a causa raiz; o log correspondente do servidor ou da aplicação normalmente fornece os detalhes úteis.

Um erro 500 é causado pelo meu navegador ou pela conexão com a internet?

Geralmente, não. HTTP 500 indica um problema ocorrido enquanto o servidor processava a solicitação. Tente novamente a URL exata para confirmar o comportamento, mas concentre a investigação nos logs do servidor, da aplicação, da configuração e do deployment.

Por que ocorre um erro 500 depois de editar o .htaccess?

No Apache, uma diretiva inválida, uma regra malformada ou uma regra que depende de um módulo indisponível pode impedir o processamento da solicitação. Faça backup do arquivo, renomeie-o temporariamente e verifique o log de erros do Apache antes de recriar as regras. Isso não se aplica a configurações somente com Nginx.

Como corrijo um erro 500 causado por um plugin ou tema do WordPress?

Use o log do PHP ou da aplicação para identificar o componente quando possível. Desative ou reverta esse plugin ou tema específico, usando SFTP ou o gerenciador de arquivos se a área administrativa estiver indisponível, e teste novamente a URL que falhou. Se o site voltar a funcionar, investigue a compatibilidade, a configuração ou uma atualização disponível antes de reativá-lo.

Permissões incorretas podem causar um 500 Internal Server Error?

Sim. Se o processo do web server não conseguir ler ou executar um arquivo ou diretório necessário, a solicitação poderá falhar. Corrija o caminho afetado usando as configurações de propriedade e permissão esperadas pelo provedor de hospedagem; tornar tudo gravável não é uma correção geral segura.

O que devo fazer se não conseguir ver o log de erros?

Peça ao host para verificar os logs do PHP, da aplicação e do web server da sua conta no horário exato da falha. Painéis de hospedagem compartilhada podem não expor todos os logs, embora o provedor consiga recuperá-los.

Documentação adicional

Para obter detalhes específicos e confiáveis sobre o ambiente, consulte a documentação do web server em uso, como Apache HTTP Server ou Nginx, junto com a documentação do PHP sobre registro de erros e limites do runtime. Consulte também a documentação do CMS, framework, painel de controle da hospedagem ou plataforma de deployment relevante para conhecer os locais dos logs, o modelo de permissões, o processo de recuperação e os requisitos de configuração.