A loop occurs when two layers disagree about the current scheme or canonical host. The browser follows HTTPS to a proxy, the origin believes the request is HTTP and redirects again; or www, WordPress and server rules send the visitor in a circle.
Capture the full redirect chain before clearing cookies or adding another rule.
Trace every hop
Use browser Network or an HTTP client without automatic follow:
curl -I https://example.com/Record status, Location, server/CDN headers and repeating hosts/schemes. Redact cookies and private query values.
Test root, www, login and a direct content URL separately.
Verify the certificate first
HTTPS must present a valid certificate for the requested host and full chain. A certificate error is separate from application redirects.
Install/renew Let’s Encrypt after DNS points correctly. Do not disable certificate verification or choose a flexible HTTP origin solely to bypass a certificate problem.
Check root and www coverage.
Align WordPress URLs
Read home, siteurl and WP_HOME/WP_SITEURL. They should represent the intended canonical HTTPS host/path.
Do not change both database and constants to conflicting values. Back up before updates and use WP-CLI/precise SQL.
In subdirectory or multisite installations, preserve the intentional path/network design.
Configure proxy HTTPS detection
When Cloudflare/load balancer terminates TLS, origin PHP may receive HTTP plus a trusted forwarded-proto header. Configure WordPress/web server to recognise it only from the known proxy.
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
&& 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}This simplified pattern requires trusted proxy controls; accepting spoofed public headers is unsafe.
Check Cloudflare SSL mode
Flexible mode uses HTTP to origin and commonly conflicts with origin HTTPS redirects. Prefer Full (strict) with a valid origin certificate.
Review origin rules and Always Use HTTPS. Choose one clear canonicalisation owner or ensure layers agree.
Do not stack contradictory page rules, bulk redirects and plugin redirects.
Inspect web-server rules
Back up .htaccess/Nginx configuration and identify HTTP-to-HTTPS plus www rules. A rule based on the wrong variable can redirect every proxied HTTPS request.
Use proxy-aware conditions and one canonical target. Validate/reload Nginx through authorised controls.
Do not replace multisite/language/security rules wholesale.
Check plugins and cookies
SSL/redirect/security plugins may add PHP redirects after server rules. Disable only the implicated component in staging/with WP-CLI.
Old login cookies can loop between hosts, but clear only the test browser after configuration is fixed. Check cookie domain/path and system time.
Public page cache must not store redirect responses under the wrong scheme.
Check HSTS and browser-only behaviour
HSTS makes browsers upgrade HTTP before contacting the server, and preload applies even after local settings change. Compare a fresh profile and command-line client.
Do not remove HTTPS to work around HSTS; repair the secure origin/canonical redirects. If subdomains are included, ensure all required hosts support HTTPS before extending the policy. HSTS has long-lived consequences.
Inspect redirect ownership by layer
In staging, label redirects with headers or disable one layer at a time: CDN, server, plugin and site code. This reveals which pair disagrees.
Keep a matrix of input host/scheme and expected output. Remove redundant rules after repair; one canonicalisation owner is easier to audit than several similar 301 rules.
Retest query strings.
Verify one-hop canonicalisation
Test HTTP root, HTTP www, HTTPS alternate host and final HTTPS canonical URL. Each should reach the final URL with minimal predictable redirects.
Test login/admin, REST, assets and password reset. Recurring care should monitor redirect depth and certificate status after proxy/domain changes; HTTPS is stable when every layer agrees what the original visitor requested.