500 Internal Server Error: o que significa e como resolver

Você clica no botão para pagar um pedido e, em vez da próxima página, aparece uma tela quase em branco: "500 Internal Server Error" em negrito, com "nginx" embaixo. Em outro site, o Chrome desenha a própria página, "Esta página não está funcionando", com "HTTP ERROR 500" no rodapé. Dentro de um app as palavras mudam, por exemplo "The call failed on the server; see server log for details", mas o número é o mesmo.

A seguir: o que o código significa e por que ele diz tão pouco, quem produziu a página que você vê, como um 500 difere de 502, 503 e 504, e o que visitantes, donos de sites e scripts devem fazer a respeito.

O que significa 500 Internal Server Error?#

O padrão HTTP define o código em uma frase: o servidor "encontrou uma condição inesperada que o impediu de atender à requisição" (RFC 9110, seção 15.6.1). Todo código que começa com 5 é um erro de servidor, ou seja, o servidor sabe que a culpa é dele; o 500 é o que ele usa quando nenhum código mais específico se encaixa.

É por isso que a mensagem diz tão pouco. O servidor web, o programa que aceita as conexões, como o nginx ou o Apache, repassou a sua requisição à aplicação que monta as páginas, e em algum ponto desse trabalho a aplicação falhou. O servidor web só sabe que nenhuma página utilizável voltou, então responde 500; o detalhe foi parar em um log de erros (error log) que só o operador do site pode ler.

Quem enviou a página que você está vendo?#

A aparência da página de erro diz qual programa desistiu e quanto do site ainda está funcionando.

Conferimos a última linha com um pequeno servidor de teste no nosso próprio computador, que responde a toda requisição com o status 500 e sem página, aberto no Chromium 145: exatamente essa estrutura, com o nome do nosso host na linha do meio e um botão Recarregar. Os textos em português do título, da linha do host e do botão estão no arquivo de tradução do Chromium (components_strings_pt-BR.xtb); "HTTP ERROR 500" é acrescentado pelo código e nunca é traduzido.

Como um 500 acontece, passo a passo?#

1. O seu navegador envia a requisição com o endereço, os seus cookies e os dados de qualquer formulário.
2. O servidor web a repassa à aplicação que monta as páginas na hora; os arquivos estáticos ele mesmo entrega.
3. A aplicação falha no meio do caminho: um erro não tratado, um banco de dados que não responde, uma linha de configuração errada, um script acima do seu limite de memória.
4. Algo responde 500: a página da própria aplicação, se ela capturou o erro, a página genérica do servidor web ou uma resposta vazia, se ela travou.
5. O seu navegador mostra o que recebeu, ou a própria tela "Esta página não está funcionando", se o corpo veio vazio.

Qual é a diferença entre 500, 502, 503 e 504?#

Os quatro são erros de servidor, mas apontam partes diferentes que falharam. Um 500 diz que a própria aplicação falhou; 502, 503 e 504 descrevem um gateway, o servidor que fica na frente da aplicação (um reverse proxy, um balanceador de carga ou uma CDN) e encaminha as requisições dos visitantes.

A mesma falha pode aparecer com qualquer um dos dois códigos: se a aplicação morre antes de responder e o nginx está na frente, o nginx informa um 502; se a aplicação captura o erro e responde ela mesma, você vê um 500. Erro 502 Bad Gateway: o que significa e como resolver cobre o lado do gateway.

O erro 500 é culpa sua?#

Quase nunca, e nunca por causa da sua conexão: a requisição chegou. Ainda assim, a sua requisição pode ser o gatilho, como um valor de formulário que o código não esperava ou um upload muito grande; o bug é do site, mas só dispara com você até o site corrigi-lo. Um cookie ou uma sessão de login antigos também podem confundir uma aplicação, e é por isso que apagar os cookies do site às vezes resolve um 500 que recarregar não resolve.

Um proxy ou uma VPN também não causam um 500: o erro é produzido depois que a requisição chega ao site, então um endereço IP diferente não vai fazê-lo sumir.

O que você pode fazer como visitante?#

1. Recarregue uma vez e depois espere alguns minutos. Pressione F5 ou o botão Recarregar da página de erro do Chrome; depois disso você só acrescenta carga a um servidor que já está em dificuldade.
2. Tente outra página do mesmo site. Se a página inicial carrega, mas o pagamento falha, o site está no ar e uma função está quebrada.
3. Tente o site no celular pelos dados móveis. Se falhar lá também, a falha é geral e nada no seu computador vai mudar isso. Trocar de saída com um proxy ou uma VPN é o mesmo teste; com os Proxies residenciais você repete o teste de outro país em um minuto.
4. Veja a página de status do site. Serviços maiores anunciam quedas ali; um app que continua mostrando um 500 está esbarrando na mesma queda pela API.
5. Apague os cookies do site, mas só quando o erro sobrevive à espera e segue você de página em página. No Chrome, no computador: Mais > Excluir dados de navegação, escolha um período, marque Cookies e outros dados do site e depois Excluir dados (os passos do Google). Isso encerra a sua sessão nos sites, então deixe para o final.
6. Avise o site com o endereço exato, o horário, o que você clicou e qualquer ID de requisição impresso na página.

