What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How do you fix cURL error 28 connection timed out in WordPress? Start by identifying the exact Site Health check that failed, then isolate plugin and theme conflicts before changing server settings. A timeout can affect the REST API, a loopback request, HTTPS verification, or communication with WordPress.org, and each points to a different fault.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If Site Health says the REST API encountered an error or that your site failed a loopback request, the immediate problem is that WordPress could not complete an HTTP request within its timeout window. Follow the workflow below, recording the exact URL, wording, status and time after every change.
As an Amazon Associate I earn from qualifying purchases.
What cURL error 28 means in WordPress
cURL error 28 is a timeout reported by the HTTP transport WordPress uses for outbound requests. WordPress may be trying to call its REST API, contact WordPress.org, check HTTPS, or connect back to its own public URL. The error does not identify one single defect; it says that a request did not finish before the allowed time.
A loopback request is WordPress connecting back to its own site. WordPress uses loopbacks for WP-Cron, scheduled posts, timed events and checks related to the built-in theme and plugin editors. WordPress’s WP_Site_Health::can_perform_loopback() method sends a POST request to wp-cron.php with a 10-second timeout. If the transport reports a timeout or another transport failure, Site Health marks the loopback test as critical.
WordPress.org’s Advanced Administration Handbook defines a loopback request as when WordPress tries to connect back to its own site and identifies plugin or theme conflicts as the most common cause of loopback failures.
That 10-second limit is a diagnostic boundary, not a recommendation to make every request slower. Raising unrelated PHP execution or memory limits will not repair a blocked route, failed DNS lookup, certificate problem or firewall rule.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsIdentify the failing Site Health test before changing anything
Go to Tools → Site Health in the WordPress dashboard. Open the Status tab and expand the critical or recommended item. Record the complete message, the named URL or endpoint, any HTTP status, and the time shown by your notes. Site Health runs separate checks, so the label matters.
| Site Health check | What WordPress is trying to do | What a timeout can suggest |
|---|---|---|
| REST API | Request a REST endpoint used by the editor, administration screens and integrations. | A plugin, authentication layer, web-server rule or slow application response affecting that endpoint. |
| Loopback request | POST to the site’s wp-cron.php URL and verify that WordPress can call itself. |
A plugin or theme conflict, self-DNS or routing failure, firewall/WAF block, TLS issue or HTTP authentication requirement. |
| HTTPS status | Verify that the configured site can be reached securely and that its certificate is acceptable. | Certificate-chain, hostname, protocol or trust-store problems. |
| WordPress.org communication | Connect from the server to WordPress.org services. | Outbound firewall policy, DNS resolver trouble, proxy or hosting-network restrictions. |
| Authorization-header test | Check whether authorization information survives the server and reaches WordPress. | A web-server or proxy rule that strips or rejects the header, sometimes combined with authentication. |
The REST API handbook documents these as distinct tests, including loopback, HTTPS status, WordPress.org communication and authorization-header checks. Do not assume that a browser test from your laptop proves the web server can reach the same URL; the request originates from the hosting environment.
Step-by-step repair workflow
1. Capture a reproducible baseline
- Open Tools → Site Health → Status and copy the exact error text into a ticket or private note.
- Write down whether the message names the REST API, loopback, HTTPS, WordPress.org or another check.
- Record the affected hostname, path, HTTP status if shown, and timestamp.
- Run the same check once more without changing settings. A transient result should be distinguished from a repeatable timeout.
Keep this baseline. After each diagnostic change, run the same check and note whether the wording, status or response time changes.
2. Isolate plugins, including must-use plugins when applicable
WordPress lists plugin conflicts as the most common cause of loopback failures. A plugin can intercept REST requests, add authentication, make a slow remote call, alter cron behavior or prevent the response from being returned before the timeout.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Make sure you have an administrator account and a current backup or a host-provided restore point.
- Temporarily deactivate all ordinary plugins from Plugins → Installed Plugins.
- If your installation uses must-use plugins, ask the host or developer how to disable them safely for the test; they do not always appear in the ordinary plugin list.
- Return to Tools → Site Health → Status and rerun the exact failing check.
- If the timeout disappears, reactivate plugins one at a time, testing after each activation. The first activation that reproduces the error identifies the regression window.
Do not leave unrelated plugins disabled after the test. Restore the working set, then update, reconfigure or replace the component that causes the failure. If the dashboard becomes inaccessible when plugins are active, have the host use its file or control-panel method to disable them temporarily and preserve the evidence for the developer.
3. Test with a bundled default theme
Theme code can add REST callbacks, change cron hooks, require remote services or emit output that disrupts an HTTP response. Switch temporarily to a bundled default WordPress theme under Appearance → Themes, then run the same Site Health test.
- Note the currently active theme and any required child theme.
- Activate a bundled default theme that is already installed.
- Run the REST or loopback check again and record the result.
- Reactivate the original theme when testing is complete. If the default theme succeeds, inspect the original theme’s HTTP calls and hooks with its developer rather than changing server security settings first.
A successful test with the default theme does not prove the theme is the only problem; it establishes that the failure occurs in the original theme’s code path or in an interaction between that theme and a plugin.
4. Verify WordPress and Site Address settings
Go to Settings → General and confirm that WordPress Address (URL) and Site Address (URL) use the intended hostname, spelling and protocol. If the site is meant to use HTTPS, both values should use the correct HTTPS scheme and should not point at an old hostname, staging domain or unreachable subdomain.
Rank #3
Check the hostname from the server side, not only from a desktop browser. The web server must be able to resolve the name and route a request back to the site’s listener. A public DNS record that works for visitors can still fail from the same host because of split DNS, a private zone, an incorrect resolver or a local routing rule.
5. Ask the host to inspect infrastructure when isolation does not help
If the timeout remains with every plugin disabled and a bundled theme active, escalate with the exact failing URL and timestamp. Ask the hosting provider to inspect:
- Server-side security rules and firewall or WAF logs for a request blocked or challenged because it originates from the site’s own server.
- DNS resolution from the web server, including whether the configured hostname resolves to the correct address internally.
- Routing and listener configuration, including IPv4/IPv6 behavior and whether the web server accepts connections on the expected address and port.
- SSL/TLS negotiation, certificate chain, hostname matching and the server’s trust store.
- HTTP authentication, proxy requirements or rules that reject an unauthenticated request to the site’s own URL.
- Application and web-server logs around the recorded timestamp to determine whether the request arrived, was rejected, or never reached the listener.
These are the escalation checks recommended in WordPress’s Advanced Administration Handbook. Give the host the original Site Health wording rather than a paraphrase; “connection timed out,” “resolving timed out” and an SSL error lead to different investigations.
6. Retest after every change and restore secure settings
- Change one variable at a time whenever possible.
- Run the same Site Health check, not a different test that happens to pass.
- Record the new timestamp, status and exact message.
- Restore plugins, the production theme and any diagnostic setting that was changed.
- Never leave certificate verification, firewall protection or other security controls bypassed. A temporary bypass can confirm a hypothesis, but the secure configuration must be repaired and re-enabled.
How to interpret the wording of cURL error 28
The final phrase in the error is a clue about which stage failed. Treat these as diagnostic heuristics: the exact URL and server environment determine the actual cause.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Error wording | Likely stage | Checks to request |
|---|---|---|
| Resolving timed out | DNS lookup did not complete. | Resolver reachability, authoritative records, internal or split-DNS configuration, and whether the server uses the expected resolver. |
| Connection timed out with no response | The client could not establish or complete a connection to the listener. | Routing, firewall/WAF policy, host-level blocking, address-family selection and whether the web server is listening. |
| Operation timed out after bytes were received | The connection began but the response stalled or was interrupted. | Slow upstream code, a proxy buffering issue, application logs and the response path for the exact endpoint. |
| SSL connection or certificate wording | TLS negotiation or certificate validation failed. | Certificate chain, hostname match, supported protocols, trust store and proxy interception. |
A browser may show a normal page while the server-side request fails because browsers and hosting servers can use different DNS resolvers, routes, IP versions, certificates or authentication contexts.
Choosing between a code fix and a hosting fix
Use the isolation results to decide where to spend effort. The following comparison prevents a network timeout from being treated as a generic WordPress performance problem.
| Characteristic | Plugin or theme fix | Hosting or infrastructure fix |
|---|---|---|
| Where the failure occurs | WordPress code, hooks, authentication handling, remote calls or generated responses. | DNS, routing, firewall/WAF, TLS, HTTP authentication, proxy or web-server listener. |
| Effect of deactivating plugins | The timeout disappears or returns when one component is reactivated. | The timeout remains with plugins disabled. |
| Theme test | A bundled default theme succeeds, implicating the original theme or its interaction with a plugin. | Both the original and default themes fail identically. |
| Scope of affected requests | Usually one endpoint, hook or feature associated with the component. | Several checks, a specific hostname, or all self-requests can fail. |
| What logs show | PHP errors, blocked callbacks, slow remote calls or application-level responses. | DNS failures, rejected connections, TLS errors, WAF events or no request at the listener. |
| Appropriate next action | Update, reconfigure, replace or have the component’s developer correct its HTTP behavior. | Have the host correct the rule, resolver, route, certificate, listener or authentication policy. |
Do not raise PHP limits as a first-line response to cURL error 28. A resource bottleneck is relevant only when measurements and logs show that the server is actually starved or the endpoint is demonstrably slow; a blocked network request will not be fixed by more PHP memory.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common failure patterns and the right branch
Only the REST API test fails
Keep the failing endpoint in view. Disable plugins, switch themes and retest. Pay particular attention to security, caching, authentication and editor-related extensions that add REST hooks or alter authorization headers. If the endpoint still fails with a default theme and no ordinary plugins, ask the host to inspect proxy, WAF and authorization-header handling.
Only the loopback test fails
Prioritize plugin and theme isolation, then verify the self-referential hostname and wp-cron.php path. A loopback failure can stop WP-Cron and scheduled posts even when normal visitor traffic appears healthy. Host-side DNS, routing, TLS and authentication checks are the next step if a clean WordPress configuration still cannot call itself.
HTTPS status fails with certificate wording
Do not disable certificate verification permanently. Have the host verify that the certificate covers the configured hostname, that the complete chain is served, and that the server’s trust store can validate it. Correct the certificate or hostname, restore verification, and then rerun Site Health.
WordPress.org communication fails
This points more strongly to outbound connectivity than to a theme rendering problem. Ask the host whether outbound firewall policy, DNS resolution, a required proxy or a network restriction prevents the server from reaching WordPress.org. A self-loopback test may pass while this external communication test fails.
Several checks fail at once
Capture all messages before changing settings. A shared DNS, TLS, firewall or authentication problem can produce multiple symptoms. If plugin and theme isolation does not change any of them, provide the host with the complete set of timestamps and endpoint names so it can correlate them in server and security logs.
Recommended Free Tools
What to give your hosting provider or developer
A concise evidence packet speeds up escalation:
- The site hostname and whether the failing URL uses HTTP or HTTPS.
- The exact Site Health check name and complete cURL error text.
- The endpoint or path shown by WordPress, including
wp-cron.phpwhen it is a loopback. - UTC or local timestamp with the site’s timezone.
- HTTP status, if Site Health reports one.
- Whether all plugins, must-use plugins and the active theme were tested, and what changed.
- Whether visitors and browser-based tests work while the server-side test fails.
- Relevant web-server, PHP, application, firewall/WAF, DNS and TLS log entries.
Ask for a yes-or-no finding on each layer: Did DNS resolve from the web server? Did a connection reach the listener? Was it blocked by a rule? Did TLS validate? Did HTTP authentication reject it? Did the application return a response before the timeout? This is more actionable than a request to “increase the timeout.”
After the error is fixed
Run the original Site Health check again and confirm that the warning or critical item clears. If the loopback now succeeds, check that scheduled posts and WP-Cron events execute normally. If a plugin or theme caused the regression, document the version and configuration that triggered it before updating or replacing the component. If the host changed a firewall, DNS, TLS or authentication rule, keep a record of the approved secure setting and test it after future migrations, certificate renewals and domain changes.
The durable fix is the one that restores the request path while preserving certificate validation, firewall protection and authentication controls. A passing browser page alone is not proof that WordPress can complete its own server-side HTTP request.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
