{"id":1964,"date":"2026-08-16T18:15:32","date_gmt":"2026-08-16T15:15:32","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1964"},"modified":"2026-08-04T11:29:00","modified_gmt":"2026-08-04T11:29:00","slug":"cloudflare-flexible-ssl-causes-a-wordpress-redirect-loop","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/cloudflare-flexible-ssl-causes-a-wordpress-redirect-loop\/","title":{"rendered":"Cloudflare Flexible SSL Causes a WordPress Redirect Loop"},"content":{"rendered":"

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.<\/p>\n

The durable fix is valid HTTPS between Cloudflare and the origin, a trusted proxy signal, and one clearly defined layer for canonical redirects.<\/p>\n

\nTable of contents<\/strong><\/p>\n
    \n
  1. What it means<\/a><\/li>\n
  2. A realistic WordPress example<\/a><\/li>\n
  3. Why it matters and when to use it<\/a><\/li>\n
  4. A straightforward route for beginners<\/a><\/li>\n
  5. The advanced route<\/a><\/li>\n
  6. Risks, common mistakes, backup, and rollback<\/a><\/li>\n
  7. How AIOWS helps: AIOWS SSL Manager<\/a><\/li>\n
  8. Related AIOWS articles<\/a><\/li>\n
  9. Conclusion and recommended route<\/a><\/li>\n
  10. Official sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    What it means<\/h2>\n

    Flexible mode encrypts only the browser-to-Cloudflare connection. Full (strict) mode also uses HTTPS to the origin and verifies its certificate.<\/p>\n

    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.<\/p>\n

    A realistic WordPress example<\/h2>\n

    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.<\/p>\n

    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.<\/p>\n

    Why it matters and when to use it<\/h2>\n

    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.<\/p>\n

    Use this diagnosis when every request repeats between the same URLs and Cloudflare is configured for Flexible encryption.<\/p>\n

    A straightforward route for beginners<\/h2>\n
      \n
    1. Record the current Cloudflare encryption mode and export the active redirect rules.<\/li>\n
    2. Confirm that the origin can serve the intended hostname over HTTPS with a valid certificate.<\/li>\n
    3. Change the connection to Full (strict) once origin HTTPS is ready.<\/li>\n
    4. Choose Cloudflare, the server, or WordPress as the owner of the canonical redirect.<\/li>\n
    5. Remove or disable competing scheme redirects one at a time.<\/li>\n
    6. Purge relevant cache and test HTTP, HTTPS, login, and a deep URL in a clean browser session.<\/li>\n<\/ol>\n

      The advanced route<\/h2>\n

      Trace requests without automatically following redirects and inspect each status and Location<\/code> header. Compare the visitor scheme, the Cloudflare-to-origin scheme, forwarded protocol headers, WordPress home and site URLs, and the rule that generated each hop.<\/p>\n

      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.<\/p>\n

      Risks, common mistakes, backup, and rollback<\/h2>\n

      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.<\/p>\n

      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.<\/p>\n

      \n

      How AIOWS helps:<\/p>\n

      AIOWS SSL Manager<\/h2>\n

      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.<\/p>\n

      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.<\/p>\n

      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.<\/p>\n

      Explore AIOWS SSL Manager<\/a>Compare AIOWS plans<\/a><\/p>\n<\/section>\n

      Related AIOWS articles<\/h2>\n