Reiniciar o roteador, trocar os servidores DNS ou reinstalar o navegador não adiantam aqui: eles agem na parte do caminho que já funcionou.

Se o site é seu: como encontrar a causa?#

Um 500 é vago de propósito para os visitantes, mas nunca é vago no log. Siga estes passos em ordem; a maioria dos 500 termina nos três primeiros.

1. Leia primeiro o log de erros. O Apache chama o seu log de erros de o primeiro lugar para olhar quando surge um problema; a diretiva ErrorLog define onde ele fica, normalmente um arquivo chamado error_log no Unix (documentação de logs do Apache). O nginx grava em logs/error.log por padrão, e o PHP no próprio arquivo error_log ou no log do servidor web. Procure o minuto do 500: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted é um problema de memória, o Premature end of script headers do Apache é um script que morreu antes de enviar uma página, e um stack trace aponta o arquivo e a linha.
2. Desfaça a última mudança. Um 500 que começa logo depois de uma atualização, um deploy ou uma edição de configuração é essa mudança até que se prove o contrário; reverta primeiro.
3. Plugins e temas. O guia do WordPress sobre o Internal Server Error manda desativar todos os plugins e mudar para um tema padrão (Erros comuns do WordPress); se o site voltar, reative-os um de cada vez.
4. O arquivo .htaccess. No Apache, esse arquivo de configuração por pasta é lido a cada requisição, então uma única linha errada quebra todas as páginas. O guia do WordPress aponta um .htaccess corrompido como a causa mais provável: renomeie-o para .htaccess_old e, se o site carregar, gere-o de novo em Configurações > Links permanentes. Uma diretiva que o AllowOverride não permite, ou um erro de sintaxe, produz um erro de servidor com o motivo no log.
5. Limites do PHP. O PHP interrompe um script que aloca mais do que memory_limit (128M por padrão) e encerra um que roda por mais tempo que max_execution_time (30 segundos por padrão em um servidor web). Aumente o limite no php.ini ou nas configurações de PHP da hospedagem, mas trate uma necessidade que só cresce como um bug.
6. Permissões e dependências. O servidor web roda com um usuário próprio: um script que ele não consegue ler ou uma pasta em que não consegue gravar termina em um 500 em vez de uma mensagem clara. O mesmo vale para um banco de dados fora do ar, uma chave de API ou um certificado vencidos, ou um disco cheio; isso fica no log da própria aplicação.
7. O seu painel de hospedagem. Na hospedagem compartilhada, o painel expõe o log: no cPanel, a interface Errors (Erros) dentro de Metrics (Métricas) lista até 300 das entradas mais recentes. Se elas apontarem para o próprio servidor, ou se todos os sites do servidor falharem, abra um chamado na hospedagem com o horário, a URL e as linhas do log.

Os rastreadores do Google desaceleram diante de erros 5xx e acabam descartando URLs que continuam falhando, então um 500 que se arrasta custa posições. Um monitoramento que busca algumas páginas-chave a cada minuto avisa você primeiro; verificações feitas de alguns endereços fixos e dedicados dos Proxies de datacenter podem ser liberadas no servidor e mantidas fora das suas estatísticas de erro.

Como um script ou scraper deve lidar com um 500?#

Trate um 500 como temporário, mas não como gratuito: tente de novo algumas vezes, com pausas cada vez maiores, e depois desista desse endereço.

• Limite as tentativas e aumente a pausa. Um segundo, depois dois, depois quatro, e pare após três ou quatro tentativas; um loop que martela o mesmo endereço piora a queda.
• Um 500 sob carga significa desacelerar. Se o site começa a retornar 500 enquanto o seu crawler roda com alta concorrência, reduza o número de requisições em paralelo. Nunca troque de endereço IP para forçar a passagem: a aplicação falha para todo mundo.
• Registre o corpo da resposta. Um erro em JSON, um ID de requisição ou um stack trace diz se a falha é sua (um parâmetro errado) ou deles, e distingue um 500 de verdade de um bloqueio: um 403 ou um 429 com uma página de verificação é uma decisão sobre o seu tráfego, não uma falha do servidor. 429 Too Many Requests: o que é o erro de rate limit cobre esses casos.

O exemplo abaixo aplica as regras com a biblioteca Requests do Python. Nós o rodamos contra o nosso servidor de teste local, cuja página /flaky retorna 500 duas vezes e depois 200, e cuja página /text sempre retorna 500 (Python 3.13, Requests 2.34):

import time

import requests

