When using Firefox 133.0.3 frequently first navigation to any page at the domain results in the unbranded Cloudflare 502Bad Gateway response.
What are the steps to reproduce the issue?
using Firefox 133.0.3 frequently first navigation to any page at the britishhiphop.co.uk domain results in the unbranded Cloudflare 502Bad Gateway response. I am serving Wordpress. Refreshing the page loads the page OK. After refreshing some pages can be navigated but the problem returns after several pages have loaded.
The 502/504 errors are caused by a problem connecting to an upstream server - meaning your server is trying to initiate a process and this fails to work as expected or times out. In most cases of 502 / 504 errors, back-end servers are not communicating correctly. When this happens, you will see color page with Cloudflare branding and the Error 502Bad Gateway or Error 504 Gateway Timeout. Review this Community Tip for fixing 502 or 504 gateway errors.
Thank you, can you clear cache & try again? The 502 is a catch all error, the origin is sometime difficult to pinpoint. Do you see the error in your server logs with your hosting provider?
Next, do you know if you have compression enabled at the origin? If so, can you disable it and try again to replicate the error?
Are you getting reports of the error from multiple locations or just visitors from certain locations?
Can you share the output of this trace when enter it in your browser address bar http://britishhiphop.co.uk/cdn-cgi/trace
I don’t think the problem is me as others have the same issue, but all were UK based. This has been happening for some time. This problem is not evident when browsing using Edge or Chrome.
I did use a VPN ang got the same error from SYD.
I will see if I can find anything in the Server logs, but not sure if I can access them or what I am looking for!
Here is the output of http://britishhiphop.co.uk/cdn-cgi/trace:
fl=377f21 h=britishhiphop.co.uk
ip=143.159.50.13
ts=1735422314.269
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0
colo=LHR
sliver=010-tier1
http=http/3
loc=GB
tls=TLSv1.3
sni=encrypted
warp=off
gateway=off
rbi=off
kex=X25519
OK, clearing the WP Super Cache compression may have helped. I have done some browsing on the site since and have not seen the issue return. I will keep an eye on it.
I still don’t understand why this issue only manifested with Firefox and how a single refresh would then load the page. Cloudflare could obviously fetch from the source OK as the site was fine in Chrome and Edge.
I also don’t understand why this would happen if Cloudflare has its own cache, why would it need to fetch the page from source everytime?
Do I now have to leave the compression in WP Super Cache off?
I suppose Cloudflare is giving me benefit of compression by using Brotli from its own cache?
I’ve had issues with this option even on normal cPanel hosting providers, and with domains without using Cloudflare. I guess it’s the “limitation” or something in web server configuration if it’s does or not support such thing.
Could be the new zstd compression at Cloudflare is the issue, however maybe the plugin is sending gzip or broken one, and zstd is on top from Cloudflare, therefrom some conflict happens “on-the-fly” I guess, or the compression from the WPSC plugin is doing something wrong with HTML content (if using different character set, etc.).
I keep “Expert” mode with “Enable Caching”, “Cache rebuild”, “Clear on post update” and only the “Disable caching for logged in visitors. (Recommended)” option enabled, works perfect.
No need. Leverage this compression since it works at Cloudflare edge and serves to your Website visitors compressed content. Keep it disabled at plugin settings page.
Yes. If end-visitors Web browser accepts gzip, brotli or newer zstd, it’s served with one of them.
You can also select and set which one you’d rather prefer to use, or keep it “automatic” to Cloudflare.
HTML isn’t cached by default as follows on the article below. We can set to cache it, however since WordPress you’d have some issues for end-visitors and would need to configure a way to “bypasss the cache on cookie”.
Safer approach is to use plugin to create .html documents (files) of cached versions of your posts and pages, then web server will serve them by default and Cloudflare would cache as needed. I use W3 Total Cache for such case since it’s more advanced features to setup (even free version).
Thanks so much for the response. I could have resolved this as the help did point to possible compression issue between source and Cloudflare. I dismissed this as Cloudflare was working fine for Edge and Chrome.
Something feels ‘unresolved’ even though the issue is no longer present. The site ‘feels’ a little slower on Edge after turning off compression, this may be placebo / psychological.
I’ll have a look at W3 Total Cache and think about whether that would be better than WP Super Cache.
