Trace SSL Redirect Loops with curl -Iv on Cloud Sites

If your Australian business site keeps flashing “too many redirects,” ERR_TOO_MANY_REDIRECTS, or a blank crash after a CDN or SSL change, this guide walks you through terminal diagnostics and fixes you can run yourself.

Cloud edges (CDN, WAF, load balancers) and origin servers often disagree on HTTP vs HTTPS, www vs apex, or the scheme reported in X-Forwarded-Proto. That disagreement turns into an endless 301/302 loop. Below you will use curl -Iv to watch headers bounce between proxy lines and origin blocks, then apply concrete config fixes. When the stack is too tangled for DIY, Fixwebnode website repair in Australia can take over remotely as a direct specialist—not a freelance marketplace.

Why cloud SSL redirect loops crash live sites

A redirect loop is not a “browser glitch.” It is two or more layers each forcing a different URL or scheme until the client gives up. Typical pressure moments: flipping Cloudflare SSL mode, enabling “Always Use HTTPS,” migrating WordPress to HTTPS, or terminating TLS at a load balancer while the app still rewrites to HTTPS again. Visitors in Australia see an immediate failure; search bots and payment callbacks fail the same way. Tracing with verbose curl is faster than guessing in the dashboard.

How do you trace a cloud SSL redirect loop in Australia with curl -Iv?

Run curl -Iv against both the public hostname and the origin IP (or a Host header override) and read every Location, Strict-Transport-Security, and proxy header until the chain either settles or repeats. Compare edge responses with origin-only responses; the layer that rewrites the scheme or host incorrectly is your conflict. If headers keep flipping HTTP↔HTTPS or apex↔www after three hops, stop DIY guessing and book remote repair.

Common issues that cause SSL redirect loops and crash errors

1. Edge “Flexible SSL” while origin forces HTTPS

The CDN speaks HTTP to the origin; the origin (or WordPress) answers with a 301 to HTTPS; the edge strips TLS again. Browsers see an infinite bounce. Symptom: loop only through the CDN hostname; direct origin HTTPS may work.

2. Wrong or missing X-Forwarded-Proto at the reverse proxy

Nginx, Apache, or the app trusts the connection scheme (http) behind TLS termination and issues another HTTPS redirect. Symptom: curl -Iv shows 301 to the same HTTPS URL repeatedly; app logs show scheme=http.

3. Apex ↔ www and HTTP ↔ HTTPS rules fighting across CDN and origin

One layer redirects example.com → www.example.com; another redirects www back to apex while both also force HTTPS. Symptom: alternating Location hosts in the curl chain until failure.

4. Stale HSTS plus a bad certificate or partial HTTPS rollout

Browsers lock to HTTPS via HSTS while a path, subdomain, or admin URL still redirects incorrectly or serves mixed rules after a cert change. Symptom: crash only on returning visitors; private/incognito may differ until HSTS max-age expires.

Baseline terminal trace (do this first)

From any Linux or macOS shell (or WSL), capture the full hop chain without following redirects blindly:

curl -Iv --max-redirs 0 https://www.example.com/ 2>&1 | tee /tmp/edge-headers.txt
curl -Iv --max-redirs 10 https://www.example.com/ 2>&1 | tee /tmp/edge-follow.txt
curl -Iv --max-redirs 0 http://www.example.com/ 2>&1 | tee /tmp/http-start.txt

Note every HTTP/1.1 or HTTP/2 status, Location:, cf-ray / CDN headers, server:, and strict-transport-security. Then hit origin bypassing DNS if you know the origin IP (replace safely):

curl -Iv --max-redirs 0 --resolve www.example.com:443:ORIGIN_IP https://www.example.com/
curl -Iv --max-redirs 0 -H "Host: www.example.com" http://ORIGIN_IP/

If the public URL loops but the origin response is a single clean 200 or a single intentional 301, the conflict is at the edge policy—not “WordPress is broken” in isolation.

Fix issue 1 — Flexible SSL vs origin force-HTTPS

Goal: Make edge-to-origin encryption match what the application expects so neither side rewrites the scheme forever.

Step 1 — Confirm the loop pattern

curl -Iv --max-redirs 5 https://www.example.com/ 2>&1 | grep -Ei '^(HTTP/|location:|server:|cf-ray:|strict-transport)'

Expect alternating or repeating Locations to the same host with scheme flips.

Step 2 — Set CDN SSL mode to Full (strict) when the origin has a valid cert

In Cloudflare-style dashboards: SSL/TLS → Overview → Full (strict). Flexible must not remain on if the origin or CMS forces HTTPS. Ensure the origin certificate is valid for the hostname (Let’s Encrypt or provider cert).

Step 3 — Align CMS canonical URL

For WordPress, siteurl and home must be https:// consistently (wp-config or database). Avoid plugins that “force SSL” while the edge is still Flexible.

Step 4 — Verify

curl -Iv --max-redirs 5 https://www.example.com/ 2>&1 | grep -Ei '^(HTTP/|location:)'
# Expect: one optional 301 to canonical host, then HTTP/2 200

When to call Fixwebnode: If you cannot change SSL mode (agency-locked zone), origin cert fails Full (strict), or multiple domains share one messy zone—book remote repair via the website repair landing page.

Fix issue 2 — X-Forwarded-Proto and proxy scheme detection

Goal: Teach the origin that the client already used HTTPS so the app stops emitting another HTTPS redirect.

Step 1 — See what the app believes

curl -Iv https://www.example.com/ 2>&1 | tee /tmp/loop.txt
grep -i location /tmp/loop.txt

