WordPress Keeps Logging You Out: Cookies, Sessions, Cache and Server Causes Explained

You log in to WordPress, open the dashboard and start working. A few minutes later, WordPress suddenly sends you back to the login screen. You enter your username and password again. It works for a while, then happens again. Sometimes the problem appears only when

Uncategorized Beginner

You log in to WordPress, open the dashboard and start working.

A few minutes later, WordPress suddenly sends you back to the login screen.

You enter your username and password again.

It works for a while, then happens again.

Sometimes the problem appears only when you save a post. Sometimes it happens when you move between www and non-www URLs. Sometimes administrators are affected while normal visitors see no problem at all.

This is often described as a WordPress session problem, but WordPress login persistence involves several systems working together.

Authentication cookies in the browser
WordPress session tokens
Site and WordPress URLs
HTTP and HTTPS detection
Reverse proxies and CDNs
Security plugins
Cache rules
WordPress security keys and salts
Database-stored session information

If any one of these layers disagrees with the others, WordPress may decide that your existing login is no longer valid.

PRBLEM Principle: Repeated logout is usually not a password problem. It means WordPress received a request for which the expected authentication state could not be validated.

How WordPress Keeps You Logged In

WordPress does not ask for your password on every admin request.

After a successful login, WordPress creates authentication cookies in your browser.

WordPress uses cookies such as:

wordpress_[hash]
wordpress_sec_[hash]
wordpress_logged_in_[hash]

These cookies allow WordPress to recognize your browser on later requests.

WordPress also maintains session-token information for logged-in users. The cookie presented by the browser and the session known to WordPress must still represent a valid login.

A simplified login flow looks like this:

You enter username + password
        ↓
WordPress verifies credentials
        ↓
WordPress creates authentication cookies
        ↓
Browser stores those cookies
        ↓
Next wp-admin request
        ↓
Browser sends authentication cookie
        ↓
WordPress validates it
        ↓
Valid → Dashboard loads
Invalid / missing → Login screen

Repeated logout therefore means that somewhere between those steps, the authentication cookie is missing, rejected, expired, replaced or associated with an invalid session.

First: Identify Exactly When WordPress Logs You Out

Do not begin by clearing every cache.

First identify the pattern.

Pattern A: You log in and are immediately sent back to the login screen

Investigate:

Cookie domain problems
HTTP/HTTPS mismatch
www/non-www mismatch
Browser cookie blocking
Incorrect WordPress URLs

Pattern B: Login works, but you are logged out after a few minutes

Investigate:

Security-plugin session rules
Session-token invalidation
Custom authentication code
Security keys being changed
Multiple servers with inconsistent configuration

Pattern C: You are logged out when saving or publishing

Investigate:

REST API authentication
Nonce failures
HTTPS/proxy detection
Security or firewall rules
Cookie mismatch between editor requests

Pattern D: You are logged in on one page and logged out on another

This is a strong sign that requests are reaching different hostnames, protocols, cache paths or servers.

Pattern E: Only one browser or device is affected

Start with browser cookies and extensions before changing WordPress or the server.

PRBLEM Diagnosis: The exact moment the logout occurs often tells you which authentication layer to investigate first.

Diagnosis Path A: Browser Cookies Are Missing or Corrupted

Because WordPress authentication depends on cookies, the browser is the simplest place to begin.

Test A1: Use another browser

For example, if the problem occurs in Chrome, test Firefox or Edge.

Work in wp-admin for several minutes and repeat the action that normally triggers the logout.

If the second browser remains logged in, WordPress itself may be functioning normally.

The original browser becomes the primary suspect.

Test A2: Use a private window

Open an incognito or private browser window and log in.

This provides a cleaner environment with a separate cookie store and often fewer active extensions.

If private mode works while the normal browser does not, investigate:

Old site cookies
Browser extensions
Privacy tools
Cookie-cleaning software
Corrupted site storage

Solution A1: Clear cookies for this site only

