How to Fix Too Many Redirects After a Domain, Proxy, or SSL Change

Overview

If you need a quick too many redirects fix, start with one assumption: a loop means at least two parts of your stack disagree about the canonical URL or protocol. One layer thinks the request should be http, another forces https. One layer redirects example.com to www.example.com, another redirects www back to the apex. One proxy sends headers that say the original request was secure, while the app ignores them and issues its own redirect.

That is why redirect loop after SSL changes is so common. SSL, DNS, and proxy updates often happen together, and each layer may have its own redirect setting:

• The CDN or DNS proxy can force HTTPS.
• The load balancer can terminate TLS and forward plain HTTP upstream.
• Nginx, Apache, Caddy, or Traefik can redirect HTTP to HTTPS.
• The app framework can enforce a base URL or trusted proxy rule.
• The hosting platform can attach its own canonical domain redirects.

The fastest path to a fix is to stop thinking in terms of “the site” and instead inspect the request path layer by layer:

1. DNS and proxy: where the domain points and whether traffic passes through a proxy like Cloudflare.
2. TLS termination point: where HTTPS is actually handled.
3. Reverse proxy or web server: Nginx, Apache, or platform edge settings.
4. Application logic: framework middleware, environment variables, and trusted proxy config.

In practice, most domain redirect issues come from one of four patterns:

• HTTPS forced twice, but the app does not recognize forwarded HTTPS headers.
• Host canonicalization conflict, such as apex to www in one layer and www to apex in another.
• Proxy SSL mode mismatch, especially in a cloudflare redirect loop where the edge and origin disagree about supported protocols.
• Stale platform settings left behind after moving hosting providers or changing a custom domain.

Before changing anything, reproduce the problem in a controlled way. Open a private browser window, test both http:// and https://, and note the exact starting URL. Then inspect the redirect chain using your browser dev tools or curl:

curl -I http://example.com
curl -I https://example.com
curl -IL http://example.com

The -L flag follows redirects so you can see the sequence. If the response bounces repeatedly between two hosts or protocols, you already have the pattern you need.

If DNS was also changed recently, it helps to confirm where the domain points before blaming the app. A misrouted domain can send traffic to an old origin that still has redirect rules in place. For that part of the workflow, see How to Use Dig, Nslookup, and Whois to Troubleshoot Domain Problems and How to Point a Domain to a Server: A Record, CNAME, Nameservers, and TTL Explained.

Maintenance cycle

Redirects break most often during change windows, but the underlying cause is usually configuration drift. A simple maintenance cycle reduces that risk. The goal is not constant monitoring of every 301 and 302 response. It is to review the small set of settings that control protocol and host decisions whenever infrastructure changes.

A practical maintenance cycle for https redirect troubleshooting looks like this:

1. Before a change

Document the current canonical behavior. Write down:

• Which hostname is canonical: example.com or www.example.com
• Whether HTTP should always redirect to HTTPS
• Where TLS terminates: CDN, load balancer, reverse proxy, or app server
• Which layer is responsible for redirects
• Which environment variable or config file defines the site URL

This sounds basic, but many loops happen because nobody has a single source of truth. A proxy engineer assumes the app handles redirects; the app team assumes the edge does.

2. During a change

Change one redirecting layer at a time when possible. If you switch DNS, update SSL mode, and add a framework middleware in the same hour, rollback becomes much harder. For deployments, this principle fits well with a standard release checklist. If your team needs one, Deployment Troubleshooting Checklist: What to Check When a Release Fails is a useful companion.

3. After a change

Run the same redirect checks every time:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

All four should end at one expected canonical URL. If two versions keep redirecting to each other, the loop is usually host canonicalization. If only HTTPS breaks, the loop is more likely related to SSL termination or forwarded headers.

4. On a scheduled review cycle

Review redirect logic quarterly or after any meaningful platform update. This article is worth revisiting on a recurring schedule because redirect behavior often changes indirectly. A new CDN rule, a framework update, a managed hosting migration, or a certificate automation tweak can all reintroduce a loop without anyone touching the app’s routing code.

For teams using infrastructure as code, keep redirect and proxy settings versioned wherever possible. DNS records in Terraform, server config in Git, and deployment settings documented beside the app reduce guesswork later. If that is part of your workflow, Terraform DNS Records Guide: Manage Cloudflare and Route 53 as Code can help standardize the DNS side.

Signals that require updates

You should revisit redirect configuration any time one of these signals appears, even if the site still loads for some users.

Recent domain, proxy, or SSL changes

The highest-risk moment is immediately after a nameserver change, CDN enablement, certificate renewal change, origin migration, or new reverse proxy rollout. These changes affect the exact headers and protocols seen by upstream services.

One hostname works and another does not

If https://www.example.com loads but https://example.com loops, or vice versa, the issue is often competing host redirect rules. This is especially common after connecting a custom domain to a new platform.

Only authenticated pages loop

When login pages or admin routes redirect endlessly but public pages work, check cookie security flags, app URL settings, and authentication middleware. A session cookie marked secure may not be set if the app thinks the request is HTTP, even though the browser connected over HTTPS through a proxy.

Only some regions or devices show the problem

That can point to stale DNS, mixed edge settings, caching, or inconsistent platform routing between old and new origins. It is not always a browser issue.

Redirect count spikes after deployment

In logs or APM tools, a sudden increase in 301 or 302 responses after a release is a strong sign that canonical URL logic changed. Treat this as a deployment regression, not just a browser complaint.

SSL errors appear alongside redirects

If a loop appears together with certificate warnings or protocol errors, the origin and proxy may disagree about whether end-to-end HTTPS is available. In those cases, review your SSL mode and origin certificate setup. If the main symptom becomes TLS failure instead of looping, How to Fix ERR_SSL_PROTOCOL_ERROR After DNS or Hosting Changes is the next article to consult.

