Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The WordPress “background request blocked” notice is a diagnostic result, not a single fault. WordPress could not complete a request from your site back to its own public URL, reach a REST API route, or run an HTTP check used by Site Health. The cause can be a plugin or theme, an intentional HTTP restriction, REST or firewall rules, web-server settings, DNS, TLS, or HTTP authentication.
Open Tools > Site Health, expand the failing test, and record its exact status code or cURL message before changing anything. Then work through the checks below in order: isolate plugins and the theme, inspect wp-config.php, compare the failure with server and firewall logs, and involve your host if the block is outside WordPress.
What the “background request blocked” warning means
WordPress Site Health runs tests through its REST API for background updates, loopback requests, and ordinary HTTP requests. A loopback request is WordPress connecting to its own public site, rather than a visitor connecting from a browser. WordPress uses loopbacks to run scheduled WP-Cron events and to check whether plugin or theme edits can be completed safely.
The warning therefore describes a failed communication path. It does not identify the failing component by itself. The request may be rejected by a plugin, theme, WordPress HTTP policy, REST access control, a web-application firewall, a reverse proxy, HTTP authentication, DNS, TLS/SSL, or a host firewall.
Site Health exposes the tests through REST routes including /wp-site-health/v1/tests/background-updates and /wp-site-health/v1/tests/loopback-requests. A failure on one route does not prove that every REST request is unavailable, so use the detailed result and the affected feature to narrow the diagnosis.
Check the exact failure before changing settings
Changing several security or server settings at once can hide the original cause. First capture the evidence WordPress gives you.
- Sign in with an administrator account.
- Go to Tools > Site Health.
- Open the Status tab and expand notices for REST API, loopback requests, background updates, and HTTP requests.
- Copy the complete message, HTTP status code, cURL error, requested URL, and timestamp. Keep capitalization and punctuation intact.
- Note what else is failing: scheduled events, automatic updates, the block editor, a plugin integration, or only the Site Health test.
The distinction matters. A 403 usually indicates an access rule, a 404 often indicates a missing or rewritten route, a 5xx response points to an application or server error, a timeout suggests routing or firewall trouble, and a TLS message indicates certificate or hostname validation. These are useful directions, not proof; confirm them in logs.
Use this fix sequence
1. Temporarily deactivate plugins
Plugins commonly add authentication checks, REST restrictions, outbound-request policies, or security rules that affect a self-request. From Plugins > Installed Plugins, deactivate all ordinary plugins, then run the Site Health test again.
If you cannot reach the dashboard, use your host’s file manager or SFTP to rename the wp-content/plugins directory temporarily. That disables standard plugins without deleting their files. Restore the original directory name after testing.
When the warning clears, reactivate plugins one at a time and rerun the test after each activation. The plugin activated immediately before the failure returns is the likely conflict. Check its settings for REST restrictions, login protection, XML-RPC or loopback controls, outbound HTTP allowlists, maintenance mode, or IP-based rules. Update it and consult its documentation before changing a security setting permanently.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteMust-use plugins in wp-content/mu-plugins are loaded automatically and do not appear in the normal plugin list. Include them in the investigation when your host or developer permits it. Do not delete a must-use plugin to test; ask the provider or developer to disable it safely.
2. Switch to a bundled default theme
A theme can intercept REST requests, require authentication, send redirects, or add server-facing security hooks. Temporarily switch to an installed bundled WordPress theme from Appearance > Themes. If the warning disappears, the original theme is involved.
Inspect the original theme’s custom code, especially filters that alter REST responses, login behavior, HTTP headers, redirects, or scheduled tasks. Test with the theme’s current release and a staging copy where possible. A theme conflict should be fixed in the theme or its child theme, not by leaving a production site on a default theme.
3. Check WordPress outbound HTTP restrictions
Open wp-config.php and look for the WP_HTTP_BLOCK_EXTERNAL constant. When it is enabled, WordPress blocks external HTTP requests unless the destination is explicitly permitted. This can be intentional on locked-down sites.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
If the policy is required, use WP_ACCESSIBLE_HOSTS to allow the hostnames that WordPress must contact. The value is a comma-separated list and can include wildcard domains. For example:
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.example.com' );Use the actual hostnames required by your site, and preserve any existing entries. Do not remove a deliberate block merely to make Site Health green: the restriction may be part of a security design or compliance control. Have the administrator who added it confirm the intended allowlist. A change to wp-config.php can also cause a PHP parse error, so keep a backup and edit carefully.
4. Test REST access and edge controls
Security plugins, web-application firewalls, ModSecurity rules, reverse proxies, and hosting control panels can reject the request before WordPress handles it. HTTP Basic Authentication on a staging site is another common reason for a self-request to receive a 401 or 403 response.
Check whether the public site URL redirects between HTTP and HTTPS, changes hostnames, or requires a login. A loopback must be able to reach the same canonical URL that visitors use. A proxy that permits browser traffic but blocks requests originating from the server can produce a Site Health failure even when the homepage loads normally.
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 errorsCompare the timestamp from Site Health with access, PHP, web-server, WAF, and firewall logs. Look for the requested path, response code, rule identifier, source address, redirect chain, and upstream error. If a security rule blocked the request, create the narrowest exception possible for the affected route or authenticated server request, then retest. Avoid disabling an entire firewall when a single rule can be corrected.
5. Check web-server, DNS, TLS, and authentication configuration
The server must be able to resolve the site’s hostname, establish a TCP connection, negotiate TLS when HTTPS is used, and receive a valid response. Verify all of the following with the host or server administrator:
- The site’s DNS records resolve from the hosting server, including any IPv6 record that the server may prefer.
- The certificate is valid for the exact hostname in WordPress’s WordPress Address (URL) and Site Address (URL) settings.
- The certificate chain is complete and the server clock is accurate.
- Port 80 or 443 is reachable as appropriate, and an internal firewall is not rejecting connections from the server itself.
- The web server routes the REST path to WordPress rather than returning a static 404.
- Redirects do not loop, downgrade HTTPS, or send the request to a private hostname.
- HTTP authentication is either removed from the public endpoint or configured so the server-side request can authenticate legitimately.
Do not “fix” a TLS error by disabling certificate verification. Correct the certificate, hostname, chain, DNS, or server time instead. Similarly, do not make a private staging site public solely to satisfy Site Health; decide whether loopbacks are required for that environment.
6. Ask the hosting provider to inspect server-side blocks
If plugin and theme isolation and the WordPress configuration check do not resolve the warning, the remaining cause is often outside the dashboard. Send the host the exact Site Health message, URL, status or cURL error, and timestamp. Ask whether its security rules, firewall, DNS resolver, SSL configuration, reverse proxy, or HTTP authentication blocks the site’s own URL or the REST routes.
Request the relevant log entry rather than a generic “everything is working” confirmation. The host can determine whether the request reached the web server, was stopped at the edge, failed DNS resolution, or was rejected during TLS negotiation. If the host cannot change the rule, ask for the precise allowlist entry or routing correction required by your server.
Match the response to the likely layer
Use the response and the scope of the impact to choose the next check. The same code can have different meanings on different stacks, so verify every conclusion with logs.
| Observed result | More likely causes | What to inspect |
|---|---|---|
| 403 Forbidden | Security plugin, WAF or ModSecurity rule, authentication policy, IP restriction, or REST permission check | Plugin settings, WAF rule ID, web-server access log, REST route permissions |
| 401 Unauthorized | HTTP Basic Authentication or another login requirement on the public URL | Reverse-proxy and web-server authentication settings; whether the loopback can authenticate |
| 404 Not Found | Incorrect site URL, rewrite failure, proxy route omission, or REST endpoint not reaching WordPress | Canonical URL, rewrite rules, proxy routing, and the request path |
| 500–599 response | PHP fatal error, plugin/theme exception, upstream failure, or overloaded server | PHP and web-server error logs at the test timestamp; plugin and theme isolation |
| Connection timeout | Firewall, blocked port, routing problem, DNS resolution failure, or a server that cannot connect to itself | DNS from the host, firewall logs, ports 80/443, IPv4/IPv6 behavior |
| TLS or certificate error | Expired or mismatched certificate, incomplete chain, incorrect SNI, bad DNS target, or server clock | Certificate names and dates, chain, DNS records, proxy TLS configuration, system time |
| Only Site Health fails | Test-specific restriction, transient edge rule, or a route that is not used by normal visitors | The exact REST test route and logs; do not assume all site functions are broken |
| Cron, editor, or updates also fail | A broader loopback or REST availability problem | Scheduled events, block-editor requests, update logs, and the same server-side controls |
Understand which WordPress features depend on the request
WP-Cron and scheduled events
WordPress uses loopbacks when triggering scheduled events. If the request is blocked, publishing delays, missed maintenance jobs, backup tasks, email queues, and plugin schedules may accumulate. Some hosts replace visitor-triggered WP-Cron with a system cron job, but that does not automatically repair other loopback or REST failures. Check the site’s scheduled-event status after fixing the underlying request.
Plugin and theme edit safety checks
Before WordPress saves a plugin or theme edit, it can perform a loopback check to ensure the change does not make the site inaccessible. A blocked loopback can prevent the editor from confirming a safe change. Use SFTP or a staging environment for code changes while diagnosing the problem.
Block editor and REST integrations
The block editor communicates with WordPress through REST endpoints. Third-party integrations, mobile clients, and administrative tools may do the same. A warning limited to the background-update test may not affect these features, while a REST API failure can prevent editor requests or integration calls. Test the affected feature itself instead of treating the Site Health color as the only result.
Retest without losing the evidence
After each change, rerun the relevant Site Health test and record the result. A successful test should show that the request receives a valid response without an authentication challenge, redirect loop, timeout, or TLS error.
- Restore any temporarily renamed plugin directory and reactivate plugins one at a time if you used isolation.
- Return to the production theme after testing, unless its code is the identified cause.
- Confirm the canonical URL and HTTPS settings in Settings > General.
- Run the Site Health tests again and compare the new timestamp with server logs.
- Open the block editor, trigger a harmless scheduled event, and check automatic-update status if those features were affected.
- Review logs after the successful run to ensure the fix did not merely suppress the visible warning while another request still fails.
Keep a record of the changed rule, constant, plugin, theme, or server setting. If the warning returns, that record lets you identify a recurring deployment, certificate renewal, firewall update, or plugin update quickly.
When the warning can be left for later
A non-production site protected by intentional HTTP authentication or an outbound-request policy may be unable to perform a loopback by design. In that case, document the limitation and confirm that the affected features are not required. Do not ignore the warning on a production site until you have checked scheduled events, editing safeguards, automatic updates, and any REST-dependent integration that the site uses.
Prevent future background-request failures
- Keep WordPress, plugins, themes, PHP, and server software supported and current.
- Use a staging site to test security-plugin, WAF, reverse-proxy, and authentication changes before production.
- Document intentional values for
WP_HTTP_BLOCK_EXTERNALandWP_ACCESSIBLE_HOSTS, including who owns the allowlist. - Monitor certificate expiry, DNS changes, and firewall-rule deployments.
- Keep access, PHP, WAF, and firewall logs available long enough to correlate a Site Health timestamp.
- Use the narrowest REST or firewall exception needed; avoid globally disabling security controls.
- After migrations, domain changes, or HTTPS changes, test the public canonical URL from the hosting server’s network.
What to give support if you need escalation
A useful support request contains the WordPress version, hosting environment, public site URL, exact Site Health message, HTTP status or cURL text, affected REST route, time in UTC, and whether deactivating plugins or switching themes changed the result. Include the relevant log excerpt with secrets, cookies, authorization headers, and private IP details removed. State whether the block affects cron, editing, updates, the block editor, or only the diagnostic test.
That information lets a host or developer identify the failing layer instead of asking you to disable unrelated security features. Once the server-side response, WordPress policy, or plugin conflict is corrected, rerun the tests and verify the dependent features that matter to your site.
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.
