Erro 500 Internal Server Error: como resolver no site

Entenda o erro 500 Internal Server Error no WordPress com Nginx: leia os logs, use o modo de depuração e teste plugin, tema, memória e permissões, na ordem.

Por Redação Eleven Host · @robson.direitodigital · 28 de outubro de 2026 · 8 min de leitura

O erro 500 internal server error aparece quando o servidor encontrou um problema inesperado e não conseguiu atender ao pedido. O motivo fica registrado no log do Nginx, no log do PHP-FPM ou no log de depuração do WordPress.

Este guia é para quem tem um site WordPress numa VPS com Nginx e PHP-FPM e recebeu a tela de 500 ao abrir uma página. A ordem segue o diagnóstico: o que o erro quer dizer, o que cabe ao visitante e seis passos para achar a causa, começando pelos logs. Os nomes seudominio.com.br e 8.3 (versão do PHP) são exemplos. Troque pelos seus.

O que significa o erro 500 Internal Server Error

Segundo a MDN, quando o servidor retorna o código de erro HTTP 500, ele indica que encontrou uma condição inesperada que o impediu de atender à solicitação. A MDN explica que é uma resposta genérica e abrangente, e que os arquivos de log do servidor podem trazer mais detalhes sobre o pedido.

Em linguagem simples: o servidor recebeu o pedido, mas algo quebrou do lado dele, no código do site, num plugin ou na configuração. É diferente de outros erros que você pode ver no mesmo site:

• 500: o servidor recebeu o pedido e algo quebrou ao processá-lo.
• 403: o servidor recusou entregar. O guia Erro 403 Forbidden: o que é e como resolver no seu site trata esse caso.
• 404: o servidor não achou o endereço pedido.
• 502 e 504: o programa de trás do Nginx falhou ou demorou. Os guias Erro 502 Bad Gateway: o que é e como resolver na VPS e Erro 504 Gateway Timeout: o que é e como resolver na VPS explicam cada um.

Como o 500 é genérico, a mensagem na tela não diz a causa. Ela está nos logs, e é por eles que o diagnóstico começa.

Se você é visitante ou dono do site

Se você só está visitando o site de outra pessoa, há pouco a fazer do seu lado além de tentar de novo mais tarde. A causa está no servidor ou no site, e quem pode corrigir é o dono.

Se o site é seu, os passos abaixo mostram como descobrir qual das causas é a sua. Anote a mensagem que cada log mostrar: ela aponta o próximo passo.

Passo 1: ler o log de erros do Nginx

O Nginx registra os problemas que encontra. Veja as últimas 50 linhas do log de erros, no caminho do pacote do Ubuntu:

sudo tail -n 50 /var/log/nginx/error.log

Procure linhas com a data e a hora em que você abriu a página com erro. Se aparecer uma mensagem sobre o PHP-FPM, siga para o passo 2. Se aparecer uma mensagem sobre permissão de arquivo, vá para o passo 6.

Se o log não mostrar nada ligado ao pedido, o problema pode estar no próprio PHP ou no WordPress. Os próximos passos cobrem os dois.

Passo 2: ler o log do PHP-FPM

O PHP-FPM roda como um serviço do systemd, e o journalctl lê os registros dele. A opção -u filtra pela unidade do systemd e a opção --since limita o período:

sudo journalctl -u php8.3-fpm --since "1 hour ago"

Troque 8.3 pela versão do PHP que você usa. Se a saída trouxer uma mensagem de erro com o nome de um arquivo e um número de linha, abra esse arquivo: ele pode indicar qual plugin, tema ou trecho de código quebrou.

Nem todo erro do PHP aparece nesse log. Quando ele não ajudar, o WordPress tem o próprio registro de depuração, que é o passo seguinte.

Passo 3: ligar o modo de depuração do WordPress

A documentação do WordPress permite gravar os erros num arquivo. No wp-config.php, adicione as linhas abaixo antes da linha /* That's all, stop editing! Happy blogging. */. Em português, ela pode aparecer como "Isso é tudo, pare de editar!".

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

@ini_set( 'display_errors', 0 );

Com WP_DEBUG_LOG ligado, os erros vão para o arquivo wp-content/debug.log. O WP_DEBUG_DISPLAY em false esconde os erros da página, para o visitante não vê-los. Abra a página com erro uma vez e, dentro da pasta do site, leia o fim do arquivo:

