Finally back again.
Several hours of timed out uploads and downloads and unable to get the website to load.

Found another bot named "Bytespider", which apparently comes from ByteDance, the maker of TikTok. It has now been added to the badbot list. We'll see if this helps things.

Time to check for more.
20min after you posted, the website was unreachable, uploads and downloads taking multiple attempts to get through, and Scheduler requests timing out.
Only just now the web site has been reachable.

---

Grant
Darwin NT, Australia.

Ah, we're back.
The last couple of hours- web site unreachable, uploads & downloads timing out, Scheduler requests hit and miss (mostly miss).

---

Grant
Darwin NT, Australia.

Ah, we're back.
The last couple of hours- web site unreachable, uploads & downloads timing out, Scheduler requests hit and miss (mostly miss).

I noticed that myself. Fortunately, I was able to ssh in remotely and take a look. No obvious bots this time. There were a ton of hits to the file_upload_handler in the access logs, all from different IP addresses and different platforms. Almost like a DDoS attack.

Around 4 hours that time, and much worse than previously- One system started running out of work as it couldn't return the results. Often it couldn't contact the Scheduler- and if it did it then couldn't download new Tasks.

---

Grant
Darwin NT, Australia.

Enable IPv6 address support. If possible, tunnel the domain name using Cloudflare.

Enable IPv6 address support. If possible, tunnel the domain name using Cloudflare.

I am not an expert at this networking admin stuff, so I asked Gemini regarding your suggestion:

• IPv6 Support: Potentially helpful. Many universities have massive, highly optimized IPv6 academic networks. If your server only uses IPv4, it might be hitting throttling limits or NAT (Network Address Translation) bottlenecks on the university firewall. Enabling IPv6 can allow clients to connect directly without passing through a heavy IPv4 NAT table. However, it will only help if your university network supports it and the remote users have IPv6 access.
• Tunneling via Cloudflare: Not recommended for BOINC. Cloudflare's free and standard plans strictly prohibit using their network for high-volume, non-HTML data transfers (like large BOINC input/output files). Proxying heavy data transfers through Cloudflare will violate their Terms of Service and get your domain flagged or suspended. Furthermore, Cloudflare cannot easily sit in front of a server that relies on deep university firewall rules without complex configurations.

Sounds like enabling IPv6 can't hurt. I will do that.

Server side in in the project's config.xml is boincs <dont_generate_upload_certificates/> and <ignore_upload_certificates/> set to false? if set to true it sacrifices some of BOINCs inherent DDOS protection. The tradeoff is speed but I'd suspect this is unlikely to be a bottleneck if certificates are generated and checked