Break a WordPress wp-admin Login Redirect Loop

A login loop often means authentication succeeded but the next request did not present a usable cookie for the URL WordPress believes it serves. Repeated password changes do not fix a scheme, domain, path, or proxy mismatch.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: trace cookies, site URLs, HTTPS termination, cache rules, and security plugins when successful credentials return to the login screen.

What the symptom narrows down

• WordPress Address and Site Address disagree with the browser’s canonical host or HTTPS scheme.
• A reverse proxy does not communicate the original HTTPS request to PHP.
• A cache or security layer serves login/admin responses incorrectly or rewrites cookies.

The branches are ordered to protect the strongest evidence around this possibility: wordPress Address and Site Address disagree with the browser’s canonical host or HTTPS scheme. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Access recovery is also a security event; the goal is not merely to get one administrator back in; it is to restore the intended trust path without leaving a reusable bypass or erasing evidence of unauthorized changes; in this guide, the practical goal is to trace cookies, site URLs, HTTPS termination, cache rules, and security plugins when successful credentials return to the login screen.

Evidence to collect before the fix

1. Use a private window and inspect the POST response, Location chain, and Set-Cookie attributes.
2. Compare wp option get home and wp option get siteurl with the public canonical URL.
3. Test direct origin and proxy paths only when authorized, noting HTTPS headers.
4. Temporarily bypass page caching for /wp-login.php and /wp-admin/ on staging.

The sequence moves from observation toward intervention. Preserve the result of the final check—temporarily bypass page caching for /wp-login.php and /wp-admin/ on staging—because it provides a useful comparison after the repair.

curl -sS -c /tmp/wp-login.cookies -D /tmp/wp-login.headers \
  -o /dev/null 'https://example.com/wp-login.php'
curl -sS -b /tmp/wp-login.cookies -o /dev/null -D - \
  -L --max-redirs 10 'https://example.com/wp-admin/'

Apply fixes in the safest order

1. Correct home/siteurl or trusted proxy HTTPS handling.
2. Exclude authenticated and login routes from shared caching.
3. Disable only the security/redirect rule proven to alter the chain.

Before applying “Correct home/siteurl or trusted proxy HTTPS handling,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can log in, navigate several admin pages, log out, and log in again; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Prove recovery

• Log in, navigate several admin pages, log out, and log in again.
• Check cookie Secure, HttpOnly, SameSite, domain, and path attributes.
• Confirm HTTP and alternate-host requests make one deliberate redirect to the canonical HTTPS host.

One successful refresh is not closure. Keep the incident open until you can also check cookie Secure, HttpOnly, SameSite, domain, and path attributes, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Keep an incident note with the verified account, operator, time, recovery channel, changed credentials or roles, and every temporary file or exception created; rotate exposed secrets and remove emergency access as part of the same change; include the result of this first observation: use a private window and inspect the POST response, Location chain, and Set-Cookie attributes.

State what was tested, including the result of “Use a private window and inspect the POST response, Location chain, and Set-Cookie attributes,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

• Do not define conflicting URL constants and database values without documenting precedence.
• Do not clear all users’ sessions unless the incident requires it.

Primary references

• HTTP redirects — official reference consulted for this guide.
• WordPress common errors — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Correct home/siteurl or trusted proxy HTTPS handling”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.