Cloudflare can accept HTTPS from a visitor while contacting the origin over HTTP. If WordPress or the web server redirects that origin request back to HTTPS, Cloudflare repeats the same HTTP request and the visitor sees an endless loop.
The durable fix is valid HTTPS between Cloudflare and the origin, a trusted proxy signal, and one clearly defined layer for canonical redirects.
What it means
Flexible mode encrypts only the browser-to-Cloudflare connection. Full (strict) mode also uses HTTPS to the origin and verifies its certificate.
A loop begins when the edge and origin disagree about the request scheme or when several layers apply competing redirects. WordPress must trust forwarded protocol information only from the known proxy path.
A realistic WordPress example
A visitor requests an HTTPS page. Cloudflare forwards it to the origin over HTTP, where WordPress enforces HTTPS. The resulting redirect returns to Cloudflare, which again requests the origin over HTTP.
Installing a valid origin certificate and changing Cloudflare to Full (strict) removes the scheme mismatch. Consolidating redirects prevents a second loop between Cloudflare, the server, and WordPress.
Why it matters and when to use it
Redirect loops block public pages, login, REST requests, webhooks, and forms even though each individual rule may appear reasonable. Cached redirects can also make a corrected configuration look broken.
Use this diagnosis when every request repeats between the same URLs and Cloudflare is configured for Flexible encryption.
A straightforward route for beginners
- Record the current Cloudflare encryption mode and export the active redirect rules.
- Confirm that the origin can serve the intended hostname over HTTPS with a valid certificate.
- Change the connection to Full (strict) once origin HTTPS is ready.
- Choose Cloudflare, the server, or WordPress as the owner of the canonical redirect.
- Remove or disable competing scheme redirects one at a time.
- Purge relevant cache and test HTTP, HTTPS, login, and a deep URL in a clean browser session.
The advanced route
Trace requests without automatically following redirects and inspect each status and Locationheader. Compare the visitor scheme, the Cloudflare-to-origin scheme, forwarded protocol headers, WordPress home and site URLs, and the rule that generated each hop.
Accept forwarded headers only from authenticated or otherwise trusted proxy addresses. Test authorized direct-origin HTTPS separately, then verify the edge path, REST API, callbacks, forms, and cache behavior. A direct HTTP-to-canonical-HTTPS hop should be the normal result.
Risks, common mistakes, backup, and rollback
Keeping Flexible mode as a permanent workaround leaves origin traffic unencrypted. Trusting forwarded headers from arbitrary clients enables scheme spoofing, while stacked redirects make ownership difficult to diagnose.
Preserve Cloudflare rules, origin configuration, and WordPress URL values before changing them. Maintain a way to reach the origin or administration area. If Full (strict) exposes an origin certificate problem, restore the last working edge mode only long enough to correct the certificate safely.
How AIOWS helps:
AIOWS SSL Manager
AIOWS SSL Manager can help review supported WordPress-side HTTPS settings after Cloudflare and the origin agree on the request scheme. It is useful for checking WordPress URLs and application behavior once the proxy path is sound.
AIOWS cannot install the origin certificate, change the Cloudflare encryption mode, authenticate forwarded headers, or remove an edge rule. Those controls belong to the hosting and Cloudflare configuration.
After the infrastructure change, use SSL Manager to verify the public site, login, assets, forms, and callbacks over HTTPS. Confirm raw redirect responses as well, because a cached browser page does not show which layer owns the redirect.
Related AIOWS articles
- Force HTTPS in WordPress Without Breaking the Site
- WordPress HTTPS Problems Behind a Reverse Proxy
- How to Redirect HTTP to HTTPS in WordPress with .htaccess
Conclusion and recommended route
Use authenticated HTTPS on both legs, run Cloudflare in Full (strict) mode, trust protocol headers only from the proxy, and keep one owner for canonical redirects. The accepted path should reach HTTPS in one predictable hop without breaking WordPress or its integrations.
