Hi folks,
that issue is weird (and I wouldn't consider it solved). I have this problem too, not with our bugzilla but with sites where I am customer. And the behaviour is mostly erratic, and, just like here, I wasn't able to figure out what actually triggers it. For all the usual assumptions (like those mentioned here already), there are cases where they can be ruled out, and no clue is obtained.
I am usually surfing via my cloud site, so requests come from a datacenter IP, similar to a VPN provider. (So if people want to track me, they can indeed track that static IP for as long as they like.)
Only one shop is sensible and does the right thing: allow me to configure my static IP and then always get straight customer login without 2FA or other hassle.
Some shops block anonymous access from that IP entirely (e.g. reddit).
Most shops behind cloudflare seem to at least remember the IP and not bother me with captchas anymore.
Google does the opposite and sends a virtually endless loop of captchas (a helpful reminder to not use Google).
Now for those that use heuristics. One of them is the German railway service, and it is an endless pain. I do not know what tools they use, I have opened an issue with them (which is done nothing about), and there is no one with a clue to talk to - the maximum I got was "there is a problem with linux" (but it doesn't seem they would consider to solve that problem).
One might now think that the problem comes from the datacenter IP. And at some days it does indeed help to change to a local telco customer uplink. At other days it doesn't, and sometimes I get blocked even when sitting in the railway and using their own network. At some days it does help to use a standard Android device instead of the FreeBSD desktop - at some days it doesn't. It also seems that low bandwidth makes things more difficult. And yesterday I tried to retrieve schedules, with Firefox, via local telco uplink, to no avail, but then using chromium via a datacenter IP in Africa (with ping > 200ms) worked flawlessly.
I find nothing reproducible in these observations. I am now considering whether it could make sense to find somebody at the ministry of transports (the shop is government owned) and talk to them, because it just cannot be that vital public infrastructure is stuck in inaccessibility, while people make laws about accessible websites. (But that one is just symptomatic for the two-faced-ness of modern politics.)
Now getting to Anubis. Anubis is in ports, it is ours to use. And now Your description shows that Anubis can develop the same weird and erratic behaviour. So it seems that with some effort we might be able to figure that one out.
I am using Anubis myself. I run a mirror of our FreeBSD GIT repo, and at some point Huawei got annoying - they wanted to read everything from that mirror thousandfold. I banned their IPs, they switched to Tencent and Alibaba. I banned these also, and they switched to random customer IPs all over the world. (There seems to be quite an infrastructure at their hands.)
So I installed Anubis, with some default config. There was a pause, and then they got through it. I raised the default difficulty from 2 to 6. There was again a pause, and then some queries got through. I looked into these queries, and it is interesting: while my browser takes almost a minute to solve difficulty 6, they apparently can do it in 2-3 seconds?!? Now I tuned some other things, and also switched the HTTP result code from the default 200 to 402 ("payment required"). There seems to be ceasefire for now.
So that is what seems to go on behind the scenes: a fight between reckless AI trainers and website operators, where situations like those described in this thread might be considered collateral damage. (You can contemplate on this: how the highly praised AI depends on the Web to obtain it's knowledge.)
Anubis has a bunch of config, where it basically decides to either allow a request, or block it entirely, or give it a javascript proof-of-work task of adjustable difficulty. It can make this decision based on the IP or on anything in the HTTP request header (or, if you are a paying subscriber, also on geolocation or ASN). It does not seem to do any further interactivity with the browser beyond running some javascript.
