fail2ban が正規の利用者や自分自身の IP をブロックしてしまったら、まず fail2ban-client で該当 IP の BAN を解除し、次に fail2ban.log から「どの jail が、どのログ行に反応したか」を特定します。原因の多くは、ホワイトリスト（ignoreip）の不足、リバースプロキシや CDN の配下で本当の接続元 IP がログに残っていないこと、フィルターの正規表現が広すぎることのどれかです。この記事では、解除から原因の切り分け、設定の直し方までを、起きやすい順に解説します。
まず確認：本当に fail2ban がブロックしているか
「ログインできない」「サイトが開かない」という症状は、fail2ban 以外でも起こります。WordPress のログイン制限プラグイン（Limit Login Attempts Reloaded や Wordfence など）がブロックしている場合は、ログイン画面にメッセージが表示されるのが一般的です。一方、fail2ban はファイアウォール（iptables・nftables・firewalld など）で通信そのものを遮断するため、ブラウザではタイムアウトや接続拒否になり、SSH も同時につながらなくなることがあります。
別の回線（スマートフォンのテザリングなど）から同じサイトに接続できるかを試すと、IP 単位のブロックかどうかを素早く切り分けられます。自分の IP がブロックされて SSH に入れないときは、VPS やクラウドの管理画面にあるコンソール機能（シリアルコンソールや Web コンソール）からログインします。こうした復旧経路があるかどうかを、日頃から確認しておくことが一番の備えです。
手順1：BAN されている IP を確認して解除する
サーバーに入れたら、jail の一覧と、各 jail で BAN されている IP を確認します。
# 有効な jail の一覧
sudo fail2ban-client status
# 特定の jail（例: sshd）の状態と BAN 中の IP
sudo fail2ban-client status sshd
# ログから特定 IP の BAN 記録を探す（ローテーション済みのログも含める）
sudo zgrep -h "198.51.100.23" /var/log/fail2ban.log*誤検知と判断できたら、BAN を解除します。
# 特定の jail から解除
sudo fail2ban-client set sshd unbanip 198.51.100.23
# すべての jail から解除（比較的新しい版で使えるコマンド）
sudo fail2ban-client unban 198.51.100.23unban コマンドは 0.10 系以降で追加されたもので、古い版では使えません。主要ディストリビューションの標準パッケージは対応している版が多いものの（2026年10月現在）、手元の版は fail2ban-client --version で確認してください。解除しただけでは、同じ条件がそろえばすぐに再 BAN されます。次の手順で原因を特定するまでは、一時的に後述の ignoreip に追加しておくと作業が落ち着いて進められます。
手順2：どの jail が、どのログ行に反応したかを特定する
fail2ban.log には、BAN の前に「Found」という行で、どの jail がどの IP を検知したかが記録されます。
sudo grep -E "Found|Ban" /var/log/fail2ban.log | grep "198.51.100.23" | tail -n 20出力の角かっこ内（例: [sshd] や [nginx-http-auth]）が反応した jail です。次に、その jail がどのログを見ているかを確認します。
# jail が監視しているログファイルと設定値を確認
sudo fail2ban-client get nginx-http-auth logpath
sudo fail2ban-client get nginx-http-auth maxretry
sudo fail2ban-client get nginx-http-auth findtime最後に、そのログから該当 IP の行を探し、「本当に攻撃だったのか、正規の操作だったのか」を見ます。自分の作業時刻と重なる、決まった間隔で同じ URL を叩いている（監視サービスの特徴）、決済サービスや外部連携の通知 URL へのアクセス、といった特徴があれば誤検知の可能性が高いと判断できます。
手順3：原因を起きやすい順に確認して直す
原因1：自分・社内・連携サービスの IP がホワイトリストにない
最も多いのが、管理者自身や社内ネットワーク、外形監視、決済の通知などの正規の接続元が、短時間に何度か失敗扱いになるケースです。社内は NAT で多くの人が1つの IP を共有していることが多く、数人がパスワードを打ち間違えるだけで閾値に達します。
対処は、/etc/fail2ban/jail.local（または /etc/fail2ban/jail.d/ 配下の .local ファイル）の ignoreip に追加することです。配布元の jail.conf はパッケージ更新で上書きされるため、直接編集しないでください。
[DEFAULT]
# 自分自身・社内の固定 IP・監視サービスの IP を空白区切りで列挙
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/28 192.0.2.45jail のセクションに ignoreip を書くと、DEFAULT の値は引き継がれずに置き換わります。jail 側で追加したいときは、DEFAULT と同じ値も含めて書き直してください。自宅回線のように IP が変わる環境を広い範囲で許可すると、その範囲からの攻撃も素通りになるため、許可は必要最小限にとどめます。外部サービスの送信元 IP は変わることがあるので、提供元が公開している一覧を定期的に確認してください。
原因2：リバースプロキシや CDN の IP で判定している
Cloudflare などの CDN やロードバランサーの配下では、Web サーバーのアクセスログに記録される接続元が、利用者ではなくプロキシの IP になっていることがあります。この状態で fail2ban を動かすと、プロキシの IP が BAN され、そのプロキシを経由するすべての利用者が影響を受けます。逆に、プロキシのループバック（127.0.0.1）が記録されている場合は既定で無視されるため（ignoreself）、攻撃も検知されません。
まず Web サーバー側で、本当の接続元 IP をログに残すように設定します。Nginx では real_ip モジュールを使います。
# 信頼するプロキシの IP 範囲だけを指定する（CDN の公開範囲を使い、定期的に更新する）
set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;Apache では mod_remoteip（RemoteIPHeader と RemoteIPTrustedProxy）が同じ役割です。set_real_ip_from を広く指定しすぎると、攻撃者がヘッダーを偽装して任意の IP を BAN させられてしまうため、信頼するプロキシの範囲に限ってください。
もう1つの注意点として、CDN 経由の通信では、オリジンサーバーのファイアウォールで利用者の IP を遮断しても効果がありません。TCP の接続元は CDN だからです。この構成では、CDN 側の機能（WAF やアクセスルール）でブロックするか、Web サーバーの設定でアプリ層の拒否を行う必要があります。fail2ban には CDN の API を呼ぶアクションが同梱されている場合がありますが、API の仕様は変わるため、使う前に CDN の公式ドキュメントで確認してください。
原因3：フィルターの正規表現が広すぎる
自作のフィルターや、ネットで拾ったフィルターが、正規のアクセスまで拾っていることがあります。WordPress でよくある例は、wp-login.php へのアクセスをすべて失敗として数えてしまうものです。ログイン画面を開くだけでも、ログイン成功後のリダイレクトでも、同じ URL がログに残ります。また WordPress はログイン失敗時も HTTP 200 を返すため、アクセスログだけで成功と失敗を区別するのは困難です。
フィルターの当たり方は、fail2ban-regex で実際のログに対して試せます。
# フィルターがどの行にマッチするかを確認
sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-custom.conf --print-all-matchedマッチした行に正規の操作が含まれていたら、正規表現を絞り込みます（POST だけに限定する、特定のステータスコードに限定する、など）。WordPress のログイン失敗を正確に数えたい場合は、WP fail2ban などのプラグインで「認証に失敗したこと」自体を syslog に書き出し、そのログをフィルターで読む方式のほうが誤検知を減らせます。プラグインの設定項目は版によって変わるため、導入時は公式の説明を確認してください。
原因4：閾値（maxretry・findtime）が厳しすぎる
findtime の時間内に maxretry 回の失敗があると、bantime の間ブロックされます。たとえば「10分間に3回」のように厳しい値だと、パスワードの打ち間違いや、SSH クライアントが手元の鍵を順に試すだけで BAN に達することがあります。SSH では、エージェントに鍵がたくさん登録されていると、接続のたびに複数の認証失敗が記録される場合があります。~/.ssh/config で IdentitiesOnly yes と使う鍵を指定すると、この種の誤検知を減らせます。
値を緩めるときは、ログで実際の攻撃の頻度を見てから決めてください。攻撃側は数秒おきに大量に試すことが多いため、閾値を少し緩めても防御効果はあまり落ちず、誤検知だけが減ることが多いです。
原因5：recidive や BAN 時間の延長で長期 BAN になっている
recidive jail を有効にしていると、短期間に何度も BAN された IP が、より長い期間ブロックされます。また 0.11 系以降には、繰り返し BAN されるたびに BAN 時間を延ばす bantime.increment という設定があります。いずれも、誤検知が繰り返されると想定以上に長いブロックにつながります。解除するときは、元の jail だけでなく recidive 側でも BAN されていないかを fail2ban-client status recidive で確認してください。
手順4：設定を検証して反映する
設定を変えたら、反映前に構文を確認します。
# 設定の読み込みテスト（対応している版で使用可能）
sudo fail2ban-client -t
# 問題がなければ再読み込み（特定の jail だけでも可）
sudo fail2ban-client reload
sudo fail2ban-client reload sshd反映後は、fail2ban-client get <jail名> ignoreip などで、意図した値が読み込まれているかを確かめます。設定ファイルを変更する前には、/etc/fail2ban/ ディレクトリ全体をバックアップしておくと、うまくいかなかったときにすぐ戻せます。可能であれば、本番と同じ構成のステージング環境で先に試してください。
誤検知を減らすための運用のコツ
- 管理者の接続元は固定 IP や VPN にまとめ、そこだけを ignoreip に入れる
- 監視サービスや外部連携の送信元 IP を一覧にして、変更がないか定期的に確認する
- 新しいフィルターは、まず BAN しない設定（アクションを外すなど）でしばらく運用し、fail2ban.log の Found の内容を見てから有効にする
- fail2ban.log を定期的に見て、同じ IP が何度も BAN されていないかを確認する
まとめ
- 誤検知が起きたら、
fail2ban-client set <jail> unbanip <IP>で解除し、fail2ban.log の Found 行から反応した jail を特定します。 - 原因は、ignoreip の不足、プロキシや CDN 配下で本当の IP がログにないこと、フィルターの広すぎる正規表現、厳しすぎる閾値の順に確認すると効率的です。
- CDN 経由の通信は、オリジンのファイアウォールで遮断しても効きません。real_ip の設定と CDN 側の対策を組み合わせます。
fail2ban-regexでフィルターの当たり方を確認し、jail.confではなくjail.localに設定を書きます。- SSH から締め出されたときに備えて、VPS のコンソールなどの復旧経路を確認しておいてください。