
ERR_TOO_MANY_REDIRECTS (also displayed as "This page isn't working — redirected you too many times") means the browser followed a chain of redirects that looped back on itself. After a configurable number of hops (usually 20), the browser gives up.
The site isn't down — it's responding. It's just redirecting to itself indefinitely. Here's how to find the loop and break it.
Before fixing it, see exactly what's happening:
# Follow all redirects and show each hop
curl -IL https://yourdomain.com
# If that loops, limit to 10 hops
curl -IL --max-redirs 10 https://yourdomain.com
# Check www vs non-www
curl -IL https://www.yourdomain.com
curl -IL http://yourdomain.com
The output shows every redirect. Look for where it circles back to a URL it already visited — that's the loop.
The most frequent cause: your web server or application redirects HTTP → HTTPS, but something is also redirecting HTTPS → HTTP, creating a loop.
Check your web server config:
# Nginx — look for conflicting redirects
grep -r "return 301\|rewrite.*redirect" /etc/nginx/
# Common bad pattern: return 301 http:// from inside an HTTPS server block
# Apache — check .htaccess
cat /var/www/yourdomain/.htaccess | grep -A2 -B2 "redirect\|RewriteRule"
If you're behind Cloudflare:
Cloudflare's SSL mode set to "Flexible" causes this. Flexible mode means Cloudflare connects to your origin over HTTP. If your origin also redirects HTTP → HTTPS, you get a loop: browser → Cloudflare (HTTPS) → origin (HTTP) → origin redirects to HTTPS → Cloudflare → origin (HTTP)...
Fix: Change Cloudflare SSL mode from Flexible to Full or Full (Strict) in the SSL/TLS settings.
In WordPress, if siteurl or home in wp_options doesn't match the actual URL being served, WordPress generates redirect loops.
-- Check current values
SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');
Both should match exactly — same protocol (https://), same www/non-www. If they don't:
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';
Or via wp-config.php:
define('WP_SITEURL', 'https://yourdomain.com');
define('WP_HOME', 'https://yourdomain.com');
Also check: WordPress Settings → General, and ensure the address fields match.
If you have both a www redirect and a non-www redirect active simultaneously:
# .htaccess — conflicting rules
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# AND somewhere else:
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # This strips www
Pick one canonical form (www or non-www) and have only one redirect rule.
Some applications use cookies to determine redirect targets. If a corrupt cookie contains a redirect URL that points back to itself, clearing cookies on the browser side breaks the loop for individual users.
Ask affected users to clear cookies for your domain. If that fixes it, a session or cookie-based redirect in your application logic is the root cause.
If you have Nginx in front of an application server, and both are configured to redirect HTTP → HTTPS, the request may be redirected twice. The second redirect happens on what's already an HTTPS request.
Check whether X-Forwarded-Proto headers are being passed correctly so the application layer knows the incoming request arrived over HTTPS:
proxy_set_header X-Forwarded-Proto $scheme;
Redirect loops can re-emerge after deployments, plugin updates, or CMS configuration changes. An uptime monitor catches them immediately — a redirect loop returns no 200, so your monitor will alert as soon as it starts.
Domain Monitor checks your site every minute and alerts when it stops returning a valid response. Create a free account.
When your site goes down, your status page becomes the most important page you have. Here's why it matters, what happens when you don't have one, and what a good status page does during a real outage.
Read moreYour domain is resolving, but pointing to the wrong server — showing old content, a previous host's page, or someone else's site entirely. Here's what causes this and how to diagnose it.
Read moreUptime monitoring isn't foolproof. Single-location monitors, wrong health check endpoints, long check intervals, and false positives can all cause real downtime to go undetected. Here's what to watch out for.
Read moreLooking to monitor your website and domains? Join our platform and start today.