You normally do not need to delete every cookie in your browser.

Remove cookies and site data only for the affected WordPress domain.

Then close the browser tab, reopen the site and log in again.

This forces WordPress to create a clean set of authentication cookies.

Solution A2: Check extensions that manipulate cookies

Temporarily disable browser extensions related to:

Privacy
Cookie deletion
Ad blocking
Tracking protection
Security
Automatic browsing-data cleanup

Then log in again and test.

Do not modify WordPress yet: If one browser fails while another works reliably, prove the browser problem first.

Diagnosis Path B: www and Non-www URLs Do Not Match

This is one of the classic causes of WordPress login loops and disappearing sessions.

These are different hostnames:

https://example.com
https://www.example.com

A browser can apply cookies differently depending on the domain for which they were created.

If WordPress begins a session on one hostname and later redirects you to another, authentication behaviour can become inconsistent.

Check WordPress URLs

Go to:

Settings → General

Look at:

WordPress Address (URL)
Site Address (URL)

For a normal single-domain installation, make sure the hostname and protocol are intentional and consistent.

For example:

WordPress Address:
https://example.com

Site Address:
https://example.com

or intentionally:

WordPress Address:
https://www.example.com

Site Address:
https://www.example.com

WordPress supports installations where the two URLs legitimately differ, so do not change them simply because they are different unless you understand the site’s architecture.

Look at the URL when the logout happens

Watch the browser address bar.

If you log in at:

https://example.com/wp-admin/

but later find yourself at:

https://www.example.com/wp-admin/

investigate redirects and site configuration before changing session lifetimes.

Check wp-config.php for forced URLs

Open wp-config.php and look for:

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

If these constants exist, they override the corresponding database settings.

Make sure they describe the domain the site is actually supposed to use.

Important: Do not copy these example lines into your site unless you need them. An incorrect WP_HOME or WP_SITEURL value can make the site harder to access.

Diagnosis Path C: HTTP and HTTPS Are Fighting Each Other

A second common mismatch involves the protocol.

http://example.com
https://example.com

WordPress can use secure authentication cookies when login occurs over HTTPS.

If some requests are treated as HTTPS and others as HTTP, WordPress may not receive the cookie it expects.

Test C1: Watch for protocol changes

The browser address bar should not unexpectedly change between:

http://
https://

If it does, investigate your redirect configuration.

Check FORCE_SSL_ADMIN

Your wp-config.php may contain:

define( 'FORCE_SSL_ADMIN', true );

This tells WordPress to use HTTPS for administration and login.

The setting itself is not usually a problem when HTTPS is configured correctly.

The problem appears when WordPress and the surrounding proxy or server disagree about whether a request is secure.

Diagnosis Path D: Cloudflare or a Reverse Proxy Hides HTTPS from WordPress

This is a more advanced but important case.

Your browser may connect to Cloudflare, a load balancer or another reverse proxy over HTTPS.

That system may then communicate with the WordPress origin server differently.

The architecture may look like this:

Browser
HTTPS
   ↓
Cloudflare / Reverse Proxy
   ↓
Origin Server
   ↓
WordPress

If WordPress incorrectly believes the request is HTTP even though the visitor is using HTTPS, authentication and redirect behaviour can become inconsistent.

Possible symptoms

Login loops after enabling a CDN or proxy
Repeated redirects between HTTP and HTTPS
wp-admin unexpectedly asks you to authenticate again
Mixed HTTP/HTTPS links inside administration
The problem started after moving behind a load balancer

Check whether WordPress detects HTTPS

WordPress uses its SSL-detection logic when deciding whether the current request is secure.

Properly configured reverse proxies usually forward information such as:

X-Forwarded-Proto: https

WordPress may need appropriate server or application configuration to recognize that the original request used HTTPS.

A commonly used WordPress-side pattern in trusted reverse-proxy environments is:

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

Do not add this blindly.

