Site fora do ar: erros de servidor 500, 502 e 504 e como resolver

Problemas de site fora do ar geralmente acontecem quando o servidor não consegue processar uma solicitação, quando camadas intermediárias não recebem uma resposta válida ou quando o tempo de resposta estoura. O erro 500 costuma indicar uma falha interna genérica, normalmente ligada à aplicação ou à configuração do servidor; o erro 502 mostra que a camada de proxy ou gateway recebeu uma resposta inválida do back-end; já o erro 504 significa que o back-end não respondeu dentro do tempo esperado. Para resolver de forma definitiva, é preciso interpretar corretamente o código de erro, analisar os logs do servidor, medir o consumo de recursos, depurar falhas de PHP ou da aplicação, eliminar gargalos no banco de dados e dimensionar a infraestrutura de hospedagem de acordo com a demanda de tráfego.

Para um visitante, esses erros significam apenas uma página em branco, uma mensagem assustadora no navegador ou um site inacessível. Para uma empresa, porém, podem representar vendas perdidas, queda de confiança e sinais negativos para SEO. Em projetos com baixa tolerância a indisponibilidade, como lojas virtuais, sites institucionais, portais de notícias, plataformas de cursos ou sistemas de reserva, erros 5xx podem virar prejuízo em poucos minutos. Neste guia, vamos mostrar como diferenciar os erros 500, 502 e 504, como fazer um diagnóstico rápido e quais medidas práticas ajudam a evitar que o problema volte a acontecer.

Por que problemas de site fora do ar devem ser levados a sério?

Um site cair não é apenas uma falha técnica. A experiência do usuário, a taxa de conversão, a percepção da marca e a visibilidade nos mecanismos de busca são impactadas diretamente. O Google costuma tolerar interrupções curtas e pontuais; no entanto, erros 5xx recorrentes podem desperdiçar orçamento de rastreamento, fazer com que páginas importantes sejam visitadas com menos frequência pelos robôs e gerar oscilações de posicionamento.

Na prática, erros 5xx precisam ser tratados em dois níveis. O primeiro é a resposta emergencial: colocar o site no ar novamente o mais rápido possível. O segundo é a análise da causa raiz: entender por que o mesmo erro aparece em momentos de pico, durante a execução de um cron, depois da atualização de um plugin ou quando a carga no banco de dados aumenta. Reiniciar um serviço pode trazer alívio temporário, mas, se o problema principal não for corrigido, a falha pode voltar algumas horas depois.

Imagine, por exemplo, uma loja WooCommerce que lança uma campanha e vê o uso de CPU chegar a 95%, a fila do PHP-FPM lotar e o banco de dados travar por causa de consultas lentas. Nesse cenário, visitantes podem encontrar erros 500 ou 504 ao tentar ver produtos ou finalizar pedidos. Instalar apenas um plugin de cache talvez não seja suficiente; pode ser necessário otimizar consultas, contratar um plano de hospedagem mais robusto, usar CDN, ativar cache de objetos e revisar limites de recursos em conjunto. Para projetos em crescimento, vale comparar opções de hospedagem adequadas ao tráfego em Pacotes de hosting web Hostragons e, para demandas com mais recursos dedicados, avaliar Hostragons Soluções de servidor VPS.

Principais diferenças entre erros 500, 502 e 504

Embora 500, 502 e 504 pertençam à mesma família de erros 5xx, eles não significam a mesma coisa. Um diagnóstico errado leva a uma correção errada. A tabela abaixo resume rapidamente as diferenças mais comuns.

Essa distinção é especialmente importante em ambientes que usam Nginx, Apache, LiteSpeed, PHP-FPM, Node.js, proxy reverso, CDN e balanceadores de carga. O usuário pode ver um 502 no navegador, enquanto o problema real está no serviço PHP-FPM que caiu. Da mesma forma, um erro 504 pode não ser culpa direta do servidor web, mas de uma API externa de pagamento que demora mais de 30 segundos para responder.

500 Internal Server Error: causas e passos para resolver

O que significa erro 500?

