Saltar al contenido principal

​
Descripción general

​
Cómo decide una respuesta

El motor recibe eventos de Discord, intenta atribuirlos a una persona con View Audit Log, comprueba la whitelist explícita y evalúa la política del módulo. Las ventanas se separan por actor, módulo y acción; el cooldown evita repetir el mismo castigo durante una ráfaga ya contenida. Si Discord todavía no permite verificar al actor, Headless no debe castigar a una persona al azar. Los logs de seguridad conservan detección, enforcement, fallos, cooldowns, cambios de whitelist, backups y restores.

​
Superficie observada y enforcement

Anti-Nuke registra más actividad de la que puede sancionar automáticamente. Expande el alcance para consultar qué eventos se observan y cuáles pueden generar enforcement.
La lista de eventos registrados es más amplia que las acciones con enforcement automático. Detectar un evento no significa que Headless vaya a castigar a alguien.
Anti-Nuke registra cambios de canales e hilos; roles y membresías; bans, kicks, prune, timeouts y movimientos de voz; webhooks; emojis y stickers; invitaciones; cambios del servidor, eventos programados y AutoMod; y borrados individuales o masivos de mensajes. El enforcement automático se limita a incorporación de bots, canales o threads creados/eliminados, roles eliminados, bans, kicks, prune, webhooks creados, emojis o stickers eliminados, AutoMod eliminado y ráfagas de borrado masivo.

​
Actividad coordinada

Además de evaluar la actividad atribuible a cada actor, el motor puede correlacionar eventos cualificados de varias cuentas dentro de una ventana interna. No es una exención ni una política configurable mediante los ocho comandos de módulo; Headless no publica los umbrales de correlación.
Los filtros de Sentinel y las reglas nativas de Discord son capas distintas. Consulta la guía de seguridad del contenido para ver los motores, límites y excepciones. La detección automod_weakening de Anti-Nuke observa cambios en reglas nativas; no las crea ni modera mensajes.Sentinel analiza mensajes solo cuando está habilitado. La respuesta también depende del modo, Simulation, el motor correspondiente y los permisos efectivos de Discord. Los comandos .automod y .automod content-exemptions requieren al owner del servidor o al owner configurado de Headless y abren un panel en el canal actual; usa un canal privado para el equipo. La guía de seguridad del contenido detalla las excepciones y .automod announcement-role.

​
Configurar Anti-Nuke

​
Controles de acceso separados

El owner del servidor administra el acceso y las operaciones reservadas al owner. Anti-Nuke Admin puede configurar la mayoría de opciones, pero no queda exento de las protecciones. Fake Permissions autoriza comprobaciones virtuales compatibles de comandos de Headless; no cambia permisos nativos de Discord ni crea excepciones de Anti-Nuke. .an admins requiere Manage Server nativo; las confirmaciones de reset vuelven a validar al actor.
Anti-Nuke Admin, whitelist, permisos nativos de Discord y Fake Permissions son controles diferentes. Dar acceso de configuración no añade una cuenta a la whitelist.

​
Acceso Anti-Nuke Admin

​
Exenciones de whitelist

La whitelist excluye solo las cuentas añadidas expresamente; no concede acceso administrativo. Comprueba el objetivo antes de guardar una excepción.
La whitelist exime a la cuenta añadida de las protecciones de Anti-Nuke. Concede esa excepción solo a personas o bots de confianza; no la confundas con el acceso Anti-Nuke Admin.
Respuesta histórica en español que confirma la incorporación a la whitelist y el bypass de triggers; las menciones del actor y del objetivo están ocultas.

Captura histórica de una respuesta anterior de Headless, antes de actualizar el texto al inglés; se ocultaron las menciones del actor y del objetivo.

​
Smart Setup y perfiles