Use it only when your site is actually behind a trusted proxy that correctly controls the X-Forwarded-Proto header.

If you are unsure, ask the hosting provider how HTTPS should be detected behind its proxy layer.

PRBLEM Diagnosis: If the logout problem began immediately after enabling Cloudflare, a proxy, SSL termination or a load balancer, investigate protocol detection before changing WordPress cookie lifetimes.

Diagnosis Path E: COOKIE_DOMAIN Is Wrong

Most normal WordPress websites do not need a manually defined cookie domain.

However, some installations contain a custom setting in wp-config.php.

Search for:

COOKIE_DOMAIN

You may find something similar to:

define( 'COOKIE_DOMAIN', 'www.example.com' );

or a configuration designed for subdomains.

If the domain defined there no longer matches the actual site architecture, WordPress authentication cookies may not behave as expected.

Common situation

A website originally used:

www.example.com

Later it was changed to:

example.com

but an old COOKIE_DOMAIN definition remained inside wp-config.php.

This is exactly the type of historical configuration that can create confusing authentication behaviour.

Do not add COOKIE_DOMAIN as a generic fix: It is primarily useful for particular domain configurations. If your site never needed it, adding it may create a new problem rather than solve the existing one.

Diagnosis Path F: A Cache Is Serving Pages That Should Never Be Shared

Caching can cause more than outdated content.

An incorrectly configured full-page cache or CDN can interfere with authentication when it caches pages or redirects that should remain dynamic.

Areas such as these normally require careful cache rules:

/wp-admin/
/wp-login.php

Personalized logged-in responses also should not normally be treated like anonymous public pages.

Test F1: Temporarily bypass page caching

If the problem began after changing your caching configuration, test whether authentication works normally when the relevant page-cache or CDN rule is bypassed.

Do not disable every performance feature at once.

Start with the layer that can cache HTML responses.

Check CDN cache rules

If you use a CDN or reverse proxy, make sure you have not accidentally created broad rules that cache everything without appropriate exclusions.

A rule such as:

Cache everything

requires much more careful handling than normal static-asset caching.

Authentication pages, admin requests and personalized responses must be accounted for correctly.

PRBLEM Principle: A cache should accelerate a valid authentication flow, not become part of the authentication state itself.

Diagnosis Path G: A Security Plugin Is Invalidating Sessions

Security plugins can intentionally end sessions.

This may happen because of features involving:

Session expiration
Idle-session timeout
Maximum session length
Concurrent login limits
IP-address changes
Device restrictions
Forced logout after password changes
User-role security policies

These features can be useful, but they can also look like a WordPress bug when configured too aggressively.

Test G1: Check security logs before disabling the plugin

If your security plugin provides logs, inspect them first.

Look for events corresponding to the exact time you were logged out.

Search for descriptions related to:

Session terminated
User logged out
IP changed
Authentication failed
Session expired
Security policy triggered

Test G2: Temporarily disable only the relevant session feature

If possible, turn off the specific session-control feature rather than disabling the entire security system.

Then reproduce the original workflow.

If the logout stops, you now know which policy is involved.

Reconfigure that feature instead of leaving your security plugin disabled.

Diagnosis Path H: WordPress Security Keys Are Changing

This cause is less common but extremely important.

Your wp-config.php contains authentication keys and salts such as:

AUTH_KEY
SECURE_AUTH_KEY
LOGGED_IN_KEY
NONCE_KEY
AUTH_SALT
SECURE_AUTH_SALT
LOGGED_IN_SALT
NONCE_SALT

These values are intentionally secret.

Changing them invalidates existing WordPress authentication cookies.

That is useful when you intentionally want to force users to log in again.

But if those values are being changed automatically, every existing session can unexpectedly become invalid.

When to suspect changing salts

All users are logged out at roughly the same time.
The issue follows deployments or server rebuilds.
The site runs in containers or on multiple application servers.
wp-config.php is generated automatically.
A security tool rotates WordPress keys.