O erro 500 Internal Server Error indica que o servidor não conseguiu processar a solicitação, mas também não conseguiu explicar a falha com um código mais específico. Por isso, o erro 500 abre um leque grande de possibilidades. Ele pode aparecer em WordPress, Laravel, sistemas PHP próprios, projetos Python ou aplicações Node.js por motivos diferentes. Como a mensagem exibida ao usuário traz pouca informação, as pistas reais quase sempre estão nos arquivos de log.

Causas mais comuns do erro 500

• Regras incorretas no .htaccess: RewriteRule mal escrita, redirecionamento em loop ou diretivas não suportadas podem causar erro 500.
• Erro fatal de PHP: Função inexistente, versão de PHP incompatível, limite de memória estourado ou tema/plugin com falha podem derrubar o site.
• Permissões de arquivos e pastas: Arquivos PHP com permissões inseguras ou incorretas, como 777, podem ser bloqueados pelo servidor.
• Dependências ausentes: Pacotes do Composer, módulos PHP ou arquivos de cache do framework podem estar faltando.
• Limites de recursos do servidor: CPU, RAM, entry processes ou limites de I/O excedidos podem interromper a solicitação no meio do caminho.

Como corrigir erro 500?

Antes de tudo, evite agir no escuro. Monte uma linha do tempo das alterações recentes. Se o erro começou depois de atualizar um plugin, editar o tema, trocar a versão do PHP, adicionar uma nova regra no .htaccess ou durante um pico de acessos, o campo de investigação fica bem menor. Em seguida, siga estes passos:

• 1. Verifique os logs: No cPanel, Plesk ou painel do seu servidor, analise o arquivo error_log. Linhas com fatal error, memory exhausted, permission denied ou syntax error costumam apontar diretamente para a causa.
• 2. Desfaça a última alteração: Desative o plugin, tema ou trecho de código adicionado recentemente. No WordPress, renomear temporariamente a pasta de plugins é um teste rápido e eficaz.
• 3. Teste o arquivo .htaccess: Salve o arquivo atual com outro nome temporariamente e gere regras padrão. Se o erro desaparecer, o problema está em um redirecionamento ou regra de rewrite.
• 4. Confira versão e limites do PHP: Se sua aplicação não for compatível com PHP 8.2, por exemplo, ela pode retornar erro 500. Ajuste memory_limit, max_execution_time e post_max_size de acordo com a necessidade do projeto.
• 5. Corrija permissões de arquivos: Como prática geral, usa-se 755 para pastas e 644 para arquivos. Para casos específicos, siga as orientações do seu provedor de hospedagem.
• 6. Planeje a restauração de backup: Se o site em produção estiver totalmente inacessível, voltar para o último backup íntegro pode restabelecer o serviço antes da análise profunda. Por isso, backups regulares são indispensáveis.

Se o erro 500 se repete com frequência, não basta olhar apenas para a aplicação. É importante verificar quantos processos PHP rodam ao mesmo tempo, qual é o consumo médio de memória, quantas conexões o banco de dados recebe e se existe latência de I/O no disco. Em ambientes de hospedagem compartilhada, os limites de recursos podem não acompanhar o crescimento do site. Nesses casos, vale avaliar Hosting WordPress Hostragons ou planos com recursos mais isolados.

502 Bad Gateway: entendendo falhas de proxy e upstream

O que significa erro 502?

O erro 502 Bad Gateway informa que a camada de gateway ou proxy entre o cliente e o serviço de back-end não recebeu uma resposta válida. Em arquiteturas modernas de hospedagem, o Nginx costuma funcionar como proxy reverso: encaminha requisições PHP para o PHP-FPM, requisições Node.js para a porta da aplicação ou solicitações específicas para outro serviço upstream. Se algum serviço dessa cadeia estiver parado, sobrecarregado ou configurado para uma porta errada, o erro 502 pode aparecer.

Causas típicas do erro 502

• Serviço PHP-FPM parado ou sem acesso ao arquivo de socket.
• Aplicação Node.js, Python ou Java não rodando na porta em que deveria escutar.
• IP, porta ou caminho de socket incorreto na definição de upstream do Nginx.
• CDN ou firewall sem conseguir receber a resposta esperada do servidor de origem.
• Memória RAM do servidor esgotada, levando ao encerramento de processos e à queda de serviços de back-end.

