O Que Significa um Erro 500 Internal Server Error e de Quem é a Culpa

Um erro 500 Internal Server Error é o servidor que executa o site admitindo que algo deu errado dentro de seu próprio código, e que não consegue mostrar você a página por isso. Não “a página não existe”, não “você não tem permissão”, não “volte mais tarde” - apenas um honesto, pouco útil “algo quebrou aqui, e não foi sua culpa.”

A palavra a notar é internal. Este é o servidor falando sobre si mesmo, não sobre uma rede, uma permissão, ou algo que você fez. Ele executou sua solicitação, encontrou um erro que não sabia como lidar, e a única coisa verdadeira que restava dizer era 500. É por isso que a mensagem é tão vaga: o servidor não está escondendo o detalhe para ser difícil, está recusando vazar seus próprios internos para um estranho.

Por Que Não Mostra Nada

Um 500 é o erro mais genérico da web de propósito. Quando uma aplicação falha de uma forma que não antecipou - uma exceção que ninguém capturou, uma consulta que explodiu, um null onde um objeto era esperado - a coisa segura a mostrar ao mundo externo é uma parede em branco. Os detalhes do que quebrou, o stack trace, o número da linha, a consulta que falhou, tudo fica no servidor, em um log, onde apenas as pessoas que executam o site podem lê-lo.

Portanto, o 500 que você vê e a razão para isso vivem em dois lugares diferentes. O navegador tem o código; o servidor tem a causa. Esse gap é toda a dificuldade de um 500, e é por isso que “recebi um 500” é um relatório que diz a um desenvolvedor quase nada por si só.

500 Contra 502 e 504, Que Parecem os Mesmos de Fora

Todos os três são a família de “deu errado do nosso lado” do servidor, e diferenciá-los aponta para causas muito diferentes.

500 Internal Server Error

A aplicação executou e seu próprio código falhou - uma exceção não tratada, uma queda dentro da solicitação. O servidor respondeu; a resposta foi um erro que ele mesmo cometeu

502 Bad Gateway

Um servidor front recebeu uma resposta inutilizável da aplicação atrás dele - caiu, recusou, mal formada. A falha está entre dois servidores

504 Gateway Timeout

A aplicação não respondeu em tempo algum. O servidor front desistiu de esperar

Mais ou menos: um 500 é a aplicação falhando enquanto executa, um 502 é um proxy falhando em obter uma boa resposta dela, e um 504 é a aplicação sendo muito lenta para responder. Se você recebeu um 500, o código executou e quebrou; se recebeu um 502 ou 504, muitas vezes nunca terminou de executar. Essa distinção é a primeira coisa que vale a pena saber, porque decide se você olha nos logs da aplicação ou no encanamento na frente deles.

Se Você É o Visitante

Recarregue uma vez, porque um bom número de 500s é um único momento ruim - uma solicitação que acertou uma condição de corrida, uma consulta que expirou sob uma explosão - e a próxima tentativa pousa em algum lugar saudável. Se for resolvido, não há nada para perseguir.

Se persistir, a culpa está do lado do site, e genuinamente não há nada no seu navegador que chegue a um bug no código deles. Limpar seu cache, tentar incógnito, trocar navegadores - nada disso toca o servidor, e cada um é meia hora comum gasta tratando um 500 como se fosse um problema que você pudesse corrigir do seu lugar. A única coisa útil que você pode fazer é dizer a eles, com detalhes suficientes para que encontrem a linha correspondente em seu log: o que você estava fazendo e aproximadamente quando.

Se É Seu Site

Um 500 significa que seu código lançou algo que não tratou, então a pergunta é apenas o quê, e a resposta está em seus logs em vez de na resposta que o usuário viu. Algumas causas representam a maioria delas.

Uma exceção não tratada na solicitação. A mais comum de longe. Um método chamado em um nil, uma chave que não estava lá, um tipo que não era o que o código assumiu. A solicitação chegou ao seu código, seu código lançou, e nada a capturou. Seu log de aplicação tem o stack trace; o 500 do usuário não.

Uma chamada de banco de dados com falha. Uma consulta contra uma coluna que foi renomeada, um pool de conexão esgotado sob carga, uma migração que rodou em um servidor e não em outro. Estes frequentemente chegam em explosões, porque rastreiam carga ou uma deploy em vez de uma única entrada.

Um problema de configuração ou ambiente. Uma variável de ambiente ausente, um segredo que não foi definido, um serviço que o app espera alcançar e não consegue. Estes são os que transformam cada solicitação em um 500 de uma vez, geralmente logo após uma deploy ou uma mudança de infraestrutura, e parecem alarmantes precisamente porque nada no código mudou - o chão embaixo dele mudou.

Uma deploy ruim. Novo código que lança em um caminho que os testes não cobriram, ou inicializa contra um schema que ainda não está lá. Se os 500s começaram em um lançamento, é o primeiro lugar para olhar, e um rollback é mais rápido do que um diagnóstico.

A Razão pela Qual um 500 é Tão Difícil de Rastrear Depois

O erro que o usuário viu não carrega nenhuma da causa, então um 500 relatado uma hora depois, de memória, é próximo de inútil: você tem um código genérico e um tempo aproximado, e está fazendo grep em um log para uma agulha que só pode descrever como “por volta das três da tarde.” O stack trace que teria nomeado o bug está em uma linha de log que ninguém capturou contra a solicitação que a produziu.

O que fecha um 500 rapidamente é a solicitação que o causou, seu tempo exato, e o que a pessoa estava fazendo - capturado enquanto acontecia, para que você possa combiná-lo com a única linha de log que tem o erro real nela. Essa é a diferença entre um bug que você encontra em um minuto e um log que você rola por uma tarde.

O log de rede mantém a solicitação com falha com seu 500 e o momento exato em que aconteceu, então quem pega o relatório pode alinhá-lo com o log do servidor e ler o erro real - em vez de reproduzir tudo primeiro para descobrir o que um código genérico estava escondendo.

Em Um Parágrafo

Um erro 500 Internal Server Error significa que a aplicação executou sua solicitação e seu próprio código falhou de uma forma que não tratou, então mostrou a única resposta segura e genérica que tinha - o que o torna diferente de um 502, onde um proxy não conseguiu obter uma boa resposta do app, e um 504, onde o app era muito lento para responder. Se você é um visitante, recarregue uma vez e então assuma que é do lado deles. Se é seu, a causa está em seus logs, não na resposta: suspeite de uma exceção não tratada, uma consulta que falhou, uma configuração ausente, ou a última deploy - e capture a solicitação com falha enquanto você a tem, porque um 500 não diz nada por si só.