Common issues

Most redirect loops can be traced to a small number of repeat problems. Use this section as a diagnosis map.

1. Cloudflare or another proxy is forcing HTTPS while the origin also redirects incorrectly

A classic cloudflare redirect loop happens when the proxy accepts HTTPS from the browser but connects to the origin in a way that makes the origin believe the request is plain HTTP. The origin then redirects to HTTPS again, and the cycle repeats.

What to check:

• Whether the proxy is configured to connect securely to the origin
• Whether the origin has a valid certificate for the requested hostname
• Whether the app trusts X-Forwarded-Proto or equivalent headers
• Whether both the edge and origin are set to force HTTPS

Fix approach:

• Choose a single authoritative place to enforce HTTP-to-HTTPS redirects.
• Make sure the origin understands when the original client request was HTTPS.
• Remove duplicate rules temporarily, then reintroduce only one if needed.

2. Nginx reverse proxy and app framework disagree about scheme

In self-managed stacks, Nginx reverse proxy setup is often correct enough to serve content but incomplete for redirect logic. If Nginx terminates TLS and proxies to an app over HTTP, the app needs forwarded headers to know the client used HTTPS.

What to check:

• Nginx headers such as X-Forwarded-Proto, X-Forwarded-Host, and Host
• Framework trusted proxy settings
• Environment variables like base URL, app URL, public URL, or site URL

Fix approach:

• Pass the correct forwarded headers from Nginx.
• Enable trusted proxy support in the framework.
• Avoid app-level HTTPS redirect middleware until proxy trust is confirmed.

If you are working on a VPS deployment, How to Deploy a Node.js App on a VPS With Nginx, PM2, and SSL and Linux Server Setup Checklist for New App Deployments cover the surrounding setup decisions that often contribute to these loops.

3. Apex and www redirect each other

This is one of the cleanest domain redirect issues to spot. A request to the apex redirects to www, but another rule sends www back to the apex. The conflict may exist across two layers, such as a registrar redirect plus an application redirect.

What to check:

• Registrar forwarding settings
• CDN page rules or redirect rules
• Load balancer host redirects
• Web server host rewrite rules
• Framework-level canonical host middleware

Fix approach:

• Pick one canonical host.
• Implement the redirect in one layer only.
• Remove legacy redirects left from previous hosting platforms.

4. Platform migration leaves old redirect settings behind

After moving from one host to another, a domain may still pass through old edge logic, old dashboard settings, or a stale origin. This is common when teams connect a custom domain to a new static host or app platform but do not remove previous redirect behavior.

What to check:

• Old CDN or hosting project settings
• Old DNS records still answering for subdomains
• Multiple active apps claiming the same custom domain
• Cached browser HSTS behavior masking the real result

Fix approach:

• Verify the active origin for each hostname.
• Remove or disable redirects on the previous platform.
• Test from a clean browser and with direct curl requests.

For custom domain moves on static or platform-hosted sites, How to Deploy a Static Site With a Custom Domain and Automatic HTTPS is a useful reference.

5. Application URL or callback URL is wrong

Some apps generate redirects based on a configured public URL. If that setting still points to the old hostname or wrong scheme, every request can be rewritten incorrectly. Authentication systems are especially sensitive to this.

What to check:

• APP_URL, SITE_URL, PUBLIC_URL, or similar variables
• OAuth callback URLs
• Framework route helpers that generate absolute URLs
• Admin panel or CMS site URL settings

Fix approach:

• Update the configured base URL to the canonical HTTPS hostname.
• Restart the app if environment variables are cached.
• Clear application config caches where relevant.

6. Browser cache or HSTS makes the loop look worse

Sometimes the server-side loop is fixed, but the browser keeps forcing a previous redirect path. That does not mean the problem is imaginary; it just means cached state is now part of the test.

What to check:

• Incognito or private window results
• Another browser or device
• curl responses that bypass browser history and extensions

Fix approach:

• Retest with private browsing first.
• Compare browser behavior with direct HTTP headers.
• Only trust the browser after server-side behavior is confirmed.

When to revisit

This topic deserves a regular refresh because redirect loops tend to return during operational changes, not just initial setup. Revisit your redirect configuration on a scheduled review cycle and any time search intent or platform behavior shifts your troubleshooting priorities.

Use this practical checklist when the issue appears again:

1. Map the final canonical URL. Decide the one correct hostname and protocol.
2. Test all four URL variants. Check apex/www and HTTP/HTTPS combinations.
3. Inspect the redirect chain. Use curl -IL and note where the pattern repeats.
4. Identify the redirecting layer. CDN, load balancer, web server, app, or hosting platform.
5. Disable duplicate redirect rules. Keep only one active redirect authority while testing.
6. Verify proxy headers. Ensure upstream services know the original scheme and host.
7. Confirm public URL settings. Update app environment variables and callback URLs.
8. Check DNS and active origin. Make sure the domain points where you think it does.
9. Retest in a clean client. Use incognito and command-line requests.
10. Document the fix. Record which layer owns redirects so the same loop is not reintroduced later.

If your team changes DNS providers, compare proxy features, or moves redirect logic into infrastructure as code, it is also worth reviewing related guidance such as Best DNS Providers for Developers: Cloudflare vs Route 53 vs Namecheap vs Others. And if the issue turns out not to be redirects at all but a broader release fault, return to Deployment Troubleshooting Checklist: What to Check When a Release Fails.

The lasting fix is not a single rewrite rule. It is a clear ownership model: one canonical host, one place enforcing the redirect, correct proxy trust, and a repeatable post-change test. Once those are in place, future domain, proxy, and SSL changes become much less risky.