Cloudflare reports 520 when the origin returns an empty, unexpected or unknown response. It does not identify a particular WordPress plugin. Match the failed request with origin-server evidence before changing the application.
Capture the failed request
Save the full affected URL, the time and timezone, the Ray ID if shown, and whether the failure occurs on a public page, wp-admin or an AJAX request. Note if it happens for every visitor or only after a particular action. A screenshot is useful, but the request details give the host something concrete to search for.
Compare origin and application evidence
Ask the hosting provider to correlate web-server, proxy and PHP logs at that time. An application failure, a worker termination or a malformed response may leave different traces. Compare a failing route with a working route on the same site. Do not conclude that WordPress is healthy simply because a cached homepage still loads.
Review recent changes in the request path
List changes to PHP, the server, Cloudflare settings, security rules, certificates and application code. Prioritize changes that match when the error started. Test an origin connection only through an approved diagnostic method that preserves the expected hostname and TLS validation. Avoid exposing an otherwise protected origin or globally disabling a firewall to see what happens.
Coordinate a targeted correction
The repair may belong to the host, the Cloudflare configuration or the code producing the response. Use the logs to decide ownership. If a WordPress update is implicated, compare the affected request on staging and fix or roll back the responsible component. Keep one change per test so an intermittent success is not mistaken for a confirmed repair.
Verify through the normal public route
Retest through Cloudflare using the action and visitor state that originally failed. Check both cached and uncached behaviour where applicable. Observe relevant logs long enough to cover the previously failing operation, and record any remaining intermittent failures. The goal is a valid origin response under the actual traffic path, not merely a temporarily loading page.
Questions about this problem
Should I disable every plugin?
A 520 response alone is not enough evidence for that. Start with the failed request and server logs; isolate application components only when the evidence points there.
Why does only wp-admin fail?
Administrative requests often bypass page caches and exercise different code paths. Compare the actual origin responses rather than assuming all pages have the same execution path.
Primary references
General diagnostic guidance, not a diagnosis of an individual site. Use a recoverable copy for changes that may affect production.