Erro 500 Internal Server Error: causas e solução (nginx)

O que é o erro HTTP 500?

O erro HTTP 500 (Internal Server Error) significa que algo quebrou no servidor web enquanto ele processava a sua solicitação, e o servidor não disse o quê. É o erro de servidor mais genérico.

O padrão HTTP o define em uma frase: "The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request" (RFC 9110 §15.6.1), ou seja, o servidor encontrou uma condição inesperada que o impediu de atender à solicitação. Ao contrário de um 503, ele não diz nada sobre o problema ser temporário.

Quase sempre é um bug, uma configuração incorreta ou uma falha no código do lado do servidor, e não algo que o visitante tenha feito. A correção precisa vir do proprietário ou do administrador do site.

Como o erro 500 aparece

O texto depende do servidor e da aplicação:

• 500 Internal Server Error — a linha de status padrão
• 500 Internal Server Error com "nginx" logo abaixo — a página de erro do próprio nginx
• The server encountered an internal error or misconfiguration and was unable to complete your request. — a página padrão do Apache
• Há um erro crítico no seu site. — a página de erro fatal do WordPress na versão em português (em inglês: "There has been a critical error on this website.")
• HTTP Error 500.19 - Internal Server Error — IIS, em que o número depois do ponto indica o motivo (500.19: dados de configuração inválidos)
• Esta página não está funcionando · example.com não consegue atender a esta solicitação no momento. · HTTP ERROR 500 — Chrome, quando a resposta 500 não tem uma página própria
• Request failed with status code 500 — Axios e outros códigos JavaScript que chamam uma API
• 500. That's an error. — a página de erro do próprio Google

500 Internal Server Error no nginx

Na maioria das vezes o nginx apenas repassa um 500 devolvido pela aplicação por trás dele (PHP-FPM, Node.js, Python); no caso do PHP-FPM, a mensagem de erro do próprio PHP vai parar no log do nginx. O nginx também gera um 500 próprio em poucos casos. As linhas do log de erros a procurar:

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Fonte: o código do próprio nginx; um backend que caiu ou está sobrecarregado resulta em 502 ou 504, não em 500.)

Causas comuns do erro HTTP 500

Um 500 pode vir de dezenas de problemas no lado do servidor. Os mais comuns:

• Um arquivo .htaccess quebrado — uma diretiva inválida ou uma RewriteRule errada faz o Apache responder 500 para aquele diretório e tudo abaixo dele.
• Erros fatais do PHP — erros de sintaxe, exceções não capturadas ou chamadas a funções indefinidas interrompem o script.
• Limites de memória ou de tempo do PHP — um script que ultrapassa memory_limit (128M por padrão) ou max_execution_time (30 segundos) é interrompido.
• Linhas php_value em um servidor com PHP-FPM — elas só funcionam com o mod_php do Apache; com PHP-FPM, o Apache as rejeita com um 500.
• Permissões de arquivo erradas — o PHP não consegue ler um arquivo que inclui, ou uma hospedagem com suPHP/suEXEC recusa arquivos graváveis por todos (777). (Um arquivo que o próprio servidor web não consegue ler resulta em 403.)
• Um plugin ou tema — uma extensão nova ou atualizada do WordPress, Joomla ou Drupal que derruba o site inteiro.
• Falhas na conexão com o banco de dados — credenciais erradas, servidor de banco de dados parado ou conexões demais.
• Arquivos do núcleo corrompidos — depois de uma atualização que falhou ou de um upload interrompido.
• Disco cheio — o servidor não consegue gravar logs, sessões nem arquivos temporários.
• Gatilhos próprios do nginx — um loop de reescrita, um arquivo de senhas ilegível ou uma gravação de arquivo temporário que falha (muitas vezes disco cheio); veja a seção do nginx acima.

Como resolver o erro 500 (como visitante)

Se você está vendo um erro 500 no site de outra pessoa, o problema está no servidor — não no seu dispositivo. Porém, há algumas coisas que você pode tentar antes de desistir.

• Recarregue uma vez depois de um minuto (F5, ou Cmd+R no Mac). Muitos 500 duram apenas o tempo de um deploy ou de uma reinicialização.
• Veja se está fora do ar para todos — o Verificador de site fora do ar abre a página a partir de 11 lugares, e o Verificador de headers HTTP mostra o código de status exato que o nosso servidor recebe.
• Apague os cookies do site ou tente uma janela anônima. Um cookie de sessão corrompido pode fazer alguns aplicativos falharem em todas as páginas só para você.
• Tente novamente mais tarde — a correção é no servidor, então dê tempo ao proprietário.
• Avise o proprietário do site se durar horas, informando o endereço da página e o horário em que aconteceu.

Solução 1: verifique os logs de erro do servidor

Os logs de erro são a ferramenta de depuração mais importante para erros 500. Eles dizem exatamente o que deu errado, incluindo o caminho do arquivo, número da linha e mensagem de erro. Sempre verifique os logs primeiro antes de tentar qualquer outra coisa.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Solução 2: teste e repare o .htaccess

Um .htaccess quebrado é uma causa clássica de erros 500 no Apache: um erro de digitação, uma diretiva que o servidor não suporta ou uma RewriteRule errada derruba o diretório. O log de erros do Apache informa o arquivo .htaccess e a diretiva problemática, por exemplo Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