Plano prático para resolver erro 502

No erro 502, o primeiro objetivo é descobrir qual camada da cadeia deixou de responder corretamente. A sequência abaixo é uma das abordagens que costuma gerar resultado mais rápido em atendimentos técnicos reais:

• Verifique o status dos serviços: Confirme se PHP-FPM, servidor web, banco de dados e serviços da aplicação estão em execução. Em VPS ou servidor dedicado, comandos systemctl status ajudam nessa checagem.
• Compare os logs de upstream: Analise o log de erro do Nginx junto com os logs do PHP-FPM ou da aplicação no mesmo horário. Mensagens como Connection refused, upstream prematurely closed connection ou no live upstreams são pistas importantes.
• Observe o uso de recursos: Se a RAM estiver acima de 90% e o swap estiver sendo muito usado, os serviços podem demorar ou falhar ao responder. Carga de CPU muito acima do número de núcleos também gera filas.
• Confirme configurações de socket e porta: Se o Nginx aponta para 127.0.0.1:9000, mas o PHP-FPM escuta em um socket diferente, o erro 502 será praticamente inevitável.
• Teste a camada de CDN: Faça um bypass temporário da CDN e acesse diretamente o servidor de origem. Se o problema aparece apenas via CDN, revise DNS, SSL e configurações de conexão com a origem.

O erro 502 também pode estar relacionado à configuração de SSL. Se a comunicação entre CDN e origem usa HTTPS, mas o certificado do servidor de origem expirou ou pertence a outro domínio, erros de gateway podem surgir. Para configurar a camada SSL de forma segura e correta, consulte as opções em Certificados SSL Hostragons e o material guia de instalação do certificado SSL.

504 Gateway Timeout: como resolver problemas de tempo limite de forma definitiva

O que significa erro 504?

O erro 504 Gateway Timeout indica que a camada de proxy ou gateway não recebeu uma resposta do serviço de back-end dentro do período definido. Isso não significa necessariamente que o serviço esteja completamente fora do ar; ele pode apenas estar respondendo devagar demais. Por isso, o erro 504 costuma apontar para problemas de performance, banco de dados, APIs externas ou processos de longa duração.

Causas frequentes do erro 504

• Consultas lentas no banco de dados: Falta de índices, varreduras em tabelas grandes ou bloqueios aumentam o tempo de resposta.
• Atrasos em APIs externas: Serviços de pagamento, frete, CRM ou estoque podem deixar a requisição web aguardando por muito tempo.
• Latência de rede: Se aplicação e banco de dados ficam em regiões diferentes, a latência pode se tornar crítica.
• Cron ou importações demoradas: Importação de CSV, envio de e-mails em massa ou geração de relatórios podem deixar as requisições dos usuários mais lentas.
• Configurações de timeout insuficientes: Nginx, Apache, PHP-FPM e aplicação podem ter tempos limite incompatíveis entre si.

Como corrigir erro 504?

No caso do 504, simplesmente aumentar os timeouts costuma apenas esconder o sintoma. Por exemplo, dar 120 segundos para uma consulta que não termina em 30 segundos pode reduzir a mensagem de erro, mas não melhora a experiência do usuário. A abordagem correta é medir onde está a lentidão e acelerar esse ponto.

• 1. Separe o tempo de resposta por etapa: Meça tempo da aplicação, tempo do banco de dados, tempo de API externa e tempo de espera no servidor separadamente.
• 2. Ative o slow query log: No MySQL ou MariaDB, registre consultas que passam de 1 segundo. Para consultas lentas recorrentes, adicione índices ou reescreva a lógica.
• 3. Leve tarefas pesadas para segundo plano: Geração de relatórios, processamento de imagens, envio de e-mails e sincronização de estoque devem rodar por filas, não dentro da requisição do usuário.
• 4. Use cache: Cache de página, cache de objetos e OPcache reduzem significativamente a carga de processamento em aplicações dinâmicas.
• 5. Alinhe os valores de timeout: proxy_read_timeout, fastcgi_read_timeout, max_execution_time e timeouts da aplicação não devem entrar em conflito.
• 6. Defina limites para APIs externas: Se uma API não responder, não deixe o usuário esperando indefinidamente. Use estratégias de retry, fallback e timeouts curtos.

