Você tenta entrar no painel e o WordPress devolve um 403. Ou a tela de login recarrega sozinha, como se a senha nunca estivesse certa. Ou o admin abre em branco, sem mensagem de erro. Em todos esses casos, a suspeita inicial costuma cair em plugins de segurança WordPress, mas o culpado nem sempre é o que você imagina. Pode ser o firewall do próprio plugin bloqueando seu IP, uma regra de país mal configurada, o limite de tentativas de login que travou você mesmo, ou dois plugins de segurança disputando a mesma requisição. O sintoma é parecido; a causa e a solução são bem diferentes.
Os três sintomas que chegam como conflito
Antes de sair desativando plugin, vale separar o que você está vendo. Cada sintoma aponta para uma origem provável.
| Sintoma | Causa provável | Onde olhar primeiro |
|---|---|---|
| 403 no /wp-admin ou /wp-login.php | Firewall do plugin bloqueando seu IP ou user-agent | Log de bloqueios do plugin de segurança |
| Login em loop, sem erro | Dois plugins mexendo em cookies de sessão ou nonce | Cookies no navegador e ordem de plugins |
| Tela branca no admin, site público ok | Conflito de hooks entre plugins, ou fatal error silencioso | WP_DEBUG e log de erros do PHP |
Na prática, o 403 raramente é conflito: é bloqueio. O login em loop costuma ser conflito. A tela branca pode ser qualquer um dos dois, e por isso é o caso que exige mais cuidado no diagnóstico.
Plugins de segurança WordPress: teste rápido para saber se é o plugin ou o servidor
Antes de desativar qualquer coisa, faça este teste. Ele evita que você mexa em plugin quando o problema está no Nginx, no ModSecurity do servidor ou em uma regra de CDN.
- Acesse o site por outra rede. Use o 4G do celular em vez do Wi-Fi do escritório. Se funcionar, o bloqueio é por IP e provavelmente vem do plugin de segurança ou do firewall do servidor.
- Teste com outro user-agent. Se o site abrir no navegador e falhar em um cliente de API ou em um bot de monitoramento, o bloqueio é por assinatura de requisição.
- Verifique se o site público abre normalmente. Se apenas o admin falha, o problema está na camada de autenticação, não no firewall de borda.
- Olhe o log do servidor. Um 403 registrado pelo Nginx ou pelo Apache antes do PHP rodar indica que o bloqueio é do servidor, não do plugin.
Se os quatro testes apontarem para o plugin, aí sim você parte para o isolamento. Se apontarem para o servidor, desativar plugin não vai resolver nada e só vai tirar sua proteção do ar sem necessidade.
Vale lembrar que um site fora do ar por bloqueio de firewall é diferente de um site fora do ar por queda de servidor. Se a dúvida é essa, o artigo sobre site WordPress caiu: servidor ou o próprio site? ajuda a separar os cenários antes de você mexer em plugin.
Como isolar o conflito entre dois plugins de segurança
O erro mais comum é desativar tudo de uma vez. Isso resolve o sintoma, mas você não descobre qual plugin causou o problema, e na próxima atualização ele volta. O caminho correto é isolar um por vez.
Se você tem acesso ao painel
- Anote a lista de plugins de segurança ativos. Normalmente são dois ou três: um de firewall, um de login e um de malware scan.
- Desative apenas o último que você instalou ou atualizou. Teste o login.
- Se o problema persistir, reative esse e desative o próximo da lista. Teste de novo.
- Quando o login voltar, você achou o par em conflito: o que você desativou e o que ficou ativo.
- Reative o desativado e desative o outro para confirmar. Se o problema voltar, o conflito é entre esses dois.
Se você perdeu o acesso ao admin
Sem painel, o caminho é renomear a pasta do plugin via FTP ou gerenciador de arquivos da hospedagem. Renomeie /wp-content/plugins/nome-do-plugin para /wp-content/plugins/nome-do-plugin-off. O WordPress desativa o plugin automaticamente ao não encontrar o arquivo principal. Faça isso com um plugin por vez e teste o login a cada renomeação.
Se o problema for especificamente com plugin de login, o artigo sobre plugin de login WordPress: trocar sem perder o acesso cobre o passo a passo para não se trancar do lado de fora.
O que observar em cada caso
Desativar e reativar resolve, mas o diagnóstico fica incompleto se você não olhar o que estava acontecendo. Três coisas merecem atenção durante o isolamento.
- Ordem de carregamento. Dois plugins que registram o mesmo hook na mesma prioridade podem se sobrescrever. Se o conflito só aparece quando os dois estão ativos, a ordem em que o WordPress carrega importa.
- Cookies duplicados. Plugins de segurança costumam setar cookies próprios de sessão. Abra o inspetor do navegador, veja a aba Application e procure cookies com nomes parecidos. Dois cookies de sessão competindo geram o loop de login.
- Regras de firewall sobrepostas. Se os dois plugins têm WAF, um pode bloquear a requisição do outro. Isso aparece no log como bloqueio legítimo, mas a origem é o próprio site.
Ativar WP_DEBUG no wp-config.php ajuda a capturar fatal errors silenciosos. O log fica em /wp-content/debug.log quando WP_DEBUG_LOG está ligado. Só não deixe isso ativo em produção depois do diagnóstico: o arquivo cresce rápido e pode expor caminhos internos.
Quando NÃO desativar o plugin de segurança
Desativar é a solução mais rápida e a mais perigosa. Existem casos em que ela não deve ser usada.
- Se o site acabou de sofrer tentativa de invasão, desativar o firewall deixa a porta aberta. Resolva o conflito, não remova a proteção.
- Se o bloqueio é do servidor, o plugin não é o culpado. Desativar não muda nada e você perde camada de proteção.
- Se o site é de e-commerce com checkout ativo, desativar plugin de segurança no meio do dia pode expor dados de pagamento. Faça em janela de manutenção.
- Se você não tem backup recente, não mexa. Qualquer alteração em plugin pode deixar o site em estado inconsistente.
Em resumo: desative só quando o teste rápido apontou para o plugin e você tem como reverter.
Erros comuns que prolongam o problema
Alguns padrões aparecem sempre que alguém tenta resolver conflito entre plugins de segurança WordPress sem método.
- Desativar todos os plugins de uma vez. Você perde a referência de qual causou o problema.
- Renomear a pasta errada via FTP. Confira o nome exato do diretório antes de mexer.
- Esquecer o cache. Plugin de cache pode servir a versão antiga da página e mascarar o resultado do teste.
- Não limpar cookies do navegador entre os testes. Cookies antigos de sessão mantêm o loop mesmo depois de você desativar o plugin culpado.
- Reativar os dois plugins juntos depois de resolver, sem checar se a atualização corrigiu o conflito.
Outro erro silencioso é ignorar que o problema pode ser de origem, não de plugin. Se o site foi comprometido, o sintoma pode reaparecer mesmo com plugins limpos. Nesse caso, o caminho é outro: WordPress invadido: como confirmar e agir detalha os sinais que diferenciam invasão de conflito.
Prevenção: um plugin de segurança por site
A causa raiz da maioria dos conflitos é empilhamento. Cada plugin adiciona uma camada, e camadas se sobrepõem. A regra prática é simples: um plugin de firewall, um de login e um de scan, no máximo. Se dois fazem a mesma coisa, um sai.
Antes de instalar qualquer plugin de segurança, vale seguir a mesma lógica de painel WordPress segurança: como avaliar antes de atualizar: verificar compatibilidade declarada, changelog recente e se ele sobrepõe função que você já tem.
Para quem administra vários sites, o problema se multiplica. Cada site com uma combinação diferente de plugins de segurança vira um caso único de diagnóstico. Padronizar a stack por site, com o mesmo plugin de firewall e a mesma configuração, reduz o tempo de resolução quando algo quebra. É aí que um painel como o 100% WP ajuda: você vê o estado de cada site em um lugar só e percebe mais rápido quando um deles sai do padrão.
Por fim, mantenha backup antes de qualquer alteração em plugin de segurança. Se o conflito der errado, restaurar é mais rápido do que reconstruir o acesso. A documentação oficial do WordPress sobre solução de problemas também traz o passo a passo de desativação manual de plugins quando o painel não abre.
Quando chamar alguém
Se depois de isolar você não conseguiu identificar o par em conflito, ou se o site voltou a apresentar o sintoma sem explicação, o caso pode ser mais profundo. Sinais de que é hora de envolver um especialista: arquivos modificados sem sua ação, usuários criados que você não reconhece, redirecionamentos estranhos no site público. Nesses cenários, o problema deixou de ser conflito e passou a ser segurança. O serviço de segurança e remoção de malware cobre esse tipo de investigação quando o diagnóstico caseiro não fecha.
