How to deal with new "unauthorized" fail2ban jail in SWAG

a recent pull request in the SWAG container introduces an nginx-unauthorized fail2ban jail:

in general it seems like a great idea, but I have some trouble tweaking the configurations based on the classic workflow of an authorized HTTP connection.

what I mean is, an authorized user will most often still trigger a 401 line in the logs, will it not?

if I use curl to manually GET/POST the desired URL with the provided authentication, then I will get a correct reply right away, i.e. 200 or so, and that is fine.

if instead I am using a webbrowser, it is my understanding that the browser will:

  • first try unauthenticated, thus generating a 401 log line,
  • then see the 401 reply, thus showing a user/pass dialog to the user,
  • finally GET what it was supposed to get, but with proper authentication.

in other words, is there a way to make sure that I personally do not participate in the 401 lines that this new jail is supposed to patrol?

any suggestion is welcome. thanks!

Whitelist your ip.
ignoreip = Etc

I have a dynamic IP, so that will not work.

my question is whether it is correct to assume that perfectly authorized clients will inevitably produce 401 lines, too, or whether there is a way around such an issue.

does anyone have any suggestions? as it is, the unauthorized jail is useless and dangerous more than it is useful… for anybody!

i have the same problem. i can’t use photoprism (Docker Hub) with this jail. i log in, switch a path in the application on the subdomain and i am banned. i don’t get why because i don’t know a lot about the configuration of fail2ban. But i’m glad i found this thread and now i have to research how to disable this jail (even on swag container updates) or how to add some headers in the proxy-confs that can change that behaviour or how to whitelist a url?.. no idea.

For now i just added a much higher retry amount in for the nginx-authorized in the jail.local file and mount my custom jail.local in my docker-compose


Same issue for me. I’ll take any advice, but I think I am going to deactivate this jail if there’s no work around as I keep locking myself out…

maybe @quietsy and @Roxedus, that is, the users who merged such changes, want to pitch in?

You might want to provide some logs from your nginx instance to show what IP’s it’s banning. As the jail shouldn’t block any local subnets so if nginx is seeing something different , something with your network setup is a miss (could be using nat hairpin).

that is not the point.
I am allowed to connect to my reverse proxy from the internet, am I not?
indeed, with a dynamic IP that changes over time, so that it cannot be whitelisted, I am bound to generate some 401 lines that inevitably lead to fail2ban banning me.

it might be that other users have other issues, but my original post was because of this.
AFAIK, you will always see a 401 line before you are able to successfully authenticate.

Or you can just argue against me.
It would be nice just to see some nginx logs first of what IP’s are actually getting banned then we can access what is happening.

Unfortunately we don’t have the time to discuss hypothetical scenarios. Please reproduce the issue, show us the logs along with specific instructions on how to reproduce (so we can reproduce on our end), then we’ll look into it.


these are not hypothetical scenarios, that is how the HTTP exchange works.
a web browser will first fetch the page, thus generating the 401 access code, then realize it needs to authenticate, and finally it will authenticate, thus generating a 200 status code.

e.g. - - [07/Jul/2022:10:30:09 +0000] "GET /whatever HTTP/2.0" 401 574 "-" "Mozilla/5.0 [etc]" - username [07/Jul/2022:10:30:11 +0000] "GET /whatever HTTP/2.0" 200 2797 "-" "Mozilla/5.0 [etc]"

so even if you are authorized, you are polluting the access.log file with many 401 lines.
do you want to reproduce it? just visit a webpage protected by HTTP auth and look at your own logs.

as a consequence, unless the creators of the jail want to elucidate us with respect to the logic behind this, the jail is best left disabled by default.
only those that know for sure that they can be protected by IP whitelisting should enable this.

I will say, I use http Auth all the time remotely and never had this issue.

Are you actually experiencing this issue your self? What browser extensions do you have installed?

If this was a major issue, I would expect more people complaining about this here and on our discord.

well, then you can try this on your own setup – do you generate 401 lines?
if so, then it’s only a matter of tweaking the parameters, e.g. allowing X times in the past Y minutes, and you might get locked out yourself if, of course, you are not protected by IP whitelisting and you have allowed the unauthorized jail.

some people might compulsively check their own dashboard, maybe from new connections from their android phone which does not remember the “authorization required” status of pages after the browser has been closed.

We’re not testing your hypothesis for you.

I told you above what we need from you before we look into this further. Until then this will remain an unconfirmed report.

I understand quite often you get annoyed by people complaining but not attaching logs, but this is not one of those cases – if you take some time to read through, you will easily follow along without the need for detailed logs.

I’ll keep it short and mark it as solved for other users.

the unauthorized jail is moronic and should be disabled by default, unless the user really means it.

issues might arise because even authorized connections are bound to create 401 http codes in the logs.

The fact of the matter is, while you think this might be an issue, this thread is the only place that we’ve had any sort of mention that there are issues. Your theory of why it could be an issue and the issues mentioned by @joesen and @pedrom34.

I would expect more of an uproar about this moronic change if it was causing issues for the 28k+ installs that swag has had since this PR was submitted. Another factor to consider that if you haven’t got your client IP’s passing through to your logs correctly, every connection will look like the same IP so of course it will seem like lots of 401 requests and fail2ban triggering a ban.

Anyways, @pedrom34 / @joesen - please provide some info about your setup/logs/app you’re proxying and we can help look at it. Jumping on our discord is always good as there are tons of people there that are always willing to help.

Wow. That kinda escalated quickly :sweat_smile:
I really didn’t want to start a fire by digging up this topic. Sorry about that.

I took a look at my logs, and it seems it’s DavX5 on my android phone (I’m hosting baikal on my server) and a transmission client on both android and on my pc that generate the 401 errors. And for DavX5, it generate 6 or 7 401 on a minute.

I don’t understand why as the credentials are provided on those apps, and for instance DavX5 is connecting to the server without any issue.

I’m on my phone right now but I’ll post logs and details tomorrow morning.

1 Like

Ok, so, my setup:

  • I have my router ( connected to my ISP box ( The router is in DMZ;
  • My server, a SBC with dietpi ( is running portainer;
  • On portainer, I have a container for haugene’s transmission with openvpn, and a container for swag;
  • On my server, there’s also baikal;
  • I also have a synology nas ( running a webdav server.

Everything is running smoothly.

For the logs and conf of swag, I cannot publish more than 2 links, so you’ll find here:

  • nginx-unauthorized.log for today;
  • jail.local conf for fail2ban, I deactivated the unauthorized jail as it kept on locking me out;
  • the dav subdomain proxy conf I use to connect to my baikal server with DavX5 and Thunderbird;
  • the transmission subdomain proxy conf I use to connect to haugene container from transdroid client on android and transmitter client on firefox on windows;
  • the webdav subdomain proxy conf I use.

I can provide other logs or details, just tell me what do you need.

Thanks :slight_smile: