A redirect loop occurs when two or more rules repeatedly send a request back to each other. After enabling HTTPS, inspect the hostname, scheme and proxy settings across WordPress, the web server and any CDN instead of adding another force-HTTPS rule.
IN THIS ARTICLE
01 Record the loop
Note the first URL entered and the sequence of destinations, including whether the hostname alternates between www and non-www or the scheme alternates between HTTP and HTTPS. Use a private browser session to distinguish a persistent rule from an old cached redirect.
Preserve configuration files and record recent changes before editing. Keep an authorised recovery route available in case the administration login is also affected.
02 Review each redirect layer
- Confirm that the intended hostname has a valid certificate at the relevant connection points.
- Review the WordPress Address and Site Address values, including any constants that override them.
- Inspect hosting-level redirects and application redirect plugins for conflicting canonical-host or HTTPS rules.
- If a reverse proxy or CDN is used, verify its connection mode and how the application learns the original request scheme.
- Remove or correct one verified conflict at a time and retest the same URL sequence.
03 Example: capture a short redirect chain without logging in
For a public URL caught in a loop, inspect the response headers while following at most five redirects. This request does not send login credentials, and it discards response bodies so the chain is easier to read.
curl --silent --show-error --location --max-redirs 5 \
--connect-timeout 3 --max-time 20 \
--dump-header - --output /dev/null \
'http://example.com/'Compare each Location value for alternating HTTP/HTTPS schemes or www/non-www hosts. Redact any response cookies before sharing the capture. A loop involving a proxy’s origin scheme needs the supported proxy configuration reviewed, rather than adding another generic HTTPS rule to WordPress.
Expected result: The corrected URL reaches one stable HTTPS destination through the intended short chain. Repeat login, logout and a harmless authenticated save separately, because a working anonymous homepage does not prove that cookies and form submissions are correct.
Why should HTTPS proxy headers not be changed by guesswork?
A proxy can terminate HTTPS before forwarding a request, but the origin must be configured to trust the correct information from a trusted proxy. Blindly trusting arbitrary forwarded headers from every client can create security problems.
Ask us or the responsible server administrator to confirm the supported configuration rather than pasting a generic snippet from an unrelated hosting setup. A browser-facing certificate alone does not explain the origin connection policy.
04 Verify the complete site
Test the homepage, an inner page, login, logout and an authenticated editor save. Confirm one stable canonical URL and check that important POST workflows, such as forms and checkout, are not redirected in a way that loses their data.
Clear relevant redirect and page caches after the stored configuration is correct. Test both old HTTP links and the intended HTTPS destination.
05 Escalate with the chain
Provide the affected URL, redirect sequence, time and recent SSL or CDN change. Do not send private proxy credentials or complete configuration files containing secrets.
If access is restored by temporarily removing a conflicting rule, document that state and finish the intended HTTPS configuration. Leaving mixed or inconsistent URL settings can cause later cookie, asset and API problems even after the obvious loop disappears.