PAGUP Agent ControlWordPress access for AI assistants
Start free trial

WordPress Does Not Detect HTTPS Behind Cloudflare or a Reverse Proxy

The browser uses HTTPS, but WordPress does not detect the request as secure at the origin.

Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.

Likely causes

  • The browser uses HTTPS, but WordPress does not detect the request as secure at the origin.
  • The proxy does not forward the scheme information WordPress needs to recognize HTTPS.
  • WordPress Home URL and Site URL use different schemes, hosts or paths.
  • A redirect changes the scheme, host or path and may also discard authentication headers.
  • Another plugin changes HTTPS detection, REST access or Application Password availability.

Diagnostic sequence

  1. Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.
  2. Confirm that WordPress itself evaluates the request as HTTPS, not only the browser.
  3. Inspect the trusted proxy headers used to communicate the original HTTPS scheme to WordPress.
  4. Compare WordPress Home URL, Site URL, public canonical host and REST base address.
  5. Trace every redirect and verify whether scheme, host, path and Authorization are preserved.
  6. Record WordPress, plugin, client, connector and server versions before changing anything.

Apply the smallest correction

  1. Correct trusted proxy and origin handling so WordPress reliably recognizes the original HTTPS request.
  2. Align Home URL, Site URL, public host, HTTPS scheme and REST base address.
  3. Remove or correct the redirect that changes the authenticated request unexpectedly.
  4. Adjust only the verified false-positive WAF rule, path or method instead of disabling protection globally.
  5. Escalate with sanitized, versioned evidence when the behavior remains specific to the plugin.

Verify the result

  • The notice disappears only under the corrected condition and does not return on unrelated admin pages.
  • The authenticated request reaches the canonical endpoint without an unexpected redirect.
  • The REST index responds from the canonical HTTPS URL and exposes the expected namespaces.
  • The authenticated request resolves to the intended dedicated WordPress user.

What not to do

  • Do not add an unverified permanent proxy workaround before confirming the trusted request path.
  • Do not disable the WAF or security plugin globally to bypass one request.
  • Do not edit WordPress core or third-party plugin files as the first troubleshooting step.
  • Do not grant administrator access merely to make a connection test pass.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.

Frequently asked questions

Should I force HTTPS with a permanent code snippet?

Only after the hosting and proxy contract is understood. A generic permanent snippet can hide an origin misconfiguration or trust an unverified forwarded header.

Sources and verification

This page was checked against the following primary sources. Last source review: .