If Location keeps pointing at the same HTTPS URL, scheme detection is wrong behind the proxy.

Step 2 — Nginx trust headers (origin)

When TLS terminates at the load balancer or CDN and Nginx is origin, ensure real_ip and forwarded headers are accepted from trusted proxies only, and that the app sees HTTPS:

# snip — adjust trusted ranges to your CDN/LB
set_real_ip_from 10.0.0.0/8;
real_ip_header CF-Connecting-IP;
# or X-Forwarded-For per your provider

# pass scheme to PHP/app
fastcgi_param HTTPS $https if_not_empty;
fastcgi_param HTTP_X_FORWARDED_PROTO $scheme;

If the edge already sends X-Forwarded-Proto: https, map it explicitly instead of overwriting with plain $scheme when Nginx itself speaks HTTP on :80 to the upstream edge path:

map $http_x_forwarded_proto $fwd_proto {
 default $http_x_forwarded_proto;
 '' $scheme;
}
# then use $fwd_proto in redirects / fastcgi_param HTTPS

Step 3 — Apache equivalent check

# Ensure something like:
# SetEnvIf X-Forwarded-Proto https HTTPS=on
apachectl -t && systemctl reload apache2

Step 4 — Application layer

Laravel, WordPress reverse-proxy configs, and Node apps often need TrustProxies or $_SERVER['HTTPS'] = 'on' when X-Forwarded-Proto is https. Apply one layer of truth—do not force SSL in three plugins plus Nginx plus CDN.

Step 5 — Reload and re-trace

sudo nginx -t && sudo systemctl reload nginx
curl -Iv --max-redirs 3 https://www.example.com/

When to call Fixwebnode: Multi-proxy chains (CDN → AWS ALB → Nginx → PHP-FPM) with conflicting maps are easy to break in production. Remote specialists can diff live headers against vhost files safely.

Fix issue 3 — Competing host and HTTPS redirect rules

Goal: One canonical host, one scheme policy, enforced once.

Step 1 — Dump both apex and www

curl -Iv --max-redirs 8 https://example.com/ 2>&1 | grep -Ei '^(HTTP/|location:)'
curl -Iv --max-redirs 8 https://www.example.com/ 2>&1 | grep -Ei '^(HTTP/|location:)'
curl -Iv --max-redirs 8 http://example.com/ 2>&1 | grep -Ei '^(HTTP/|location:)'

Step 2 — Pick a single canonical (for example https://www.example.com). Disable duplicate Page Rules / Redirect Rules at the CDN that send www→apex while origin still sends apex→www.

Step 3 — Origin server block (Nginx example)

server {
 listen 80;
 server_name example.com www.example.com;
 return 301 https://www.example.com$request_uri;
}
server {
 listen 443 ssl http2;
 server_name example.com;
 # ssl_certificate ...;
 return 301 https://www.example.com$request_uri;
}
server {
 listen 443 ssl http2;
 server_name www.example.com;
 # ssl_certificate ...;
 # root / app — no further host redirects
}

Step 4 — Purge CDN cache after rule changes so cached 301s stop poisoning the chain. Re-run the three curl traces until each path has at most one hop to the canonical URL, then 200.

When to call Fixwebnode: DNS at one registrar, CDN on another account, and origin panel redirects all disagree—common for small Australian businesses after a rushed HTTPS migration.

Fix issue 4 — HSTS and leftover crash behaviour

Step 1 — Detect HSTS

curl -Is https://www.example.com/ | grep -i strict-transport

Step 2 — Do not disable HSTS casually on production if it was already long-lived; fix the redirect logic first. Clear CDN cache and test with a fresh browser profile after origin/edge agree.

Step 3 — Confirm certificate and chain

echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Renew or reissue if names do not match the canonical host. Reload the web server after install:

sudo systemctl reload nginx
# or: sudo systemctl reload apache2

When to call Fixwebnode: HSTS preloaded domains, multi-subdomain cookies, or checkout paths that still loop after apex is fixed.

Extra crash checks while you are in the terminal

Redirect loops sometimes mask 502/504 origin failures after the edge “helps” with HTTPS. Check origin error logs and service health:

sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u php8.2-fpm -n 50 --no-pager
sudo systemctl status nginx php8.2-fpm --no-pager

If PHP-FPM is down, restore it before chasing more redirects:

sudo systemctl restart php8.2-fpm
curl -Iv --max-redirs 3 https://www.example.com/

Related stack work (local tooling or multisite brand setups) is covered under specialist gigs such as Melbourne software installation experts and WordPress Multisite network setup in Docklands when those are the actual root—not as a substitute for SSL loop tracing.

When DIY is enough vs when to book Fixwebnode

DIY is enough when you control CDN SSL mode, can reload Nginx/Apache, and curl -Iv shows a clear single conflicting hop you can remove. Re-test from a second network after cache purge.

Book Fixwebnode when loops span locked partner CDN accounts, multiple origins, broken Full (strict) certificates, WordPress multisite domain mapping, or the site is losing sales during business hours and you need a remote specialist on the live path. Fixwebnode works directly with individuals, sole traders, and local operators across Australia; see geographic coverage on the service areas hub.

Get the redirect loop stopped

You now have a repeatable method: capture edge vs origin headers with curl -Iv, align SSL mode and X-Forwarded-Proto, enforce one canonical host, and verify until the chain ends in 200. If the bounce continues under pressure, start a conversation with Fixwebnode for remote website support—practical repair on this exact failure mode, not a bid board.

Next step: open the Fixwebnode website repair Australia page and describe the hostname, CDN, and what your curl Location chain shows. We will pick up from those headers and stabilise the edge–origin path.