> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vetox.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Anti-Raid

> Erkenne Massen-Beitritts-Raids und prüfe verdächtige Konten am Eingang mit konfigurierbaren Join-Guard-Bedingungen. Basic-Stufe.

Anti-Raid erledigt zwei unabhängige Aufgaben: Es reagiert auf eine **Flut** von Beitritten und prüft **einzelne** Konten beim Ankommen.

<Info>
  Erfordert **Basic**-Premium. Darunter wird die ganze Seite durch eine Preisübersicht ersetzt — die Einstellungen werden gar nicht angezeigt.
</Info>

<Note>
  Anti-Raid braucht außerdem seinen Schalter auf der Seite [Einrichtung](/de/server-management/setup). Ist er aus, zeigt diese Seite ein gelbes Banner, und **jedes Bedienelement ist deaktiviert**, bis du es aktivierst.
</Note>

## Raid-Erkennung

Wenn genug Mitglieder innerhalb deines Fensters beitreten, erklärt Vetox einen Raid.

| Einstellung                  | Standard | Bereich                      |
| ---------------------------- | -------- | ---------------------------- |
| **Mindestanzahl an Nutzern** | 15       | **2** bis 100                |
| **Intervall (in Sekunden)**  | 5        | 1 bis 300                    |
| **Aktion während Raid**      | Kick     | Kick, Ban oder Mute          |
| **Kontoalter**               | 3 Monate | 1, 2, 3, 6, 9 oder 12 Monate |

<Warning>
  **Kontoalter ist ein Filter, keine Voraussetzung.** Nur Konten, die **jünger** als die Schwelle sind, werden für den Raid-Auslöser gezählt. Ältere Konten, die zeitgleich beitreten, werden komplett ignoriert.

  Es zu erhöhen macht Anti-Raid sensibler, nicht weniger.
</Warning>

<Warning>
  **Nur das Mitglied, das die Schwelle auslöst, wird bestraft.** Die früheren Beitretenden im Fenster werden zwar in deinem Alert genannt, aber nicht gekickt, gebannt oder gemutet.

  Wenn alle in der Welle behandelt werden sollen, nutze unten Join Guard.
</Warning>

<Note>
  Die Zahlenfelder lassen dich unter das Minimum von 2 gehen, aber diesen Wert zu speichern schlägt mit einem generischen Fehler fehl. Halte ihn bei 2 oder darüber.
</Note>

## Raid-Berichte

Wähle einen Kanal und schreibe eine Start- und eine Endnachricht. Beide unterstützen Variablen.

| Variable       | Funktioniert in |
| -------------- | --------------- |
| `[Usernames]`  | Startnachricht  |
| `[Users]`      | Startnachricht  |
| `[UsersCount]` | Startnachricht  |

<Warning>
  Zwei Einschränkungen hier:

  * **`[ServerName]` wird im Picker angeboten, aber nie ersetzt.** Es wird als wörtlicher Text gepostet.
  * **Die Endnachricht ersetzt gar nichts.** Jede Variable darin wird wörtlich gepostet. Schreibe sie als reinen Text.
</Warning>

<Note>
  `[UsersCount]` schließt das Mitglied, das den Raid ausgelöst hat, aus, daher liest es sich um eins niedriger als deine Schwelle.
</Note>

<Warning>
  **Den Berichtskanal zu leeren hat keine Wirkung.** Die Auswahl wirkt geleert, aber der alte Kanal bleibt erhalten, und Alerts gehen weiterhin dorthin. Der Kanal erscheint nach dem Speichern sichtbar wieder.

  Um Alerts zu stoppen, lenke sie auf einen Kanal, den du archivieren kannst, statt das Feld leeren zu wollen.
</Warning>

## Join Guard

Join Guard prüft jeden Beitritt einzeln und läuft **unabhängig von der Raid-Schwelle** — er handelt, egal ob gerade ein Raid stattfindet. Bis zu 10 Bedingungen.

### Regeln

Jede Bedingung enthält bis zu fünf Regeln:

| Regel                    | Prüft                                                                      |
| ------------------------ | -------------------------------------------------------------------------- |
| **Kontoalter**           | Älter oder jünger als eine bestimmte Anzahl an Stunden, Tagen oder Monaten |
| **Standard-Avatar**      | Das Konto hat nie ein Profilbild gesetzt                                   |
| **Kein Banner**          | Das Konto hat kein Profil-Banner                                           |
| **Benutzername enthält** | Der Benutzername enthält eines deiner Stichwörter, eines pro Zeile         |
| **Generierter Name**     | Der Benutzername passt zu maschinell erzeugten Mustern                     |

