Erro ao estabelecer conexão com o banco de dados no WordPress: como resolver

Você carrega o seu site e cada página — tanto a parte pública quanto o wp-admin — é substituída por uma única frase cinza: Erro ao estabelecer uma conexão com o banco de dados. Nada é renderizado, porque nada pode ser. O WordPress nem chegou a construir uma página.

Este é o modelo mental que torna a correção rápida. O WordPress guarda todo o seu conteúdo — posts, páginas, configurações, usuários — em um banco de dados MySQL, não em arquivos. A cada requisição, ele lê quatro credenciais de acesso do wp-config.php, conecta-se a esse banco de dados e puxa o que precisa. Este erro significa que essa conexão foi tentada e recusada. A solução consiste em descobrir por que ela foi recusada, e há apenas três possibilidades.

As três causas, em ordem de probabilidade

1. Uma credencial errada no wp-config.php: o resultado habitual de trocar de hospedagem.
2. O servidor de banco de dados está fora do ar ou sobrecarregado: o resultado habitual de nada ter mudado do seu lado.
3. O banco de dados está corrompido: menos comum, e se manifesta de outra forma.

Percorra-as nessa ordem.

Passo 1: confira as quatro credenciais

Abra o wp-config.php na raiz do seu site via SFTP ou pelo gerenciador de arquivos da sua hospedagem. Quatro linhas definem a conexão:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Cada uma delas precisa corresponder exatamente ao que a sua hospedagem atribuiu. Abra a seção de banco de dados do painel de controle da sua hospedagem (no cPanel é “MySQL Databases”) e compare caractere por caractere:

• DB_NAME: as hospedagens costumam prefixar o nome com o da sua conta, como cpaneluser_wpdb. O prefixo faz parte do nome.
• DB_USER: o mesmo prefixo se aplica, e o usuário precisa estar atribuído a esse banco de dados, não apenas existir.
• DB_PASSWORD: o culpado mais comum, de longe. Se estiver em dúvida, redefina-a no painel de controle e cole o novo valor. Fique atento a um espaço no final ou a uma aspa tipográfica.
• DB_HOST: não presuma localhost. Muitas hospedagens usam um servidor de banco de dados dedicado com um endereço como mysql.yourhost.com, às vezes com um :port. O painel de controle mostra o valor correto.

Como este arquivo é justamente onde vivem esses quatro valores, a forma mais segura de regenerar um wp-config.php limpo e com as aspas corretas é o gerador de wp-config.php: preencha os quatro campos do banco de dados e cole o resultado sobre o bloco antigo.

Este passo, sozinho, corrige o erro depois de quase toda migração, porque credenciais que estavam certas na hospedagem antiga estão erradas na nova.

Passo 2: confirme que o servidor de banco de dados está realmente no ar

Se as credenciais estão corretas e o erro persiste — especialmente se ele apareceu sozinho, sem nenhuma mudança da sua parte — o suspeito é o próprio servidor de banco de dados.

Em hospedagem compartilhada isso é comum e geralmente temporário: o serviço MySQL fica sobrecarregado durante um pico de tráfego ou atinge o limite de conexões por conta e começa a recusar novas conexões. Costuma se recuperar em poucos minutos. Recarregue depois de uma breve espera antes de fazer qualquer coisa drástica.

Para testar se as credenciais são sequer válidas, independentemente do WordPress, largue um pequeno script ao lado do wp-config.php:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Use seus DB_HOST, DB_USER e DB_PASSWORD reais. Se imprimir Connected, suas credenciais funcionam e o problema está em outro lugar (um banco de dados corrompido, passo 3). Se imprimir um erro de conexão, a mensagem diz qual: “Access denied” significa usuário ou senha errados; “Can’t connect to MySQL server” significa host errado ou serviço realmente fora do ar — hora de contatar sua hospedagem. Apague o script assim que terminar.

Passo 3: repare um banco de dados corrompido

Um sinal separa a corrupção de um problema de conexão: a parte pública carrega, mas o wp-admin mostra o erro, ou o contrário. Se a conexão estivesse de fato recusada, ambas estariam fora do ar. Uma divisão dessas aponta para tabelas danificadas.

O WordPress tem uma ferramenta de reparo integrada. Adicione uma linha ao wp-config.php, acima do comentário “stop editing”:

define( 'WP_ALLOW_REPAIR', true );

Depois acesse esta URL diretamente no seu navegador:

https://yoursite.com/wp-admin/maint/repair.php

Ela carrega sem login — esse é justamente o ponto, já que você pode estar trancado do lado de fora — e oferece “Repair Database” e “Repair and Optimize Database”. Execute.

Depois apague imediatamente essa linha do wp-config.php. Enquanto ela estiver presente, qualquer pessoa na internet pode acessar essa URL e executar um reparo no seu banco de dados. Isso não é uma limpeza opcional; é fechar uma brecha que você acabou de abrir.

Passo 4: quando o reparo nem sequer conecta

Se a própria página de reparo mostrar o erro de conexão, não há nada a reparar — o banco de dados está totalmente inacessível, então você volta ao passo 1 ou ao passo 2. Nesse ponto, a jogada confiável é restaurar o banco de dados a partir do backup mais recente da sua hospedagem. A maioria dos painéis de controle mantém snapshots diários automáticos do banco de dados; uma restauração de ontem à noite é quase sempre mais rápida e segura do que perseguir uma corrupção à qual você não consegue se conectar.

Conselhos que você pode ignorar tranquilamente

“Reinstale o WordPress e pronto.” Este erro é sobre a conexão com o banco de dados, não sobre os arquivos do núcleo. Reinstalar substitui justamente os arquivos que estão funcionando bem e não toca em nada que esteja quebrado.

“Aumente o limite de memória do PHP.” O esgotamento de memória é um erro diferente, com uma mensagem diferente. Aumentar o limite não faz nada por uma conexão de banco de dados recusada e apenas esconde o fato de que você nunca conferiu as credenciais.

“Limpe o cache.” A falha acontece no PHP antes que qualquer cache possa servir uma página. Limpar o cache não muda nada enquanto a conexão está recusada; só vale a pena fazer isso depois que o site voltar.

“Edite o banco de dados diretamente para consertar.” Recorrer ao phpMyAdmin para editar tabelas à mão antes de confirmar que a conexão sequer funciona é como uma queda temporária vira perda de dados permanente. Confirme primeiro a conexão; toque nos dados por último, e apenas a partir de um backup.

Ainda travado?

Se as credenciais se confirmam com o script de teste, o servidor está no ar, e o reparo conecta e não relata erros, mas o site ainda mostra a mensagem, o suspeito restante é um plugin que fala com o banco de dados por sua própria conexão — um plugin de cache ou de banco de dados que guardou um host obsoleto. Renomeie wp-content/plugins para plugins-off via SFTP para descartá-lo. Se o erro sumir, reintroduza os plugins um de cada vez até ele voltar.