2

Any advice for debugging a 520 error from Cloudflare?

I know this isn’t SO but Ive been having the toughest time finding a decent way to find the cause of a 520 error from Cloudflare.

I have a droplet of Digital Ocean running Apache 2.4X and randomly throughout the day I will get 520 errors in the browser’s Networking log.

Naturally, there’s nothing even noted in the Apache error log or access log. And Cloudflare has no logs on this in the console.

If I retry the request it will go through with no problem.

Anyone experienced something like this?

Comments
  • 2
    Anything is SO if you're stubborn enough.
  • 1
    Never ever use cloudflare
  • 1
    If @FrodoSwaggins says not to use cloudflare, you should listen.
  • 0
    @FrodoSwaggins Too late. It’s already deeply integrated into all of my “infrastructure”.

    Looks like a couple 520 errors a day is going to be the new norm.
  • 3
    @Nachfolger cloudflare is literally a terrorist organization. Their anti ddos firewall platform that does external crypto can see all your ptxt traffic

    Which is short for you don’t have to be a genius to know it’s an NSA way of defeating encryption. Sounds dramatic but if it isn’t that then it’s just some company doing data mining trying to defeat encryption (I say trying but I really mean succeeding) and is that really any better?

    Avoid at all costs. I would cut off all my fingers and toes before using cloudflare.
  • 1
    @FrodoSwaggins and how often are most services hit by ddos's? Basically never. And what damage does it do? Often nothing at all.

    It's insurance against catching a cold.
    And it's free; all you have to do is let someone watch and record every move you make, every sentence you utter, every word you write.
  • 1
    The solution is timestamped logs on the server end, full verbosity, then see what happened.
  • 0
    You have a plugin that causes your website to return over 10 headers.
  • 1
    We actually experienced a simillar problem at my workplace, it turned out that due to recent changes in our network the external domain landed in our central Apache proxy and then went to the actual application server, which had a NGINX proxy serving the application... normally it should just go straight to the NGINX. We ended up having 520 or 500 every few minutes, then the request would go through, then back to errors. No errors anywhere, just status codes in access logs. Probably could've been fixed by fixing Apache configs but changing where the requests go fixed our problem.
Your Job Suck?
Get a Better Job
Add Comment