HTTPS troubleshooting guide

Fix a WordPress HTTPS redirect loop without guessing.

A loop is rarely solved by adding one more redirect. Find where HTTPS terminates, choose one layer to own the redirect, then align WordPress with that decision. If login instead fails outright after a move to a new host — no loop, just a rejected password — that is a different problem; see login failures after migration.

6 min readPublished 1 August 2026Apache and proxy reference
01Map the request path first.

Know whether HTTPS ends at a CDN, load balancer, host proxy, or Apache itself.

02Use one redirect owner.

A CDN rule, host rule, plugin rule, and .htaccess rule should not all compete to force HTTPS.

03Align WordPress URLs.

Home and Site URL settings must agree with the public HTTPS URL that visitors actually use.

Why HTTPS redirect loops happen

A common loop begins when a reverse proxy accepts HTTPS from the visitor but connects to Apache over HTTP. Apache then sees an HTTP request and redirects it to HTTPS. The proxy repeats its HTTP connection to Apache, and the browser never reaches WordPress. A second common cause is two layers disagreeing about the canonical host or whether HTTPS is already enabled.

1 Browser requests HTTPS2 Proxy terminates TLS3 Apache sees HTTP and redirects4 Proxy repeats the request

The diagram is not proof that a proxy is the cause; it is a reason to identify the actual path before editing. Check your CDN, host control panel, caching plugin, and root .htaccess for overlapping redirects.

If your browser shows ERR_TOO_MANY_REDIRECTS (Chrome) or "The page isn't redirecting properly" (Firefox) instead of a login form, that message is generic browser behavior — it is not specific to WordPress or to any single cause. It means the redirect chain looped a set number of times, which matches every scenario on this page.

One specific version of the proxy-mismatch cause is common enough to name directly: Cloudflare's "Flexible" SSL/TLS mode. Flexible mode terminates HTTPS at Cloudflare and connects to your origin over plain HTTP — while WordPress, via a plugin or .htaccess, is simultaneously trying to force every HTTP request to HTTPS. The result loops indefinitely, because Cloudflare answers each forced-HTTPS redirect with another Flexible-mode HTTP request. If the site is behind Cloudflare, set SSL/TLS mode to Full or Full (strict) before touching any redirect rule.

Pick the redirect layer that can see the truth

Where TLS endsBest redirect ownerAvoid
Directly at ApacheA server or root .htaccess rule can be appropriate.A duplicate redirect in a plugin or CDN.
CDN, load balancer, or host proxyThe upstream layer, or a host-approved proxy-aware configuration.A basic Apache HTTPS check that mistakes the proxy connection for the visitor connection.
Managed WordPress hostThe host’s documented HTTPS setting.Adding independent redirects before confirming how the host handles TLS.
Do not enable a generic .htaccess HTTPS redirect behind a TLS proxy.

The generator flags this risk because a normal %{HTTPS} check may only see the proxy-to-Apache HTTP connection. Use the host’s documented proxy-aware approach instead.

Resolve the loop in a deliberate order

  1. 01
    Record the redirect chain.

    Test both the HTTP and HTTPS public URLs in a private window or with your host’s diagnostic tools. Note every host and protocol change rather than relying on the browser’s final error.

  2. 02
    Identify the TLS terminator.

    Check whether a CDN, load balancer, managed host, or Apache presents the certificate to visitors. This determines whether Apache can accurately detect public HTTPS.

  3. 03
    Choose a single redirect owner.

    Keep the rule at the layer that knows the public protocol. Temporarily remove or disable duplicate rules only on an authorized site and keep a recovery path.

  4. 04
    Confirm the WordPress URLs.

    In Settings → General, or the equivalent configuration, make Home and Site URL match the public canonical HTTPS address and host.

  5. 05
    Clear the caches and retest.

    Purge the CDN, server, and plugin cache as appropriate, then test logged-out pages, login, and wp-admin. Re-enable only the redirect rule you deliberately chose.

Quick answers

What does ERR_TOO_MANY_REDIRECTS mean on a WordPress site?

It is a generic browser message meaning the redirect chain looped past a limit — it does not identify the cause itself. On WordPress it is almost always a TLS-termination mismatch: something forces HTTPS while another layer (often a CDN in a "flexible" TLS mode) keeps sending the request back as HTTP.

Why does WordPress keep redirecting from HTTPS to HTTPS?

Usually an upstream proxy ends HTTPS and forwards HTTP to Apache. An Apache rule sees that internal HTTP hop and redirects even though the visitor was already using HTTPS.

Does Cloudflare cause WordPress HTTPS redirect loops?

Its "Flexible" SSL/TLS mode does, when combined with a WordPress-side forced-HTTPS redirect: Cloudflare connects to the origin over HTTP no matter what the visitor requested, so a rule that forces HTTPS on that HTTP connection loops. Switch Cloudflare to Full or Full (strict) instead of removing the WordPress-side redirect.

Should I force HTTPS in WordPress, a plugin, Cloudflare, and .htaccess?

No. Pick one clear owner for the redirect. Multiple layers can conflict, make diagnosis difficult, or cause a loop when they interpret the original protocol differently.

When is an .htaccess HTTPS redirect appropriate?

It can be appropriate when Apache itself receives the visitor’s HTTP request directly. If a proxy terminates TLS first, follow the host or proxy provider’s documented configuration instead.

Primary reference: WordPress server configuration documentation.