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.

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.

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

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.

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.