O teste mais rápido é renomear o arquivo temporariamente. Se o site carregar depois de renomeá-lo, o problema era o .htaccess.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Solução 3: corrija as permissões de arquivo

As permissões causam um 500 quando o PHP não consegue ler um arquivo que inclui, ou em hospedagens suPHP/suEXEC que recusam arquivos graváveis por todos. As configurações usuais são 644 para arquivos e 755 para pastas. Nunca use 777: é um risco de segurança e, em hospedagens suEXEC/suPHP, causa um 500 por si só.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Solução 4: aumente os limites de memória e execução do PHP

O PHP interrompe scripts que ultrapassam o limite de memória ou o tempo máximo de execução, e o visitante recebe um 500. Os padrões, 128M de memória e 30 segundos, costumam ser baixos demais para páginas pesadas.

Aumente-os onde o seu servidor os lê. Para PHP-FPM, edite o php.ini do FPM (por exemplo /etc/php/8.3/fpm/php.ini) e recarregue o php-fpm; as mudanças no .user.ini podem levar até 5 minutos para valer.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Solução 5: desative plugins e tema (CMS)

Se você está usando WordPress, Joomla ou outro CMS, um plugin ou tema com defeito é uma das causas mais comuns de erros 500. A forma mais rápida de testar é desativar todos os plugins de uma vez e depois reativá-los um por um.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Solução 6: verifique a conexão com o banco de dados e repare

O erro 500 pode ocorrer quando a aplicação não consegue se conectar ao banco de dados. Isso acontece quando as credenciais estão erradas, o servidor de banco de dados está fora do ar ou as tabelas estão corrompidas.

Primeiro verifique as credenciais do banco de dados no arquivo de configuração (wp-config.php para WordPress, .env para Laravel). Depois teste a conexão e repare tabelas corrompidas se necessário.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Solução 7: verifique a compatibilidade da versão do PHP

Um código escrito para uma versão mais antiga do PHP pode causar erros fatais em uma mais nova (ou o contrário). Depois de uma atualização do PHP, as funções removidas e os comportamentos alterados são os culpados de sempre; funções obsoletas (deprecated) só geram avisos.

Verifique qual versão do PHP o seu site realmente executa. O php -v na linha de comando pode mostrar um PHP diferente do que o site usa; por isso, veja também o painel da hospedagem ou uma página phpinfo() temporária:

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Solução 8: verifique o espaço em disco

Quando um servidor fica sem espaço em disco (ou sem inodes), ele não consegue gravar logs, arquivos temporários nem dados de sessão, e as requisições começam a falhar com 500.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs 502 vs 503 vs 504: qual a diferença?

A distinção principal: 500 = o servidor quebrou internamente. 502 = o proxy recebeu lixo do backend. 503 = o servidor está vivo, mas ocupado. 504 = o proxy desistiu de esperar. Você pode conferir o código de status exato que o seu servidor retorna com o Verificador de headers HTTP do DNS Robot.

Quando o erro é um 502, a aplicação pode estar bem e o problema fica entre o proxy e a aplicação. O nosso guia do 502 Bad Gateway trata desse caso.

Como os erros 500 afetam o SEO

A própria documentação do Google descreve o que acontece (documentação dos rastreadores do Google):

• O rastreamento fica mais lento. Com erros 5xx, o Google reduz a taxa de rastreamento do site, em proporção ao número de URLs que retornam erros.
• As páginas indexadas ficam, no início. URLs já indexadas são mantidas por um tempo, mas as que retornam erro de servidor de forma persistente são removidas.
• A recuperação é gradual. Quando o servidor volta a responder com 2xx, o Google aumenta o rastreamento aos poucos.
• Use 503 para uma parada planejada de um ou dois dias, com um header Retry-After (Google), para que a parada seja lida como temporária (guia do 503).

Como prevenir erros 500

Prevenção é sempre melhor do que depuração. Siga estas boas práticas para minimizar o risco de erros 500 no seu site.

• Configure monitoramento de uptime — Use ferramentas como UptimeRobot ou Pingdom para verificar seu site a cada 1-5 minutos. Receba alertas instantâneos quando um erro 500 ocorrer.
• Sempre teste mudanças em staging — Nunca faça deploy diretamente em produção. Teste atualizações de plugins, upgrades de PHP e mudanças de configuração em um ambiente de staging primeiro.
• Use controle de versão (Git) — Faça commit de cada alteração para poder reverter instantaneamente um deploy ruim com um único comando.
• Implemente tratamento de erros adequado — Envolva consultas ao banco de dados e chamadas de API em blocos try-catch. Registre stack traces completos no servidor para cada erro.
• Monitore espaço em disco e recursos do servidor — Configure alertas para uso de disco acima de 80%, CPU alta e pressão de memória.
• Mantenha o software atualizado — Versões desatualizadas do CMS, plugins e software do servidor contêm bugs conhecidos que causam travamentos.
• Mantenha backups automatizados — Teste seu procedimento de restauração regularmente. Um backup que você nunca testou não é um backup.
• Defina os limites do PHP adequadamente — Configure memory_limit e max_execution_time com base na sua carga de trabalho real, não nos valores padrão.
• Use pipelines de CI/CD — Automatize testes antes do deploy. Se os testes falharem, o deploy não deve prosseguir.