When you say unreliably...

Does it work at first, and then it suddenly stops for a while, before resetting? Or is it sporadic and unpredictable?

Wondering if it's rate limit related. If so, normally an easy fix.

I just run check of my nickname, and it also makes reproducible false positive for Hackenproof

On first run of URL with presumably my profile, it bumped into robot-protection from CloudFlare. Once passed, it gave redirect to URL https://hackenproof.com/error and large 404 letters in the middle. All consecutive attempts to access URL ascribed as my profile led to same error page.

Running curl to same URL leads to 403 code, presumably Cloudflare protection: curl -I https://hackenproof.com/hackers/aytvill

$ curl -I https://hackenproof.com/hackers/aytvill
HTTP/2 403
date: Thu, 21 Nov 2024 11:08:05 GMT
content-type: text/html; charset=UTF-8
content-length: 8189
accept-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
critical-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
cross-origin-embedder-policy: require-corp
cross-origin-opener-policy: same-origin
cross-origin-resource-policy: same-origin
origin-agent-cluster: ?1
permissions-policy: accelerometer=(),autoplay=(),browsing-topics=(),camera=(),clipboard-read=(),clipboard-write=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()
referrer-policy: same-origin
x-content-options: nosniff
x-frame-options: SAMEORIGIN
cf-mitigated: challenge
cf-chl-out: Sv2 vtocz0SlhLjA5i6Lnor9wJz3IWWAUzBu7gfJzanfxHRiAu0xablsw6aXnfYo1eY9xc0hEhUQ3Yk0aHbjqfGaUTl470Yq4tiSYGVZO7hqe eP53BfN5wQ6YJacUjDOH3RmG2L5 CJ4sE/9UIA2A==$V8332 2cuRDBzA/tKECAww==
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=GOt81Ha8gCJxv9xmn1Y7WwES2MYsbsuPRPd9wlOyRAULbLaGtVU6F2kbnHDIETnGoN/Bt1aCUAkE/IZvl/UWw11PrrV7AMo/r7yAEFUZ/Gkdy4AvyPBSfkcevV7eiSHvSw=="}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 8e6038452c1b8da5-HEL
server-timing: cfL4;desc="?proto=TCP&rtt=15985&sent=5&recv=7&lost=0&retrans=0&sent_bytes=3398&recv_bytes=807&delivery_rate=180537&cwnd=245&unsent_bytes=0&cid=9e130cd7ef02879f&ts=33&x=0"

When I initially filed the issue, HackenProof gave a false positive the first time and then gave correct negatives after that. Now that I've gone back to reproduce the issue again, it's reproducibly producing false positives. Passing --dump-response reveals that it's getting an HTTP 403, likely due to Cloudflare protection as aytvill said above.