Fix ERR_TOO_MANY_REDIRECTS on WordPress /wp-login.php and /wp-admin

The situation

It's 2 AM. Someone just flipped the site to HTTPS, changed the domain, or touched an .htaccess rule. Now every attempt to hit /wp-login.php or /wp-admin ends the same way:

ERR_TOO_MANY_REDIRECTS — This page isn't redirecting properly when accessing /wp-login.php or /wp-admin

The browser fires off 20+ redirect requests, detects the loop, and quits. You're locked out. Regular visitors may or may not be affected — depends on where the loop starts. Let's work through the fixes from fastest to most drastic.

Why this happens

WordPress redirects when siteurl or home in the database doesn't match the URL the server is actually serving. That mismatch creates a feedback loop WordPress can't escape.

The most common triggers:

Moving HTTP → HTTPS without updating wp-config.php or the database
Changing domain names and only partially updating settings
Wrong WP_SITEURL or WP_HOME constants hardcoded in wp-config.php
A caching plugin or CDN (Cloudflare, Nginx FastCGI) intercepting the login redirect
Stale WordPress auth cookies that the server rejects — it keeps redirecting to re-authenticate, cookie gets rejected again, repeat
A reverse proxy stripping HTTPS headers so WordPress thinks the request is plain HTTP while the browser is already on HTTPS

Quick fix: override siteurl and home in wp-config.php

This is the fastest test. Open wp-config.php and drop these two lines before the /* That's all, stop editing! */ comment:

define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');

These constants take priority over whatever the database holds. Reload /wp-login.php — if the loop stops, the database has a wrong URL and that's your root cause.

Once you're back in, go to Settings → General and verify both WordPress Address and Site Address are correct. After that you can pull the hardcoded constants out of wp-config.php if you prefer the database to stay authoritative.

Fix the database directly (when wp-config.php override doesn't help)

Connect with phpMyAdmin or drop into MySQL directly:

mysql -u db_user -p db_name

Check what's actually stored:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Migrated from HTTP to HTTPS? You'll likely see http://yourdomain.com still sitting there. Fix it:

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';

No phpMyAdmin access but WP-CLI is installed? Two commands do the same job:

wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Clear cookies and browser cache

Before going deeper into server-side fixes, rule out stale cookies. They're responsible for more redirect loops than people expect.

Open an incognito/private window and try /wp-login.php directly
Or wipe cookies for your domain: DevTools → Application → Cookies → right-click → Clear
Try a completely different browser as a sanity check

If a fresh browser loads the login page cleanly, the cookies were the culprit. No server changes needed — just log in from the clean session.

Fix .htaccess (Apache)

A single bad redirect rule in .htaccess is enough to create a loop. The quickest way to confirm: temporarily get the file out of the way.

mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

Try /wp-login.php again. Got in? Your .htaccess had a bad rule. Regenerate the default WordPress version from Settings → Permalinks → Save Changes, or paste this in manually:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Fix for HTTPS behind a reverse proxy (Nginx + Apache stack)

Running WordPress behind a load balancer or an Nginx reverse proxy? The PHP process likely sees HTTP while the browser is on HTTPS. WordPress redirects to HTTPS. Nginx proxies the request back as HTTP. WordPress redirects again. The loop runs until the browser gives up — usually after 20 hops.

Add this to wp-config.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Then confirm your Nginx config is actually forwarding the header:

proxy_set_header X-Forwarded-Proto $scheme;

Test the config and reload:

sudo nginx -t && sudo systemctl reload nginx

Fix for Cloudflare SSL loops

Cloudflare's Flexible SSL mode is probably the single most common cause of WordPress redirect loops after a CDN migration. Here's the mechanic: Flexible tells Cloudflare to talk plain HTTP to your origin server. WordPress detects HTTP, immediately redirects to HTTPS. Cloudflare proxies it back as HTTP. WordPress redirects again. The site never loads.

Head to Cloudflare Dashboard → SSL/TLS and switch the mode to Full or Full (Strict). The loop stops within a few seconds — no cache purge needed.

Disable all plugins via filesystem (nuclear option)

Redirect plugins, login security tools, and some caching plugins can all manufacture this loop. When you can't get into the dashboard to deactivate them, do it from the filesystem:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins.bak

Try /wp-login.php. If it loads, a plugin is the culprit. Restore the folder:

mv /var/www/html/wp-content/plugins.bak /var/www/html/wp-content/plugins

Re-enable plugins one at a time from the dashboard. The loop will come back when you hit the bad one — that's your target.

Verify the fix worked

Open https://yourdomain.com/wp-login.php in an incognito window — the login form should load without any redirect
Check DevTools → Network: the response for /wp-login.php should be 200 OK, not a chain of 301 or 302 responses
Log in and confirm the admin dashboard loads normally
Run wp option get siteurl && wp option get home to confirm both database values are correct