Cloudflare Shows an Origin Error and My Site Says “Database Connection Error”: What to Do

When Cloudflare reports an origin error and your WordPress site says “Error establishing a database connection,” you may be seeing two symptoms of one outage—or two separate problems. Cloudflare sits between visitors and your web server. WordPress, meanwhile, needs to connect to its database before it can display most pages. If DNS vs hosting issue the server is down, overloaded, or unable to reach the database, both messages can appear.

Start with the quickest reversible checks. Don’t change DNS, edit files, or disable security tools at random. Record what you see, preserve a backup before changing anything, and work out whether the failure is at Cloudflare, the origin server, or the database.

First: Capture the Error and Check the Scope

Write down the exact message, Cloudflare error code, affected URL, and the time you first noticed the outage. Include your time zone. Take a screenshot if possible. These details help your host or developer compare the incident with server and database logs.

Check the site from a second connection, such as a phone using mobile data, and test a few URLs: the homepage, a post, and /wp-admin/. If only one page fails, the problem may be narrower than a full-site outage. If every page fails, focus first on server and database health.

• Check whether Cloudflare’s status page reports an incident.
• Check your hosting control panel for maintenance notices, resource warnings, or a server outage.
• Note whether email hosted on the same server is also affected. That can be a useful clue, though it does not prove the web server is down.

Understand What the Cloudflare Error Means

Cloudflare’s error code can help locate the failing connection. The exact wording can vary, so record the code shown on the error page rather than relying on a description alone.

Example code Common meaning First area to check 521 The origin web server refused or did not accept Cloudflare’s connection. Web server status, firewall rules, and origin availability. 522 Cloudflare timed out while trying to connect to the origin. Server load, network reachability, and firewall behavior. 524 Cloudflare connected to the origin, but the origin took too long to respond. Slow requests, resource limits, or an overloaded application/database. 520 The origin returned an unexpected or empty response. Web server, application, or origin logs.

A Cloudflare error does not automatically mean Cloudflare caused the outage. If WordPress itself reports a database connection error, the origin may be responding but unable to complete the request. Conversely, if the origin cannot be reached at all, the database message you saw earlier may be a separate symptom from before the server became unavailable.

Fast, Reversible Triage

1. Check whether the hosting account and server are online. Look in the control panel for server status, account suspension notices, resource limits, or maintenance messages.
2. Check the incident timeline. Ask whether a deployment, WordPress update, password change, migration, DNS change, or hosting change happened shortly before the outage.
3. Test the origin without changing DNS. A controlled bypass proxy test can help distinguish a Cloudflare-to-origin problem from an origin application problem.
4. Check database service status and credentials. Do this before editing WordPress files.
5. Make one change at a time. Record the result and how to reverse it before moving to the next step.

Avoid repeatedly refreshing a failing site or launching multiple repair attempts. During an outage, unnecessary requests can add load to an already struggling server.

Run a Safe Bypass Proxy Test

A bypass proxy test means testing the origin server directly instead of sending the request through Cloudflare. It can help answer this question: “Does the origin respond correctly when Cloudflare is not in the request path?”

The safer approach is to test with the origin IP while preserving the site’s hostname. If you have command-line access and know the correct origin IP, a technical administrator can use a command like this, replacing the example values:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

This sends a test request to the specified IP while keeping the hostname and HTTPS details. Use the real domain and confirmed origin IP; 203.0.113.10 is only an example. Do not paste private credentials into commands or share them in support tickets.

If the direct request also fails, investigate the origin server or application. If it works directly but fails through Cloudflare, check Cloudflare’s origin settings, firewall rules, SSL/TLS configuration, and whether Cloudflare’s published IP ranges are allowed through the server firewall.

Do not permanently expose the origin IP or broadly disable the firewall just to test. Avoid switching a DNS record to “DNS only” during a live incident unless you understand the security and traffic implications. If you temporarily change a Cloudflare setting, record its previous value and restore it after the test.

Check Hosting and Server Health

A server health check should establish whether the web server and database are running, whether the server has available resources, and whether network traffic can reach the site. If you have a hosting panel, check its service and resource dashboards. If you have server access, review system and web-server status using your provider’s documented tools.

Look for signs such as exhausted disk space, high CPU or memory use, a database service that stopped, a full process limit, or repeated restarts. A full disk can prevent WordPress from writing logs or temporary files. Heavy traffic or a long-running database query can also make the origin slow enough to trigger a timeout.

