My application keeps sending users back to the login screen (the session is lost); why?

Short answer

Session loss has two main sources: the requests are going to another Backend Service that does not hold the session, or the browser is not sending the session cookie back or the application cannot read it. The first group includes Persistence not being defined at all, its durations being shorter than the session of the application, and the server going down. In the second group, TR7's cookie actions stand out: Cookie Encryption binds the cookie to the client's IP address and User-Agent, and when these change, the cookie that cannot be decrypted goes to the application with the value FAILED_COOKIE_DECRYPTION; SameSite=Strict in HTTP Cookie Security does not send the cookie on SSO returns. Access over HTTP with a Secure cookie and an application that is unaware that TLS is terminated on TR7 also lead to the same result.

Possible Causes

Cause	How to recognize it	Page to check
Persistence is not defined	In HTTP Logs, the requests of the same client go to different Backend Services	How do I know whether my application needs persistence?
Persistence exists but breaks	The server changes in certain situations	Persistence is enabled, but my users still end up on different servers; why?
The Persistence duration is shorter than the session	It drops after a certain idle time; in New Cookie, the Cookie Max-Idle default is 30 minutes and the Cookie Max-Life default is 8 hours	What is the difference between New Cookie and Current Cookie?
Cookie encryption and a changing IP or User-Agent	After switching between a mobile network and Wi-Fi, or after a browser update; the cookie value in the application log is FAILED_COOKIE_DECRYPTION	The action is limited with Certain Cookies to only the session cookies produced by the application; if there is a CDN in front of TR7, the real client IP is resolved with Trusted Proxy (There is a CDN such as Cloudflare / Akamai in front of TR7; how do I get the Real client IP (trusted proxy)?)
Cookie encryption is on with All Cookies	A login flow that depends on JavaScript or third-party cookies breaks	The scope is set to Certain Cookies
SameSite=Strict	A new login is required on an SSO, OAuth or payment return	Can I automatically add the Secure, HttpOnly and SameSite attributes to cookies?
Secure cookie and HTTP access	When the site is opened with http://, there is no session	How do I redirect HTTP to HTTPS?
The application is unaware of HTTPS	After login, the Location is http://…	The backend application generates http:// in absolute URLs; how do I fix it?
Host or cookie Domain mismatch	The Set-Cookie Domain value is an internal name; switching between the www and non-www address	How do I set up a redirect that adds or removes www?
The server goes down from time to time	Drops in the health check history	The health check keeps going back and forth between up/down (flapping); what should I do?
The personalized page comes from the cache	A logged-out page for a logged-in user	How do I prevent user-specific content from being cached by mistake?

Definitive rules:

• The Cookie Encryption key is derived from the vService ID, the client's IP address and the User-Agent information. If the IP or User-Agent changes, the cookie cannot be decrypted; TR7 does not delete the cookie, it forwards it to the Backend Service by setting its value to FAILED_COOKIE_DECRYPTION. When the action is enabled, the unencrypted cookies given earlier cannot be decrypted either; the sessions open at that moment drop.
• In HTTP Cookie Security, Mark as Secure is applied only to the responses of HTTPS requests; Mark as SameSite=Strict is applied to all Set-Cookie headers, including TR7's own Persistence cookie. If a value other than Strict is needed, Replace HTTP Header Content is used.

Where Is It Monitored?

Screen	Path	What it shows
Browser developer tools	Network and Application tabs	The Set-Cookie values (Domain, Path, Secure, SameSite), whether the cookie is sent in the next request, the Location after login
HTTP Logs	Load Balancer vServices → vService → Logs & Tracking	Which Backend service the requests of the same Client IP go to
Load Balancer Management	vService → Load Balancer Management	The Persistence setting and the actions that touch cookies on a single screen
Application log	Backend Service	FAILED_COOKIE_DECRYPTION in the cookie value

How to Diagnose?

1. The cookie is tracked in the browser: whether Set-Cookie comes in the login response; the Domain, Path, Secure and SameSite values; whether the cookie is sent in the next request; and whether the Location value after login is http:// are checked.
2. A server change is looked for: Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP Logs is opened; in the Filter panel, the user's address is selected from the Client IP card and the Backend Service value is checked. If the server changes at the moment of the return to the login screen, the problem is in Persistence (How do I find the requests of a specific client IP in the logs?).
3. The vService settings are reviewed: the Persistence type and durations; the Cookie Encryption and HTTP Cookie Security actions on the vService and the Set HTTP Header actions that change the Host header are checked.
4. The application log is examined: if FAILED_COOKIE_DECRYPTION appears in the cookie value, Cookie encryption could not decrypt the cookie.
5. The server status and reloads are checked: whether the Backend Service went down at the time of the event and whether the configuration was reloaded are checked (Does saving a configuration change reset the persistence tables?).

Common Misconceptions

• "Session loss is always a Persistence problem." TR7's cookie actions and HTTP/HTTPS differences also drop the session.
• "Turning on Cookie encryption with All cookies is the most secure." The JavaScript and third-party cookies that TR7 does not encrypt also become FAILED_COOKIE_DECRYPTION; only the cookies produced by the Backend Service are named with Certain Cookies.
• "SameSite=Strict works without problems in every application." In SSO, OAuth and payment flows that return from external sites, the cookie is not sent.
• "Deleting and recreating the vService solves the problem." The encryption key is bound to the vService ID; on the new vService, all the encrypted cookies given earlier become invalid.

How it is done in the documentation

• Cookie Encryption · The Encryption Key and Validity
• HTTP Cookie Security · Operational and Safe Usage Recommendations
• HTTP (L7) vService · Persistence

Related questions

• Persistence is enabled, but my users still end up on different servers; why?
• The backend application generates http:// in absolute URLs; how do I fix it?
• An infinite redirect loop occurred; why?