Dicas e Soluções

Admin do Magento 2 não abre? Corrija 404, loop de login e tela branca

Especialista investigando falha de acesso ao Admin do Magento em corredor de servidores

Admin do Magento 2 não abre? Corrija 404, loop de login e tela branca

O Admin do Magento 2 não abre, retorna erro 404, volta repetidamente para o formulário de login ou exibe apenas uma tela branca? Embora todos esses sintomas impeçam o acesso ao painel, eles apontam para camadas diferentes da loja. A causa pode estar na rota administrativa, nos cookies, no armazenamento de sessões, no servidor web, em uma extensão ou em um erro fatal do PHP.

Antes de limpar todos os caches ou executar uma atualização, identifique exatamente o que acontece. O roteiro abaixo ajuda a separar os cenários e escolher verificações que preservam logs e reduzem o risco de piorar a indisponibilidade.

Primeiro, classifique o erro do Admin

Abra o painel em uma janela anônima e registre a URL, o horário e a mensagem exibida. Se possível, compare o resultado em outro navegador e outra conexão. Essa triagem simples evita tratar uma falha local de cookie como indisponibilidade geral.

  • Erro 404 antes do login: confirme a rota administrativa e as regras do servidor web.
  • Login volta para a mesma página: investigue cookies, HTTPS, sessões e balanceadores.
  • Tela branca ou erro 500: procure exceções do Magento e erros fatais do PHP.
  • Página sem CSS ou JavaScript: verifique arquivos estáticos, permissões, URL base e publicação do deploy.
  • Admin e loja estão indisponíveis: avalie manutenção, PHP-FPM, banco de dados e serviços de infraestrutura.

Não compartilhe publicamente a rota do Admin, credenciais, cookies, tokens ou trechos de configuração com segredos. Ao anexar logs a um chamado, remova esses dados antes.

Admin do Magento 2 não abre com erro 404

1. Confirme a rota administrativa correta

A URL do painel pode ter sido personalizada e não ser simplesmente /admin. No diretório da instalação, consulte a rota configurada:

php bin/magento info:adminuri

Use o resultado apenas em ambiente controlado. Se o comando falhar, preserve a mensagem: ela pode revelar um problema de inicialização da aplicação, permissões ou dependências, e não necessariamente uma rota incorreta.

2. Compare a resposta do Magento com a do servidor web

Uma página 404 com o layout da loja indica um caminho diferente de uma resposta genérica do Nginx, Apache, CDN ou proxy. Confira também o código HTTP nas ferramentas de rede do navegador ou com uma requisição de cabeçalho feita a partir de uma máquina autorizada.

Se a resposta nem chega ao Magento, revise o virtual host, o diretório público configurado, as regras de reescrita e o encaminhamento do proxy. Alterações recentes de domínio, certificado, CDN ou estrutura de diretórios merecem atenção especial.

3. Verifique se a loja ficou em manutenção

Consulte o estado antes de remover qualquer marcador:

php bin/magento maintenance:status

Quando toda a aplicação apresenta indisponibilidade, siga um diagnóstico específico para o erro 503 e o modo de manutenção do Magento 2. Não desative a manutenção durante um deploy ainda incompleto, pois o código e o banco podem estar em estados incompatíveis.

O login do Magento volta para a mesma página

Um loop de login geralmente significa que as credenciais foram enviadas, mas a sessão administrativa não permaneceu válida. Antes de redefinir a senha, observe se aparece uma mensagem de usuário inválido. Se não houver mensagem e o formulário apenas recarregar, examine a persistência da sessão.

4. Teste cookies, domínio e HTTPS

Apague apenas os cookies do domínio da loja ou use uma janela anônima. Em seguida, confirme se o navegador aceita o cookie e se ele não é criado para um domínio, subdomínio ou caminho diferente daquele usado no acesso.

Ambientes atrás de CDN, proxy reverso ou balanceador também precisam informar corretamente ao Magento que a conexão original é HTTPS. Caso essa identificação esteja errada, podem ocorrer redirecionamentos e cookies incompatíveis com a navegação segura. Compare a URL configurada com a URL efetivamente acessada, sem mudar valores diretamente em produção antes de testar em staging.

5. Confirme se as sessões estão disponíveis

Se as sessões usam arquivos, verifique espaço em disco, permissões e capacidade de gravação. Se usam Redis ou Valkey, confirme disponibilidade, latência, autenticação e isolamento entre cache e sessões. Reiniciar ou esvaziar esse serviço encerra sessões de clientes e administradores, portanto não deve ser o primeiro teste.

