What to Do When Fail2Ban Locks You Out of Your VPS (2026): Self-Rescue Guide for SSH Lockouts, unbanip, and ignoreip

If you still have an open SSH session, or can log in from another IP, first check:

sudo fail2ban-client status

Then look at the SSH jail:

sudo fail2ban-client status sshd

Focus on:

• Currently banned: the current number of bans;
• Banned IP list: the list of banned IPs;
• whether your current public IP is in it.

Check your own public IP:

curl -4 ifconfig.me

If your IP is in the list, the SSH service isn't broken — you've been banned by Fail2Ban.

If you can still get into the VPS via another IP, another user, a jump host, or a preserved session, unban directly:

sudo fail2ban-client set sshd unbanip 你的IP

Some versions also support unbanning an IP from all jails:

sudo fail2ban-client unban 你的IP

If this is just a test environment and you want to temporarily clear all bans:

sudo fail2ban-client unban --all

In production, don't casually run unban --all, because it will also release real attacking IPs.

After unbanning, test again:

ssh root@你的服务器IP

Or:

ssh 用户名@你的服务器IP

If no SSH connection works at all, you need out-of-band login:

• Cloud provider web console;
• VNC / noVNC;
• Serial Console;
• Rescue Mode;
• IPMI / KVM console.

After logging in, don't start deleting rules at random — first run:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 你的IP

If fail2ban-client is unavailable, temporarily stop the service:

sudo systemctl stop fail2ban

This is only a temporary rescue. Once you can SSH in again, fix the configuration immediately, otherwise Fail2Ban may ban you again after a restart.

The correct location is usually:

sudo nano /etc/fail2ban/jail.local

In [DEFAULT], add:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 你的固定IP 你的VPN出口IP

If you have a fixed subnet at the office or home, you can also use CIDR:

ignoreip = 127.0.0.1/8 ::1 203.0.113.10 198.51.100.0/24

After saving, reload:

sudo fail2ban-client reload

Or:

sudo systemctl reload fail2ban

Note: ignoreip only protects against future bans; it doesn't necessarily automatically lift an already-banned IP. An already-banned IP still needs unbanip first.

Common Fail2Ban files:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.local
/etc/fail2ban/jail.d/*.local
/etc/fail2ban/fail2ban.conf

The principle is simple:

• jail.conf is the default configuration; editing it is not recommended, as upgrades may overwrite it;
• jail.local holds local override configuration;
• jail.d/*.local is suitable for splitting by service;
• fail2ban.conf is Fail2Ban's own configuration, which contains database-related options.

A separate SSH configuration can be written like this:

[sshd]
enabled = true
port = ssh
maxretry = 3
findtime = 10m
bantime = 1h

If you changed SSH to a non-22 port, update this accordingly:

port = 2222

Otherwise Fail2Ban's monitoring and firewall actions may not match your actual SSH port.

The three core parameters:

If you set it like this:

maxretry = 1
findtime = 1h
bantime = 1w

then it's very easy to ban yourself for a week.

For a personal VPS, a relatively safe starting point:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

If there really are many attacks, consider progressive banning rather than pushing bantime to several weeks from the start.

There's a nasty situation: you've added yourself to ignoreip and unbanned yourself, but after restarting Fail2Ban or the server, you're banned again.

The cause may be that old ban records are still kept in Fail2Ban's database.

Check the configuration:

sudo grep -n 'dbpurgeage\|dbfile' /etc/fail2ban/fail2ban.conf

dbpurgeage controls how long records are kept in the database. If old records remain, old bans may be restored after a restart.

Troubleshooting approach:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 你的IP
sudo systemctl reload fail2ban

If it still keeps happening, you can temporarily stop Fail2Ban, verify the database and configuration, then start it again:

sudo systemctl stop fail2ban
sudo systemctl start fail2ban

Don't casually delete database files without understanding the impact. In production, they also hold records of real attacking IPs.

On systems like Ubuntu 22.04/24.04 and Debian 12, many logs are in journald.

You can set this in [DEFAULT]:

backend = systemd

Then reload:

sudo systemctl reload fail2ban

If the backend doesn't match, two problems can occur:

• Fail2Ban doesn't read SSH login failure logs and bans nothing at all;
• A custom jail reads the wrong logs and treats normal requests as attacks.

Before changing the log backend, first check the Fail2Ban logs:

sudo journalctl -u fail2ban -n 100 --no-pager
sudo tail -n 100 /var/log/fail2ban.log

Log paths may differ across distributions; in systemd environments, check journalctl first.

Many self-lockouts aren't from SSH but from custom jails for Nginx, Traefik, Caddy, or application login pages.

For example, while debugging a backend login, you get repeated 401/403 responses, which Fail2Ban identifies as an attack:

sudo fail2ban-client status
sudo fail2ban-client status nginx-http-auth
sudo fail2ban-client status 自定义jail名

Unbanning isn't always just about sshd; it depends on the specific jail:

sudo fail2ban-client set nginx-http-auth unbanip 你的IP

If you access the origin through Cloudflare, a reverse proxy, or a load balancer, also confirm whether the application receives the real client IP or the proxy IP. Otherwise Fail2Ban may ban the wrong target.

For Cloudflare origin issues, see: What to Do When Your VPS Website Shows Cloudflare 521 / 522.

Before enabling Fail2Ban, it's recommended to do three things first:

1. Confirm you can log in via the cloud provider console/VNC;
2. Add your fixed IP or VPN egress to ignoreip;
3. Keep a current SSH session open and don't disconnect immediately.

After enabling, test:

sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo journalctl -u fail2ban -n 50 --no-pager

Don't set maxretry very low and bantime very long when you have only one network egress, no console access, and no whitelist.

If you suspect Fail2Ban has banned you, follow this order:

1. Switch networks or log in to the VPS using a preserved SSH session.
2. Run fail2ban-client status to see which jails exist.
3. Run fail2ban-client status sshd to see whether your IP is banned.
4. Run fail2ban-client set sshd unbanip 你的IP to unban.
5. If SSH is completely inaccessible, use the cloud provider's VNC/console/rescue mode.
6. Add ignoreip to [DEFAULT] in /etc/fail2ban/jail.local.
7. Check whether maxretry/findtime/bantime is too aggressive.
8. Check whether a custom Nginx/Traefik jail is banning you by mistake.
9. If you're banned again after a restart, check dbpurgeage and database persistence.
10. After reloading, keep one SSH session open for testing; don't disconnect immediately.

Fail2Ban self-lockout is not a rare event, especially on new VPSs, during security hardening, when changing the SSH port, or while debugging a reverse proxy.

For an emergency, first use fail2ban-client status to find the jail, then set sshd unbanip to unban; if SSH is completely inaccessible, go through the cloud provider console. Long-term fixes rely on ignoreip, reasonable maxretry/findtime/bantime, the correct jail.local, and an understanding of database persistence. Fail2Ban is a good tool, but only if you don't let it shut you out first.