Do not replace the keys as a random fix

Regenerating WordPress security keys will intentionally invalidate existing login cookies.

It can be useful during a security response, but it is the opposite of what you want while trying to preserve existing sessions.

PRBLEM Diagnosis: If everyone gets logged out simultaneously, investigate shared configuration changes. A single user’s browser cookie is unlikely to explain a site-wide logout event.

Diagnosis Path I: WordPress Session Tokens Are Being Removed

WordPress maintains login session tokens for users.

If the session token associated with your login is removed, the browser may still contain a cookie but WordPress will no longer consider that session valid.

This can happen intentionally when:

You log out
A session-management feature destroys other sessions
A security plugin terminates sessions
An administrator forces session invalidation
Custom code manipulates user sessions

WordPress provides internal APIs for destroying current, other or all sessions.

This means custom plugins can deliberately log users out even though the browser and password are working correctly.

When to investigate custom session code

The problem started after a custom authentication plugin was added.
Only a certain user role is affected.
The logout happens after a specific action.
Security logs show no obvious cause.
Browser cookies remain present but WordPress still rejects the login.

At this stage, inspect plugins and custom code for session-management functionality rather than repeatedly deleting browser cookies.

Diagnosis Path J: A Plugin Conflict Changes Authentication Behaviour

Plugins do not have to be labelled as security plugins to affect login behaviour.

Plugins related to these areas may interact with authentication:

Membership
Single sign-on
Social login
Two-factor authentication
WooCommerce accounts
Custom login pages
User-role management
Cookie compliance
Reverse-proxy integration
Login redirects

Use controlled plugin isolation

Do not immediately disable every plugin on a production website.

If possible, reproduce the issue on a staging site.

Start with plugins that logically participate in authentication.

If you still cannot identify the cause, use the half-split method:

20 plugins active
       ↓
Disable 10
       ↓
Test login persistence
       ↓
Problem gone?
YES → suspect is in disabled group
NO  → suspect is in active group
       ↓
Split suspicious group again

Repeat until the component is isolated.

Then determine what setting or code path inside that component invalidates the session.

Diagnosis Path K: The Login Lifetime Was Intentionally Shortened

WordPress authentication cookies have expiration times.

Plugins and custom code can change those expiration periods.

Search custom plugins, theme code and snippets for:

auth_cookie_expiration

For example, custom code can modify the cookie lifetime using that filter.

If someone previously configured very short sessions for security reasons, WordPress may be behaving exactly as configured.

Do not increase the lifetime before diagnosing the cause

If WordPress logs you out after two minutes because a plugin destroys the session token, increasing cookie expiration to thirty days will not fix the problem.

A long-lived invalid cookie is still invalid.

PRBLEM Principle: Cookie expiration and cookie validity are different problems.

Use Browser Developer Tools to See What Happens to the Cookie

If the basic checks do not reveal the problem, inspect the authentication cookies directly.

In Chrome and many Chromium-based browsers:

Log in to WordPress.
Press F12.
Open the Application tab.
Open Cookies.
Select your WordPress domain.

Look for WordPress cookies whose names begin with values such as:

wordpress_
wordpress_sec_
wordpress_logged_in_

Do not copy or share their values. Authentication cookies are sensitive credentials.

Instead, inspect properties such as:

Domain
Path
Expiration
Secure flag

Useful diagnostic questions

After logging in, does the cookie exist?

When WordPress logs you out, does the cookie disappear?

Does it exist for www.example.com while you are browsing example.com?

Is the cookie marked Secure while requests unexpectedly switch to HTTP?

These observations can tell you whether the browser lost the cookie or WordPress rejected a cookie that was still present.

Security warning: Never post authentication-cookie values in a forum, support ticket, screenshot or public bug report.

The Cookie Exists but WordPress Still Says You Are Logged Out

This is an important distinction.