Falhas nessa camada também podem esvaziar carrinhos e desconectar usuários. Para ambientes que estejam planejando mudanças de backend, consulte o guia de migração entre Redis e Valkey sem interromper cache e sessões.

Tela branca, erro 500 ou página incompleta no Admin

6. Preserve e correlacione os logs

Reproduza o erro uma vez, anote o horário e consulte os registros do Magento, do PHP-FPM e do servidor web. Entre os arquivos que podem ajudar estão:

var/log/system.log
var/log/exception.log
var/log/debug.log

Também verifique os relatórios em var/report, quando existirem. Procure pelo evento no mesmo intervalo de tempo, em vez de copiar arquivos inteiros. Uma exceção registrada horas antes pode não ter relação com a tentativa atual.

Erros de classe ausente, memória, dependência, conexão com banco ou código de extensão exigem correções diferentes. Não habilite a exibição pública de erros em produção: além de não corrigir a causa, isso pode expor caminhos internos e detalhes da aplicação.

7. Descubra se uma extensão ou deploy iniciou a falha

Verifique o que mudou imediatamente antes do problema: instalação de módulo, atualização via Composer, compilação, troca de tema, alteração de PHP ou deploy de configuração. Compare o código implantado com o artefato aprovado e confirme se o processo terminou sem erros.

Evite desabilitar módulos aleatoriamente, editar tabelas ou executar setup:upgrade como tentativa genérica. Esse comando pode alterar o esquema e os dados. Ele só deve fazer parte do procedimento quando a versão implantada realmente exigir atualização e houver backup, janela de manutenção e plano de reversão.

Se o Admin abre sem estilos, confirme se o problema ocorre apenas no painel e inspecione as requisições de CSS e JavaScript. Respostas 404 para arquivos estáticos podem indicar publicação incompleta, URL base incorreta, permissões ou versão de conteúdo divergente entre nós do ambiente.

O cache deve ser limpo?

O cache pode manter configuração antiga, mas não explica sozinho todo erro de login ou página branca. Primeiro consulte o estado:

php bin/magento cache:status

Limpe somente os tipos relacionados à mudança confirmada. Um flush amplo pode remover dados de uma instância compartilhada, aumentar a carga e esconder temporariamente o sintoma. Veja como identificar qual camada de cache do Magento 2 realmente precisa ser limpa.

Checklist antes de alterar a produção

  • Registre a URL, o código HTTP, o horário e o alcance da falha.
  • Confirme a rota administrativa pelo CLI.
  • Teste em janela anônima sem divulgar a URL do painel.
  • Verifique cookies, HTTPS e armazenamento de sessões.
  • Correlacione logs do Magento, PHP e servidor web.
  • Revise o último deploy e as extensões modificadas.
  • Faça backup e prepare reversão antes de mudanças estruturais.
  • Valide a correção em staging sempre que possível.

Perguntas frequentes

Por que o Admin do Magento 2 retorna erro 404?

As causas mais comuns incluem uso da rota administrativa errada, regras de reescrita ausentes, virtual host apontando para o diretório incorreto ou bloqueio no proxy. O comando php bin/magento info:adminuri ajuda a confirmar a rota configurada.

Por que o login do Magento apenas recarrega a página?

Esse comportamento costuma indicar que a sessão não foi mantida. Verifique cookies, domínio, HTTPS, cabeçalhos do proxy e o backend de sessões. Não reinicie Redis ou Valkey sem avaliar o impacto sobre clientes conectados e carrinhos.

Posso limpar todos os caches para recuperar o painel?

Não é recomendável começar por um flush geral. Identifique primeiro se a falha está relacionada à configuração em cache. Limpar tudo pode aumentar a carga, afetar dados compartilhados e não corrigir erros de PHP, sessão ou servidor web.

É seguro executar setup:upgrade quando o Admin não abre?

Somente quando um deploy exige atualização de esquema ou dados e existe um procedimento controlado. Executar o comando sem confirmar a causa pode modificar o banco e dificultar a reversão.

Conclusão

Quando o Admin do Magento 2 não abre, a forma mais rápida de chegar à correção é diferenciar 404, loop de login, tela branca e falha de arquivos estáticos. Preserve os registros, confira rota, cookies, sessões e deploy antes de fazer mudanças amplas. Se a indisponibilidade persistir ou afetar a operação da loja, uma análise técnica do ambiente pode localizar a camada responsável e permitir uma correção com menor impacto.