WordPress
WordPress SSL redirect loops: find which layer disagrees about HTTPS
WordPress SSL redirect loops happen when WordPress, the web server, and a reverse proxy disagree about whether the original request was HTTPS. The loop is often two layers alternately forcing opposite URL/scheme assumptions, not a certificate problem.
Capture the redirect sequence
Follow the URL with curl or browser network tools and record every HTTP status and Location header. Test both http:// and https:// forms plus www/apex variants to see which component changes the URL.
Use a temporary browser profile when cached 301/HSTS behavior could obscure the current server response.
Check WordPress home and siteurl
Verify the stored WordPress Address and Site Address match the intended canonical HTTPS hostname. Hard-coded wp-config constants can override database values, so inspect both.
Search for plugins that enforce SSL or canonical hostnames before adding another redirect rule.
Teach WordPress about proxy HTTPS correctly
If TLS terminates at a trusted reverse proxy, the origin may receive HTTP. Configure the proxy/application so the original scheme is communicated and trusted only from that controlled proxy.
A generic trust of X-Forwarded-Proto from the public internet can create security issues.
Consolidate redirect ownership
Choose one clear web/proxy canonical redirect path, remove duplicate plugin rules, purge caches, and retest. After the loop is gone, verify mixed content and certificate hostname separately.
- Record every redirect.
- Verify home/siteurl.
- Handle trusted proxy scheme.
- Remove duplicated SSL redirect rules.