WordPress keeps logging out: how to fix it

You log in to WordPress, navigate to a page or click a link, and find yourself back at the login screen. You log in again, and the same thing happens. Sometimes the session lasts a few minutes. Sometimes it lasts a single click. No error message, no explanation – just a silent redirect back to wp-login.php.

This is not a random glitch. WordPress sessions depend on a chain of cookies, URL settings, and server configuration all working together. When any link in that chain breaks, the authentication cookie becomes invalid and WordPress treats you as a logged-out visitor. The fix depends on identifying which link is broken.

How WordPress sessions work#

Understanding the mechanism makes the diagnosis much faster.

When you log in, WordPress creates two cookies in your browser:

1. wordpress_logged_in_{hash}  – identifies who you are. Used by WordPress to determine if you should see the admin bar, which user profile to load, and whether you have permission to access specific pages.
2. wordpress_{hash}  – used specifically for wp-admin authentication. This cookie is only sent for requests to the admin area.

The {hash} portion of the cookie name is derived from the site URL in your WordPress settings. This is important – if the URL changes or is inconsistent, the cookie name changes, and your existing cookie no longer matches.

Both cookies contain:

• Your username
• An expiration timestamp
• A token (a unique session identifier)
• An HMAC hash (a cryptographic signature using your authentication keys and salts from wp-config.php)

On every authenticated request, WordPress reads the cookie, verifies the HMAC signature, checks the expiration, validates the token against the session store in the database, and confirms the user still exists. If any of these checks fail, you are logged out.

Cause 1: WordPress URL mismatch#

The most common cause. WordPress stores two URLs in the database:

• WordPress Address (siteurl) – where WordPress core files live
• Site Address (home) – the URL visitors use to reach the site

These are configured in Settings > General. The authentication cookie is tied to the domain and path derived from these values. If there is any inconsistency – http vs https , www vs non-www, a trailing slash difference, or a path difference – the cookie set during login does not match the URL of the page you navigate to, and the browser does not send it.

How to confirm

Check the two URLs:

wp option get siteurl
wp option get home

They should be identical in most WordPress installations. Common mismatches:

• https://example.com  vs  http://example.com
• https://www.example.com  vs  https://example.com
• https://example.com  vs  https://example.com/  (trailing slash)

How to fix

Update both to the same value:

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

Or via SQL:

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

If you cannot access wp-admin, you can force the URLs in wp-config.php:

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

These constants override the database values. Remove them after fixing the database values if you want to manage the URLs from Settings > General again.

Cause 2: HTTPS not detected behind a proxy or CDN#

If your site uses HTTPS but sits behind a reverse proxy, load balancer, or CDN (like Cloudflare), the proxy terminates SSL and forwards the request to WordPress over HTTP. WordPress sees the request as HTTP and generates cookies with the wrong secure flag, or redirects to HTTP, creating a loop.

How to confirm

Your site URL is https:// but WordPress sometimes generates HTTP URLs or sets cookies without the Secure flag. You may see the login page alternate between HTTP and HTTPS.

How to fix

Tell WordPress to trust the proxy’s forwarded protocol header. Add this to wp-config.php :

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

This makes WordPress recognize HTTPS even when the connection from the proxy is HTTP. The X-Forwarded-Proto header is set by the proxy and is trusted because it comes from your own infrastructure, not from the client.

On Hostney, Nginx sets this header automatically when proxying to PHP or Apache backends, so WordPress detects HTTPS correctly without manual configuration.

Also force SSL for the admin area:

define('FORCE_SSL_ADMIN', true);

Cause 3: Authentication keys and salts changed or missing#

WordPress uses the keys and salts in wp-config.php to generate the HMAC signature in the authentication cookie:

define('AUTH_KEY',         'unique phrase here');
define('SECURE_AUTH_KEY',  'unique phrase here');
define('LOGGED_IN_KEY',    'unique phrase here');
define('NONCE_KEY',        'unique phrase here');
define('AUTH_SALT',        'unique phrase here');
define('SECURE_AUTH_SALT', 'unique phrase here');
define('LOGGED_IN_SALT',   'unique phrase here');
define('NONCE_SALT',       'unique phrase here');

If any of these change, every existing authentication cookie becomes invalid instantly. Every logged-in user is logged out.

How to confirm

You were logged out suddenly without any settings change. Multiple users were logged out at the same time. Someone recently edited wp-config.php.

How to fix

If the keys were accidentally changed, restore wp-config.php from a backup to get the original keys back. All users can log in again with their existing cookies.

If the keys were intentionally changed (security measure after a compromise), this is expected behavior. All users need to log in again. This is actually the recommended way to force all sessions to expire – see My WordPress site was hacked: what to do right now for the full incident response procedure.

If the keys are set to the default placeholder ( put your unique phrase here ), generate new ones from the WordPress API:

https://api.wordpress.org/secret-key/1.1/salt/

Copy the output and replace the existing key definitions in wp-config.php. After this change, all users will need to log in again – this is a one-time event.

Cause 4: Cookie domain or path mismatch#

WordPress sets cookies for a specific domain and path. If you have custom cookie settings in wp-config.php that do not match your actual site URL, cookies are set for the wrong domain and the browser does not send them on subsequent requests.

How to confirm

Check wp-config.php for these constants:

grep -i "cookie" wp-config.php

Look for:

• COOKIE_DOMAIN
• COOKIEPATH
• SITECOOKIEPATH
• ADMIN_COOKIE_PATH

How to fix

If any of these constants are set and the values are wrong, either correct them or remove them entirely. WordPress calculates the correct values automatically from the site URL in most cases. Custom cookie configuration is only needed for unusual setups (multisite, subdirectory installations, or sites with multiple domains).

