ERR_CONNECTION_TIMED_OUT means the browser did not receive a completed connection or response in time. It does not identify WordPress—or a particular plugin—as the cause.
Compare the same URL on another permitted network and check whether the request reaches the host, proxy or CDN. That separates a local connection problem from DNS, filtering, server capacity or a WordPress request that begins but never completes.
Keep the exact message, hostname and failure time. DNS lookup failures and a CDN’s HTTP error page describe different stages and should be recorded separately.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Find the last layer that receives the request
| Comparison | What it narrows down | Next check |
|---|---|---|
| One network fails, another works | Network path, resolver or access rule | Original connection and rule logs |
| Several independent networks fail | Wider server or routing problem | Host status and access logs |
| Homepage works, one job times out | Particular application workload | Job logs, workers and external calls |
| Cloudflare error page appears | Proxy reported a specific stage | Use the exact error’s documentation |
| Failure follows a migration | Domain destination | Authoritative A, AAAA and CNAME records |
Separate one connection from a wider outage
- Record the original URL and exact browser message.
- Test that same URL on a second permitted connection.
- Compare an ordinary post and the failing action.
- Note the time and time zone of each result.
- Use those comparisons to decide whether network or host investigation comes first.
Try the site on another device or permitted network and check the host’s reported service status. If mobile data works while home Wi-Fi does not, investigate the original network path, resolver or access rules before changing the website.
If several independent connections fail, the server or its public connection deserves attention. That is evidence of a wider problem, although it still does not identify a particular plugin or hosting limit.
Note the time and time zone, exact error and tested addresses. A report that the homepage works but one import request times out gives the host a much clearer starting point than “the site is down.”
Check what changed around the domain
A recent migration can leave a hostname pointing to an old server. Compare authoritative DNS records with the destination supplied by the current host, including relevant A, AAAA and CNAME records.
Different visitors can follow different paths. An incorrect IPv6 destination, for example, may affect some connections while others reach the correct IPv4 server. Check the records and results rather than deleting records without understanding their purpose.
A DNS lookup failure is not the same error as a connection timeout. Browser messages can distinguish these stages, and the exact message matters. Clearing local DNS data can help with a stale result but does not repair an incorrect authoritative record.
A proxy error provides a different clue
If the site uses a CDN or reverse proxy, visitors may receive an HTTP error page from that service instead of a browser timeout. The response code and provider identify a different point in the path.
Cloudflare 522 concerns origin connection timing; 524 indicates a connection was established but the expected response did not complete within the applicable timeout. These should be investigated using the current documentation for that error rather than treated as interchangeable browser messages.
Do not switch off proxying casually to test a protected origin. A host can compare origin behavior using the correct hostname and connection settings without making the origin publicly exposed.
Determine whether WordPress receives the request
Ask the host to match the failure time with access logs and worker or database activity. A missing application request points to a different stage from one that begins and stalls. Keep the hostname correct in any origin comparison; exposing a protected origin is not needed for an initial diagnosis.
If the request never reaches the application, changing a WordPress theme cannot solve the failed connection. Use the last layer that recorded it to decide where investigation should continue.
If the server accepts it but the application takes too long, inspect the particular action. An import, backup or external API request can require much more work than an ordinary post view.
Look for worker queues, slow queries, exhausted memory or stalled external requests. A limit increase may sometimes be appropriate, but only after understanding what the request is doing and whether that workload is reasonable.
Review access rules without removing protection
A firewall can drop connections from a particular address or fail to allow the expected proxy traffic. Compare the failing request with the rule logs and the provider’s current requirements.
A narrow correction to an identified rule is preferable to removing the entire firewall. On a managed connection, the network administrator should investigate restrictions rather than having users bypass them.
Confirm recovery beyond the homepage
After the relevant correction, repeat the original URL and action from the affected connection. Check an ordinary post and the admin workflow too. A cached homepage loading successfully does not establish that new application requests are working.
If the failure remains, share the exact URL, timestamp, comparison results and relevant error or request identifier with the host. Remove credentials and private data from any logs you send. Those details help distinguish connection trouble from an application that receives requests but cannot finish them.
Connection references and escalation evidence
Confirm the original action recovers
Retest from the affected connection at the exact URL. Check a fresh application action as well as the cached homepage. Record the correction and remaining failures so that another timeout can be compared with a known working baseline.