Commands

fail2ban restart vs reload

Most configuration changes only need a reload, which keeps the server and its bans. Here is what each command does, when you need a full restart, and how to test your configuration before you apply it.

Updated 6 min readChecked against fail2ban 1.1.1

After editing jail.local, a filter or an action, run sudo fail2ban-client -t to test the configuration, then sudo fail2ban-client reload (or sudo systemctl reload fail2ban) to apply it. A reload re-reads all files, starts new jails, removes disabled ones and keeps current bans. Use sudo systemctl restart fail2ban only when changing server settings such as the socket or database, or when the service is stuck.

bash
sudo fail2ban-client -t && sudo fail2ban-client reload
output
$ sudo fail2ban-client reload
OK

Restart vs reload at a glance#

Command What happens Bans
fail2ban-client reload Re-reads config, updates running jails, starts new and stops removed ones Kept
fail2ban-client reload <jail> Same, for one jail Kept
fail2ban-client restart <jail> Stops and starts one jail (alias for reload --restart <jail>) Lifted, then restored from database
fail2ban-client restart --unban <jail> Restarts one jail and drops its bans Cleared
fail2ban-client reload --restart --unban Restarts every jail and drops all bans Cleared
fail2ban-client restart Stops and starts the whole server Restored from database
systemctl reload fail2ban Runs fail2ban-client reload Kept
systemctl restart fail2ban Stops and starts the service Restored from database

"Restored from database" means bans that haven't expired come back right after the restart. A restart is not a way to clear bans — use --unban or fail2ban-client unban --all for that (unban guide).

Test the fail2ban configuration first#

fail2ban-client -t (or --test) reads the full configuration the same way a start would, without touching the running server:

text
$ sudo fail2ban-client -t
OK: configuration test is successful

A broken jail prints the reason and fails:

text
$ sudo fail2ban-client -t
... ERROR   Found no accessible config files for 'filter.d/sshdx' under /etc/fail2ban
... ERROR   Unable to read the filter 'sshdx'
... ERROR   Errors in jail 'sshd'.
ERROR: test configuration failed
text
$ sudo fail2ban-client -t
... ERROR   Failed during configuration: Have not found any log file for 'sshd' jail.
ERROR: test configuration failed

The test checks that files parse, filters and actions exist and log files are found. It doesn't check values that are only evaluated by the server, such as a mistyped time like bantime = 1x, so watch /var/log/fail2ban.log after the reload too.

To see the configuration fail2ban will actually load, after jail.conf, jail.d/ and jail.local are merged, dump it:

bash
sudo fail2ban-client -d | grep "'sshd'"
sudo fail2ban-client --dp        # same, easier to read

Lines like ['set', 'sshd', 'bantime', '1h'] show the effective values. If your override doesn't appear, it's in the wrong section or file — remember the order jail.conf → jail.d/*.conf → jail.local → jail.d/*.local, where later files win. Common mistakes are on config and regex errors.

Reload the configuration#

bash
sudo fail2ban-client reload
# or, on systemd hosts (the unit's ExecReload runs the command above)
sudo systemctl reload fail2ban

A reload:

  • re-reads jail.conf, jail.d/, jail.local, every filter and action;
  • applies new settings (bantime, maxretry, failregex, ignoreip…) to running jails without dropping their bans or failure counters;
  • starts jails you just enabled and removes jails you disabled;
  • refuses to apply anything if the new configuration has an error, leaving the running jails as they were.

This covers almost every change: editing jail.local, adding a jail, changing a filter in filter.d/, adding ignoreip entries.

Reload or restart one jail#

bash
sudo fail2ban-client reload sshd       # apply new settings to sshd only
sudo fail2ban-client restart sshd      # stop and start sshd

reload <jail> is the fast path when you changed only that jail or its filter. restart <jail> fully stops the jail — its firewall rules are removed (logged as Repeal Ban) — and starts it again, re-creating the rules and restoring bans (Restore Ban):

log
2026-10-25 18:42:40,861 fail2ban.actions        [3190]: NOTICE  [manual] Repeal Ban 203.0.113.42
2026-10-25 18:42:41,032 fail2ban.actions        [3190]: NOTICE  [manual] Restore Ban 203.0.113.42

Restart a jail when you changed its ban action (for example from iptables-multiport to nftables), its port, or its backend. A reload removes an action that is no longer configured (unbanning its addresses there) and adds the new one, but it doesn't push the existing bans through the new action. A jail restart rebuilds the firewall rules and restores every ban with the new settings.

To get a clean slate for one jail:

bash
sudo fail2ban-client restart --unban sshd

Add --if-exists in scripts to skip jails that aren't running instead of failing.

Restart fail2ban completely#

bash
sudo systemctl restart fail2ban

On a server started by systemd, prefer systemctl over fail2ban-client restart so systemd keeps tracking the process. A full restart is needed when you change:

  • fail2ban.local settings that the server reads only at startup, such as socket, pidfile or dbfile;
  • the fail2ban package itself (after an upgrade);
  • anything, when the server hangs or a reload reports Reload already in progress.

fail2ban-client restart on its own prints Shutdown successful and Server ready. The fail2ban systemd unit is PartOf the firewall services, so restarting nftables, firewalld or iptables also restarts fail2ban, which re-creates its rules.

Which changes need what#

You changed Do this
jail.local / jail.d/ settings reload
Enabled or disabled a jail reload
A filter in filter.d/ reload <jail> (test with fail2ban-regex first)
ignoreip reload
banaction / action / port of a jail restart <jail>
backend or logpath of a jail restart <jail>
loglevel / logtarget in fail2ban.local reload, or set it live with fail2ban-client set loglevel
socket, pidfile, dbfile systemctl restart fail2ban
Upgraded the package systemctl restart fail2ban

Reload without breaking SSH access#

If you're working over SSH, make sure your own address is in ignoreip before you reload a stricter config, and keep a second session open until you've checked fail2ban-client status sshd. Locked out anyway? The unban guide covers getting back in.

FAQ#

How do I reload fail2ban after changing jail.local?#

Run sudo fail2ban-client -t to check the files, then sudo fail2ban-client reload or sudo systemctl reload fail2ban. The reload applies the new settings, starts newly enabled jails and keeps existing bans. No full restart is needed for jail changes.

What is the difference between fail2ban restart and reload?#

A reload re-reads the configuration and updates the running server and jails in place, keeping bans. A restart stops the server (or one jail), removing its firewall rules, then starts it again and restores unexpired bans from the database. Use reload for config edits, restart for action changes or a stuck service.

How do I restart a single fail2ban jail?#

Run sudo fail2ban-client restart <jail>, for example sudo fail2ban-client restart sshd. It's an alias for reload --restart <jail>. Add --unban to drop that jail's bans as well: sudo fail2ban-client restart --unban sshd.

How do I test fail2ban configuration?#

Run sudo fail2ban-client -t (long form --test). It parses every configuration file, checks filters, actions and log paths, and prints OK: configuration test is successful or the exact error. sudo fail2ban-client -d dumps the merged settings so you can verify an override.

Does restarting fail2ban clear all bans?#

No. fail2ban saves bans in /var/lib/fail2ban/fail2ban.sqlite3 and restores the unexpired ones on start. To clear them, run sudo fail2ban-client unban --all, or sudo fail2ban-client reload --restart --unban to restart all jails without their bans.

Spotted something wrong or out of date? Tell us — every page is checked against the current fail2ban release.