Detect whether WordPress URLs, HTTPS enforcement, reverse proxy headers or conflicting redirect plugins form a loop.
Recognize the symptoms before changing settings
The same visible error can originate in different layers. Your first objective is to identify whether the failure is specific to a route, a user action, a hosting component or a recent change. Do not treat a browser message as a complete diagnosis.
- A browser reports ERR_TOO_MANY_REDIRECTS or a redirect loop.
- The sequence alternates between http and https, or between www and bare domain.
- It began after a domain move, SSL/CDN setting or redirection-plugin change.
Record the original URL, time of failure, browser or HTTP error and the last change that occurred before the issue began. These observations make later comparisons reliable, especially when caching or multiple servers are involved.
Before you change anything
If the site is taking payments or sending messages, confirm whether an operation may have already completed before resubmitting it. Make one isolated change at a time, then test the original failure again.
Diagnosis: find the layer that actually failed
Work through these plausible causes in evidence-first order. More than one can coexist, but fixing the first confirmed cause is safer than making several speculative adjustments.
Common underlying causes
- Conflicting HTTPS redirects at CDN and origin.
- Site Address and WordPress Address point at incompatible hosts.
- A caching or redirect plugin creates a second canonicalization step.
- Reverse proxy does not pass expected HTTPS headers.
Three checks that narrow the problem
- Record Location headers from the failing chain rather than only the final browser error.
- Compare direct origin and CDN access where your host permits.
- Check WordPress General settings and network multisite configuration where applicable.
The relevant response, request log and configuration source together provide better evidence than a generic error screenshot. If you cannot access logs, gather the failing URL and timestamp and request the corresponding records from your hosting provider.
How to interpret conflicting results
If the first check points toward conflicting https redirects at cdn and origin, focus on reproducing that condition without changing unrelated settings. A quick improvement after a targeted test is useful evidence but not yet proof that the root cause is removed.
If your second check suggests site address and wordpress address point at incompatible hosts, collect the corresponding service or application log and compare what happens immediately before and after the failed request. This prevents mistaking correlation for cause.
If neither case fits, consider reverse proxy does not pass expected https headers. Work from the outside in: DNS and connection, web server and proxy, PHP/WordPress runtime, then the affected plugin, theme or data. When a check gives inconclusive results, record that uncertainty instead of labelling it a confirmed fix.
Step-by-Step Troubleshooting
Choose the safest method for your access level. Use the Beginner tab for recovery and the Advanced tab for log-based diagnosis and targeted fixes.
Capture which URLs are redirecting
Use browser developer tools (Network → Preserve log) to inspect the first redirects. Write down the host and scheme at each hop before clearing caches.
curl -I -L --max-redirs 8 https://example.com/Check canonical WordPress addresses
In Settings → General, verify the WordPress Address and Site Address for the intended protocol and hostname. Do not alter these settings without a recovery plan when the dashboard depends on them.
Find duplicate redirect rules
Review CDN SSL mode, server rewrite rules and redirect plugins. Deactivate one conflicting rule on staging or with a documented rollback, then retest the chain.
Inspect proxy HTTPS awareness
If SSL terminates upstream, ask the host to confirm forwarding of secure-request headers. A WordPress site incorrectly seeing HTTP may redirect repeatedly to HTTPS.
Check for cookie-dependent loops
Test logged-in and logged-out requests in a private window. Distinguish login redirect conditions from site-wide canonical redirect loops.
Keep exactly one canonical policy
Decide on https plus either www or non-www. Configure redirects consistently at one primary layer and verify that other layers do not reverse them.
How to verify the repair
Do not call a problem solved solely because one browser reload succeeds. Retest the exact workflow that failed, then include a normal public request and one administrator action. Keep the site cache and authenticated/anonymous behavior in mind.
- The canonical URL loads after zero or one intentional redirect.
- Logged-out and logged-in routes stop bouncing between hosts or protocols.
Complete the checklist below as you test. The progress indicator belongs to this article and is intended as a reading aid, not a guarantee of server health.
Solution Checklist
If it still fails: rollback and escalation
If the symptom remains, stop repeating the same changes. Save the newest error evidence and compare it with the pre-change state; the unchanged behavior is a useful clue that the current hypothesis was wrong.
- Restore original WordPress address settings.
- Restore only the changed CDN/server redirect policy if behavior worsens.
When escalating to your provider or developer, send the time, affected URL, relevant status/log excerpt, environment version and the specific changes already tried. Remove passwords, session cookies, personal information and secret keys from the report.
How to prevent the error from returning
- Document one canonical domain strategy.
- Recheck redirects after CDN or SSL migrations.
After a successful fix, make a brief incident note: symptom, root cause, effective change, verification test and rollback instructions. This is much more useful than keeping a list of unverified tweaks.
Further reading: official documentation
This guide explains diagnostic choices rather than guaranteeing that one setting will work on every host. Verify the actual software versions, hosting environment and provider restrictions before applying examples.