An investigation involving Wordfence, Cloudflare, WordPress cron, PHP, and Nginx uncovered an unexpected interaction between HTTPS enforcement and WordPress background operations.
Managing WordPress security involves considerably more than installing a security plugin and assuming it’s doing its job.
You need to know whether the plugin is functioning, whether scheduled security operations are completing, and whether the systems surrounding it are interfering with its work.
At Paranoid Hosting, we’d been investigating a particularly frustrating problem: Wordfence security scans were failing to run reliably on certain websites, even though those websites appeared to be operating normally.
The websites were online. HTTPS was enforced. Wordfence was installed and configured. Manual scans often worked.
But scheduled scans were another story.
Some failed to start properly. Others repeatedly attempted to resume without making progress. Eventually, their last successful scan dates grew increasingly stale.
For months, we investigated possible causes involving WordPress cron, Cloudflare firewall rules, Wordfence configuration, PHP execution, and server resources.
Along the way, we found and corrected several genuine problems.
But the mystery persisted.
Then we discovered that WordPress was generating HTTP requests for websites that operated exclusively over HTTPS.
That seemingly minor configuration inconsistency turned out to be the missing piece.
A Security Scanner That Isn’t Scanning
Wordfence is one component of our WordPress security infrastructure. Its scanning engine examines installations for malware, suspicious files, known vulnerabilities, and other security concerns.
But a security scanner provides little value if it silently stops scanning.
That’s why we maintain centralized security reporting rather than relying entirely on individual WordPress dashboards.
Our reporting identifies outdated scans, failed scans, vulnerable components, and suspicious files requiring investigation.
When multiple websites began appearing with scans that hadn’t completed in several days, we needed to establish why.
What made the problem difficult was its inconsistency.
Some websites completed their scheduled scans normally.
Others didn’t.
And several of the affected websites could successfully initiate scans when someone clicked the button manually.
That was an important clue.
The scanning engine wasn’t necessarily broken. Something appeared to be interfering with the mechanism responsible for starting scheduled scans.
First Suspect: WordPress Cron
WordPress relies on scheduled events for background operations ranging from publishing content to plugin maintenance and security tasks.
Naturally, cron was one of the first things we investigated.
We examined the scheduled events, checked the relevant Wordfence hooks, reviewed execution schedules, and inspected the plugin’s internal status records.
We found repeated attempts to resume scans that weren’t progressing.
But the evidence didn’t support a simple explanation involving missing cron events or a universally broken scheduler.
Wordfence was attempting to initiate work.
The actual scanning stages just weren’t advancing.
That shifted our attention toward the request used to launch the scan.
Second Suspect: Cloudflare
Our WordPress hosting infrastructure uses Cloudflare extensively, including its Web Application Firewall.
Cloudflare’s security controls are valuable, but legitimate background operations can occasionally trigger firewall protections.
Wordfence uses WordPress’s admin-ajax.php endpoint for various operations, including scan initiation.
During our investigation, we discovered Cloudflare Managed Challenge rules interfering with certain Wordfence AJAX requests.
Those were genuine problems.
We corrected the affected rules to permit the necessary WordPress AJAX traffic without broadly disabling unrelated security protections.
That eliminated one potential obstacle.
But some scheduled scans still weren’t completing.
The lesson was becoming clear: finding a legitimate problem doesn’t necessarily mean you’ve identified the cause of every related symptom.
Multiple independent failures can look almost identical from a plugin dashboard.
Looking Inside the Wordfence Scan Engine
Eventually, we stopped focusing exclusively on the settings exposed in the Wordfence interface and examined what its PHP code actually did.
We found that Wordfence can initiate scanning operations by sending a nonblocking HTTP request to the website’s own WordPress AJAX endpoint.
The request targets an action resembling:
/wp-admin/admin-ajax.php?action=wordfence_doScanThe relevant HTTP request uses parameters including:
'timeout' => 0.01,
'blocking' => falseThis makes sense architecturally.
Wordfence needs to initiate a potentially lengthy process without forcing the original PHP request to remain open while the scan runs.
But nonblocking HTTP requests have an important characteristic: they don’t necessarily process redirects in the same way as ordinary blocking requests.
That suggested a question we hadn’t previously examined closely enough.
What if Wordfence was successfully dispatching its scan-launch request, but the request never reached WordPress?
Following the Request Through the Network
We began testing the WordPress HTTP transport directly while monitoring the Nginx access logs.
The behavior was revealing.
Nonblocking requests directed to the website’s HTTP address appeared to be accepted by the WordPress HTTP API, but they never appeared in the origin server’s access log.
Increasing the request timeout didn’t resolve the behavior.
Blocking HTTP requests could reach the server after following a redirect.
Nonblocking HTTP requests did not.
Then we repeated the experiment using HTTPS directly.
This time, the request appeared in the Nginx access log.
We had finally isolated a reproducible difference.
The server was capable of receiving the request.
WordPress’s HTTP transport was capable of sending it.
But when the nonblocking request started with HTTP, it wasn’t reaching the intended endpoint.
The critical difference was the redirect between HTTP and HTTPS.
When HTTPS Enforcement Masks an Internal Configuration Problem
One reason this issue remained undetected was that HTTPS was already enforced throughout our hosting infrastructure.
Websites were configured to use secure connections, with HTTP requests automatically redirected to HTTPS. Visitors accessing an HTTP address were sent to the secure HTTPS version.
From the perspective of a website visitor, everything worked as intended.
That also meant there was ordinarily no visible reason to question the underlying WordPress URL settings. Whether someone entered an HTTP or HTTPS address, they ended up on the secure website.
But HTTPS enforcement at the infrastructure level and HTTPS configuration within WordPress are two different things.
On affected installations, WordPress still had URL settings resembling:
home: http://example.com
siteurl: http://example.comThose settings weren’t preventing browsers from reaching the secure website. Our existing HTTPS redirects handled that.
The complication emerged when WordPress generated URLs for internal background operations.
Wordfence uses WordPress’s URL-generation functions to construct requests involved in launching security scans. In a background execution context, those functions could produce an HTTP URL based on the stored WordPress configuration.
Cloudflare would correctly redirect that HTTP request to HTTPS.
But unlike a browser, the nonblocking request used to initiate the scan didn’t complete the redirect.
Consequently, the request never reached the WordPress AJAX handler responsible for starting the scan.
HTTPS enforcement was working correctly. The problem was that an internal background operation couldn’t follow the redirect that enforcement produced.
That’s why ordinary website testing never exposed the issue.
Correcting the WordPress URL settings to HTTPS eliminated the unnecessary redirect entirely, allowing the scan-launch request to target the secure endpoint directly.
From an Isolated Failure to a Fleet-Wide Configuration Problem
Once we’d identified the problem on one installation, the next question was whether the same mistake existed elsewhere in our hosting infrastructure.
We used our existing fleet-management tools to develop an automated remediation process that connected to our managed servers, discovered WordPress installations, and examined their URL configurations.
We didn’t limit the investigation to websites currently experiencing Wordfence scan failures.
We included development environments, archived installations, and websites excluded from routine maintenance.
The results revealed a widespread pattern.
Numerous WordPress installations were still configured internally with HTTP URLs despite operating over HTTPS.
More significantly, many of those installations were also on our list of websites with stalled or unsuccessful scheduled Wordfence scans.
This was no longer looking like a collection of unrelated security-scanning failures.
We’d identified a common configuration defect capable of explaining the behavior across multiple servers.
Our remediation process corrected affected WordPress URL settings while preserving each website’s hostname and directory structure.
It also recorded successful changes, identified installations already configured correctly, and flagged exceptions requiring individual attention.
The Exceptions That Automation Uncovered
Fleet-wide remediation is rarely as simple as issuing the same command everywhere.
During the process, we encountered an installation whose WordPress URLs were explicitly defined in wp-config.php using the WP_HOME and WP_SITEURL constants.
Those constants override the corresponding database options.
Updating the database alone couldn’t correct the effective configuration.
We addressed the hardcoded values separately.
Another installation required individual attention because unexpected WP-CLI output formatting prevented our automated script from interpreting its existing settings correctly.
Neither exception was particularly complicated once identified.
But they demonstrated why automated maintenance needs reliable error reporting.
A script that claims success without identifying exceptions creates a false sense of security.
Our objective wasn’t simply to execute a command across the infrastructure.
It was to eliminate a configuration defect and identify anything preventing that correction.
Why the Problem Persisted for So Long
Several factors made this issue unusually difficult to recognize.
HTTPS was already enforced. Our infrastructure automatically redirected HTTP requests to HTTPS, so visitors consistently reached the secure versions of the websites. That made the underlying WordPress URL mismatch largely invisible during normal operations.
Manual scans could work. That encouraged investigation of cron and scheduling rather than the underlying scan-launch request.
Some Cloudflare rules really were interfering with Wordfence. Those legitimate issues complicated the investigation and initially appeared to explain the failures.
The failure occurred between multiple systems. Wordfence generated the URL, WordPress dispatched the request, Cloudflare issued the redirect, and the nonblocking request didn’t reach its destination.
There was no obvious website outage. Visitors could continue using the affected websites normally while background security scans failed.
That last point is especially important.
A website can be fully accessible while critical background security operations are malfunctioning.
Without centralized monitoring of scan completion, the problem might remain unnoticed indefinitely.
The Broader HTTPS Configuration Problem
Correcting the WordPress home and siteurl settings addressed the immediate problem with URLs generated for background operations.
But it also exposed a broader issue.
WordPress databases may contain historical HTTP URLs in content, widgets, page-builder data, and custom fields.
Those stored values require separate attention using serialization-aware database tools.
Likewise, configuration files, environment variables, and provisioning scripts can reintroduce incorrect URL settings if they aren’t included in routine audits.
The long-term answer is to treat HTTPS configuration as an enforceable infrastructure standard.
A website operating exclusively over HTTPS should generate HTTPS URLs internally, not rely on a redirect to compensate for incorrect application settings.
That standard matters beyond Wordfence.
Other plugins and background processes may encounter similar problems when their requests depend on redirects that the underlying HTTP client doesn’t follow.
Security Monitoring Needs to Monitor Itself
This investigation reinforced something we’ve long considered essential to managed WordPress hosting.
Installing a security plugin is not the same thing as ensuring that the plugin is doing its job.
A firewall can be enabled while interfering with legitimate security operations.
A scheduled task can exist without completing successfully.
A security scanner can appear properly configured while its scans grow increasingly stale.
And a website can serve HTTPS to every visitor while internally generating HTTP requests that interfere with background processing.
That’s why Paranoid Hosting invests in centralized monitoring, fleet-wide audits, and diagnostic tools that look beyond individual WordPress dashboards.
When a security operation stops completing, we want to know.
When a recurring failure appears across multiple websites, we want to identify the shared cause rather than repeatedly applying isolated fixes.
And when we identify a systemic configuration problem, we want to correct it across the infrastructure rather than waiting for each installation to exhibit symptoms.
The Missing Piece Was Just Five Characters
After months of investigating Wordfence scheduled-scan failures, the decisive breakthrough came from examining the actual HTTP requests instead of relying solely on Wordfence’s reported scan status.
Our testing established why the nonblocking scan-launch request wasn’t reaching its destination.
The subsequent infrastructure-wide audit uncovered the same incorrect HTTP configuration on many of the websites experiencing scheduled-scan failures.
We corrected those configurations, removed the unnecessary redirect from the affected scan-launch paths, and addressed the exceptions identified by our automation.
What had appeared to be a collection of intermittent Wordfence failures was traced to a common configuration defect hiding behind websites that otherwise worked normally.
The practical fix was simple: ensure WordPress generated HTTPS URLs directly.
Finding that fix required tracing the interaction between Wordfence, WordPress, Cloudflare, the HTTP transport, and the origin server.
That’s the difference between assuming a security system is working and investigating whether it’s actually doing the job it was installed to do.
At Paranoid Hosting, we believe that difference matters.