Introduction
An Apache site can fall into a redirect loop right after SSL is enabled when HTTP and HTTPS rules disagree about the canonical URL. The most common pattern is a proxy or load balancer terminating TLS while Apache still thinks the request arrived over plain HTTP, so it keeps redirecting an already secure request back to HTTPS. The fix is to make Apache and every upstream layer agree on the request scheme and host.
Symptoms
- Browsers report too many redirects immediately after enabling SSL
- The site works over HTTP or direct origin access but loops over HTTPS
- Redirect loops happen only behind a load balancer, CDN, or reverse proxy
- WordPress or application URLs show a different protocol than the live request
- The problem started after adding rewrite rules, SSL virtual hosts, or proxying
Common Causes
- Apache redirect rules force HTTPS without recognizing forwarded HTTPS traffic
- Multiple redirect rules exist in virtual hosts,
.htaccess, and the application itself - A load balancer terminates TLS but does not pass the correct forwarded protocol header
- The application canonical URL is set to HTTP while Apache tries to force HTTPS
- Hostname normalization and protocol redirects trigger each other in the wrong order
Step-by-Step Fix
- Reproduce the loop with a specific URL and map each redirect hop so you know whether the cycle is caused by host, scheme, or path changes.
- Review Apache virtual host rules,
.htaccess, and application-level redirect settings together instead of debugging them separately. - Confirm where TLS terminates and whether Apache receives a forwarded header that correctly indicates the original request was HTTPS.
- Adjust Apache rewrite conditions so HTTPS redirects do not run again for already secure requests coming through a proxy or load balancer.
- Check the application's configured site URL or canonical URL and make sure it matches the intended HTTPS hostname.
- Remove duplicate redirect logic where possible so one layer owns the canonical redirect behavior.
- Reload Apache, clear only the relevant caches, and retest both the public hostname and any proxy path involved.
- Verify there is now a single clean redirect path, such as HTTP to HTTPS or non-www to www, rather than a loop between competing rules.
- Keep redirect ownership documented across Apache, proxies, and the application so future SSL changes do not reintroduce loops.