If developer tools show that the authentication cookie is still present but WordPress redirects you to the login screen, WordPress may be rejecting the cookie rather than the browser deleting it.

Investigate:

Session-token invalidation
Security-key changes
Plugin authentication filters
Different servers using different configuration
Database/session problems

This is a very different problem from a browser that refuses to store cookies.

Advanced Case: Multiple Web Servers Do Not Share the Same Authentication Configuration

Larger WordPress installations may run behind a load balancer with multiple application servers.

For example:

Load Balancer
   ↓           ↓
Server A     Server B
   ↓           ↓
   Shared Database

If the servers do not use identical WordPress authentication keys, salts and relevant configuration, a cookie accepted by one server may fail when the next request reaches another.

The symptom can appear random:

Request 1 → Server A → Logged in
Request 2 → Server A → Logged in
Request 3 → Server B → Logged out
Request 4 → Server A → Login appears to work again

If your site uses multiple application servers, containers or auto-scaling instances, verify that authentication-related WordPress configuration is identical across every instance.

Also verify that all servers use the intended shared database and deployment configuration.

PRBLEM Diagnosis: Apparently random login failures in a load-balanced environment should make you ask whether different requests are reaching servers with different authentication configuration.

Special Case: WordPress Logs You Out Only When You Save a Post

The block editor uses background requests and WordPress APIs while you edit and save content.

If you stay logged in while browsing wp-admin but encounter authentication errors while saving, check:

REST API requests
Security-plugin firewall rules
Proxy configuration
HTTP/HTTPS detection
Cookie domain consistency
Expired or invalid nonces

You may see an editor message suggesting that the response is invalid, authorization failed or the session expired.

Check Site Health

Go to:

Tools → Site Health

Look for problems involving the REST API, HTTPS or loopback requests.

An editor-specific failure may provide more useful evidence than a general logout message.

Special Case: Only Administrators Are Logged Out

If subscribers or customers remain logged in while administrators are repeatedly disconnected, investigate functionality that treats privileged users differently.

Admin security policies
Two-factor authentication
wp-admin cache exclusions
Administrator session limits
Custom dashboard plugins
Security rules based on role

A role-specific pattern is evidence that the entire WordPress authentication system is probably not universally broken.

Special Case: All Users Are Logged Out at the Same Time

This pattern deserves special attention.

If many users lose their sessions simultaneously, look for events that affect authentication globally.

WordPress security keys were regenerated.
A deployment replaced wp-config.php.
A security tool forced session termination.
A migration restored older database data.
A session-management process removed tokens.
Servers started using inconsistent authentication configuration.

A global event requires a global explanation.

Do not waste time clearing cookies individually on every user’s computer.

Three Main Solution Paths

Solution Path 1: Domain or Protocol Mismatch

Use this path if requests switch between www and non-www, or between HTTP and HTTPS.

Choose the site’s intended canonical hostname.
Confirm WordPress Address and Site Address.
Check WP_HOME and WP_SITEURL.
Inspect COOKIE_DOMAIN if it is manually defined.
Correct redirect rules.
Verify HTTPS detection behind proxies.
Clear old site cookies and log in again.

Solution Path 2: Plugin, Security or Session Policy

Use this path if URLs remain stable but sessions are intentionally terminated.

Inspect security logs.
Check idle timeout and maximum-session settings.
Check concurrent-login rules.
Temporarily disable the suspected feature.
Test the original workflow.
Isolate authentication-related plugins if necessary.
Reconfigure or replace the component responsible.

Solution Path 3: Infrastructure or Configuration Inconsistency

Use this path when the problem appears random, affects many users or started after a server/deployment change.

Check whether authentication keys or salts changed.
Verify all application servers use the same wp-config.php values.
Check reverse-proxy HTTPS headers.
Confirm every server uses the intended database.
Check whether deployments regenerate configuration.
Inspect session-token behaviour.
Test requests across multiple application instances if possible.

A Fast Troubleshooting Order

WordPress keeps logging you out
        ↓
