How to Fix a WordPress Login Redirect Loop

If you return to wp-login.php after entering the correct information, or the browser shows ERR_TOO_MANY_REDIRECTS, the problem is usually a cookie, domain, or HTTP/HTTPS detection mismatch. Security plugin, cache and reverse proxy can also create the same token. Clearing the cookie is a good test, but when several users have problems at the same time, you should see the redirect chain on the server side.

Quick answer: Test in an incognito window, record network redirects, see if the scheme and host are the same in all hops, and then home/siteurl, check the proxy and cookie settings. Do not disable HTTPS or bypass certificate validation; The goal is for WordPress and the proxy to come to the same conclusion about whether the request is safe.

Separate the two types of problems

Real HTTP loop

Browser switches between two or more URLs until the redirect limit is reached; For example, HTTP to HTTPS and then the application back to HTTP. In DevTools or the header tool, see the 301/302 statuses and the Location value of each hop.

Return to the form after login

In this case, the redirect may be limited, but the session may not be valid. The cookie is set to an inappropriate domain, path or secure flag, cached a personal response, or removed a user login hook.

Start from the browser

1. Clear only site domain cookies.
2. Temporarily leave privacy or password manager extensions in the test window.
3. Log in with the same canonical URL; Do not switch between www and no www.
4. In Network, enable the preserve log option and record the login request chain.
5. Check that the login response really sends the cookie header and the next request returns it.

The cookie value and nonce are sensitive data; Clean up the screenshot or HAR before sharing.

home and siteurl must match the actual architecture

If the domain or HTTPS has changed, the WordPress Address and Site Address values ​​may be out of date. The WP_HOME and WP_SITEURL constants in wp-config take precedence over the database value. Find the effective source before changing; Defining multiple conflicting values ​​at the same time complicates the problem.

wp option get home
wp option get siteurl

These commands only read the value. URL change in multisite or domain transfer is a broader issue and search/replace must respect serialization and store data.

WordPress behind CDN or Reverse Proxy

The browser may connect to the CDN with HTTPS, but the proxy connection to the origin is with HTTP. If the forwarding headers are not correct and trusted, WordPress sees the request as insecure and generates a conflicting redirect. In Nginx, scheme and host should usually be passed upstream, but the header name and policy should be consistent with framework and chain proxies.

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;

These two example lines are part of a server block, not the complete copyable configuration. If there are multiple proxies, blindly trusting the incoming header from the Internet can cause spoofing. The trust boundary and header overwriting in the edge should be clear.

Cache should not store the login page publicly

wp-login.php, wp-admin and responses with user cookies should be removed from public storage according to the cache policy. Plugin cache, Nginx FastCGI cache, CDN and browser are separate layers. perform a targeted purge and modify the rule; Permanently turning off the entire cache only removes the token.

Security, Membership and SSO Plugins

Changing the login URL, IP restriction, captcha, social login and SSO can generate redirects. Check plugin log and destination hook. If the trace or change time refers to a specific plugin, disable it in staging. In production, discarding the security layer should be short, controlled, and accompanied by alternative access restrictions.

Why is changing the.htaccess file not always the answer?

In Apache, the conflicting rule may be the cause of the loop, but in Nginx, the file .htaccess is not read. redirect may be defined in CDN, virtual host, plugin and WordPress at the same time. Specify an owner for canonical redirect and delete duplicate rules.

Common mistakes

• Disabling HTTPS for temporary login and creating mixed content or insecure cookie.
• Change database URL, wp-config, CDN and Nginx at the same time.
• Clear all caches without recording which layer was effective.
• Trust any X-Forwarded-Proto Valid proxy borderless input.
• Open wp-admin for all IPs to bypass login policy.

A verification process after modification

Login and logout in new window, refresh admin page, also test with a non-admin role and canonical URL in HTTP and HTTPS see The redirect chain should be short and explainable. Then re-enable/check the cache, WAF and error log and delete the temporary rule.

When is expert checking necessary?

If the site is behind multiple proxies, has SSO or the loop occurs only for some users, cookie and header checking should be done all the way. WordPress technical troubleshooting service Suitable for coordinated analysis of WordPress, CDN, Nginx and session. If your problem is not loop and you don't enter the administration at all, first wp-admin login problem guide.

FAQ

Why only one user sees loop?

More likely old cookie, browser extension or account status. Comparing the incognito window and another user helps narrow down the scope.

Is Cloudflare always to blame?

No. TLS asymmetric mode or rule edge can be involved, but the redirect chain determines which layer made the response.

Is changing the siteurl in the database sufficient?

Not always. Fixed wp-config, multisite, proxy and cache may make another effective value. Find the active source first.

Why does it temporarily fix after clearing the cookie?

Incompatible domain cookie or secure flag may be regenerated. Check the login response to determine the reason for the repetition.