Разумно ли использовать перебор 301 для блока fail2ban, когда у вас включено перенаправление http на https?

Недавно мои серверы начали подвергаться бомбардировке анонимными сканерами / брутфорсом.

Вот так выглядел мой журнал доступа к nginx после атак:

xxx.xxx.xxx.xxx - - [07/Sep/2019:23:30:16 +0200] "GET /phpMyAdmin/index.php HTTP/1.1" 404 548 "-" "Mozilla/5.0..
xxx.xxx.xxx.xxx - - [07/Sep/2019:23:30:18 +0200] "GET /admin/index.php HTTP/1.1" 404 548 "-" "Mozilla/5.0..

Наряду с множеством других URL-адресов / страниц администратора / случайных имен, к которым они пытались получить доступ. Я провел небольшое исследование, и появился fail2ban. Итак, я его установил.

Я оставил его на некоторое время, но атаки повторялись снова. Я понял дефолт [nginx-botsearch] не отлавливает все атаки, не говоря уже о неверной настройке пути к журналу.

Я немного погуглил и остановился на этом настраиваемом фильтре:

# /etc/fail2ban/jail.local

[nginx-404-errors]
enabled = true
port     = http,https
logpath  = /var/log/nginx/*.log
maxretry = 2

# /etc/fail2ban/filter.d/nginx-404-errors.conf

[Definition]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400) .*$
ignoreregex =

Это сработало очень хорошо, но злоумышленник решил запустить http. Но дело в том, что у меня есть правило перенаправления http на https на nginx.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

Итак, теперь я получаю тонны журнала переадресации 301 в access.log. Я подумал, может мне стоит просто добавить 301 к регулярному выражению, которое я использовал выше. Итак, теперь это:

failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400|301) .*$

Атаки пока прекратились. Но я беспокоюсь, что обычные посетители могут столкнуться с проблемами при попытке зайти на сайт по http, и fail2ban может их зацепить.

Должен ли я таким образом смягчить подобные атаки методом перебора? Или я должен пойти другим путем?