Test another browser
        ↓
Problem disappears?
YES → Browser cookies/extensions
NO
        ↓
Check www vs non-www
        ↓
Check HTTP vs HTTPS
        ↓
Check WP_HOME / WP_SITEURL
        ↓
Check COOKIE_DOMAIN if manually set
        ↓
Using Cloudflare / proxy / load balancer?
        ↓
YES → Verify HTTPS detection
        ↓
Check page-cache/CDN rules
        ↓
Check security-plugin session policies
        ↓
Check authentication-related plugins
        ↓
Cookie remains but session fails?
        ↓
Check session tokens / security keys
        ↓
Multiple servers?
        ↓
Verify identical auth configuration

Do Not Use These as First Fixes

Do not reinstall WordPress.
Do not reset your password repeatedly if the password clearly works.
Do not increase cookie lifetime before checking why the current cookie becomes invalid.
Do not add COOKIE_DOMAIN without understanding your domain setup.
Do not disable HTTPS to make login work.
Do not disable every security feature permanently.
Do not regenerate WordPress salts unless you intentionally want existing sessions invalidated.
Do not cache wp-admin or login responses using broad CDN rules.
Do not change several URL and proxy settings simultaneously.

If you change multiple authentication variables at once and the problem disappears, you will not know which change solved it.

How to Verify the Fix

A successful login once is not enough.

After applying the fix, perform the same sequence that previously caused the logout.

Clear old cookies for the site if configuration changed.
Log in normally.
Open several wp-admin screens.
Edit a post.
Save the post.
Open Media Library.
Open Plugins.
Return to the dashboard.
Wait longer than the previous failure interval.
Repeat the actions again.

Also watch the browser URL throughout the test.

Confirm that it remains on the expected:

hostname
protocol
domain

If the site uses a proxy or multiple application servers, repeat enough requests to make sure the fix is stable rather than coincidental.

If WordPress Still Logs You Out

If the basic fixes fail, stop treating the problem as a generic cookie issue.

Collect evidence.

Record:

The exact URL used to log in
The URL shown immediately before logout
Whether www changes
Whether HTTP/HTTPS changes
Whether the authentication cookie still exists after logout
Whether another browser is affected
Whether all users are affected
Whether the problem began after enabling a plugin, CDN or proxy
Whether the site uses multiple application servers
Whether security keys or deployment configuration recently changed

Then you can report something useful such as:

Login succeeds at https://example.com/wp-admin/. The session remains valid while browsing wp-admin, but saving a post redirects to the login screen. The authentication cookie is still present. The issue began after the site was moved behind a reverse proxy.

That immediately points the investigation toward authentication validation, HTTPS detection and proxy configuration.

Compare that with:

WordPress keeps logging me out.

The first report contains evidence. The second contains only a symptom.

Quick Recovery Checklist

Test another browser.
Test a private/incognito window.
Clear cookies only for the affected domain.
Check whether browser extensions remove or restrict cookies.
Compare www and non-www URLs.
Compare HTTP and HTTPS URLs.
Check WordPress Address and Site Address.
Check WP_HOME and WP_SITEURL.
Inspect COOKIE_DOMAIN if manually defined.
Check reverse-proxy and Cloudflare HTTPS detection.
Verify login/admin pages are not incorrectly cached.
Inspect security-plugin session settings.
Check authentication-related plugins.
Check whether authentication keys or salts changed.
Investigate session-token invalidation.
Verify identical configuration across multiple servers.
Test the exact workflow that previously triggered logout.

Final Diagnosis

When WordPress repeatedly logs you out, the most useful question is not whether your password is correct.

If the password works repeatedly, authentication is succeeding at least temporarily.

The real question is what happens to the authenticated session afterward.

Browser layer: The authentication cookie is blocked, deleted or corrupted.

Domain layer: Requests move between different hostnames and the expected cookie is not available.

HTTPS layer: WordPress and the proxy disagree about whether the request is secure.

