Como proteger um servidor Discord contra spam e raids em 2026

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.