Just installed Brave on my PC, trying to go to Twitter causes it to load infinitely for a bit before freezing on the Twitter logo. I’ve tried clearing the cache/cookies, disabling all extensions, running in private browser, and nothing has fixed it. Are there any other ideas?
I do not have an x.com account, but I used a Brave Browser New Window (not Private Window) to visit the site. Next, I opened a Developer Tools (aka “DevTools”) window, so I could see something of what may be going on … and, see the following screenshot … in which, on the right, lists a lot of Server > cloudflare events.
The short of that is, Cloudflare “Keystone” Cops are involved, and like the Google Unified Login Eco-System that keeps demanding more lowering of Brave Browser protection … that may also now be required at X.
Make sure that you are not blocking ‘x.com’ and ‘cloudflare.com’ domains and hostnames.
I try to test, incrementally, by first clicking the Site-Specific Brave Shields (lion icon adjacent to right end of URL address field) → Disable Block fingerprinting … and reload the webpage.
Next, try Allow all cookies. Next, try Block trackers & ads (instead of the Aggressively ...
In other words, inching your way toward what finally works to satisfy the Gate House Guard Shack staffed by the Cloudflare “Keystone” Cops.
Re Cloudflare, see:
‘This site cannot be reached on windows - #4 by 289wk’
‘This site cannot be reached on windows - #6 by 289wk’
Screenshot of DevTools window for ‘x.com’ visit, set to Network tab:
I’ve tried incrementally lowering the shield like you suggest, as well as completely disabling it. Same issue. I’m not sure how to check if I’m blocking a domain or hostname?
I submitted the issue to ChatGPT. Its answer:
Classic **Cloudflare challenge loop** - and Brave’s Shields (especially fingerprinting + cookie blocking) can absolutely trigger it on sites like X Corp. (X.com) that sit behind Cloudflare.
Key domains involved
1. X (Twitter) domains
These are commonly used by X and should generally be allowed:
x.comwww.x.comtwitter.com(still heavily used internally)www.twitter.comapi.twitter.commobile.twitter.comabs.twimg.com(static assets like JS/CSS)pbs.twimg.com(images/media)video.twimg.comton.twimg.com
If cookies or scripts from these are blocked, X can break or loop reloads.
2. Cloudflare domains
Cloudflare doesn’t just use one hostname—it dynamically serves challenges and assets:
challenges.cloudflare.com
(most important for challenge loops)*.cloudflare.com*.cloudflare.net*.cloudflareinsights.com(analytics / bot signals)
The challenge loop often happens when:
cf_clearancecookie can’t be set/read- JS challenge scripts are blocked
- fingerprinting defenses interfere with validation
What to allow in Brave (targeted approach)
Instead of disabling Shields entirely, try:
Step-by-step tuning
-
Cookies
-
Allow all cookies (including 3rd-party) for:
x.comtwitter.comchallenges.cloudflare.com
-
-
Fingerprinting
- Set to “Standard” (not “Strict”) for
x.com
- Set to “Standard” (not “Strict”) for
-
Trackers & ads
- Set to “Standard” (Aggressive can break Cloudflare challenges)
-
Scripts
-
Ensure scripts are NOT blocked for:
challenges.cloudflare.comabs.twimg.com
-
Diagnostic trick (useful for your testing)
In DevTools → Network tab, filter by:
cfchallengetwimg
Look for:
- repeated requests to
challenges.cloudflare.com - 403 / 401 responses
- missing or constantly resetting
cf_clearancecookie
If you see a loop like:
x.com → challenges.cloudflare.com → x.com → challenges.cloudflare.com
…it’s almost always a cookie or fingerprinting rejection issue.
Subtle gotcha
Even if you allow domains manually, Brave’s ephemeral storage / partitioned cookies can still interfere.
So if the issue persists:
- Try a new private window with Shields down
- Or temporarily disable “Forgetful browsing” / aggressive privacy flags
Practical recommendation
Tell the user to:
-
Keep Shields ON
-
Set:
- Trackers → Standard
- Fingerprinting → Standard
- Cookies → Allow all (for site)
-
Specifically ensure:
challenges.cloudflare.comis not blocked
Only if that fails → disable Shields for x.com.
From what ChatGPT suggested, I would use:
[*.]x.com[*.]twitter.com[*.]twimg.com[*.]cloudflare.com[*.]cloudflare.net[*.]cloudflareinsights.com
Brave Browser Settings windows, where you can enter domain names and hostnames:
brave://settings/content/javascriptbrave://settings/cookiesbrave://settings/content/braveShields
I suggest those for hard-to-solve cases, because I have seen reports here at the Brave Community, where making adjustments only via the Site-Specific Shields Setting (lion icon “east” of the URL address field) … has not worked.
Some websites are tricky - they force a reload of a webpage or frame within a webpage, and that, frequently. The cases I have seen - the Site-Specific Shields Settings are miraculously set back to where they were - meaning, in some situations they do not stick.
Thus, the list of Brave Browser Settings windows - where entries made, do stick. An example of how I treat a Google problem:
‘Way too many captchas after every single search after updating to Brave 1.88.136 (Official Build) (64-bit) - #25 by 289wk’
1 Like
Weirdly enough, I left the shield off last night when I closed the browser, and when I opened it again today it worked fine? Will update if it stops working again. Thanks for the help!
1 Like
There can be a difference between,
how a website reacts to:
a) Brave settings that are spur-of-the-moment - ie Site-Specific Brave Shields (lion icon)
b) Brave settings that are already in place - ie my reply above.
Browser Support > Desktop Support
#̴̙͚͖̀͘͝
This is here for a personal marker, please disregard
I did test this from mobile brave, to confirm that twitter.com only does a simple redirect to X.com which is technically x.com
I was also able to confirm that identidy calls are indeed made, cloudflare, etc, however I cant upload the video here due to the size constraints. If it interest you, just ask, but i doubt it will solve your specific problem here.