URL = "http://127.0.0.1:18500/flaky"  # nosso servidor de teste local; coloque aqui a página de que você precisa
PROXIES = None  # ou {"http": "http://user:pass@pr.proxynet.io:8000", "https": "http://user:pass@pr.proxynet.io:8000"}
ATTEMPTS = 4  # um limite: um 500 que persiste é problema do site, não seu


def fetch(url):
    wait = 1.0
    for attempt in range(1, ATTEMPTS + 1):
        r = requests.get(url, proxies=PROXIES, timeout=20)
        if r.status_code in (403, 429):
            raise RuntimeError(f"{url}: HTTP {r.status_code} is a block or a rate limit, not a server error")
        if r.status_code < 500:
            return r
        print(f"attempt {attempt}: HTTP {r.status_code} {r.reason}, body: {r.text.strip()[:60]!r}")
        if attempt < ATTEMPTS:
            time.sleep(wait)
            wait *= 2  # 1 s, 2 s, 4 s
    raise RuntimeError(f"{url}: HTTP 500 after {ATTEMPTS} attempts, skip it and come back later")


r = fetch(URL)
print(f"HTTP {r.status_code}: {r.text.strip()}")

Saída para /flaky:

attempt 1: HTTP 500 Internal Server Error, body: '{"error":"database connection lost"}'
attempt 2: HTTP 500 Internal Server Error, body: '{"error":"database connection lost"}'
HTTP 200: ok

Para /text, quatro tentativas são impressas e o script termina com:

RuntimeError: http://127.0.0.1:18500/text: HTTP 500 after 4 attempts, skip it and come back later

Por um proxy, preencha PROXIES com o endereço do Endpoint Generator; a lógica não muda, porque o 500 vem do destino. Quais códigos tentar de novo e em quais parar, do 403 ao 504, está em Códigos de status HTTP no web scraping: 403, 407, 429, 503.

Onde você pode encontrar um 500#

• Um "500 Internal Server Error" seco, com "nginx" embaixo, em um site pequeno, muitas vezes logo depois de uma atualização do CMS ou do PHP.
• Dentro de um app como o Discord ou o de um banco, cujas telas chamam a API do próprio serviço e mostram o número que ela retornou.
• A mensagem "The call failed on the server; see server log for details" em uma aplicação web Java: o texto fixo que o framework GWT envia com um 500 quando uma chamada ao servidor falha.

Erros comuns#

• Recarregar a cada segundo. A aplicação já está falhando; mais requisições a deixam ainda mais lenta e escondem o momento em que ela se recupera.
• Donos de sites: aumentar o memory_limit sem ler o log. Um limite maior esconde um vazamento de memória por uma semana, e depois o 500 volta.
• Donos de sites: mostrar o stack trace aos visitantes. Um modo de depuração esquecido ligado em produção imprime caminhos de arquivos e detalhes do banco de dados na página de erro.
• Scrapers: rotacionar IPs diante de um 500. O site falha para todos os endereços; tente de novo com pausas ou pule a página.

Guia de decisão#

Perguntas frequentes#

O erro 500 internal server error é culpa minha?#

Não. O código significa que o próprio software do site falhou ao tratar a sua requisição; a sua conexão e o seu navegador fizeram a parte deles. O que você digitou pode disparar um bug que já existia, mas corrigi-lo continua sendo tarefa do site.

Quanto tempo dura um erro 500?#

Não há um tempo fixo. Um reinício ou uma queda breve do banco de dados passam em segundos; uma atualização com defeito ou um arquivo .htaccess quebrado duram até o dono perceber e corrigir.

O que significa "500 Internal Server Error nginx"?#

O nginx é o programa servidor web na frente do site, e a página é a página de erro genérica dele: a aplicação por trás do nginx falhou e o nginx não tinha nenhuma resposta adequada para repassar.

O que significa "The call failed on the server; see server log for details"?#

É o texto fixo que o framework GWT, usado por algumas aplicações web Java, envia com o status 500 quando uma requisição ao servidor lança um erro. O log a que ele se refere só pode ser lido pelos operadores do site; para você, é um 500 comum.

Por que o Discord ou outro app mostra um erro 500?#

Os apps buscam os seus dados pela API do serviço, e quando ela responde 500 o app mostra o número. A queda está do lado do serviço; veja a página de status dele e tente mais tarde.

Limpar os cookies resolve um erro 500?#

Às vezes, quando a aplicação engasga com um cookie ou uma sessão antigos. Tente isso só depois de recarregar e esperar; a maioria dos 500 está no servidor, e apagar dados não faz nada por eles.

Em resumo#

Um 500 Internal Server Error significa que a aplicação do site encontrou um problema que não conseguiu tratar, e o servidor enviou um erro genérico em vez da página. Os visitantes recarregam uma vez, esperam e testam de outro dispositivo; os donos leem o log de erros e voltam pela última mudança, pelos plugins, pelo .htaccess, pelos limites do PHP e pelas permissões; os scripts tentam de novo com pausas crescentes e nunca forçam a passagem com endereços novos. Os tipos de proxy estão comparados na nossa página de proxies.