A browser hides most of a redirect chain. `curl -IL` exposes the repeating pair: perhaps HTTP becomes HTTPS at the CDN, while the origin—unaware of TLS—sends it back to HTTP.

The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you record every Location hop and reconcile WordPress, web-server, CDN, HTTPS, and locale rules so only one layer owns each redirect.

Read the failure at the right layer

  • Home/siteurl and proxy HTTPS detection disagree.
  • Both a plugin and the server enforce different www, language, slash, or login rules.
  • A cached redirect survives after the rule that created it changed.

The branches are ordered to protect the strongest evidence around this possibility: home/siteurl and proxy HTTPS detection disagree. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Routing should be read as a chain of explicit HTTP responses; wordPress, the web server, proxy, CDN, and browser can each redirect or cache independently; the address finally visible in the browser hides that chain; in this guide, the practical goal is to record every Location hop and reconcile WordPress, web-server, CDN, HTTPS, and locale rules so only one layer owns each redirect.

Build a clean diagnostic record

  1. Run curl -IL --max-redirs 10 URL and write each status and Location in order.
  2. Test HTTP/HTTPS and www/non-www variants separately.
  3. Inspect CDN rules, server rules, WordPress URL settings, and redirect plugins as distinct layers.
  4. Bypass caches only for diagnosis and compare origin behavior.

The sequence moves from observation toward intervention. Preserve the result of the final check—bypass caches only for diagnosis and compare origin behavior—because it provides a useful comparison after the repair.

This request stops after ten hops and prints each response header. Look for two layers alternating scheme, host, port, or trailing slash.

curl -sS -o /dev/null -D - \
  -L --max-redirs 10 \
  -w 'final=%{url_effective} status=%{http_code} redirects=%{num_redirects}\n' \
  https://example.com/affected-path/

Interpretation and safety: Repeat with and without browser cookies only when authentication is relevant. Remove one duplicate normalization rule at a time.

A bounded staging experiment

Treat “Home/siteurl and proxy HTTPS detection disagree” as a working hypothesis, not a conclusion. Establish a baseline first: run curl -IL --max-redirs 10 URL and write each status and Location in order. Record both the result you expected and the result you actually saw.

A supporting result justifies a staging test of the narrowest repair: choose one canonical scheme and host, then assign each normalization to one layer. A result that contradicts “Home/siteurl and proxy HTTPS detection disagree” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.

Repair the cause—not the message

  1. Choose one canonical scheme and host, then assign each normalization to one layer.
  2. Configure trusted proxy HTTPS headers so WordPress sees the original request correctly.
  3. Purge the specific cached redirect after configuration is corrected.

Before applying “Choose one canonical scheme and host, then assign each normalization to one layer,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can every alternate version should reach the canonical page in as few hops as practical; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Verification checklist

  • Every alternate version should reach the canonical page in as few hops as practical.
  • wp-admin and login flows must preserve secure cookies.
  • Test a deep URL, query string, and POST-sensitive route.

One successful refresh is not closure. Keep the incident open until you can also wp-admin and login flows must preserve secure cookies, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Capture curl -I or curl -IL output, the canonical host/scheme policy, proxy/CDN rule names, WordPress home and site URL values, and one deep affected path; remove cookies and authorization headers before sharing evidence; include the result of this first observation: run curl -IL --max-redirs 10 URL and write each status and Location in order.

State what was tested, including the result of “Run `curl -IL –max-redirs 10 URL` and write each status and Location in order,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Tempting moves to avoid

  • Do not add another redirect to counter an existing redirect.
  • Do not use JavaScript or meta refresh when an HTTP redirect is available.

Incident handoff

ScopeMap and Fix a WordPress “Too Many Redirects” Loop · URL · role · first/last occurrence
EvidenceStatus · request ID · first relevant log entry
ChangeOne action · backup/rollback point · operator
ProofOriginal reproduction · adjacent paths · monitoring window

Primary references

Editorial note: The scenario above illustrates how to approach “Choose one canonical scheme and host, then assign each normalization to one layer”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.