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.
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.
sudo fail2ban-client -t && sudo fail2ban-client reload$ sudo fail2ban-client reload
OKRestart 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:
$ sudo fail2ban-client -t
OK: configuration test is successfulA broken jail prints the reason and fails:
$ 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$ sudo fail2ban-client -t
... ERROR Failed during configuration: Have not found any log file for 'sshd' jail.
ERROR: test configuration failedThe 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:
sudo fail2ban-client -d | grep "'sshd'"
sudo fail2ban-client --dp # same, easier to readLines 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#
sudo fail2ban-client reload
# or, on systemd hosts (the unit's ExecReload runs the command above)
sudo systemctl reload fail2banA 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#
sudo fail2ban-client reload sshd # apply new settings to sshd only
sudo fail2ban-client restart sshd # stop and start sshdreload <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):
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.42Restart 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:
sudo fail2ban-client restart --unban sshdAdd --if-exists in scripts to skip jails that aren't running instead of failing.
Restart fail2ban completely#
sudo systemctl restart fail2banOn 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.localsettings that the server reads only at startup, such assocket,pidfileordbfile;- 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.