Cache layer: Dynamic login or administration responses are being handled by inappropriate cache rules.

Plugin layer: Security, membership or authentication code intentionally terminates the session.

Session layer: WordPress no longer recognizes the session token represented by the browser cookie.

Configuration layer: Security keys, salts or server configuration change between requests.

Infrastructure layer: Different servers disagree about the authentication environment.

Once you determine which layer invalidates the login, repeated logout stops being a mysterious WordPress problem and becomes a specific configuration issue that can be tested and fixed.

PRBLEM Principle: A login session is a chain of trust between the browser, WordPress and the server. When WordPress logs you out, find which link stopped agreeing with the others.

Did this solution fix your problem?

Optional feedback helps us improve this guide. Never send private data.

PRBLEM / COMMUNITY

Discuss This Solution

Ask a question, compare results, or share a safe fix that worked for you.

Describe the exact issueInclude the error, device or software version, and what you already tried.

Protect your informationNever post passwords, recovery codes, private logs or personal data.

WordPress Keeps Logging You Out: Cookies, Sessions, Cache and Server Causes Explained

How WordPress Keeps You Logged In

First: Identify Exactly When WordPress Logs You Out

Pattern A: You log in and are immediately sent back to the login screen

Pattern B: Login works, but you are logged out after a few minutes

Pattern C: You are logged out when saving or publishing

Pattern D: You are logged in on one page and logged out on another

Pattern E: Only one browser or device is affected

Diagnosis Path A: Browser Cookies Are Missing or Corrupted

Test A1: Use another browser

Test A2: Use a private window

Solution A1: Clear cookies for this site only

Solution A2: Check extensions that manipulate cookies

Diagnosis Path B: www and Non-www URLs Do Not Match

Check WordPress URLs

Look at the URL when the logout happens

Check wp-config.php for forced URLs

Diagnosis Path C: HTTP and HTTPS Are Fighting Each Other

Test C1: Watch for protocol changes

Check FORCE_SSL_ADMIN

Diagnosis Path D: Cloudflare or a Reverse Proxy Hides HTTPS from WordPress

Possible symptoms

Check whether WordPress detects HTTPS

Diagnosis Path E: COOKIE_DOMAIN Is Wrong

Common situation

Diagnosis Path F: A Cache Is Serving Pages That Should Never Be Shared

Test F1: Temporarily bypass page caching

Check CDN cache rules

Diagnosis Path G: A Security Plugin Is Invalidating Sessions

Test G1: Check security logs before disabling the plugin

Test G2: Temporarily disable only the relevant session feature

Diagnosis Path H: WordPress Security Keys Are Changing

When to suspect changing salts

Do not replace the keys as a random fix

Diagnosis Path I: WordPress Session Tokens Are Being Removed

When to investigate custom session code

Diagnosis Path J: A Plugin Conflict Changes Authentication Behaviour

Use controlled plugin isolation

Diagnosis Path K: The Login Lifetime Was Intentionally Shortened

Do not increase the lifetime before diagnosing the cause

Use Browser Developer Tools to See What Happens to the Cookie

Useful diagnostic questions

The Cookie Exists but WordPress Still Says You Are Logged Out

Advanced Case: Multiple Web Servers Do Not Share the Same Authentication Configuration

Special Case: WordPress Logs You Out Only When You Save a Post

Check Site Health

Special Case: Only Administrators Are Logged Out

Special Case: All Users Are Logged Out at the Same Time

Three Main Solution Paths

Solution Path 1: Domain or Protocol Mismatch

Solution Path 2: Plugin, Security or Session Policy

Solution Path 3: Infrastructure or Configuration Inconsistency

A Fast Troubleshooting Order

Do Not Use These as First Fixes

How to Verify the Fix

If WordPress Still Logs You Out

Quick Recovery Checklist

Final Diagnosis

Did this solution fix your problem?

Leave a reply Cancel reply