La recomendación integrada es de solo lectura: no guarda ni aplica cambios. Smart Setup se abre desde Dashboard → Anti-Nuke → Smart Setup y exige owner o Anti-Nuke Admin. La vista previa muestra el análisis y los campos que cambiarán; dura 10 minutos, queda vinculada a la sesión y al servidor, y se invalida si cambia la revisión de configuración. Cancelar no persiste el plan.
La recomendación es una heurística ordenada, no una auditoría: primero High-Admin / Gang con al menos tres roles no gestionados (sin contar @everyone) que tengan Administrator; luego Maximum desde 10 000 miembros; después Gaming desde 35 roles no gestionados o 12 bots; Business / Staff si algún nombre de rol contiene staff, team, business o empresa; Creator desde 6 bots; y Community en los demás casos. Gana el primer criterio coincidente.
Ningún preset convierte un rol en confiable ni crea admins, whitelist o Fake Permissions. Community, Gaming, High-Admin / Gang, Creator y Business / Staff aplican stripstaff; Maximum aplica ban y la base de seguridad más estricta. El sistema habilita Anti-Nuke en modo Auto y desactiva Simulation al confirmar perfiles estándar; revisa el preview antes de aplicar.
  • Community: base equilibrada (balanced); castigo base stripstaff.
  • Gaming: protección estricta para servidores activos; castigo base stripstaff.
  • High-Admin / Gang: refuerza servidores con muchos roles Administrator; castigo base stripstaff.
  • Creator: refuerza protecciones configurables para comunidades de creadores; castigo base stripstaff.
  • Business / Staff: configuración estricta para equipos; castigo base stripstaff.
  • Maximum Security: activa las protecciones críticas disponibles y usa ban como castigo base.
  • Custom: conserva la configuración existente, aplica solo las decisiones revisadas y usa stripstaff como castigo base.
Para comunidades de voz, limita Manage Channels y otros permisos de escalada a roles de confianza: esa capacidad puede permitir que un actor interrumpa o reconfigure canales.
Los perfiles estándar de Smart Setup habilitan Auto y desactivan Simulation. .an max está disponible para Anti-Nuke Admin y activa Auto, apaga Simulation, aplica el castigo global ban y habilita módulos y triggers críticos. Revisa la vista previa y la configuración antes de confirmar.

​
Monitor, Auto y Simulation

La configuración inicial recomendada es Monitor con Simulation activada. Monitor registra actividad sin castigos; Simulation prueba detecciones sin modificar miembros, roles, canales ni bots. Auto aplica respuestas reales cuando Simulation está desactivada. Cambiar a Auto y usar .an strict requiere owner. .an on restaura el último modo guardado y puede reactivar Auto.
Empieza con Monitor y Simulation activada. Revisa detecciones, permisos y jerarquía antes de permitir respuestas automáticas.

​
Prueba informativa

.an test registra una prueba informativa sin castigo. Si el motor estaba apagado, también lo activa.

​
Opciones de los módulos

Cada subcomando acepta on, off o status. Los flags dependen de las capacidades del módulo; las firmas de abajo corresponden al parser actual de Headless. botadd no acepta umbral, castigo configurable ni --command.

​
.antinuke ban

​
.antinuke kick

​
.antinuke role

​
.antinuke channel

​
.antinuke emoji

​
.antinuke webhook

​
.antinuke

--threshold define cuántas acciones del módulo dentro de su ventana activan la respuesta. Los umbrales disponibles aceptan valores de 1 a 50; vanity y botadd no admiten --threshold.
--do elige entre none, warn, jail, kick, ban y stripstaff. botadd no admite un castigo configurable.
El flag --command cuenta acciones de moderación iniciadas mediante comandos de Headless; --command solo se admite en ban, kick y role.

​
Módulos disponibles

Cada módulo conserva su propia configuración. Los subcomandos aceptan on, off y status; en botadd, solo on y off cambian la configuración, mientras que status es una consulta de solo lectura.
Los módulos ban, kick y role admiten umbral, castigo y --command. El último permite contar acciones ejecutadas con comandos de Headless.
channel protege la creación y eliminación de canales; emoji, la eliminación de emojis; y webhook, la creación de webhooks. Admiten umbral y castigo, pero no --command.
vanity vigila cambios de URL y permite configurar el castigo, pero Discord no permite a Headless revertir esa URL (.antinuke vanity on --do stripstaff). En botadd, on/off activan o desactivan el módulo y status solo consulta el estado; en Auto puede retirar un bot no autorizado si los permisos y la jerarquía de Discord lo permiten.
Headless confirma que el módulo Anti-Nuke vanity quedó activado con castigo ban; la mención del usuario está oculta.

Respuesta real de Headless a .antinuke vanity on --do ban; se ocultó la mención del usuario.

Antes de elegir stripstaff, configura y revisa los roles protegidos con .bind staff y .bind staff list.

​
Sintaxis y comandos de prefijo

