Você cria um servidor Discord, configura os canais, coloca alguns moderadores e fica tudo bom.
Até começar a crescer.
Aí aparece conta mandando o mesmo link em 20 canais, cinco usuários com username quase igual entram juntos, alguém resolve mencionar @everyone várias vezes e no pior caso uma conta de administrador comprometida começa a apagar canal.
A resposta óbvia é automação.
Só que tem outro problema: se você configura automação agressiva demais, o bot começa a ser mais irritante que o spam.
Então a pergunta boa não é:
Como eu bloqueio o máximo possível?
É:
Como eu bloqueio comportamento realmente suspeito sem pegar usuário normal junto?
Neste artigo vou passar pelas opções que existem hoje, o que o próprio Discord já resolve, como eu penso a arquitetura de antispam e antiraid e onde ferramentas como BetterAntispam entram nisso.
Por que proteger um servidor Discord realmente importa
Spam não é só alguém mandando:
COMPRE CRYPTO AQUI
COMPRE CRYPTO AQUI
COMPRE CRYPTO AQUI
Isso é fácil.
O problema são os casos menos óbvios.
Uma conta criada há 20 minutos pode ser raider.
Também pode ser alguém que acabou de criar Discord.
Um usuário sem avatar pode ser bot.
Também pode ser alguém que não colocou foto ainda.
Dez pessoas entrando juntas pode ser raid.
Também pode ser um streamer que acabou de divulgar seu servidor.
Então um bom sistema de moderação não deveria olhar uma informação e decidir:
conta nova = ban
Você quer contexto.
Por exemplo:
conta criada agora
+
sem avatar
+
entrou junto com 30 contas
+
username parecido
+
começou a mandar o mesmo link
Agora ficou interessante.
É exatamente aí que separar sinais fracos de sinais fortes começa a fazer diferença.
O que dá para proteger automaticamente
Hoje dá para automatizar bastante coisa.
Spam de mensagem
Você consegue detectar:
- mensagens rápidas;
- texto repetido;
- excesso de menções;
- links repetidos;
- convites;
- excesso de emoji;
- texto muito grande;
- ghost ping;
- spam de comandos.
Raids
Você consegue observar:
- quantidade de joins;
- velocidade dos joins;
- idade das contas;
- características parecidas entre contas;
- comportamento logo depois do join.
Ações destrutivas
Também dá para observar ações administrativas como:
- bans em massa;
- kicks;
- canais apagados;
- cargos apagados;
- webhooks;
- alterações perigosas de permissões.
Verificação
Você também pode colocar alguma fricção antes do usuário receber acesso completo:
botão
↓
palavra
↓
matemática
↓
CAPTCHA
Mas não significa que você deveria ligar tudo no máximo.
O que nenhum bot consegue saber perfeitamente
Intenção.
Esse é o problema.
O bot sabe que alguém enviou cinco mensagens em cinco segundos.
Ele não sabe automaticamente por quê.
Imagina:
não
pera
acho que achei
sim
era isso mesmo
Cinco mensagens rápidas.
Se sua regra for:
if (messagesInFiveSeconds >= 5) {
banUser()
}
parabéns, você acabou de banir uma conversa normal.
Então eu trato comportamento como evidência.
Não como verdade absoluta.
Método 1: usar só o AutoMod do Discord
Antes de instalar qualquer bot, usa as ferramentas que o Discord já oferece.
É bom.
O AutoMod consegue bloquear mensagens com palavras específicas, spam e excesso de menções, além de mandar alertas para moderadores e aplicar timeout dependendo da configuração.
O próprio Discord também tem proteção contra raids, níveis de verificação e Slowmode.
Vantagens
- já está integrado ao Discord;
- não depende de outro serviço;
- bloqueia vários tipos de conteúdo antes da mensagem aparecer;
- configuração simples;
- consegue alertar a staff.
Desvantagens
- você tem menos controle sobre lógica customizada;
- nem todo ataque é baseado em mensagem;
- não resolve sozinho uma conta de administrador comprometida;
- algumas comunidades precisam analisar eventos em conjunto.
Veredito
Eu ligaria AutoMod mesmo usando outro bot.
Não tem motivo para recriar tudo que o Discord já faz.
Método 2: bot tradicional de moderação
Depois você tem bots gerais de moderação.
Normalmente eles fazem:
- warn;
- timeout;
- mute;
- kick;
- ban;
- logs;
- Slowmode;
- filtros.
Para muita comunidade isso já resolve.
O problema aparece quando você quer começar a responder coisas como:
esses 20 joins têm relação entre si?
ou:
esse usuário está repetindo comportamento que já apareceu em outras contas?
Aí você começa a sair de uma regra simples e entrar em análise de comportamento.
Método 3: proteção em camadas
É o modelo que eu prefiro.
Em vez de ter um botão:
SEGURANÇA = ATIVADA
separa os problemas.
Discord AutoMod
↓
conteúdo básico
Antispam
↓
comportamento de mensagens
Antiraid
↓
comportamento de joins
Antinuke
↓
ações administrativas
Verificação
↓
controle de entrada
Essa também é basicamente a arquitetura que usamos no BetterAntispam.
Antispam não deveria tentar resolver nuke.
Antinuke não deveria decidir se alguém está mandando emoji demais.
São problemas diferentes.
Mantém separado.
Como isso funciona tecnicamente
Vamos pegar antispam.
Primeiro você precisa de estado.
Se você só olha a mensagem atual:
client.on("messageCreate", message => {
console.log(message.content)
})
você não sabe se ela é repetida.
Então guarda um histórico pequeno.
const states = new Map()
function getState(userId) {
if (!states.has(userId)) {
states.set(userId, {
messages: []
})
}
return states.get(userId)
}
Quando chega mensagem:
client.on("messageCreate", message => {
if (!message.guild || message.author.bot) return
const state = getState(message.author.id)
state.messages.push({
content: message.content,
timestamp: Date.now()
})
})
Agora remove coisa velha.
const WINDOW = 30_000
state.messages = state.messages.filter(
item => item.timestamp > Date.now() - WINDOW
)
Pronto.
Agora você consegue saber o que aquele usuário fez nos últimos 30 segundos.
Não mistura detecção com punição
Esse ponto é importante.
Não faz:
if (detectSpam(message)) {
await message.member.ban()
}
Seu detector agora decide punição também.
Eu prefiro:
const signals = detectSignals(message, state)
const decision = evaluate(signals)
await execute(decision)
Você tem:
detecção
↓
decisão
↓
ação
Agora se seu detector está bom mas a punição está agressiva, você muda a punição.
Não precisa mexer na detecção.
Trabalha com vários sinais
Imagina algo assim:
let score = 0
if (isSendingFast) {
score += 10
}
if (isRepeatingMessages) {
score += 20
}
if (isMassMentioning) {
score += 30
}
if (isRepeatingSuspiciousLinks) {
score += 35
}
Depois:
if (score >= 60) {
quarantine()
} else if (score >= 35) {
timeout()
} else if (score >= 20) {
log()
}
Os números são exemplo.
Não pega isso e coloca em produção sem pensar.
O importante é o modelo.
Uma coisa moderadamente estranha pode não significar nada.
Várias coisas estranhas acontecendo juntas significam mais.
Similaridade é melhor que igualdade
Spammer não precisa mandar exatamente a mesma string.
Isso:
entra aqui https://site.com/1
e isso:
ENTRA AQUI!!! https://site.com/2
provavelmente são a mesma campanha.
Mas:
messageA === messageB
vai dizer que não.
Então normaliza.
function normalize(content) {
return content
.toLowerCase()
.trim()
.replace(/\s+/g, " ")
.replace(/[!?.,]+/g, "")
}
Pode remover URL antes de comparar também.
function removeUrls(content) {
return content.replace(/https?:\/\/\S+/gi, "")
}
Agora você consegue identificar padrões sem depender de igualdade perfeita.
Só não exagera.
bom dia
e
bom dia pessoal
também são parecidos.
Contexto continua importando.
Raid não deveria ser só "X joins em Y segundos"
O jeito mais simples de detectar raid é:
if (joinsLastMinute >= 20) {
raid()
}
Funciona até algum criador de conteúdo mandar 50 pessoas legítimas para seu servidor.
Quantidade é um sinal.
Analisa a composição também.
function calculateRisk(member) {
let score = 0
const accountAge =
Date.now() - member.user.createdTimestamp
if (accountAge < 60 * 60 * 1000) {
score += 20
}
if (!member.user.avatar) {
score += 10
}
return score
}
Agora imagina:
30 joins em 1 minuto
+
25 contas muito novas
+
20 sem avatar
+
vários usernames parecidos
Muito mais útil que saber simplesmente:
30 pessoas entraram
BetterAntispam usa esse tipo de ideia com análise de padrões de join e perfis suspeitos.
Mas você consegue implementar o mesmo conceito em qualquer projeto.
Quarentena é muito útil para falso positivo
Quando você não tem certeza suficiente para banir alguém, não precisa escolher entre:
faz nada
e:
ban permanente
Tem um meio.
Quarentena.
usuário suspeito
↓
remove acesso aos canais
↓
loga o motivo
↓
staff analisa
Se depois ficar óbvio que era ataque, escala.
Se for legítimo, restaura.
É muito melhor que transformar um score imperfeito em punição permanente.
Antinuke é completamente diferente de antispam
Agora imagina que o atacante não é membro novo.
É um administrador.
Ou uma conta de bot comprometida.
Ele não precisa mandar uma mensagem.
Pode fazer:
delete channel
delete channel
delete channel
ban member
ban member
delete role
create webhook
change permissions
Seu antispam está olhando messageCreate.
Ele não vai ajudar.
Nesse caso você precisa observar eventos administrativos e Audit Logs.
Por exemplo:
const limits = {
channelDelete: {
count: 3,
window: 10_000
},
roleDelete: {
count: 3,
window: 10_000
},
memberBan: {
count: 5,
window: 10_000
}
}
De novo, números de exemplo.
Não usa o mesmo limite para tudo.
Apagar um canal não necessariamente tem o mesmo risco de alterar uma permissão crítica.
Essa separação é o motivo de BetterAntispam tratar antinuke como um sistema diferente do antispam.
E quando o bot começa a crescer?
Aqui fica interessante para quem está fazendo isso em Node.
Esse código:
const joins = []
funciona enquanto existe um processo.
Agora você coloca:
Shard 1
Shard 2
Shard 3
Shard 4
Cada processo tem o próprio array.
Então você talvez tenha:
Shard 1 → 8 joins
Shard 2 → 7 joins
Shard 3 → 9 joins
Nenhum processo individual vê uma raid enorme.
Mas globalmente foram 24 joins.
Se o estado precisa ser compartilhado, move para uma camada compartilhada.
Redis é uma opção.
Discord Gateway
↓
processos / shards
↓
Redis
↓
detecção
↓
decisão
Não precisa ser Redis.
Só entende onde está sua fonte de verdade.
Rate limit importa justamente quando tudo dá errado
Durante uma raid você recebe mais evento e quer executar mais ação.
Seu bot começa a:
- deletar mensagem;
- aplicar timeout;
- mudar cargo;
- banir;
- editar canal;
- ativar Slowmode;
- mandar logs.
Tudo ao mesmo tempo.
Então não pensa só em detecção.
Pensa na fila de execução também.
prioridade 1
impedir mais dano
prioridade 2
conter atacante
prioridade 3
lockdown
prioridade 4
limpeza
prioridade 5
logs secundários
Não faz o embed bonito do log atrasar a ação que realmente impede o ataque.
E não hardcode os rate limits da API.
O próprio Discord diz que eles podem variar e que aplicações devem respeitar os headers e retry_after.
Raid Mode deveria mudar as regras temporariamente
Se o sistema já detectou raid, não precisa tratar o próximo usuário exatamente como trataria num dia normal.
Você pode temporariamente:
- aumentar verificação;
- ativar Slowmode;
- bloquear canais;
- aumentar sensibilidade;
- restringir novos usuários;
- avisar moderadores.
Depois volta ao normal.
É melhor que deixar configuração extremamente agressiva ligada 24 horas por dia.
modo normal
→ otimiza para usuário legítimo
modo raid
→ otimiza para contenção
BetterAntispam tem lockdown automático seguindo essa ideia, mas de novo, o conceito não depende dele.
Limpeza faz parte da proteção
Às vezes prevenção falha.
Já entraram usuários.
Já mandaram 2.000 mensagens.
Agora você precisa limpar.
Então o fluxo completo não é:
detectar
↓
fim
É:
detectar
↓
conter
↓
remover atacante
↓
limpar
↓
voltar ao normal
Ferramentas de bulk moderation ajudam aqui.
BetterAntispam tem /nuke para limpeza de canal e /slowmodebulk para aplicar Slowmode em massa.
O ponto não é o comando.
É pensar em recuperação antes de precisar dela.
Melhores práticas para proteger um Discord em 2026
1. Liga AutoMod primeiro
Não recria tudo.
O Discord já consegue resolver bastante coisa.
2. Não confia em um único sinal
Conta nova não significa atacante.
Sem avatar não significa bot.
Join rápido não significa raid.
Combinação de comportamento é mais útil.
3. Separa detecção de ação
Seu detector deveria produzir informação.
Outra parte decide a punição.
4. Usa quarentena quando existe dúvida
É muito mais fácil recuperar uma quarentena errada que um ban permanente errado.
5. Configura exceções
Bots, staff e canais especiais podem ter comportamento diferente.
Não desliga o sistema inteiro porque um webhook legítimo manda links.
Exime aquele webhook.
6. Protege contra conta de staff comprometida
Antispam não resolve administrador malicioso.
Antinuke é outra camada.
7. Faz um modo de emergência
Não tenta configurar 30 coisas manualmente enquanto a raid já está acontecendo.
8. Testa falso positivo
Não testa só:
o spammer foi bloqueado?
Testa também:
o usuário normal continuou funcionando?
Esse segundo teste é igualmente importante.
Guia rápido de configuração
Se eu fosse configurar um servidor hoje, faria nessa ordem.
Passo 1 — AutoMod
Liga:
- proteção de spam;
- menções;
- palavras relevantes;
- alertas.
Não precisa banir automaticamente todo mundo que dispara regra.
Passo 2 — nível de verificação
Escolhe baseado no risco real da comunidade.
Passo 3 — camada adicional de moderação
Pode ser seu próprio bot, BetterAntispam ou outra ferramenta.
Só não instala cinco bots fazendo exatamente a mesma coisa sem saber qual deles tomou a ação.
Passo 4 — antispam
Começa conservador.
Olha logs.
Ajusta.
Passo 5 — exceções
Configura usuários, cargos, bots e canais legítimos.
Passo 6 — antiraid
Primeiro entende como joins normais do seu servidor se comportam.
Depois define thresholds.
Passo 7 — antinuke
Define limites separados para ações realmente destrutivas.
Passo 8 — testa tudo
Cria um canal de teste.
Manda spam.
Testa link.
Testa menção.
Testa role exempt.
Testa quarentena.
Run whatever tests you want, é bom. Melhor quebrar a configuração no canal de teste que descobrir o problema quando tiver 100 contas entrando.
O que procurar em uma solução de moderação
Se você não quer construir tudo manualmente, eu olharia isso antes de escolher uma ferramenta.
Thresholds configuráveis
Seu servidor não é igual ao servidor de outra pessoa.
Exceções granulares
Usuário, cargo, canal e bot.
Punições progressivas
log
↓
timeout
↓
quarentena
↓
kick
↓
ban
Antiraid separado
Raid não é simplesmente spam mais rápido.
Antinuke
Conta de administrador comprometida é outra classe de ameaça.
Lockdown
Você precisa conseguir mudar o estado do servidor rápido.
Logs que explicam a decisão
Usuário punido não é log bom.
Você quer saber qual sinal disparou.
Ferramentas de recuperação
Quando prevenção falhar, staff precisa conseguir limpar rápido.
Verificação configurável
Nem toda comunidade precisa de CAPTCHA pesado.
Onde o BetterAntispam entra nisso
Eu trabalho no BetterAntispam e ele foi basicamente construído em volta dessa separação.
Hoje ele tem antispam, antiraid, antinuke, verificação, lockdown e ferramentas de limpeza.
O motivo de citar ele aqui não é falar:
esse é o melhor bot, instala agora
Isso não ajuda muito quem está lendo.
O interessante é que ele é uma implementação real das ideias acima.
Por exemplo:
spam
→ detector próprio
raid
→ análise de joins/perfis
nuke
→ ações administrativas
verificação
→ camada antes do acesso
lockdown
→ resposta global
Você pode implementar exatamente a mesma arquitetura no seu próprio bot com Node.js e discord.js.
Na verdade detecta a biblioteca automaticamente dentro da sua própria aplicação se você tiver uma camada abstrata, usa os eventos que o wrapper já resolve e manda só os dados normalizados para os detectores.
O detector não deveria precisar saber se o evento veio diretamente de discord.js ou de outra biblioteca.
Ele só precisa receber:
{
guildId,
channelId,
userId,
username,
content,
timestamp
}
Essa separação deixa muito mais fácil trocar implementação depois.
Conclusão
O objetivo de moderação automática não deveria ser bloquear o maior número possível de usuários.
Isso é fácil.
ban todo mundo
Pronto, zero spam.
Também zero comunidade.
O problema interessante é pegar comportamento ruim enquanto usuário normal quase não percebe que o sistema existe.
Usa AutoMod para o básico.
Combina sinais em vez de confiar em um campo.
Separa antispam de antiraid.
Separa os dois de antinuke.
Usa quarentena quando ainda existe dúvida.
Mantém estado compartilhado se sua aplicação estiver distribuída.
Respeita rate limits.
E mede falso positivo.
Porque uma ferramenta de segurança só é boa enquanto as pessoas legítimas conseguem continuar usando o sistema normalmente.
Referências
- Discord — Auto Moderation in Discord
- Discord — How to Protect Your Server from Raids 101
- Discord Developer Documentation — Rate Limits
- Discord Developer Documentation — Audit Logs
- BetterAntispam
Transparência: eu trabalho no BetterAntispam, citado neste artigo como exemplo de implementação. O artigo foi produzido com assistência de IA e revisado para publicação. As ideias técnicas acima não dependem do BetterAntispam e podem ser aplicadas em qualquer bot ou sistema de moderação para Discord.