Die Erkennung generierter Namen deckt Namen ab, die auf drei oder mehr Zahlen enden, mit Zahlen beginnen, einen Unterstrich gefolgt von Zahlen enthalten, Zahlen gefolgt von einem Unterstrich, nur Zahlen und kurze zufällige Buchstaben-Zahlen-Mischungen.

### Übereinstimmung

Jede Bedingung wählt **Alle Regeln müssen passen** oder **Beliebige Regel muss passen**.

<Warning>
  „Beliebige“ mit einer breiten Regel wie *Standard-Avatar* wird bei einem großen Anteil ganz normaler neuer Mitglieder greifen. Kombiniere Regeln und bevorzuge „Alle“, es sei denn, du bist dir sicher.
</Warning>

### Aktionen

Bis zu fünf pro Bedingung: Rolle zuweisen, Kick, Ban, Timeout über eine Minutenanzahl, DM senden, in einen Kanal posten oder einen Moderationsfall eröffnen.

<Note>
  Aktionen laufen in Reihenfolge, und **ein Kick oder Ban stoppt alles** — verbleibende Aktionen dieser Bedingung und alle späteren Bedingungen werden übersprungen.

  Setze deine Logging- und DM-Aktionen **vor** jeden Kick oder Ban, sonst laufen sie nie.
</Note>

Join-Guard-Nachrichten unterstützen ein weit reicheres Variablenset als Raid-Berichte, inklusive des Mitglieds, seines Kontoalters, der passenden Regeln und des Bedingungsnamens.

## Eine sinnvolle Konfiguration aufbauen

<Steps>
  <Step title="Beginne mit reiner Raid-Erkennung">
    Die Standardwerte decken den offensichtlichen Fall ab. Lass Join Guard zunächst leer.
  </Step>

  <Step title="Füge eine enge Join-Guard-Bedingung hinzu">
    Kombiniere zwei oder drei Regeln mit „Alle“ — ein sehr neues Konto **und** ein Standard-Avatar **und** ein generierter Name ist fast nie ein echtes Mitglied.
  </Step>

  <Step title="Nutze eine nicht-destruktive Aktion, während du zuschaust">
    Weise eine Quarantäne-Rolle zu und eröffne einen Fall, statt zu bannen. Prüfe eine Woche lang.
  </Step>

  <Step title="Ziehe die Schrauben erst an, wenn du es magst">
    Wechsle zu Kicks oder Bans, nachdem du gesehen hast, wie sich die Bedingung im echten Datenverkehr verhält.
  </Step>
</Steps>

## Fehlerbehebung

<AccordionGroup>
  <Accordion title="Raids werden nicht erkannt">
    Prüfe, dass die beitretenden Konten tatsächlich jünger als deine Kontoalter-Schwelle sind — ältere Konten werden nie gezählt.
  </Accordion>

  <Accordion title="Nur ein Mitglied wurde bestraft">
    Erwartet. Die Raid-Erkennung handelt nur beim auslösenden Mitglied. Nutze Join Guard, um bei jedem passenden Beitritt zu handeln.
  </Accordion>

  <Accordion title="Eine Variable wurde als wörtlicher Text gepostet">
    `[ServerName]` wird nie ersetzt, und die Endnachricht ersetzt gar nichts.
  </Accordion>

  <Accordion title="Alerts gehen weiterhin in den alten Kanal">
    Das Leeren des Berichtskanals wird nicht gespeichert. Wähle stattdessen einen anderen Kanal.
  </Accordion>

  <Accordion title="Speichern schlägt mit einem generischen Fehler fehl">
    Meist liegt die Nutzer-Schwelle unter 2 oder das Intervall über 300 Sekunden. Beides wird vom Formular akzeptiert und beim Speichern abgelehnt.
  </Accordion>

  <Accordion title="Join Guard hat meine Logging-Aktion übersprungen">
    Ein Kick oder Ban weiter oben in der Aktionsliste bricht alles danach ab. Ordne so um, dass Logging zuerst läuft.
  </Accordion>
</AccordionGroup>

## Verwandt

<CardGroup cols={2}>
  <Card title="Protection" icon="lock" href="/de/moderation/protection">
    Schützt vor Schäden von innen.
  </Card>

  <Card title="Auto-Rollen" icon="user-plus" href="/de/engagement/auto-roles">
    Verzögerte Rollen sind eine unauffälligere Anti-Raid-Maßnahme.
  </Card>
</CardGroup>