• Check disk usage, memory, CPU, and process limits.
• Check whether the web server and database services are running.
• Review web-server and database logs around the timestamp you recorded.
• Look for recent resource-limit notices or account suspension messages.

If you lack server access, send the host a focused request rather than a vague “my check here site is down” message. For example: “At 14:32 UTC on October 15, requests to example.com returned Cloudflare error 522, and WordPress displayed ‘Error establishing a database connection.’ Please confirm whether the origin web server and MySQL/MariaDB service were running, whether resource limits were reached, and whether your logs show rejected or timed-out connections.”

Check WordPress Database Credentials

WordPress stores its database connection settings in wp-config.php, usually in the site’s document root. The key values are:

• DB_NAME — database name
• DB_USER — database username
• DB_PASSWORD — database password
• DB_HOST — database server hostname or connection address

These values must match the database and user configured by your hosting provider. Do not assume that DB_HOST is localhost. Some hosts use a specific hostname, socket path, or managed database address. A recently changed password, migration, restored backup, or hosting move can leave the values out of sync.

Back Up Before Editing wp-config.php

Before opening or changing the file, make a copy of the current wp-config.php and store it somewhere private. The file contains sensitive credentials, so do not email it unprotected, post it publicly, or include it in a screenshot. Use your host’s secure file manager or a secure connection, and avoid editing it if you are unsure which copy belongs to the live site.

Compare the four values with the hosting control panel or the credentials supplied for the current database. Check for accidental spaces, missing quotation marks, or a password that changed during a migration. Do not paste the password into a public chat or ticket.

What changed: If you correct a value, note which setting you changed and where the confirmed value came from. How to roll back: Restore the private backup if the edit makes the error worse. If the values are correct, do not keep changing them; move on to database availability and permissions.

Confirm the Database Is Available

Correct credentials cannot connect to a database service that is stopped, unreachable, or refusing connections. In your hosting panel, check whether the database exists, whether its user is assigned to it, and whether the user has the necessary permissions. A database name or username may include a hosting-account prefix, so compare the full value exactly.

Some hosts offer a database status tool or a way to test a connection. Use only the provider’s documented method. Avoid running repair commands or changing database permissions unless you have a current backup and understand the effect. If the database service is down or the account has reached a limit, the host will need to confirm and resolve that server-side condition.

Use WordPress’s Database Repair Option Carefully

WordPress has a database repair mode that may help with certain table problems, but it is not a fix for incorrect credentials or a stopped database server. Back up the database first. If you enable a repair option in wp-config.php, remove it immediately after the repair; leaving it enabled can expose a repair page to visitors.

Do not use database repair as the first response to a Cloudflare origin error. First confirm that the origin is reachable, the database service is available, and the credentials are correct. If you are not comfortable working with database tools, ask your host or WordPress maintainer to verify the database and take a backup before attempting repair.

What Changed and How to Roll Back

Keep a short incident scratchpad as you work. Include the exact error text, Cloudflare code, URL, timestamp and time zone, test result, and every setting or file you changed. This prevents repeated guesses and gives support staff useful evidence.

Change What changed to record How to roll back Edited wp-config.php Setting name, time, and confirmed source of the value. Restore the private pre-edit copy. Changed Cloudflare proxy or SSL setting Previous and temporary values, plus test result. Restore the recorded original value. Changed a firewall rule Exact rule and reason it was changed. Reinstate the prior rule; do not leave broad access open.

When to Escalate

Escalate promptly if the server is unreachable, the database service is down, disk or resource limits are exhausted, or you cannot verify the database credentials. Ask the host to check origin reachability, web-server and database service status, resource limits, firewall events, and logs at the exact time of failure.

If the origin responds directly but Cloudflare does not, share the Cloudflare error code and the result of your bypass proxy test with the person managing Cloudflare. If the origin responds with a WordPress database error, provide the host with the database hostname and time of the failed request—but never send the database password in an ordinary email.

After the Site Comes Back

Confirm the homepage, a few internal pages, and /wp-admin/ work through Cloudflare. Check that HTTPS is valid and that any temporary test settings have been restored. Review logs for a recurring cause, such as failed database connections, resource exhaustion, or blocked Cloudflare traffic.

The key is to separate the layers: Cloudflare’s connection to the origin, the health of the origin server, and WordPress’s connection to its database. A measured, reversible check at each layer is safer—and usually faster—than changing several settings at once.