Chromaniac
Well-known member
page_cache iirc is used for internal filesystem guest caching.
That wouldn’t have anything to do with this addon. 520 means your origin web server is returning something erroneous. Typically caused by a misconfiguration of your web server. You’ll want to contact Cloudflare support so they can help you track down what it is exactly.
No idea... my origins are all running HTTP/2 without errors, so not something I know anything about first-hand. If Cloudflare has an error with it, maybe it's specific to certain web server configs?Did Cloudflare resolve their HTTP/2 to origin bug that can cause 520 errors?
Suddenly tons of CF 520 errors
Hello everybody, since yesterday afternoon there are 520 error messages from Cloudflare in our forum. The error occurs completely randomly and everywhere. We only moved to a new server a few weeks ago and everything went perfectly. I will of course also contact my hoster. But I have already...xenforo.com
Ya, if it's limited to certain servers, I'd say it's probably a server config thing, not a Cloudflare thing. But who knows... like I said, I've never seen it myself so no idea if Cloudflare "fixed" anything on their end.I haven't had it happen on my own servers, fortunately. Only a small number of my clients have had this. The first client... wow what a headache it was tracking it down to a Cloudflare issue!
It'sNope... no clue whatpage_cache
is. Probably a third-party addon (no reference to it in XenForo's source).image_cache
is the directory that the image proxy uses.
But ya, you can move it to R2 if you want... however, it's a pretty terrible idea to store cached things in the cloud if you ask me... But do whatever you want.
image_cache
, not page cache
. It's not something I would do... but like I said, there's nothing preventing you from doing it, so have at it.It'simage_cache
, notpage cache
.
(My brain's in automotive repair mode today, not "coding like it's 1996" day...)
So since it's the image proxy cache, it should work the same as having attachments in R2, I'm thinking?
I wouldn't store anything else in R2 though.
/dev/shm
(a RAM volume). /tmp, /var/logs/nginx (web server logs), image_cache, oembed_cache, etc... these are all things that aren't going to be catastrophic if the server reboots and loses what's in memory... it saves a lot of disk writes (especially for things like /tmp and web logs) and accessing it is extremely fast.totally agree with you, that's why I have a feature request to have R2 attachments local cached...It's not something I would do... but like I said, there's nothing preventing you from doing it, so have at it.
To me a "cache" is something that doesn't need to persist (nothing catastrophic is going to happen if you lose the contents of the cache) and should also be very fast. Storing it in R2 makes it not super fast... request comes in, server handles it, first makes an API call to fetch the image from some remote data center where R2 data lives, then it needs to take that and pass it through to the user. So let's say it's a 10MB image... the server needs to download 10MB from R2 before it can then send that same 10MB to the user.
Again... it will work, but to me a cache should be local and as fast as possible. Like for me, I have a lot of things on my servers mapped to/dev/shm
(a RAM volume). /tmp, /var/logs/nginx (web server logs), image_cache, oembed_cache, etc... these are all things that aren't going to be catastrophic if the server reboots and loses what's in memory... it saves a lot of disk writes (especially for things like /tmp and web logs) and accessing it is extremely fast.
Just depends on how your server resources are... if you are short on disk space, then ya... probably makes sense to free that up by moving it to R2.
Probably just the standard tools like traceroute and stuff to try and determine where in the route is having problems. The bigger issue is that just like with IPv4, if it’s a switch or router out of your control that is having problems with the underlying network traffic, is well… out of your control. Debugging IPv6 network connectivity doesn’t have anything to do with XenForo or Cloudflare, so the good news is Google is going to be a good resource for anyone on the Internet trying to debug similar issues.Does anybody know a good way to debug cURL 6+7 errors? I can't catch the reason I have it a few times a week seen via ACP. I suspect it has to do with IPV6, but we can't find the real reason for that.
It will work fine, yes.Does Cloudflare work on sites behind an htaccess password?
It does, yes. However I've found that Cloudflare's Zero-Trust Network Access system is more convenient than HTTP AUTH. Same way the addon can lockdown access to the XF admin area, except do it for the whole domain, rather than just admin.php.I've been wondering this for a while. Does Cloudflare work on sites behind an htaccess password? I want to do some testing with an XF install I've been working on, but haven't activated App for Cloudflare on it.
I do like that step, and it also stays in spirit with our license (running a second copy for development, privately).It does, yes. However I've found that Cloudflare's Zero-Trust Network Access system is more convenient than HTTP AUTH. Same way the addon can lockdown access to the XF admin area, except do it for the whole domain, rather than just admin.php.
I tried to traceroute, but it doesn't allow to traceroute to R2 buckets. Pinging works fine by the way with any data loss for over hours of pinging.Probably just the standard tools like traceroute and stuff to try and determine where in the route is having problems. The bigger issue is that just like with IPv4, if it’s a switch or router out of your control that is having problems with the underlying network traffic, is well… out of your control. Debugging IPv6 network connectivity doesn’t have anything to do with XenForo or Cloudflare, so the good news is Google is going to be a good resource for anyone on the Internet trying to debug similar issues.
So I tried to enable IPV6 on the server level and so far so good.I tried to traceroute, but it doesn't allow to traceroute to R2 buckets. Pinging works fine by the way with any data loss for over hours of pinging.
IMPORTANT for existing users: New functionality requires 1 additional API permissions in order to use the new function. You can go to your Cloudflare API Tokens, edit the token you have and add the following permission:
At this point, you should have a total of 19 permissions for your API token.
Account.Billing: Read
- Added sanity check to make...
Account Request Tracer
and Intel
permissions. You can always see all the permissions it's needing for full functionality under XenForo admin -> Options -> CloudflareWe use essential cookies to make this site work, and optional cookies to enhance your experience.