WP Assistant
By Atiba

Fix Wordfence: “wp_remote_post() test back to this server failed”

Wordfence’s Diagnostics runs a loopback test that posts to your own site. If you see “wp_remote_post() test back to this server failed”, WordPress couldn’t reach admin-ajax.php (or was blocked on the way). Common causes include Cloudflare/WAF rules, host security modules (mod_security), maintenance/coming-soon gates, Basic Auth, bad SSL, IPv6 hiccups, or a plugin conflict. Use the checklist below to identify the blocker and restore scans.

Wordfence > Tools > Diagnostics shows “wp_remote_post() test back to this server failed.” Scans won’t start. I’m behind Cloudflare and also use a coming-soon plugin. How do I fix this?

What this error means

Wordfence asks WordPress to POST back to your site (a “loopback request”) to confirm that background tasks and scans can run. If wp_remote_post() can’t reach /wp-admin/admin-ajax.php or is blocked with 403/503/timeout, Diagnostics reports this failure and scans may stall.

Quick checks (1–2 minutes)

  1. Confirm the failure path: In Wordfence → Tools → Diagnostics → “Connecting back to this site,” expand details and note any HTTP code (403/503/timeout). Also open Tools → Site Health → Status for any Loopback request warnings.
  2. Temporarily disable: coming-soon/maintenance plugins, HTTP Basic Auth (password protection), or any “geoblocking”/firewall plugin. Re-test Diagnostics.

Fix #1: Cloudflare / CDN rules (most common)

CDNs can block your site’s own requests. Do the following:

  1. Tell Wordfence it’s behind Cloudflare: Wordfence → All Options → General → Detection → How does Wordfence get IPs → choose “Use the Cloudflare ‘CF-Connecting-IP’ HTTP header to get a visitor IP”. Save.
  2. Bypass security for AJAX & REST endpoints: In Cloudflare, add a WAF/Firewall rule to Skip security for requests where the URI path contains /wp-admin/admin-ajax.php or /wp-json/. If you use “Under Attack Mode” or “Bot Fight Mode,” exclude those paths.
  3. Re-test: Run the Diagnostics test again.

Why this works: Correct IP detection prevents self-requests from looking like “unknown bots,” and the bypass rule lets loopbacks through Cloudflare untouched.

Fix #2: Host WAF / mod_security / server-level blocks

Hosts often enable rules that block admin-ajax.php or POSTs that look automated.

  1. Ask your host to check error/WAF logs during your loopback test and allowlist /wp-admin/admin-ajax.php from your server’s own IP (loopback). Mention the Wordfence loopback test specifically.
  2. Remove duplicate redirects or odd rewrites in .htaccess that could send admin-ajax.php into a redirect loop.

Fix #3: IPv6/SSL edge cases

Some environments fail loopbacks over IPv6 or with strict SSL validation.

  1. Use IPv4 for scans: Wordfence → Scan → Scan Options and Scheduling → Advanced Scan Options → enable Use only IPv4. Save.
  2. Re-test Diagnostics. If you saw an SSL error, ensure the site’s SSL chain is valid; your host can reinstall the certificate bundle if needed.

Fix #4: Maintenance / coming-soon / Basic Auth

Anything that blocks anonymous visitors will also block loopbacks.

  • Disable maintenance/coming-soon plugins while testing.
  • If the site is HTTP Basic Auth protected, remove it temporarily or configure your server to allow admin-ajax.php through:
<Files "admin-ajax.php">
  Require all granted
</Files>

(Use cautiously; prefer disabling Basic Auth during testing.)

Fix #5: Plugin/theme conflicts

  1. Temporarily deactivate other security/firewall, rate-limit, or anti-spam plugins, then re-run Diagnostics.
  2. Switch to a default theme briefly to rule out theme-level blocks (rare).

Fix #6: Turn off remote-start and re-run

Some setups behave better when scans start locally.

  1. Wordfence → Scan → Scan Options and Scheduling: disable Start all scans remotely.
  2. Set Maximum execution time per scan stage to a modest value (e.g., 20 seconds), save, then run a scan.

Collect clues if it still fails

  • Look for HTTP 403/503 in hosting logs at the exact test time.
  • Enable Wordfence Debugging (Tools → Diagnostics → Debugging Options) and re-test to capture details.
  • Check Tools → Site Health → Status for Loopback request errors that may point to the culprit.

FAQ

Do I need to open my site to the world? No, only make sure your own site can POST to admin-ajax.php. That’s what the bypass/allow rules do.

Will bypassing AJAX reduce security? Not if you scope it precisely to /wp-admin/admin-ajax.php and keep WordPress/plugins updated. The rule simply prevents your CDN/WAF from blocking legitimate loopbacks.

Do scans work with maintenance mode? Typically no. Loopbacks must be able to reach AJAX without a login wall.

Success check

Return to Wordfence → Tools → Diagnostics. Under “Connecting back to this site,” the test should now succeed. Run a full scan to verify.

Need human WordPress help?

WP Assistant is a free tool created by Atiba Software, a WordPress design and development company located in Nashville, TN. If you need more personalized WordPress assistance let us know, and we’ll get back to you ASAP!

Related