Have the same problem with my setup (where NC is running behind a reverse proxy). I checked that my proxy is setting the X_Forwarded_For header correctly, which was the case.
Also, the Nextcloud Throttler is actually trying to get the original IP from the visitor, so I’m not sure why the Proxy IP is popping up in the Throttle warning at all.
This worked for me on my server with a public facing static IP on NC 27.1.3
Thank you.
And your proxy is defined as a trusted proxy ?
Thanks! I just did that and it went from slow 20 seconds to never log ins to fast again.
But… I don’t know why this was needed.
I have a home lab with a Dell blade server. I have running 3 versions of next-cloud from 23 25 and 28. The fastest is version 23.xx
They get progressively slower and version 28 is the worst.
I log in from my workstation 192.x.x.x and the VM next-cloud on same subnet. This is how I build and test them. Why would this issue be wanted on a default installation? Was never an issue till the new and slow versions.
Why do I have to whitelist when I did not before?
Its fixed I just do not understand the why of it. Anyone?
If you set your log level to INFO (1) then whenever BFP is triggered, it appear appear in you logs.
Your logs will tell you why/what connections are triggering the BFP. The only thing that can trigger BFP is invalid login attempts from a particular source IP address.
You may want to read the recently updated chapter covering BFP in the Admin Manual. It may provide some hints that will help you sort out why it’s being triggered in your environment.
Thanks for the information.
I did set logs to 3 and removed the white list. After a 2 bad log in attempts (on purpose) the warning came back.
The log says this.
no app in context IP address throttled because it reached the attempts limit in the last 30 minutes [action: login, delay: 200, ip: 192.168.0.114]
I’m thinking the brute force detector has changed since version 23 to 27. I never triggered before the new version with the same settings and sever same router etc.
How many log ins does it take to trigger it? I did 2 or 3 bad log on attempts and it went off.
Also how does the throttle last or the setting for it?
I made a 2nd test account log in using a 2nd gamil account. I’ve done that in all my testing so that is not new. The new is the early trigger and sluggish log on speed. The warning logs do go away long as I don’t try log out then log back in.
So each log on triggers it. I tried with the same php settings on version 25.xx and cant get a log throttle warning. So something has changed between 25.xx and nextcloud 28.xxx
This might not apply for web long ons just in a network setup.
Nice pick up Lionel.
Fixed my error efficiently!
I was running my first Nextcloud instance with the sqlite db. I had many Nextcloud clients running on desktops and phones. I started over with a fresh Nextcloud server using mysql and started receiving this brute force message. I believe it was because of all the clients trying to log to the old server. I logged out of all the clients then ran Lionel’s command. The message is gone!
For those running Nextcloud on unRAID, I used this command:
docker exec -it Nextcloud php occ security:bruteforce:reset 10.1.1.1
Why are admin users being throttled in the first place?
Admin accounts are just as likely (and probably more interesting / more likely) to be targeted with brute force password attempts. Keep in mind brute force protection is only triggered for invalid login attempts.
Not only logins 
I am referring to logged in Admins
when my vpn changes my IP i again need to run
occ security:bruteforce:reset ?
I am referring to logged in Admins
Logged in admins by definition aren’t triggering BFP.
when my vpn changes my IP i again need to run
occ security:bruteforce:reset?
No. Only if your environment has a misconfiguration. (Usually reverse proxy related).
See Admin settings->Overview for any errors/warnings.
But the IP of one logged in user can also be the same IP of a loggin in Admin?
I am sorry to contradict again, but even logged in admins can trigger BFP quite easily, e.g. if they are trying to guess talk conversation tokens. Only being an admin does not prevent that.
Exactly, and since BFP is not based on users, but on IPs, there’s no whitelist for Admins.
Indeed and fair. I was simplifying for sake of discussion.