Em um cenário real, uma página de listagem de produtos pode filtrar 60 mil itens sem índice no campo de categoria. Durante uma campanha, isso aumenta a chance de erros 504. Adicionar índices, armazenar resultados de filtros em cache e otimizar consultas pesadas pode resolver o problema sem aumentar recursos imediatamente. Porém, se o crescimento do tráfego for permanente, talvez seja necessário escalar a infraestrutura.

Checklist de 10 passos para diagnóstico rápido

Quando um site cai de repente, agir de forma desorganizada faz perder tempo. A lista abaixo ajuda a investigar erros 500, 502 e 504 de maneira sistemática:

• 1. Confira se o erro acontece para todos ou apenas para você: Teste em outra rede, pelo celular e com ferramentas externas de uptime.
• 2. Confirme o código de status HTTP: Use as ferramentas de desenvolvedor do navegador ou um comando como curl -I https://seudominio.com para ver o código real.
• 3. Liste as alterações recentes: Houve deploy de código, atualização de plugin, mudança de DNS, renovação de SSL, troca de versão do PHP ou ajuste de servidor?
• 4. Leia os logs do servidor web: Registros de erro do Apache, Nginx ou LiteSpeed são a primeira fonte a consultar.
• 5. Analise os logs da aplicação: WordPress debug log, logs em storage do Laravel ou logs de processos Node.js ajudam a identificar a origem.
• 6. Meça os recursos do servidor: CPU, RAM, espaço em disco, inodes, I/O de disco e número de conexões devem ser avaliados em conjunto.
• 7. Verifique o banco de dados: O limite de conexões foi atingido? Existem consultas bloqueadas? As consultas lentas aumentaram?
• 8. Teste firewall e CDN: Regras de WAF, filtros de bots ou conexão da CDN com a origem podem estar se comportando de forma incorreta.
• 9. Tenha o backup pronto: Se um arquivo crítico foi corrompido ou uma atualização falhou, você precisa de um plano rápido de restauração.
• 10. Crie um relatório de causa raiz: Depois de resolver, documente horário, impacto, causa, solução e medidas para evitar repetição.

Essa lista é especialmente útil para dividir responsabilidades dentro da equipe. Ao entrar em contato com o provedor de hospedagem, informar horário do erro, URL afetada, código exibido, última alteração realizada e, se possível, um print da tela reduz bastante o tempo de solução. Para problemas de acesso relacionados a domínio, DNS e redirecionamentos, recursos como Consulta de domínio e registro Hostragons e Guia de gestão de DNS também podem ajudar no diagnóstico.

Como interpretar corretamente os recursos do servidor

Uma parte significativa dos erros 5xx está ligada a gargalos de recursos. Porém, CPU alta nem sempre significa código ruim; às vezes o problema é um volume inesperado de tráfego orgânico, um ataque de bots, um cron mal configurado ou uma rotina de backup pesada. Por isso, as métricas não devem ser analisadas isoladamente, mas sim junto com a linha do tempo dos eventos.

Métricas essenciais para monitorar

• Uso de CPU: Uso constante acima de 80% aumenta o risco de filas e atrasos.
• RAM e swap: Quando o uso de swap cresce, os processos ficam mais lentos e erros 502 ou 504 podem ser disparados.
• I/O de disco: Escrita intensa de logs, backups grandes ou operações de banco de dados podem causar espera de I/O.
• Entry process e conexões simultâneas: Em hospedagem compartilhada, limites de processos simultâneos podem se transformar em erro 500.
• Conexões do banco de dados: Chegar perto do limite max_connections aumenta a chance de falhas na aplicação.
• TTFB: Aumento constante no tempo até o primeiro byte é um aviso precoce antes de erros 504.

Você pode usar uma abordagem simples de limite: se em períodos normais o TTFB fica entre 300 e 600 ms, mas durante uma campanha sobe para 5 ou 10 segundos, é melhor planejar capacidade antes que o erro apareça para o usuário. Monitoramento de uptime, análise de logs e medição de performance, quando usados em conjunto, permitem perceber o problema antes que ele cresça.

Medidas permanentes na aplicação, no banco de dados e na hospedagem

O que fazer na camada da aplicação

Qualidade e atualização do código são uma das defesas mais fortes contra problemas de site fora do ar. Remova plugins que não são usados, escolha temas e extensões de fontes confiáveis e teste a compatibilidade com versões de PHP em um ambiente separado. Em vez de alterar diretamente o site em produção, usar um ambiente de staging ajuda a detectar erros 500 antes que eles afetem visitantes reais.

• Não exiba mensagens de depuração para usuários em produção; grave-as em arquivos de log.
• Antes de atualizar, faça backup completo dos arquivos e do banco de dados.
• Separe processos demorados da requisição feita pelo usuário.
• Otimize imagens e reduza scripts desnecessários.
• Analise tráfego de bots; limite bots maliciosos ou excessivos com WAF.

O que fazer na camada do banco de dados

A performance do banco de dados é crítica, especialmente em WordPress, WooCommerce, fóruns, áreas de membros e sistemas com muito conteúdo dinâmico. Em sites com milhares de produtos, pedidos, comentários ou registros de log, o crescimento das tabelas pode aumentar a quantidade de consultas lentas. Manutenção regular, revisão de índices e limpeza de dados desnecessários reduzem o risco de erro 504.

• Use o slow query log para encontrar as consultas mais custosas.
• Adicione índices corretos em colunas filtradas com frequência.
• Limpe opções desnecessárias carregadas automaticamente.
• Arquive periodicamente revisões antigas, registros temporários e tabelas de log.
• Programe backups do banco de dados para horários de menor movimento.

O que fazer na camada de hospedagem

Se a infraestrutura de hospedagem for mal dimensionada, até um site bem otimizado pode sofrer em momentos de tráfego intenso. Um site institucional simples e uma loja virtual de alto tráfego não têm a mesma necessidade de recursos. Tráfego, número de transações, proporção de páginas dinâmicas, uso de e-mail, tamanho do banco de dados e necessidades de segurança devem ser avaliados em conjunto.

• Para sites pequenos e médios, planos de hospedagem fáceis de gerenciar podem ser suficientes.
• Sites com muitas operações dinâmicas tendem a funcionar melhor em VPS com CPU e RAM isoladas.
• Em projetos corporativos, backup regular, SSL, WAF e monitoramento de uptime devem ser padrão.
• Registros DNS devem ser mantidos simples, removendo cadeias de redirecionamento desnecessárias.
• Se houver CDN, o servidor de origem, o SSL e as regras de cache precisam estar configurados corretamente.

Ao fazer essa análise, olhar apenas para espaço em disco pode levar a uma decisão errada. Um site que usa 2 GB de disco pode consumir mais CPU do que outro com 20 GB, caso tenha muitos usuários simultâneos e páginas dinâmicas. Por isso, a escolha do plano deve considerar tráfego real e carga de processamento, não somente armazenamento.

O que fazer com erros 5xx do ponto de vista de SEO?

Mecanismos de busca não costumam penalizar imediatamente erros 5xx temporários. Porém, interrupções recorrentes afetam rastreamento e indexação. Se o Googlebot encontra respostas 500, 502 ou 504 com frequência em páginas importantes, pode reduzir a frequência de rastreamento. Além disso, quando usuários clicam em um resultado orgânico e encontram erro, a confiança e a conversão diminuem.

Para reduzir o risco de SEO, use monitoramento de uptime em páginas críticas, acompanhe as estatísticas de rastreamento no Search Console e analise, nos logs do servidor, os códigos retornados para solicitações do Googlebot. Em manutenções planejadas, é melhor retornar um 503 Service Unavailable curto e configurado corretamente do que deixar o site gerar erros 500 não planejados. Uma página de manutenção com cabeçalho Retry-After informa aos mecanismos de busca quando tentar novamente.

Especialmente em migrações de site, troca de domínio ou mudança para HTTPS, redirecionamentos mal configurados e problemas de certificado podem causar falhas de acesso parecidas com erros 5xx. Antes da migração, reduza o TTL do DNS, faça backup, teste em um domínio ou subdomínio de validação e acompanhe os logs após a troca. Esse procedimento simples evita surpresas no momento em que o tráfego real chega ao novo ambiente.