El grupo de prefijo se registra como .antinuke; .an es su alias corto. También acepta .anti-nuke, .sentinel, .sent y .sen. Usa el prefijo público . en los ejemplos.
  • .an muestra la ayuda del grupo; .an status y .an monitor consultan el estado y las señales.
  • .antinuke config muestra la configuración de este servidor. Es una consulta de solo lectura disponible para owner o Anti-Nuke Admin.
  • .antinuke list [category=all] abre listas paginadas del servidor o el detalle de una categoría; omitir la categoría consulta all.
  • .an access abre el panel de Anti-Nuke Admins y whitelist.
  • .antinuke admin [user] [action=toggle] acepta toggle, add o remove; si se omite, alterna el acceso. Es exclusivo del owner y no cambia la whitelist.
  • .an admins lista admins y requiere Manage Server nativo.
  • .antinuke whitelist [target] [action=toggle] acepta toggle, add o remove; si se omite, alterna la excepción. Solo el owner puede cambiarla; el target puede ser un miembro o el ID de un bot externo al servidor.
  • .an whitelist list y .an whitelist users son consultas de solo lectura disponibles para owner o Anti-Nuke Admin. Las mutaciones de whitelist, .an whitelist here @user y .an whitelist everyone @user son exclusivas del owner.
  • .antinuke permissions <grant|remove> <permission> [--do <none|warn|jail|kick|ban|stripstaff>] configura la respuesta de permisos observados; requiere owner o Anti-Nuke Admin. .an perms es alias.
  • Cada módulo tiene una tarjeta de sintaxis propia en Opciones de los módulos; usa solo las opciones enumeradas para ese módulo. En botadd, on y off cambian el estado; .antinuke botadd status solo lo consulta.
  • .an mode monitor|auto cambia el modo; seleccionar Auto requiere owner. .an on restaura el último modo y .an off apaga Anti-Nuke (owner-only).
  • .an strict es owner-only y puede iniciar enforcement real. .an max está disponible para Anti-Nuke Admins y también puede iniciar enforcement.
  • .an punishment [action] consulta el castigo global; cambiarlo requiere owner. .an instant on|off|status [ban_threshold] [ban_window] es owner-only y admite umbral de 2–10 bans y ventana de 10–120 segundos.
  • .an logs [#channel] consulta o cambia el canal de logs y requiere Anti-Nuke Admin.
  • .an alerts on|off|status [#channel] [dm-on|dm-off] configura las alertas al owner y es owner-only.
  • .an backup status|list|create|show|preview|restore|delete [ID]|on|off|every [horas] permite consultar, crear, previsualizar, programar o eliminar snapshots; el restore real requiere owner e ID explícito.
  • .an reset whitelist|bans solicita confirmación, vuelve a validar owner o Anti-Nuke Admin y puede vaciar la whitelist o desbanear a todos y retirar hardbans; .an clearwhitelist es otro reset confirmado que solo vacía la whitelist.

​
.antinuke list

​
.antinuke botadd

La consulta status no cambia la configuración. Usa on o off únicamente cuando quieras modificar el módulo.
Headless confirma que se activó el módulo botadd de Anti-Nuke; la mención del usuario está oculta.

Respuesta real (en inglés) de Headless a .antinuke botadd on; se ocultó la mención del usuario.

​
.antinuke permissions

Los comandos y aliases vigentes se pueden consultar en el catálogo de Commands.

​
Roles staff y alertas

stripstaff retira los roles staff configurados que Headless puede administrar según los permisos y la jerarquía actuales. .bind staff @rol alterna un rol en la lista compartida que usa Anti-Nuke Strip Staff y Staff Roles del Dashboard; .bind staff list muestra la lista. El alias heredado settings staff puede aparecer en instalaciones existentes. .an restorestaff @miembro intenta devolver roles staff guardados, pero no puede saltarse permisos, jerarquía ni roles que ya no existan. Las alertas del owner pueden dirigirse a un canal y, si se habilita, a DM; los logs dedicados conservan evidencia y no cambian por sí mismos la política. DM de protección a miembros: al activar Anti-Nuke por primera vez, Headless habilita esta opción si el owner todavía no la había configurado. Después respeta su elección. Mientras Sentinel esté activo y la opción siga habilitada, cada miembro humano nuevo recibe un DM informativo de mejor esfuerzo; el envío se programa aparte y no retrasa la protección de entrada. Si el miembro no acepta DMs, el fallo se ignora. El texto inicial es Headless · Active protection, con una explicación de la protección y un footer administrado por el staff. Al cargar ajustes, Headless sustituye únicamente las antiguas cadenas integradas en español; los textos personalizados se conservan.

​
Comandos

​
Comandos slash

Headless registra /antinuke recommend, status, access, list, admins, monitor, backup, backupnow, backuplast, backuptest, backuprestore, mode, disable, botadd, logs, alerts, instant, dashboard, admin, whitelist, reset y punishment. Las consultas privadas responden de forma ephemeral. La mayoría requiere owner o Anti-Nuke Admin. A diferencia del prefijo .an admins, que requiere Manage Server nativo, /antinuke admins usa el acceso de configuración de owner o Anti-Nuke Admin. /antinuke admin, whitelist, backuprestore, disable, logs, alerts, instant, punishment y elegir Auto en mode requieren owner. /antinuke reset usa confirmación y revalida al actor, pero no tiene el mismo gate owner-only que esos comandos. Nota: Los comandos slash se ejecutan desde la interfaz de Discord. Revisa sus opciones y permisos en el catálogo; la mayoría requiere owner o Anti-Nuke Admin y las consultas privadas responden de forma ephemeral.
.an reset bans puede desbanear a todos los miembros y retirar los hardbans después de confirmarlo. Verifica el servidor y revisa el impacto antes de confirmar esta acción irreversible.

​
Backups y recuperación

Los snapshots pueden incluir roles, canales, sobrescrituras de permisos y membresías rol-miembro. El valor inicial crea una copia cada 6 horas y conserva 12 copias. Cada captura limita la operación a 250 recursos y 5.000 vínculos miembro-rol; la vista informa si algo quedó fuera. Consultar, crear, previsualizar, programar y eliminar snapshots requiere acceso de configuración Anti-Nuke. Solo el owner del servidor o el owner de Headless puede ejecutar el restore real; el preview sí está disponible para quien tenga acceso de configuración. El restore real además necesita un ID explícito. Un preview no cambia Discord y no garantiza reconstrucción perfecta: los recursos pueden tener nuevos IDs y Discord conserva límites de jerarquía, capacidad y rate limit.

​
Consultar y crear snapshots

El subcomando acepta acciones como status, list, create, show, preview, restore, delete, on, off y every. El ID solo se usa en acciones que identifican una copia.
También funciona: .antinuke backup list

​
Previsualizar una restauración

El preview calcula los cambios sin modificar Discord. Usa el ID que aparece en la lista de snapshots.
Los límites y diferencias que muestra el preview pueden cambiar antes de una restauración real; vuelve a revisar el resultado justo antes de aplicarla.

​
Restaurar un snapshot

Solo el owner del servidor o el owner de Headless puede ejecutar la restauración real, y debe indicar un ID existente.
Los fallos parciales se registran, pero la restauración no es transaccional y no revierte automáticamente los cambios que Discord ya aceptó. Comprueba el servidor y el ID antes de continuar.

​
Programar snapshots

La programación usa horas y cantidad de copias retenidas. El comando limita los valores a los rangos admitidos por Headless.

​
Permisos y límites de Discord

View Audit Log es esencial para atribuir acciones. Según la respuesta, Headless también necesita Manage Roles, Manage Channels, Manage Webhooks, Ban Members, Kick Members o Moderate Members. El rol del bot debe estar por encima de lo que administra. Headless no puede castigar al owner, gestionar roles superiores ni impedir una acción que Discord ya aceptó. Revisa resultados parciales y fallos en logs.

​
Configuración inicial segura

1

Analiza sin modificar

Ejecuta .an recommend; la recomendación no guarda cambios.
2

Previsualiza Smart Setup

En Dashboard → Anti-Nuke → Smart Setup, elige un preset y revisa los cambios. Solo owner o Anti-Nuke Admin puede abrir y aplicar la vista previa.
3

Ajusta módulos y accesos

Configura umbral y castigo solo donde estén disponibles; revisa por separado Anti-Nuke Admin, whitelist y Fake Permissions.
4

Prueba y valida

Mantén Monitor y Simulation, revisa los logs y el estado resultante. Cambia a Auto solo tras validar permisos, jerarquía y respuesta.

​
Diagnóstico y preguntas rápidas

Comprueba que Anti-Nuke esté activo, el modo efectivo sea Auto, Simulation esté apagada y el módulo habilitado. Revisa permisos de Discord, jerarquía, castigo configurado y logs. Si el Audit Log no permite atribuir la acción con fiabilidad, Headless evita castigar a un actor incierto.
No. Anti-Nuke Admin concede acceso de configuración y Administrator es un permiso nativo de Discord; ninguno crea una excepción. Solo una entrada explícita de whitelist exime al usuario o bot.

​
Páginas relacionadas

Fake Permissions

Conoce qué permisos virtuales pueden satisfacer algunos comandos de Headless.

Anti-Raid / Join Gate

Configura las reglas de ingreso y la protección contra oleadas.

Moderación

Revisa sanciones, permisos, casos y límites de moderación.

Seguridad del contenido

Configura filtros de Sentinel y distingue sus excepciones de AutoMod de Discord.

Permisos de Headless

Consulta los permisos nativos y virtuales que usa Headless.
También puedes abrir el Dashboard para configurar el módulo y revisar sus vistas previas.