tail -n 30 wp-content/debug.log

A documentação do WordPress não recomenda deixar o WP_DEBUG ligado num site no ar. Use o modo para achar o erro e depois volte para:

define( 'WP_DEBUG', false );

Como cuidado extra, apague o debug.log quando terminar, porque ele pode ficar acessível pelo navegador.

Quer um servidor para hospedar o seu site? Os planos de VPS são a partir de R$ 17,00/mês, no Plano Bronze; confira na loja o que cada plano inclui. Ver planos de VPS

Passo 4: plugin ou tema com defeito

A documentação do WordPress cita o plugin e o tema entre as causas comuns do Internal Server Error. Desde o WordPress 5.2 existe o modo de recuperação: quando um plugin ou tema dá erro fatal, o visitante vê a mensagem "O site está passando por dificuldades técnicas" (em inglês, "The site is experiencing technical difficulties") e o administrador recebe instruções no e-mail de administração do site.

Para testar sem entrar no painel, desative os plugins de uma vez renomeando a pasta, dentro da pasta do site. O WordPress deixa de achar a pasta e, com isso, desativa os plugins:

mv wp-content/plugins wp-content/plugins.desativados

Se o site voltar, renomeie a pasta de volta e reative os plugins um por um no painel. Quando o erro reaparecer, você achou o culpado.

mv wp-content/plugins.desativados wp-content/plugins

Se os plugins não forem a causa, troque o tema para um tema padrão do WordPress e teste de novo. Antes de atualizar plugins e temas, siga o roteiro de Como atualizar o WordPress com segurança: passo a passo.

Passo 5: limite de memória do PHP

A documentação do WordPress também cita o limite de memória do PHP como causa. No log, pode aparecer a mensagem "Allowed memory size of ... bytes exhausted", que indica que o PHP usou toda a memória que podia.

O WP_MEMORY_LIMIT define a memória máxima que o PHP pode usar no site. O exemplo da documentação é este, no wp-config.php:

define( 'WP_MEMORY_LIMIT', '64M' );

A própria documentação alerta que aumentar o limite pode esconder a causa real. Use o aumento para testar e, se o erro sumir, descubra o que consome tanta memória, como um plugin pesado.

Passo 6: permissões e configuração do Nginx

Um arquivo que o PHP não consegue ler também pode gerar o erro. As regras de permissão para pastas e arquivos estão no mesmo guia do erro 403: 755 nas pastas, 644 nos arquivos, sem usar 777.

Se você mexeu na configuração do Nginx, teste a sintaxe antes de aplicar:

sudo nginx -t

Se o teste apontar erro, corrija a linha indicada. Estando tudo certo, recarregue:

sudo systemctl reload nginx

Se você mudou o php.ini, reinicie o PHP-FPM:

sudo systemctl restart php8.3-fpm

Se o seu servidor for Apache, e não Nginx, um arquivo .htaccess corrompido é outra causa citada pela documentação do WordPress. O Nginx não lê esse arquivo, então ele não explica um 500 no Nginx.

Precisa de um banco de dados na nuvem para o seu site? O 11SQL Mini sai a partir de R$ 9,90/mês; confira na loja o que cada plano inclui. Ver planos de 11SQL

Perguntas frequentes

O erro 500 é problema do meu navegador ou da minha internet?

Não. Segundo a MDN, o 500 indica que o servidor encontrou uma condição inesperada. O problema está no servidor ou no site, e o visitante pouco pode fazer além de tentar mais tarde.

Onde fica o motivo do erro 500?

Nos logs. A MDN diz que os arquivos de log do servidor podem trazer mais detalhes. Num site WordPress na VPS, olhe o log do Nginx, o log do PHP-FPM e o wp-content/debug.log.

Posso deixar o WP_DEBUG ligado no site?

Não é o caminho. A documentação do WordPress não recomenda deixar o WP_DEBUG ligado num site no ar. Ligue para achar o erro e depois volte para false.

Aumentar o WP_MEMORY_LIMIT resolve o erro 500?

Pode resolver quando o erro é de memória, mas a documentação alerta que o aumento pode esconder a causa real.