Quando procurar o suporte de hospedagem?

Alguns erros podem ser resolvidos pelo administrador do site; outros exigem acesso ao servidor e conhecimento técnico mais avançado. Nas situações abaixo, é recomendável acionar rapidamente o suporte de hospedagem:

• O erro afeta todo o site e o painel administrativo também está inacessível.
• Os logs exibem linhas como permission denied, upstream failed ou resource limit exceeded.
• PHP-FPM, servidor web ou serviço de banco de dados caem repetidamente.
• Com a CDN desligada o site abre, mas com a CDN ligada retorna 502 ou 504.
• Os limites de recursos são atingidos com frequência e não está claro qual plano é o mais adequado.
• O acesso parou de funcionar depois de mudanças em SSL, DNS ou firewall.

Ao abrir um chamado, incluir as seguintes informações acelera muito a solução: horário de início do erro, URLs afetadas, código de erro exibido, últimas alterações feitas, captura de tela, linhas de log se houver e se o problema é contínuo ou intermitente. Esses dados ajudam a equipe técnica a reproduzir o problema e investigar a camada correta.

Perguntas frequentes

Erro 500 significa que meu site foi hackeado?

Não. O erro 500, sozinho, não é sinal de invasão. Na maioria dos casos, ele aparece por erro de PHP, conflito de plugin, regra incorreta no .htaccess, permissão de arquivo ou limite de recursos. No entanto, se o erro vier acompanhado de alterações inesperadas em arquivos, redirecionamentos suspeitos ou contas de usuários desconhecidas, é recomendável fazer uma varredura de segurança.

O erro 502 Bad Gateway pode ser causado pelo usuário?

Geralmente, não. O erro 502 quase sempre indica um problema de comunicação em alguma camada do servidor, proxy, CDN ou serviço de back-end. O usuário pode limpar o cache do navegador e testar em outra rede, mas, se o erro aparece para todos, a solução deve ser procurada no lado do servidor.

Para erro 504 Gateway Timeout, basta aumentar o timeout?

Às vezes isso traz alívio temporário, mas não é uma solução definitiva. No erro 504, o objetivo principal é encontrar a causa raiz, como consulta lenta, atraso de API externa, uso intenso de CPU ou processo de longa duração. O aumento de timeout deve ser aplicado com cuidado e junto com otimização de performance.

Erros 5xx derrubam minhas posições no Google imediatamente?

Interrupções curtas e raras geralmente não causam perda permanente de posicionamento. Porém, se erros 5xx se repetem com frequência, páginas importantes ficam inacessíveis por muito tempo ou o Googlebot encontra falhas de servidor regularmente, a frequência de rastreamento e o desempenho orgânico podem ser afetados.

Qual é o hábito mais importante para evitar que um site fique fora do ar?

O hábito mais importante é combinar monitoramento constante com boa gestão de mudanças. Acompanhamento de uptime, backups, revisão de logs, testes em staging, softwares atualizados e monitoramento de recursos, quando aplicados juntos, evitam que boa parte dos erros 500, 502 e 504 se transforme em uma indisponibilidade grave.

Resumo rápido e próximo passo

Embora os erros 500, 502 e 504 façam parte da mesma família, eles apontam para camadas diferentes: 500 costuma indicar falha de aplicação ou configuração; 502 aponta para problema de comunicação entre proxy e upstream; 504 está ligado a timeout e gargalos de performance. A solução correta passa por confirmar o código de erro, ler logs, medir recursos, revisar alterações recentes e aplicar otimizações permanentes.

Se o seu site sofre com problemas de site fora do ar com frequência, vale analisar em conjunto os recursos atuais de hospedagem, a configuração de SSL e DNS e a performance da aplicação. Para encontrar uma infraestrutura adequada à sua necessidade ou conversar com uma equipe técnica sobre as melhores opções, você pode conhecer as soluções da Hostragons; o objetivo é construir uma experiência web mais rápida, segura e resistente a interrupções.