If you are not running multisite, remove all custom cookie constants from wp-config.php and let WordPress use its defaults.

Cause 5: Browser rejecting cookies#

Sometimes the problem is not server-side at all. The browser is not storing or sending the cookies.

How to confirm

Try a different browser. If the problem only occurs in one browser, the issue is client-side.

Common browser-side causes

Cookies blocked. The browser’s privacy settings may block third-party or all cookies. Ensure cookies are allowed for your domain.

Browser extensions. Privacy extensions (uBlock Origin, Privacy Badger, Cookie AutoDelete) can intercept and block WordPress authentication cookies. Temporarily disable extensions and test.

Clock skew. Cookie expiration is time-based. If your computer’s clock is significantly wrong (hours or days off), the browser may consider cookies expired immediately after they are set. Sync your system clock.

Corrupted cookies. The browser may have a corrupted cookie for your domain. Clear all cookies for your site’s domain specifically (not all cookies – just the ones for your domain), then log in again.

Cause 6: Session tokens expired or corrupted in the database#

WordPress stores session tokens in the usermeta table under the key session_tokens . Each session has a token, an expiration time, and metadata. If the session data is corrupted or the database clock is out of sync, valid sessions are rejected.

How to confirm

You can log in but are logged out on the next request. The cookie is valid (correct HMAC), but the token check against the database fails.

How to fix

Delete all sessions for your user and log in fresh:

wp user session destroy --all

Or for a specific user:

wp user meta delete admin session_tokens

Then log in again. WordPress creates a fresh session token.

If this happens to multiple users or recurrently, check the server’s clock. A database server with a clock skew will generate inconsistent timestamps that confuse session validation:

date

Compare this with an accurate time source. If the server clock is off, sync it with NTP.

Cause 7: Caching logged-in pages#

If a caching layer caches pages that include authentication cookies or nonces, a user may receive a cached page that contains another user’s nonce or no nonce at all. WordPress sees the invalid nonce and redirects to the login page.

How to confirm

The problem comes and goes, or affects some users but not others. It correlates with cache-related settings or traffic patterns.

How to fix

Ensure that logged-in users are excluded from page caching. This is a fundamental caching rule for WordPress:

• WordPress caching plugins (WP Super Cache, W3 Total Cache) should have “Do not cache pages for logged-in users” enabled.
• Server-level caching (Nginx FastCGI cache, Varnish) should bypass cache when WordPress login cookies are present.
• CDN caching (Cloudflare) should not cache HTML responses with Set-Cookie headers or pages behind wp-admin.

On Hostney, the Nginx FastCGI cache automatically detects WordPress login cookies and bypasses the cache for authenticated users. The Hostney Cache plugin manages these exclusions, so this issue does not occur with the default configuration. See How Hostney handles WordPress cache purging automatically for how the caching layer works with WordPress sessions.

Cause 8: PHP session conflicts#

Some plugins use PHP sessions ( session_start() ) alongside WordPress’s cookie-based authentication. If the PHP session handler is misconfigured (wrong save path, no write permission, session garbage collection too aggressive), it can interfere with the authentication flow.

How to confirm

The error log shows session-related warnings:

Warning: session_start(): open(/tmp/sess_..., O_RDWR) failed: Permission denied

How to fix

Check the PHP session save path:

wp eval "echo session_save_path();"

Ensure the directory exists and is writable by PHP. On Hostney, each container has its own isolated temporary directory, so session conflicts between sites do not occur.

If a plugin is using PHP sessions and causing problems, identify which plugin calls session_start() :

grep -r "session_start" wp-content/plugins/

The plugin may have an alternative session handling option, or you may need to ensure the session save path is writable.

Quick diagnostic checklist#

When WordPress keeps logging you out, work through this sequence:

1. Check URLs. Run  wp option get siteurl  and  wp option get home . They must match exactly, including protocol and www/non-www.
2. Check cookies in browser. Open developer tools > Application > Cookies. Look for  wordpress_logged_in_*  after logging in. If it is not there, the browser is rejecting it.
3. Check wp-config.php. Look for custom  COOKIE_DOMAIN ,  COOKIEPATH , or modified authentication keys.
4. Try a different browser. If it works in another browser, the issue is client-side (extensions, privacy settings, clock).
5. Clear all caches. Server cache, plugin cache, CDN cache, browser cache.
6. Check error logs. PHP errors during authentication are logged but not displayed to users.

Most cases are resolved at step 1 or 2. URL mismatches and browser cookie issues account for the vast majority of WordPress session problems.

How Hostney handles sessions#

HTTPS detection. Nginx automatically sets the X-Forwarded-Proto header, so WordPress correctly detects HTTPS regardless of the backend configuration. This eliminates the most common proxy-related cookie issue.

Cache exclusions. The Nginx FastCGI cache detects WordPress session cookies and automatically bypasses cache for logged-in users. This prevents the cached-page-with-wrong-nonce scenario entirely.

Container isolation. Each site’s PHP process runs in its own container with its own session storage. One site’s session handling cannot interfere with another’s.

Consistent URLs. SSL is provisioned automatically and the site URL is set correctly during setup. The HTTP-to-HTTPS mismatch that causes most session problems on other platforms is avoided from the start.

Summary#

WordPress logging you out repeatedly means the authentication cookie is not being sent, not being accepted, or not matching the expected values. The cause is almost always a URL mismatch (HTTP vs HTTPS, www vs non-www), a proxy not forwarding the protocol correctly, changed authentication keys, or a caching layer serving cached pages to logged-in users.

Check the site URL settings first – this fixes the majority of cases. If the URLs are correct, work through cookies, wp-config.php, and caching. The error logs are your friend here, especially the PHP error log, which captures authentication failures that WordPress does not display to the user. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.