A login can appear successful and still lose its session on the next request. PHP sessions depend on a cookie reaching the browser and the server being able to retrieve the matching session data. Check both sides before changing cookie settings at random.
Confirm the browser sends the cookie
Use the browser's developer tools to inspect the login response and the next request. Did the response set a session cookie? Is it sent after the redirect? Compare hostname, scheme and path: a cookie scoped to one subdomain or path may not reach another. Secure cookies require HTTPS, and SameSite behavior can affect cross-site flows.
Start the session before output and use the same session configuration consistently. Review proxy HTTPS detection if TLS terminates before PHP; an incorrect view of the request scheme can produce the wrong cookie behavior.
Check where session data is stored
Inspect PHP's configured session handler and save path in the web runtime, not only CLI. Verify that the web-server process can write and read the storage. In a load-balanced setup, requests may reach different servers; they need shared session storage or reliable affinity.
Look for cleanup jobs, permission changes, disk pressure or application code that clears the session. Add temporary diagnostics that log a request ID and session state without logging the session ID itself or sensitive values.
Regenerate the identifier at the right point
After authentication, regenerate the session ID to reduce fixation risk, while preserving the intended session data. Test the transition with a fresh browser session and inspect the new cookie. Do not confuse a security-driven ID rotation with an unexplained session loss.
Trace the exact sequence: login POST, response headers, redirect and first authenticated request. That sequence usually narrows the fault to cookie scope, storage or application logic.
Related Articles