# How to protect a server against raids > Protect a Discord server against raids in three layers — what to configure before it happens, and what to do in the first sixty seconds when it does. - Canonical: https://discordguides.blog/blog/protect-against-raids - Published: 2026-08-25 - Author: The Manual desk - Facts checked: 2026-08-30 - Sources: - probot.io premium page (https://probot.io/en/premium) — checked 2026-08-30 - wickbot.com (https://wickbot.com) — checked 2026-08-30 - docs.gaiusbot.me (https://docs.gaiusbot.me/) — checked 2026-08-30 - Publication: The Manual, an independent site not affiliated with Discord Inc. --- A raid is a coordinated join by many accounts, usually new ones, usually followed by mass posting. It is a different problem from spam, and [word filters](/blog/set-up-discord-automod) do not address it — the accounts are real, the messages may be individually innocuous, and the damage comes from volume. Defence is three layers: **stop them joining**, **slow them down once in**, and **recover afterwards**. Most servers build the second and neither of the others. **Before you start:** you need **Manage Server** and **Manage Roles**. Do this now rather than during an incident. ## Layer one: raise the join bar Discord's own verification levels are free and underused. Server Settings → Moderation. **Medium** requires a verified email and five minutes of Discord account age. **High** requires ten minutes of membership in your server. **Highest** requires a verified phone number. For most communities, **High** is the right resting level. It is invisible to genuine members — they read the rules for ten minutes anyway — and it defeats throwaway accounts entirely. Also enable the **explicit media filter** for all members while you are on this screen. ## Layer two: a join gate Verification level stops accounts that are minutes old. It does not stop accounts farmed weeks in advance, which is what an organised raid uses. A join gate does. The pattern: new members land with no access to anything except one channel, where they take a deliberate action — press a button, complete a captcha, type a phrase — that grants the member role. This costs a genuine member ten seconds. It costs a raid its automation, because scripted accounts either fail the gate or all pass it at an identical, obvious rhythm. If your bot supports **account-age filtering** on the gate, set it. Refusing accounts younger than seven days blocks most farmed cohorts. ## Layer three: rate limits on the join itself This is the layer that catches what the first two miss. Anti-raid detection watches the **join rate**. Ten joins in ten seconds is not organic for most servers, and a bot configured for it can lock the server automatically — pausing invites, gating new members, or timing out the cohort — before anyone posts. Set the threshold from your own numbers, not a default. Look at your busiest legitimate hour and set the trigger meaningfully above it. Too tight and a successful post elsewhere locks your server during exactly the moment you wanted the traffic. Configure what the trigger _does_, too. Auto-lock is safe and reversible. Auto-ban on join-rate alone is not — one false positive bans a wave of genuine new members. ## What a layer-three implementation actually looks like Vetox's Anti-Raid module is a concrete example of layer three, and walking through it shows how the advice above turns into settings. It ships as two independent checks. **Raid detection** is the flood alarm: it counts accounts younger than a configurable age joining inside a rolling window — 1 to 300 seconds, a threshold of 2 to 100 joins — and once the count is reached, posts an alert naming who joined and applies one response: mute, kick or ban. Two details worth knowing before you configure it yourself. **Only the member who actually trips the threshold is punished**, never the rest of the join wave, which is exactly the false-positive risk this guide is warning about with "auto-ban on join-rate alone." And **mute is one of the three response options**, so the reversible, safe-by-default choice this guide recommends is available without falling back to kick or ban. **Join Guard** runs a per-account screen alongside it, automatically rather than by challenge: every join is checked against up to ten conditions, each combining up to five rules — account age, a default avatar, no profile banner, username keyword matches, and six patterns that catch generated-looking names (strings of trailing digits, an underscore-then-numbers shape, and similar) — with AND/OR logic. A condition's response can assign a quarantine role, time out, DM the member, post to a channel, or **open a case**: a review card naming which rules matched, with Kick, Ban, Timeout and Ignore buttons for a human to decide from. That last option is this guide's "recovery, not retaliation" instinct built into the tool — a suspicious join gets held and flagged rather than auto-punished, and a moderator makes the actual call. Both checks are part of the **Basic** plan at $4.99/month, alongside the rest of Anti-Raid's configuration — there is no separate charge per rule or per condition. ## The first sixty seconds of an actual raid Order matters. Do these in sequence. 1. **Raise verification to Highest.** One click, stops the inflow immediately. 2. **Pause invites** if your bot supports it, or delete active invite links. 3. **Do not start banning individually.** You will not out-click a script, and manual bans during a raid produce mistakes that take longer to unwind than the raid took. 4. **Use the bulk tool** — most anti-raid bots can action everyone who joined in a time window. That is the correct instrument. 5. **Then** clean the messages, with a bulk purge scoped to the affected channels. Recovery, not retaliation. The goal is a working server in ten minutes, not justice. ## Afterwards Two things worth doing while it is fresh. **Check what got through and why.** If the accounts were three weeks old, your age filter is too low. If they passed the gate, the gate is scriptable and needs changing. **Check your audit log for anything that was not messages.** The dangerous version of a raid is not spam — it is one authorised account deleting channels or mass-banning while everyone is watching the noise. That is a nuke, and it is a different attack wearing a raid as cover — a separate defence from anything above, because the account doing the damage is already trusted rather than freshly joined. [Why you should not give a bot Administrator](/blog/discord-administrator-permission-risk) covers the tool built for that specific threat. ## Where the tooling sits Discord's verification levels and explicit media filter are free and are the first thing to configure regardless of bot. Beyond that, anti-raid is commonly a paid feature. [ProBot](https://probot.io/en/premium) includes Advanced Protection on both paid tiers from $40/year. Vetox gates Anti-Raid at its $4.99/month Basic tier while keeping moderation and logging free. [Wick](https://wickbot.com) and [Gaius Cyber](https://docs.gaiusbot.me/) are the security specialists, and Wick covers anti-nuke most thoroughly among them. If raids are a recurring problem rather than a one-off, they go deeper than any general bot. Whichever you use, configure it **before** you need it. Nobody has ever successfully set up anti-raid during a raid.