Skip to content

Check E1 · Requests from your server to itself

E1: Cloudflare blocks or challenges requests from your own server

Check E1 of Edge Doctor for Cloudflare® sends the requests WordPress sends to itself, such as WP-Cron, and reports when Cloudflare answers with a block or a challenge.

Last reviewed 2026-10-30Plugin version 1.0.1Cloudflare dashboard paths checked 2026-10-25

What the check looks at

WordPress talks to its own site over the network: WP-Cron, the REST API and Site Health all depend on it, and these requests go through Cloudflare like any visitor’s. E1 sends three of them: a POST to wp-cron.php the way WordPress does (skipped when DISABLE_WP_CRON is on), a REST request, and a request for the home page.

An answer counts as a challenge when it carries cf-mitigated: challenge, and as a block when it is a 403 or 429 from Cloudflare with a Ray ID or a 1xxx error code in the page.

Like every request Edge Doctor sends, these go only to the hosts of your Site Address and WordPress Address (home_url() and site_url()). An address WordPress gives on another host, such as a single sign on page, is never requested.

Results and what they mean

ResultWhat it means
PassedConfidence: HighYour server can reach your own site
Cloudflare let every request from your server through.
FailedConfidence: HighCloudflare is blocking your own server
Cloudflare answered at least one request with a challenge page, which a server cannot solve, or refused it. The result names the request, the status and any error code, and the address to allow (masked in the copied report).
Could not checkConfidence: LowThis check could not be completed
Every request failed before an answer came back. See the reasons below.
Not applicableCloudflare is not in front of this site
Check A1 did not detect Cloudflare, so this check sent no request. Reason not_behind_cloudflare.

When the result names a reason

  • loopback_failed: Your server could not reach its own site, so this check had nothing to read. The plugin links this result to its own guide: Your server could not reach its own site.
  • blocked_by_config: WordPress itself refused the requests from your site to itself, so none was sent. WP_HTTP_BLOCK_EXTERNAL is on, and your own address is not let through. The plugin links this result to its own guide: WordPress blocks requests to your own site.
  • not_behind_cloudflare: This site is not behind Cloudflare.

Symptoms you may notice

  • Scheduled posts show Missed schedule, and other scheduled tasks such as backups or emails do not run on time.
  • Site Health reports that the REST API or a loopback request failed.
  • With a payment plugin active, the result adds that webhooks from the payment provider are probably refused the same way: payments can be taken and never recorded.

Why it happens

Security features look at the request, not at who sent it, and a request from your server looks like automated traffic. Bot Fight Mode is the usual cause of challenges, and it cannot be bypassed or skipped with WAF custom rules or Page Rules (Cloudflare: Bot Fight Mode).

Error 1020 means a firewall rule matched. A rule aimed at a country or a network can catch your own server, because the request comes from the server’s own address.

Confirm it by hand

From the server (SSH), send the same kind of request WordPress sends and read the answer:

curl -s -o /dev/null -D - -X POST --data "test=1" "https://example.com/wp-cron.php" | grep -iE "^HTTP|cf-mitigated|cf-ray"

cf-mitigated: challenge, or a 403 or 429, confirms it. The same command from your own computer may pass, because the rule matches your server’s address.

In the Cloudflare dashboard, open the security events, add a filter for IP equals your server’s address, and the sampled logs show the action and the feature that took it.

Analytics > Events, then Add filter: IP equals your server addressPath checked on 2026-10-25 against the Cloudflare documentation. Cloudflare moves dashboard items from time to time; if the path differs, search the dashboard for the setting name.

How to fix it

Allow your server’s address with an IP Access rule. Bot Fight Mode does not trigger when an IP Access rule matches the request first, and allowing an IP bypasses custom rules, rate limiting rules and WAF Managed Rules. Use the address the result shows in full on the report page.

Security rules > Create rule > IP access rulesPath checked on 2026-10-25 against the Cloudflare documentation. Cloudflare moves dashboard items from time to time; if the path differs, search the dashboard for the setting name.

Or turn Bot Fight Mode off, if it is the feature that acted and you do not want to keep it.

Security Settings, filter Bot traffic > Bot Fight ModePath checked on 2026-10-25 against the Cloudflare documentation. Cloudflare moves dashboard items from time to time; if the path differs, search the dashboard for the setting name.

For a custom rule with error 1020, narrow the rule so it does not match your server’s address.

In WordPress: you can also run WP-Cron from a system cron with WP-CLI (wp cron event run --due-now), which does not go through Cloudflare. The REST API, Site Health and webhooks still do, so allowing the address is still the fix.

Limitations

The plugin sends three requests at the moment the checks run. A rate limit or a rule that matches only some of the time may let them through and block others later.

Your server may leave through a different address for different requests, for example over IPv6. Allow every address it uses.

When WordPress refuses requests to its own site, nothing is sent and the result points to the blocked-by-config guide instead.

Sources

Run this check on your own site with Edge Doctor for Cloudflare®, free on WordPress.org.

Edge Doctor for Cloudflare® is not affiliated with or endorsed by Cloudflare, Inc. Cloudflare is a registered trademark of Cloudflare, Inc.