Why Is My Website Redirecting Unexpectedly?
Unexpected redirects usually come from conflicting HTTP-to-HTTPS, www/apex, application, proxy, or authentication rules; inspect every hop before changing DNS or code.
How it works
A redirect is an HTTP response. DNS decides which server is contacted, but it does not itself issue a 301 or 302, although an old DNS target can expose a different server's rules.
Start with the actual HTTP chain. DNS chooses an address for the hostname, but the server or intermediary at that address sends a redirect response. Changing DNS before recording the entered URL, status code, Location target, and final URL can obscure a clear application or proxy rule problem.
HTTP-to-HTTPS and www-to-apex rules are common layers. A loop can occur when a CDN redirects HTTP to HTTPS while an origin, unaware of forwarded protocol headers, redirects HTTPS traffic back to HTTP. Another loop occurs when a CDN insists on www while an application insists on apex. Only one layer should own each canonical decision.
Framework middleware, locale rules, trailing-slash settings, and application routes can add redirects after the proxy has already handled the hostname. Load balancers and reverse proxies can also rewrite host or scheme information. Identify the layer producing each hop before changing a rule; a redirect loop is usually a disagreement between layers, not one bad line alone.
Cookies and authentication matter. A logged-out request may be correctly sent to sign-in, while an authenticated request returns to a dashboard. Browsers can cache permanent redirects, so test in a fresh context when verifying a change. Cached behavior is not proof that the origin still sends the same response.
Use the public headers checker to map the bounded unauthenticated chain, then compare TLS and DNS only when the destination itself is unexpected. It cannot see private routes, credentials, or every CDN region. Fix the authoritative redirect rules and remove redundant layers rather than adding another redirect to mask the loop.
Typical redirect-loop causes
A common loop occurs when a CDN forces HTTPS while an origin thinks it receives HTTP and redirects back. Another occurs when www-to-apex and apex-to-www rules disagree across a proxy and application. Framework middleware, locale rules, and login/session redirects can add further hops.
Cookies and authentication can change the result. A public logged-out check might redirect to a sign-in route, while an authenticated browser follows a different path. Cached permanent redirects can also make a browser appear to ignore a recently corrected rule.
Debug the chain first
Write down the entered URL, status, Location, and final URL for every hop. Test HTTP and HTTPS, www and apex, and the intended canonical host separately. Identify which layer produced each response: application, reverse proxy, load balancer, or CDN.
Then check TLS for the final host and DNS only if the hostname reaches an unexpected deployment. The HTTP Headers Checker follows a bounded public chain without cookies or credentials, so use it as a baseline rather than a substitute for authenticated application testing.
Practical guidance
- Inspect every Location header before changing rules.
- Test HTTP/HTTPS and www/apex independently.
- Separate public redirect behavior from cookie or login flows.
Common question
Can DNS create a redirect loop? Not directly, but stale or incorrect DNS can send a request to a server with different redirect rules.