Round-robin sends each request to a different backend — by design. For stateless services that's perfect. But the moment a user logs in, fills a cart, or starts a remote desktop, the application starts holding state on one specific backend. If request #2 lands on a different one, the user sees an empty cart, a logged-out screen, or a frozen RDP session.
Session persistence (or 'affinity') solves this by pinning a user to a chosen backend for the duration of the session. The catch: there's no single right way to pin. Source-IP works for unique-IP users but breaks behind corporate NAT. Cookies work in browsers but not for raw TCP. URL-parameter hash works for stateless URLs but not for user-scoped flows. Each method is right somewhere.
The answer is to ship every method and pick per vService.
Each vService picks its persistence method from a dropdown — alongside its load-balancing algorithm. Both layers are independent: choose Fastest+ for backend selection and a TR7 cookie for affinity, or round-robin with source-IP, or whatever combination fits the workload. Method choice is hot-swap, no restart.
Five self-persistent load-balancing algorithms (source, URI, URL-param, header, RDP-cookie) plus four explicit persistence methods (TR7 cookie, backend cookie, dynamic, SAM). Cover every common case.
Session Affinity Manager lets you set the cookie source (TR7-generated or backend-generated), session format (UUID, IP-timestamp-random, IP-random, custom), and security flags (HttpOnly, Secure, SameSite=Strict/Lax) — without touching backend code.
Persistence runs on top of the load-balancing algorithm: the algorithm picks the backend for the first request, persistence pins the rest. Fastest+ for cold-start, sticky cookie for the session — works together.
Change persistence method on a live vService and new sessions adopt the new method immediately. Existing pinned sessions continue undisrupted until they expire.
Pick the method that fits the protocol, the client population, and the application's session model. All 9 available per vService — no code, no plugin.
Same client IP always lands on the same backend. Simple, code-free, works for any protocol. Best when client IPs are diverse — breaks down behind shared NAT or corporate proxies.
Hash on the URL length distributes load by URL complexity while pinning identical URLs to the same backend. Useful for cache-affinity scenarios.
Hash on a specific query parameter (e.g. ?user_id, ?session_token). Routes the same user-scoped request to the same backend without requiring cookies.
Hash on a custom HTTP header. Useful when the upstream caller injects tenant or correlation IDs, or for header-based A/B routing.
Read the RDP session cookie embedded in the protocol negotiation. Required for RDP gateways and remote-desktop farms — keeps users on the same RDP host after reconnect.
TR7 ADC generates and manages the affinity cookie itself — no backend code required. Operator sets the cookie name and a max-idle timeout; the ADC reads it on every request, the backend ignores it. Easiest persistence to bolt onto a legacy app.
Use the application's own session cookie for affinity — operator names the cookie (PHPSESSID, JSESSIONID, app-id, anything custom) and TR7 ADC reads the existing value. No new cookies added. Right when the application already tracks sessions and you don't want to layer a second cookie.
Hash-key persistence table maintained in memory. Each entry maps a key — any combination of request headers, cookies, source IP, or URL parameters — to a backend. Operator sets the table size (10K to 100M entries, default 3M) and the entry expire time. Use when persistence rules need to be more flexible than a single fixed cookie or header.
The advanced cookie-based persistence engine. Choose who generates the cookie, the session-id format, and the security flags — all from the UI, no backend changes. See details below.
SAM is TR7's most flexible persistence method. Where a plain cookie pins a session, SAM lets you control every property of that cookie from a dropdown — without backend changes, without writing rule code.
Choose who generates the affinity cookie: TR7-generated (default — no backend involvement) or backend-generated (use the application's existing session cookie). Switch between them without breaking active sessions.
Session identifier format options: UUID (random 128-bit), IP-timestamp-random (traceable, time-ordered), IP-random (anonymous within a tenant), or Custom. Custom mode opens the full traffic variable surface — combine any request headers, cookies, URL components, TLS session info, source IP (raw or masked), JWT claims, query parameters, and even request body fields with operator-defined transform functions (masking, hashing, substring extraction, case normalization, concatenation). The same variable-and-transform engine drives Dynamic persistence hash keys. See the spotlight below for real-world combinations.
Cookie security flags: HttpOnly (no JavaScript access — XSS protection), Secure (HTTPS-only), SameSite=Strict (no cross-site sending — CSRF protection), SameSite=Lax (compatibility-friendly variant). Combine as needed.
Everything above is a per-vService dropdown in the SAM panel. No custom rule code, no backend integration, no separate WAAP rule for cookie handling. SAM is a configuration, not a script.
SAM Custom Format and Dynamic persistence hash keys accept every traffic variable TR7 ADC sees — combine them, transform them, build the exact persistence rule your application needs
Users add items across multiple page loads. Backend cookie or TR7 cookie keeps the cart state on one backend — checkout never sees an empty cart.
Logged-in sessions where the user's permission cache lives on one backend. SAM with TR7-generated cookie + HttpOnly + Secure works without backend code changes.
RDP sessions must reconnect to the same host. RDP cookie persistence reads the protocol-native session ID — no extra config, no cookie injection.
Applications that don't track sessions themselves. Source-IP or URL-parameter persistence pins users without requiring code changes to the legacy app.
See how 9 persistence methods cover every common case — from RDP gateways to legacy apps to SAM-controlled cookies.