Not sure if it's just me but I routinely get stuck in a captcha redirect loop with archive.today (like captcha button, get redirected back to same captcha page)
Same with me for a few weeks now. Turned on my vpn and things worked. So the other suggestion to not use cloudflare dns is probably what is happening under the covers. Archive doesn't like CF at all.
stuck in a captcha redirect loop with archive.today
Their captcha page is odd, styled to look like Cloudflare's captcha gate but uses reCAPTCHA which Cloudflare publicly spoke about switching from.
Code of the page also seems to include a strange XmlHttpRequest to some blog site with randomized query string (see end of https://pastebin.com/W21Au8RK), along with some fingerprint library (though commented out)
That blog site loads very slow for me if I go there manually - maybe some kind of DoS being directed to it?
Seen this same faux-cloudflare page used on btdig.com too, with the same strange XmlHttpRequest & fingerprint code, pretty weird.
This worked for me. I found that I changed my DNS server to Cloudflare with the AdGuard software installed on MacOS a while back (AdGuard > Preferences > DNS), and changing this to a different server fixed it.
I also used the command `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` on Terminal (double-check this command before using) to flush the DNS cache, so the change would immediately take effect with the archive websites.
The technical reasons behind it are that the archive.today guy wants any takedown notices to be cross-border, so he wants to know what country you are in so he can redirect you to a server outside it.
Cloudflare doesn't support a DNS extension that allows this (eDNS maybe?) and so it fails.
There's a longstanding issue with using Cloudflare DNS. If you change Firefox's secure DNS provider settings to NextDNS the page loads without any captcha.
This is not the longstanding Cloudflare issue. That made Archive sties totally unreachable.
This Captcha issue occurs with non-cloudflare resolvers as well, although with great inconsistency. It depends on the resolver and the user's location when they query. Results can change hours later.
