HTTP (L7) vService

What Is HTTP (L7) vService?

HTTP (L7) vService is the basic service type on TR7 that provides load balancing for HTTP and HTTPS traffic at the Layer 7 (Application Layer) level. It is designed for web applications, API services, microservice architectures and content delivery scenarios.

HTTP vService receives HTTP/HTTPS requests from clients, processes them according to the configured rules and directs them to the appropriate Backend Services. In this process, advanced operations such as SSL termination, content-based routing, caching, compression and security checks are performed.

In the TR7 architecture, HTTP vService is the vService type with the richest feature set. Compared to the other types (L7 TCP, Network), it supports all optimization and security features specific to the HTTP protocol.

What can be done with HTTP vService?

• Load balancing in the HTTP/1.1, HTTP/2 and HTTP/3 (QUIC) protocols,
• Reducing the Backend Service load with SSL/TLS termination,
• Web application security with WAF integration,
• Smart traffic distribution with content-based routing (content switching),
• Performance optimization with caching and compression,
• Improving the user experience with session persistence.

L7

Operating layer

Full HTTP awareness at the application layer

13

Load balancing algorithms

From round robin to hash-based routing

5

Session persistence types

None · New/Current cookie · Hash · SAM

TLS 1.3

Latest SSL/TLS

SNI · ALPN · HTTP/2 termination

HTTP/3

QUIC support

HTTP/1.1 · HTTP/2 · HTTP/3 (QUIC)

WAF

Application security

Layered protection with WAF and L7 DDoS

1 IP

Virtual Hosting

Many separate vServices on the same IP:port

QOS

Resource isolation

CPU and memory control per vService

AGS

Authentication

Central identity control in front of the application

Why HTTP vService?

In modern web architectures, the load balancer is not merely a component that distributes traffic; it is a critical control point in terms of security, performance and availability. HTTP vService combines all the capabilities offered at this control point under a single configuration.

High Availability

It is unacceptable for a single server failure to affect the entire service. HTTP vService eliminates the single point of failure (SPOF) by distributing traffic among multiple Backend Services. With health checks, faulty servers are automatically taken out of service; when a server becomes healthy again, it is automatically put back into traffic. Thanks to session persistence methods, active user sessions are preserved without disruption during traffic distribution.

Performance Optimization

HTTP vService prevents repeated requests from reaching the Backend Services with caching, reduces bandwidth usage with compression (GZIP/Deflate), increases connection reuse with Keep-Alive and distributes the load optimally with load balancing algorithms. With the QOS settings, the CPU and memory resources allocated to each vService can be controlled.

Security

Web applications are constantly under attack. HTTP vService blocks SQL injection, XSS and OWASP Top 10 threats with WAF, provides defense against application layer attacks with L7 DDoS & Threat Protection, and filters known malicious sources with IP Reputation and IP blacklists/whitelists. Encryption management is centralized with SSL/TLS termination; an authentication layer is added in front of the application with AGS.

Scalability and Operational Efficiency

When new Backend Services are added, traffic is distributed automatically. With centralized configuration, monitoring and reporting, many servers are managed from a single point. Operational visibility is provided with notifications and log forwarding.

Content Awareness and Flexibility

Thanks to Layer 7 awareness, HTTP vService evaluates traffic not only at the IP and port level but also at the level of the Host header, the URL, HTTP headers and content attributes. With Content Switching, different paths or domains are directed to different Backend Services; with Virtual Hosting, many separate vServices run on the same IP:port; with Actions, header adding, modifying and redirect operations are applied to requests and responses.

Supported Features

HTTP vService has the most comprehensive feature set offered by TR7.

Category	Features
Protocol	HTTP (unencrypted), HTTPS (HTTP/1.1, HTTP/2), HTTP/3 (QUIC), HTTP → HTTPS redirect; separate timeout for WebSocket tunnel connections
SSL/TLS	SSL/TLS termination, SNI, ALPN, SSLv3–TLSv1.3 version range, multiple certificates, TLS Security Profiles
Security	WAF, L7 DDoS & Threat Protection, IP Reputation, IP blacklist/whitelist, Rate Limiting
Authentication	Identity control in front of the application with AGS - AAM (Application Access Management)
Performance	Cache, Compression (GZIP/Deflate), Keep-Alive, QOS resource isolation, Bandwidth control
Routing	Content Switching, Virtual Hosting, Conditional / Default Backend Service, HTTP → HTTPS Redirect
Traffic Manipulation	Actions (header add / delete / modify, redirect, rewrite), X-Forwarded-For
Session Persistence	None, New cookie, Current cookie, Hash, Session Affinity Manager (SAM)
Algorithms	Round robin (default), Weighted Round Robin, Least Connection, Least Response Time¹, Least Bandwidth¹, First, Random, Fastest, Fastest+, Source, URI, URL Param, HDR
Monitoring & Reporting	Access Log, Debug mode, Reports, Notifications (SNMP / e-mail / SMS / interface)
Integration	SIEM / Syslog (CEF / JSON log profiles), IPFIX sending (Actions)

¹ Least Response Time and Least Bandwidth are applied as Least Connection when the selected Core Engine version does not support them.

Virtual Hosting

Under normal conditions, an IP address and port pair is used by a single vService. Virtual Hosting is an HTTP-type-specific feature that allows as many separate vServices as desired to be created on the same IP:port. In this way, many domains or applications can be served with a limited number of IP addresses, each with its own independent vService configuration. It is especially valuable in environments where IPv4 addresses are scarce.

Each vService defines the domain(s) it will serve in its own Virtual Hosting list. Traffic arriving at the same IP:port is received by a common front distributor and directed to the related vService according to the request's Host header (SNI in HTTPS). Each vService runs independently with its own certificate, security profiles, load balancing algorithm and Backend Services.

How does it work?

In the HTTP protocol, each request carries a Host header; this header specifies which domain the client wants to access. TR7 forwards the request to the related vService by matching on this header among the vServices on the same IP:port.

In HTTPS traffic, SNI (Server Name Indication) is used. Since SNI conveys the target domain name during the TLS handshake, the correct vService and its SSL certificate can be selected.

TIP

When the switch in the Virtual Hosting field is set to Enabled, the first domain row opens; when the switch is set to Disabled, the list is emptied. The feature is active as long as there is at least one domain in the list. The wildcard character (*) is supported in domain definitions; a wildcard definition (*.example.com) also matches more than one subdomain level (a.b.example.com). Virtual Hosting is valid only in the HTTP type; while there is a domain in the list, protocols with the HTTP/3 (QUIC) badge cannot be used.

Sharing and matching rules

• In all vServices that share an IP:port, the Virtual Hosting list must be filled and the frontends must be in the same encryption class (encrypted: HTTP/1.1, HTTP/2; unencrypted: HTTP, HTTP → HTTPS). A vService with an empty list cannot be defined on the same IP:port.
• In unencrypted frontends, matching is done with the exact value of the Host header; on ports other than 80, the Host value sent by the client also includes the port number.
• HTTP requests that match no vService's list receive a 503 response; in HTTPS, when the SNI does not match or the client sends no SNI, the connection is closed.

Use Cases:

• Multiple Websites: Separate vServices for www.example.com, blog.example.com, support.example.com on the same IP:port.
• Microservice Architecture: Managing the api.example.com, auth.example.com, cdn.example.com services over a single address with independent vServices.
• Multi-tenant Structures: Managing customer-based domains with separate vServices in SaaS applications.
• Development/Test Environments: Separation of dev.example.com, staging.example.com, prod.example.com.

The Virtual Hosting field in the add form and a step-by-step example are located in the HTTP vService Add Form section.

Supported Protocols

HTTP vService works at Layer 7. The options offered in the frontend Protocol selector:

• HTTP: unencrypted HTTP
• HTTP/1.1 and HTTP/2: with TLS termination (SNI, ALPN); the allowed TLS version range is determined in the SSL Security profile
• HTTP/3 (QUIC): served on the same address in addition to HTTP/1.1 or HTTP/2 (options with the HTTP/3 badge); depends on the QUIC support of the selected Core Engine version
• HTTP → HTTPS: redirecting unencrypted requests to HTTPS

For long-lived tunnel connections such as WebSocket, there is a separate Tunnel(Websocket) timeout value in the Timeout profile.

When the Keep Header Names action is attached to the vService, HTTP/2 and HTTP/3 are disabled; the frontend runs with HTTP/1.1.

Best Practices

• SSL/TLS should be enforced. All HTTP traffic should be redirected to HTTPS; the HTTP → HTTPS option is used as the Protocol on port 80. TLS 1.2 and later versions are enforced with an appropriate TLS Security Profile.
• WAF should be enabled. It provides protection against SQL injection, XSS and other OWASP Top 10 threats. The rules are optimized by monitoring the false positive rate.
• L7 DDoS & Threat Protection should be configured. Application layer attacks are reduced with request and connection rate limits, bot protection and IP reputation checks; the action to be applied when a limit is exceeded (block, redirect, CAPTCHA, etc.) is determined.
• Compression should be enabled. For text-based content (HTML, CSS, JavaScript, JSON), compression (GZIP/Deflate) provides bandwidth savings and speed improvement.
• Caching should be used. Caching for static content and frequently accessed API responses reduces the Backend Service load.
• Health checks should be configured. Appropriate health check profiles are defined for the Backend Services; the check interval is optimized for fast detection of faulty servers.
• X-Forwarded-For should be enabled. The XFF header is added so that the Backend Services can see the real client IP address. It is critical for log analysis and security.
• Timeout and vService limits should be adjusted to the application. Timeouts and connection/session limits are configured according to the characteristics of the application; holding resources unnecessarily and connection overflows are avoided.
• Session persistence should be chosen correctly. An appropriate persistence method is selected for stateful applications; if sessions need to be monitored or rebalanced at runtime, SAM is preferred. Persistence is not used in stateless applications; it disrupts load distribution.
• Critical vServices should be isolated with QOS. By allocating separate CPU and memory resources to high-priority services with QOS, stable performance is achieved even under load.

How to Add?

A new HTTP vService is added through the TR7 web management interface with the following steps:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The Load Balancer → Load Balancer vService List → Add steps are followed.
3. The HTTP selection that comes by default in the Type field is kept; the vService is configured for the HTTP/HTTPS protocol.
4. A unique name for the vService, the vDevice it will run on and the Frontend IP/Port/Protocol information it will listen on are entered.
5. The Backend Services to which the traffic will be directed are selected from the Default Backend Services or Conditional Backend Services field.
6. If needed, advanced settings (WAF, cache, compression, QOS, etc.) are configured from the Details panel.
7. The vService is added by clicking the Save button.

TIP

Reaching the page via quick search

Instead of navigating the menu step by step, the related page is reached directly by using the search bar in the bottom left corner of the screen. The search bar opens with the Alt + T shortcut on Windows and Opt + T on macOS; typing the name of the feature being searched for is then sufficient.

The vService listing screen and general vService management are located on the vService page; this page covers the add form and the Details panel of an HTTP-type vService.

HTTP vService Add Form

A new vService is added to the TR7 device by following the Load Balancer → Load Balancer vService List → Add steps. When HTTP is selected in the Type field, the following form is displayed.

HTTP vService Add Form

INFO

Status

Determines the initial status of the vService after it is created.

Option	Description
Enabled	The vService starts as active. It starts receiving traffic as soon as the configuration is applied. It is the standard selection for production environments.
Disabled	The vService is created but stays disabled. It does not receive traffic. It is used before the configuration is completed or during maintenance processes. It needs to be switched to Enable manually.
Debug mode	The vService starts as active and creates detailed debug logs for all requests. For each request, the request/response headers, timing information and processing details are recorded. It is offered only in the HTTP type; it is the same switch as the Details › Debug box.

Disabling and the Frontend IP

On TR7, IP addresses are device-level network resources that live independently of the vService; the vService uses this address only as a listening point (see Profile-Based IP Model). For this reason, when the vService is set to Disabled, the Frontend IP addresses (Interface IP / VIP) defined on it are not disabled automatically; depending on the interface, they continue to respond at the network layer.

If the Frontend IP address also needs to be turned off, the related IP is managed from the Interfaces List screen with the Disable (temporary) or Delete IP (permanent) operation.

About Debug mode

Debug mode produces a large amount of logs and increases disk I/O and CPU usage. Long-term use in a production environment is not recommended; it should be turned off when troubleshooting is completed. The Debug box in the Details panel is not a separate feature but the same switch: when the box is checked, Status switches to Debug mode, and when Debug mode is selected in Status, the box is checked. The additional capability of Details is that it can limit debugging with a condition.

INFO

Name Required

A unique name is entered for the vService.

INFO

vDevice Required

The vDevice on which the vService will run is selected.

INFO

Type Required

HTTP is selected as the vService type. Type is the discriminator field of the form: the selected type determines which fields/modules appear in the rest of the form and in the Details panel. HTTP is the TR7 type with the richest feature set.

Type	Layer	Description	Use Area
HTTP	Application (L7)	Full HTTP awareness; HTTP/1.1, HTTP/2, HTTP/3 (QUIC); SSL termination and content-based routing.	Websites, APIs, web applications
L7 TCP	Application (L7)	L7 processing for non-HTTP TCP protocols; SSL termination (TCP + TLS) support.	RDP, SQL, LDAP, SMTP, MQTT, custom TCP protocols
Network	Network (L3/L4)	High-performance packet-level distribution; TCP / UDP / ANY protocol, DSR / Route (NAT) / SNAT modes.	DNS, UDP services, raw TCP/IP

Fields specific to the HTTP type and common fields

Fields that exist only in the HTTP type (not visible in the L7 TCP and Network types):

• Main form: Virtual hosting · protocols with the HTTP/3 (QUIC) badge
• Details: Debug · WAF · L7 DDoS & Threat Protection · AGS · Trusted proxy · Cache · Compression · X-Forwarded-For

Details fields that exist in both HTTP and L7 TCP (in order): L7 DDoS & Threat Protection · Actions · LOG · SSL security · Notification · Report · QOS · Bandwidth · vService limits · Timeout · LB algorithm. In addition, TLS termination, certificate, SSL security profile and conditional / default Backend Service routing are also valid in both L7 types.

In the Network (L4) type, there are only packet-level distribution and L4-specific fields.

WARNING

Type is the most decisive choice of creation: while an existing vService is being edited, the Type and vDevice fields are locked and cannot be changed. When the type is changed in a new record, the Frontend list, modules and actions are reset. The correct type must be determined from the start: all web/HTTPS traffic is of the HTTP type.

For the other vService types and the full comparison: vService · L7 TCP · Network

INFO

Virtual Hosting

Normally, an IP:port combination can be used by only a single vService. Virtual Hosting allows as many vServices as desired to be created on the same IP:port: each vService defines the domain(s) it will serve in its own Virtual Hosting list, and TR7 directs incoming traffic to the correct vService according to the Host header (HTTP) or SNI (HTTPS). It can be used only in the HTTP type.

With Virtual Hosting:

• The same IP:port is shared among multiple vServices,
• Each vService serves its own domain(s) and presents its own SSL certificate with SNI,
• Traffic is directed to the related vService according to the Host / SNI value,
• Wildcard domains (*.example.com) are supported.

When the switch in the field is set to Enabled, the first domain row opens, and when it is set to Disabled, the list is emptied; having at least one domain in the list makes that vService eligible to join a shared IP:port. Each row added to the list must be a valid domain name and must be unique within the list.

Configuration steps:

1. For each vService that will share the same IP:port, the domain(s) that vService will serve are added to the Virtual Hosting list (≥ 1 domain).
2. Each vService is directed to its own targets (Default Backend Services / Conditional Backend Services).
3. For HTTPS, each vService selects its own certificate from the Certificate field; the certificate is presented with SNI.

Example scenario: multiple vServices on a single IP:port

Separate vServices sharing a single 192.168.1.100:443 address, each serving its own domain:

vService / Domain	Target
www.example.com	Web Backend Service
api.example.com	API Backend Service
cdn.example.com	Static content servers
admin.example.com	Management panel server

The incoming request is directed to the vService serving the related domain according to the Host/SNI value.

Certificate management

A separate certificate or a wildcard certificate such as *.example.com can be defined for each vService. Thanks to SNI support, TR7 automatically selects the correct certificate belonging to the domain requested by the client.

Cannot be used together with HTTP/3 (QUIC)

While there is at least one domain in the virtual hosting list, options with the HTTP/3 badge are not offered in the Protocol selector; a previously selected QUIC option is automatically removed when the first domain is added. These two features cannot be used together on the same frontend.

INFO

Frontend (Frontend IP · Port · Protocol)

The IP address, port number and protocol (SSL/TLS) behavior the vService will listen on are defined.

Modern application publishing model

On TR7 ASP, multiple Frontend IP addresses and ports can be defined together within a single vService.

Thanks to this architecture, the need to define separate vServices for HTTP (80) and HTTPS (443) traffic is eliminated. Port-based routing, SSL behavior and redirect operations are managed over a single vService, without the need to write additional rules.

Frontend IP/Port/Protocol Configuration

A new frontend address is added with the (+) icon. Each row creates an independent listening point. The form does not prevent saving a vService whose list is left empty; however, if no IP is selected in an added row, saving is prevented.

Frontend IP

The IP address to be listened on in the vService is selected. The selected Frontend IP represents the endpoint at which the traffic coming from clients is received on TR7. The vService accepts traffic over this IP according to the defined port and protocol and processes it according to its rules; as the final point, the client traffic is forwarded to the Backend Service or Group.

IP Type	Description
Interface IP	An IP assigned to a physical or virtual interface; it appears in the list in the Interface IP (interface) address format.
VIP (Virtual IP)	Used for high availability; it is defined in cluster setups and appears in the list in the VIP (interface) address format. Details are located on the Add IP Address (Cluster) page.

Port

The TCP port number to be listened on is entered; it refers to the service port on which clients will connect to TR7. A single port or a port range can be entered.

Port	Common protocol	Use
80	HTTP	Standard web traffic
443	HTTPS	Encrypted web traffic
8080	HTTP	Alternative/proxy port
8443	HTTPS	Alternative encrypted port

Protocol

Determines the protocol and SSL/TLS behavior of the frontend: it defines whether the client connection will be accepted unencrypted (HTTP) or encrypted (HTTPS) and how the TLS session will be terminated on TR7. In the encrypted options, the TLS session is terminated on TR7 (SSL Termination / Offloading); decryption is done on TR7, and traffic is forwarded to the Backend Services encrypted or unencrypted depending on the configuration.

The options are offered under three groups:

Group	Option	Description
Unencrypted	HTTP	No SSL; traffic is received unencrypted (plain HTTP). For internal networks or scenarios in which SSL is terminated at another layer.
Encrypted (HTTPS)	HTTP/1.1	TLS termination over HTTP/1.1.
	HTTP/1.1 + HTTP/3 badge	In addition to HTTP/1.1, HTTP/3 (QUIC) is also offered on the same address.
	HTTP/2	TLS termination over HTTP/2; protocol negotiation is done with ALPN.
	HTTP/2 + HTTP/3 badge	In addition to HTTP/2, HTTP/3 (QUIC) is also offered on the same address.
Redirect	HTTP → HTTPS	Automatically redirects incoming unencrypted requests to HTTPS (301 redirect).

What is the HTTP/3 badge (QUIC)?

Options with the HTTP/3 badge also offer HTTP/3 (QUIC, UDP-based) on the same address in addition to HTTP/1.1 or HTTP/2 over TCP; if the client supports it, it switches to QUIC, otherwise it stays on the TCP connection. For QUIC to work, the related UDP port must be reachable. Options with the HTTP/3 badge are not offered while there is a domain in the virtual hosting list (details in the warning above).

Certificate requirement

When one of the options in the Encrypted (HTTPS) group (HTTP/1.1, HTTP/2 and their variants with the HTTP/3 badge) is selected, the Certificate field appears; at least one SSL certificate must be selected for TLS termination. The form does not mark this field as required, and saving without a certificate is not prevented.

Typical configuration: 80 → 443 redirect + HTTP/2

For a standard website, two frontend rows are defined within a single vService:

Frontend IP	Port	Protocol
VIP 192.168.1.100	80	HTTP → HTTPS
VIP 192.168.1.100	443	HTTP/2

All requests arriving at port 80 are redirected to 443; on 443, TLS with HTTP/2 is terminated on TR7 (SSL Termination / Offloading).

INFO

Certificate

In frontends with an Encrypted (HTTPS) protocol selected (HTTP/1.1, HTTP/2 or their variants with the HTTP/3 badge), the SSL certificates to be used for TLS termination are selected. Certificates are added with multiple selection: more than one certificate can be defined in the same vService.

• More than one certificate can be selected; each can belong to a different domain (SNI).
• Wildcard certificates (*.example.com) are supported.

The selected certificates are matched automatically according to the domain the client specifies with SNI. In this way, multiple domains can be served, each with its own certificate, on a single HTTPS frontend.

Certificate creation and management are located on the SSL/TLS Certificates page. Security parameters such as the allowed TLS versions and cipher suites are determined with the SSL Security profile (see TLS Security Profiles).

INFO

Conditional Backend Services

Allows incoming traffic to be directed to different Backend Services according to specific conditions; it is known in the industry as Content Switching (content-based routing). Each request is forwarded to the appropriate target according to criteria such as the request's path, headers, cookies or client IP.

Content routing on a single screen: In traditional ADCs / load balancers, content-based routing often requires creating a separate content-switching virtual server for each target and making separate policy/rule bindings to them. On TR7, all conditional routing rules are defined on a single vService screen; there is no need to create additional virtual servers or separate policy objects.

Adding New Conditional backend services

This field does not appear in the form until the first rule is added: when the first rule is created with the + Conditional backend services button in the Default Backend Services table, the field appears in the form; subsequent rules are added with the same button. Each rule consists of two components:

1. Condition: The criterion(s) that determine which requests will match this rule. Multiple criteria can be combined with AND / OR.
2. Backend Services: The target(s) to which the traffic will be directed when the condition is met. Multiple Backend Services and/or Backend Groups can be selected together.

Conditional Routing Order

Evaluation order

Conditional routings are evaluated in order from top to bottom: the first matching condition is applied and the evaluation stops. The order is changed by drag and drop. If no rule matches, the traffic falls to Default Backend Services.

Multiple conditions: AND / OR logic

Configuration Example

A condition block can evaluate multiple criteria together, such as the content of the HTTP request, client network information and header values. The criteria are turned into multi-level decision trees with the AND and OR operators.

• AND: All conditions in the block must be met at the same time. Example: if the path starts with /api and the client IP is in the 10.10.10.0/24 block. It is used in narrowed scenarios such as separating API calls coming from the internal network or defining services specific to trusted subnets.
• OR: If any of the connected conditions is met, the block matches. Example: if the HTTP Host header is internalapi.example.com. It is used to gather different access paths under a single target.

As in the example: if the first AND block or the second block is met, the client is directed to the related Backend Service; if neither is met, it is directed to Default Backend Services.

Common use cases:

Scenario	Condition	Target
API routing	Path starts with /api/*	API servers
Mobile traffic	User-Agent contains Mobile	Mobile-optimized servers
Admin panel	Path starts with /admin/*	Management servers
Static content	Path ends with .css, .js, .png	CDN/Static servers
Beta users	Cookie contains beta=true	Beta servers
Geographic routing	Source IP is in a specific country	Regional servers

All condition types are described on the Conditions page.

INFO

Default Backend Services

It is the primary target of the vService: when Conditional backend services is not used, all traffic is directed here, and when conditional routing is used, the traffic that matches no rule is directed here. In this way, a safe and controlled Fallback (default) target is provided for requests that fall outside the defined conditions. It exists in every vService type (HTTP / L7 TCP / Network).

Existing targets are selected from the drop-down list; multiple Backend Services and/or Backend Groups can be selected together. When more than one target is selected, the traffic is distributed among them according to the vService's LB Algorithm and Session Persistence settings.

Backend Service Selection

With the Backend service and Backend group buttons in the selector, a new Backend Service or Backend Group can be defined without leaving this screen. While the list is empty, the text Add backend services appears; if the same Backend Service is added to the list twice, the form prevents saving with the Duplicated backend services error.

Without a default Backend Service

If Default backend services is left empty and no conditional routing matches, a 503 Service Unavailable response is returned to the client with TR7's own error page.

INFO

Save

The vService adding operation is completed by clicking the Save button. While there is an invalid field in the form, the button is disabled; no separate confirmation window opens for saving. After saving:

• The vService is added to the vServices list.
• If Status is Enabled, the vService becomes active immediately and starts receiving traffic.
• The vService status becomes visible on the monitoring screens.

Details

Advanced configuration options are accessed by activating the Details button. These settings control security (WAF, L7 DDoS, AGS), performance (cache, compression), traffic manipulation, logging, resource management (QOS, bandwidth) and timeout behavior.

HTTP vService "Details" Form

Permission

The WAF and QOS boxes in Details and the Certificate selector in the main form appear disabled if the user does not have the related module permission.

INFO

Debug

Used to create detailed debug logs under specific conditions or for all requests. For each request, the request/response headers, timing information and processing details are recorded.

With the Select conditions field, it is determined for which requests the debug logs will be active:

• If left empty: Debug is active for all requests.
• If a condition is selected: Only the requests that match the condition are logged (e.g. requests coming from a specific IP address/block).

This box is the same switch as the Debug mode option in the Status field: when the box is checked, Status becomes Debug mode, and when Debug mode is selected in Status, the box is checked. The additional capability of Debug in Details is that a condition can optionally be defined to limit debugging to only those requests (targeted / conditional debug). In addition, with the Custom debug log entries list, additional Smart Variable-based fields (Entry name / Entry value) can be added to debug records.

Performance impact

Debug produces a large amount of logs and increases disk I/O and CPU usage. Long-term use in a production environment is not recommended; it should be turned off when troubleshooting is completed. Whenever possible, debug limited by a condition should be preferred instead of all traffic.

INFO

WAF

Used to enable the Web Application Firewall (WAF) module.

WAF is described on the WAF - WAAP page.

INFO

L7 DDoS & Threat Protection

Used to enable the L7 DDoS & Threat Protection feature.

The management of this protection layer is located on the Bot/DDoS Protection page.

INFO

AGS

Used to enable the AGS - AAM (Application Access Management) module.

AGS is described on the AGS - AAM page.

INFO

Trusted Proxy

When there is another proxy or CDN in front of TR7 (e.g. an upstream load balancer or a content delivery network), the connection comes not directly from the client but from this intermediate layer; therefore, the client IP appears as the address of the intermediate layer. Trusted Proxy resolves the real client IP address by evaluating X-Forwarded-For-like headers forwarded by trusted intermediate layers.

In this way, logging, geographic restriction, rate limiting and security checks work according to the real client address. Trusted proxy definitions are kept in a profile and attached to the vService from here.

The management of the Trusted Proxies profile is located on the Trusted Proxies page.

INFO

Cache

Enables the caching of HTTP responses; subsequent requests for the same content are served directly from the cache. In this way, the back-end (Backend Service) load decreases and response times improve.

When a request arrives, TR7 first checks the cache: if there is a match (cache: HIT), the response is served directly from the cache and the Backend Service is not contacted; if there is no match (cache: MISS), the request is forwarded to the Backend Service, and the returned response is cached if it complies with the rules.

Default behavior when the profile is enabled:

Parameter	Default
Cached (HIT) Header Name	TRCACHE
Max. object size (MB)	Empty (0–2048 MB; if left empty, the object size limit stays at the engine default)
Total cache size	Automatic; determined according to the vService's QOS memory limit
Cache Timeout	1 hour (min. 10 s)
Caching Rules	By static file extensions
Dynamic Caching	Disabled

Settings such as conditional caching rules, ignoring Host / Query / headers in the cache key and dynamic caching are configured in the profile.

Cache profile management is located on the Cache page.

INFO

Compression

Enables HTTP responses to be sent to the client compressed; it significantly reduces bandwidth usage for text-based content and improves page load time.

TR7 checks the client's Accept-Encoding header: if the client supports GZIP or DEFLATE, the response is compressed with the related algorithm; otherwise, it is sent uncompressed. Only the MIME types defined in the profile are compressed; already compressed content such as image/png is not affected.

Default behavior when the profile is enabled:

Parameter	Default
Compression Algorithm	GZIP (alternative: DEFLATE)
Compression Level	1; fastest, minimum CPU (range 1–9)
Offloading	Disabled
File Types	text/plain

Compression profile management is located on the Compression page.

INFO

Actions

Actions are reusable traffic manipulation components (GUI-based, no-code) that operate on TR7 traffic. They define "what to do when a condition is met" and come into play in the life cycle of the request/response.

Defined first, then selected in the vService: An action is defined centrally, once on the Actions screen; for it to be applied to live traffic, the related vService must select that action from its Details › Actions field. The same action can be attached to multiple vServices.

• Execution timing: On the request (On Request) or on the response (On Response).
• With conditions: It works unconditionally (all traffic) or limited by Conditions.
• Order: Multiple actions in a vService are processed from top to bottom according to the order of addition; an action that blocks/redirects overrides the subsequent ones.

Examples: HTTP header add/delete/modify · URL rewrite · redirect · security headers (HSTS, CSP, X-Frame-Options) · cookie manipulation · rate limiting.

Action management and all action types are described on the Actions page.

INFO

X-Forwarded-For

Since TR7 works as a Reverse Proxy (Load Balancer), the Backend Services see TR7's IP address instead of the client's IP by default. When this option (on/off; off by default) is enabled, TR7 forwards the real client IP to the Backend Service with the X-Forwarded-For HTTP header.

Header	Content
X-Forwarded-For	Original Client IP Address

This information is critical for logging, geographic restrictions, rate limiting, security checks and application-level decision mechanisms.

X-Forwarded-For ↔ Trusted proxy: These two fields concern opposite directions: X-Forwarded-For adds the real client IP in the direction from TR7 to the Backend Service; Trusted Proxy, on the other hand, resolves the real client IP by reading the X-Forwarded-For header coming from a proxy/CDN in front of TR7.

Application-side behavior

For the X-Forwarded-For header to be effective, the Backend Service or the application layer must be configured to read this header and use it as the client IP. Otherwise, the real client IP information may not be taken into account by the application.

INFO

LOG

Used to enable the sending of vService Access logs to Syslog-SIEM servers. With the Log profile, which information will be sent, in which format and where is defined.

Supported formats for HTTP vServices:

Nine line formats are listed in the selector:

Format	Description
Standard Log Format (HTTP)	Basic format compatible with Apache CLF
Apache Combined	Standard + Referrer + User Agent
Apache VHost	VHost + Standard + Referrer + User Agent
CEF Format (HTTP)	Common Event Format; SIEM integration
TR7 JSON Format (HTTP)	Detailed JSON format; all fields
TR7 WAF log	WAF event information only
Manual Formats (HTTP)	Customizable JSON line format
Manual Formats (HTTP)	Customizable CEF line format
Manual Formats (HTTP)	Freely defined log line

Log profile management is located on the Logs page.

INFO

SSL Security

Determines the security policy of the SSL/TLS traffic on the vService: the allowed TLS version range, encryption algorithms (ciphers) and elliptic curve (ECDHE) parameters are defined with this profile. The certificate itself is selected in the Certificate field; this profile manages how that TLS session is established.

Default behavior when the profile is enabled:

Parameter	Default
Min. SSL Version	TLSv1.1
Max. SSL Version	- (unlimited)
Cipher algorithms	Only secure (HIGH:!aNULL:!MD5)
Curve / ECDHE	System recommendation (automatic)

Advanced settings such as the SNI / Host consistency check, mTLS (client certificate verification), OCSP stapling, HSTS, post-quantum key exchange and SSL hardware acceleration are also configured in the profile.

SSL security profile management is located on the TLS Security Profiles page.

INFO

Notification

Monitors the status, performance and certificate metrics of the vService and automatically sends notifications to administrators when thresholds are exceeded or the status changes.

Monitored metrics and default thresholds:

Metric	Default
Backend Service / vService status (UP/DOWN)	On status change
Bandwidth	128 Mbps
Number of new connections	1000 conn/s
Request rate	2500 req/s
Current session	1000
Certificate expiry	30 days before expiry

Channels (off by default): SNMP notification · E-mail · SMS · UI notification (in-interface notification). With the Silent at night option, notifications are muted during night hours; per-source-IP thresholds (connections/s, requests/s, errors/s, incoming/outgoing traffic) can also be defined in the profile.

Notification profile management is located on the Notifications page.

INFO

Report

Turns vService traffic into detailed reports: the report is viewed on the screen as HTML and exported as PDF and Excel (XLSX). Traffic is analyzed in 31 different sections as standard; reports can be sent automatically by e-mail at specific periods (daily / weekly / monthly / annual) as PDF or XLSX attachments.

Custom (manual) report fields

In addition to the standard sections, custom report tables can be created with Smart Variable support. In this way, HTTP headers, cookie values or other request/response information (e.g. X-Forwarded-For, X-Request-ID) can be added to the report and categorized according to custom business rules: that is, any desired information outside the default sections can be reported.

Report profile management is located on the Reports page.

INFO

QOS

Used to enable the Quality of Service settings. It provides resource isolation and prioritization for the vService.

QOS makes it possible to limit or guarantee the CPU cores, memory (RAM) and processing resources to be allocated to the vService. In this way, each vService runs in isolation within the defined resources (a separate QOS setting is required for each vService) and maintains its performance independently of the other services. Thanks to prioritization, critical vServices can run with higher processing priority even under system load.

Inline Mode

On/off (off by default). When enabled, automatic inline DNAT rules that map the vService's Backend Services to the frontend addresses are generated at the firewall layer. It is used in setups where TR7 is positioned directly in the traffic path (inline).

Route Table

The route table the vService will use is selected. By default, the system's default route table is used; if separate route tables are defined for different network segments, the appropriate one can be selected. This field appears only when more than one route table is defined.

Memory Limit

The upper limit of the memory (RAM) to be allocated to the vService. Options: 1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 128, 256 GB. The default is 2 GB.

Cores

The processor cores on which the vService will run are selected. One or more cores, each different, can be assigned only from among the available cores (not reserved for the system) on the device. The selector is opened with the Automatic / Manual switch; with Automatic, the assignment is made by itself, and with Manual, at least one core must be checked (At least one core must be selected). When Manual is selected, the CPU Priority and Cpu Usage Limit (%) fields below become visible.

CPU Priority

The processing priority of the vService: Low · Normal · High. The default is Normal. High priority gives critical vServices a processor advantage under system load.

Cpu Usage Limit (%)

The upper limit of the CPU percentage the vService can use (1–100; a decimal value can be entered). It has no default value; if not specified, no percentage limit is applied.

Core Engine

The version of the load balancing core on which the vService will run is selected. Supported capabilities may vary by version; by default, the version recommended by the system is used.

INFO

Bandwidth

Used to limit the bandwidth that the vService sends to the client (in the download direction) (on/off; off by default). When enabled, a single Total limit value is entered; the unit selector next to it offers Kbps (default), Mbps and Gbps, and the upper limit is 32 Gbps. The limit is applied to the vService's total traffic flowing from the Backend Service to the client; there is no separate limit for the incoming direction.

In this way, a vService is prevented from negatively affecting the performance of other services with excessive traffic. It is used especially to ensure fair resource usage in shared environments, to guarantee capacity for critical services and to limit the impact of sudden traffic increases.

In cases where the bandwidth needs to be limited for individual requests (per-request), the Bandwidth Limitation action can be used.

INFO

vService Limits

Keeps connection and session traffic under control with upper limits; it protects the vService and the system against overload and connection overflows. Even if no vService Limit profile is selected, it works with the default values below (when a profile is selected, these values are replaced with those in the profile):

Limit	Default	Description
Max. total connections	20,000	Total concurrent connections
Max. failed connection retries	3	Backend Service connection error retries
Max. new connecions/s	5,000	New connections per second
Max. connections/s	10,000	Total connections per second
Max. session rate/s	10,000	Sessions per second
Max. total SSL connections	5,000	Concurrent SSL connections
Max. SSL connections/s	2,000	SSL connections per second
Buffer size(kB)	128	Request/response buffer size

vService limit profile management is located on the vService Limits page.

INFO

Timeout

Used to control the connection and session timeout behaviors between the client and TR7 and between TR7 and the Backend Services. If no profile is selected, the following defaults apply:

Timeout	Default	Description
HTTP keepalive timeout	120 s	The time the client HTTP connection is kept open without data flow
HTTP request timeout	30 s	The time allowed for an HTTP request to be received completely from the client
Connect timeout	20 s	The time to establish a TCP connection with the Backend Service
Server timeout	90 s	The time to wait before data is received from the Backend Service
Client timeout	90 s	The time the connection is kept open before data comes from the client
Queue timeout	60 s	The time a request can wait in the Backend Service queue
Tunnel(Websocket) timeout	120 s	The idle wait time in long-lived connections such as WebSocket
Client FIN	3 s	The closing time after the client terminates the connection
Server FIN	6 s	The closing time after the Backend Service terminates the connection

Timeout profile management is located on the Timeouts page.

INFO

LB Algorithm

The load balancing algorithm is the method that determines according to which rule the incoming client traffic is distributed among multiple Backend Services. The goal is to increase performance, prevent a single server from being overloaded and provide high availability.

TIP

In scenarios with a single Backend Service behind the vService, the LB Algorithm and Persistence selection does not matter.

Algorithms

The 13 load balancing algorithms supported specifically for HTTP vServices are given in the table below; the default is Round robin. The Self-Persistent column shows whether the algorithm provides session persistence by itself.

Algorithm	Self-Persistent	Description	Recommended Scenario
Round robin	✗	Distributes incoming requests to the servers in turn and equally. Each new request goes to the next server, and when the end of the list is reached, it returns to the beginning. It does not take server capacities into account.	Homogeneous environments where all servers have the same hardware. Stateless applications and short-lived HTTP requests.
Weighted Round Robin	✗	Adds a weight factor to Round Robin. Servers with a higher weight receive proportionally more requests (e.g. at a 3:1 ratio, the powerful server receives 3 out of every 4 requests).	Heterogeneous Backend Services with different CPU/RAM/processing power; environments where new and old generation servers run together.
Least Connection	✗	Tracks the current number of active connections and directs each new request to the server with the fewest connections. It provides dynamic workload balancing.	Long-lived connections such as WebSocket, database connections and file transfers; scenarios with variable request durations.
Least Response Time	✗	Scores the servers according to the measured time and directs to the server with the lowest value. The Time metric field determines which time is taken as the basis: Total time (queue + connection + response; default) or Response time (response time only).	Backend Services whose response time varies from server to server; scenarios where back-end speed is decisive.
Least Bandwidth	✗	Averages the measured bandwidth usage of the servers over the Bandwidth window duration and directs to the server using the least bandwidth.	Streaming and large file scenarios where bandwidth is the bottleneck.
First	✗	Evaluates the servers in the defined order; it directs all traffic to the first server until it reaches its maximum connection limit, and moves to the next one when the limit is exceeded.	Active-passive (failover) architectures; cases where minimum server usage is required to minimize license costs.
Random	✗	Selects a random server among the Backend Services for each request. If a weight is defined, the selection probability is proportional to the weight. Simple and low-overhead.	Systems that process many short-lived and independent requests; stateless microservices; test/development environments.
Fastest	✗	Continuously measures the response times of the servers and directs to the server with the lowest latency.	Real-time applications where low latency is critical: API gateways, financial transaction systems, game servers.
Fastest+	✗	Extends Fastest; in addition to response time, it evaluates a second metric such as the number of active connections or server load. Two-dimensional optimization.	High-traffic production environments where both speed and capacity balance are important; e-commerce and media streaming.
Source	✓	Generates a hash from the client source IP address and consistently selects the same server according to this hash. Requests coming from the same IP always go to the same server.	Systems that have no application-level session management but require user consistency; simple session persistence.
URI	✓	Calculates a hash from the URI path in the HTTP request. Requests made to the same URI consistently go to the same server. It maximizes cache locality.	CDN and caching layers; static content distribution; cache-tiering architectures; disk I/O optimization.
URL Param	✓	Generates a hash from the value of the specified URL query parameter (e.g. ?user_id=123); requests with the same parameter value consistently go to the same server. If the parameter is absent, routing is distributed to the other servers.	User/session-based routing; tenant_id isolation in multi-tenant applications; user-specific state.
HDR	✓	Calculates a hash from the value of the specified HTTP header (e.g. X-User-ID, Authorization, X-Tenant-ID). If the header is absent, a fallback is applied.	Token/API key-based routing in API gateways; correlation-id tracking; customer segmentation in B2B platforms.

Algorithm-specific additional fields

Additional fields appear in the LB Algorithm box according to the selected algorithm:

Algorithm	Additional field	Description
URI	URI character length (required) · URI depth	The URL length to be included in the hash (1–10,000) and the depth calculated by the number of / characters (1–100).
URL Param	URL parameter to use (required) · Check post parameters	The word to be searched for in the URL parameters; if checked, POST parameters are also scanned (off by default).
HDR	HDR name (required)	The name of the HTTP header to be used as the basis for the hash.
Fastest	Fastest Opt-1	Selected from the metric list below.
Fastest+	Fastest Opt-1 · Fastest Opt-2	The two metrics must be different.
Least Response Time	Time metric	Total time (default) / Response time.
Least Bandwidth	Bandwidth window	The window over which the measured bandwidth is averaged; the default is 10 s, the range is 1 s – 1 h.
Source · URI · URL Param · HDR	Hash consistency	Prevents hash-based persistence from overloading the Backend Services (off by default).

Fastest Metrics

The Fastest algorithm selects the server that performs best according to the specified metric. The routing criterion is determined by selecting one of the following metrics:

Metric	Description
Least Response Time	Measures HTTP response times and directs to the server with the lowest average response time. It covers the time from the first byte until the response is completed. It is the metric that most directly reflects application layer performance.
Least Connection Time	Measures the TCP connection establishment time (three-way handshake). It prefers the server with which the connection is established the fastest. It reflects network latency and the server's network stack performance.
Least Queue Time	Measures the time requests wait in the queue before being forwarded to the back end. It directs to the server with the shortest queue waiting time.
Least Connections	Tracks the current number of active TCP connections and selects the server with the fewest connections. It is effective in scenarios that include long-lived connections.
Least Queues	Monitors the depth of the pending request queue per server. It directs to the server with the least queue depth.
Least Connection Error	Counts the connection errors (connection refused, timeout, reset) that occur within a specific time window. It prefers the server with the lowest error rate.
Least aborted connections	Monitors the number of connections terminated early (aborted) by the server. It is useful for detecting slow or unresponsive servers.
Least used connections	Evaluates the number of connections currently used by the server and prefers the least used server.

Fastest+ Metrics

The Fastest+ algorithm provides multi-dimensional optimization by evaluating two different metrics together. The first metric (Opt-1) is used as the primary criterion, and the second metric (Opt-2) as the secondary criterion in case of a tie or in weighted calculation.

Operating logic:

1. The values of both metrics are collected for all servers.
2. The servers are sorted according to the primary metric (Opt-1).
3. For equal or close values, the secondary metric (Opt-2) comes into play.
4. The server that best meets both criteria is selected.

All Fastest metrics can be used for Opt-1 (Fastest Opt-1) and Opt-2 (Fastest Opt-2) (Least Response Time, Least Connection Time, Least Queue Time, Least Connections, Least Queues, Least Connection Error, Least aborted connections, Least used connections); the two metrics must be different. By default, Opt-1 comes with the Least Response Time value and Opt-2 with the Least Connection Time value.

Example Opt-1 / Opt-2 combinations:

Combination	Use Case
Least Response Time + Least Connections	Selects the server that responds the fastest; in a tie, prefers the least loaded one. Ideal for general-purpose web applications.
Least Connections + Least Connection Error	Prioritizes load balance; in a tie, selects the most reliable server. Suitable for systems that require high availability.
Least Response Time + Least Queue Time	Makes a performance-oriented selection; avoids servers with queue buildup. Effective for momentary traffic fluctuations.
Least Connection Error + Least Response Time	Evaluates reliability first, then performance. Provides stability in environments with unstable back ends.

Session Persistence

Persistence is the mechanism that ensures that successive requests from a client are directed to the same Backend Service. It is also called Session Affinity or Sticky Sessions.

Under normal conditions, TR7 evaluates each request independently and can direct it to any back end according to its algorithm. However, some applications require communicating with the same server throughout the user session.

Persistence Type	Description
None	Persistence is disabled. Each request is evaluated independently according to the selected algorithm. Suitable for stateless applications or architectures that keep session data in a central store (Redis, database).
New cookie	On the first request, TR7 adds a special persistence cookie to the response. In subsequent requests, this cookie is read and the client is directed to the same server. The cookie name and timeout duration can be configured. It works independently of application cookies.
Current cookie	Uses the value of an existing cookie already created by the application (e.g. JSESSIONID, PHPSESSID, ASP.NET_SessionId). TR7 does not add a new cookie; it makes the routing decision by reading the existing one.
Hash	Provides session persistence by calculating a hash from a specified key (source IP, header, URL parameter, etc.; defined with Smart Variables). The key → Backend Service mapping is kept in a device-local table on TR7; unlike SAM, it is not shared among cluster devices. It can be used in the HTTP and L7 TCP types.
Session Affinity Manager (SAM)	Provides cookie-based, stateful session persistence; it distributes sessions evenly among servers and can rebalance them when servers are added/removed. Details are located in the Session Affinity Manager (SAM) section.

Comparison of persistence types:

Feature	None	New cookie	Current cookie	Hash
State keeping (TR7)	-	No	No	Yes
Cookie requirement	-	TR7 creates it	The application creates it	Not required
Application intervention	-	Not required	Must produce a cookie	Not required
Scalability	High	High	High	Medium
Failover behavior	-	A new server is assigned	A new server is assigned	A new server is assigned if the server is unreachable
HTTPS support	✓	✓	✓	✓
Non-HTTP protocols	✓	✗	✗	✓

New cookie configuration parameters:

Parameter	Description
Cookie Name	The name of the persistence cookie to be created by TR7. The default is TR-C. A unique name that does not conflict with existing application cookies should be selected.
Cookie max-idle	The maximum time the cookie stays valid without a request; if no new request arrives during this time, the persistence record becomes invalid. The default is 30 minutes (range 60 s – 7 days).
Cookie max-life	The total lifetime of the cookie; regardless of activity, the cookie becomes invalid when this time expires. The default is 8 hours (range 10 min – 30 days).

Max-Idle: It is reset with every request; the session continues as long as the user is active. Max-Life: It is an absolute expiration date and is not reset. With the default values (max-idle 30 min, max-life 8 hours), persistence ends if the user stays inactive for 30 minutes or a total of 8 hours passes.

Current cookie: common framework cookie names:

Framework / Platform	Default Cookie Name
Java (Tomcat, Jetty, WildFly)	JSESSIONID
PHP	PHPSESSID
ASP.NET	ASP.NET_SessionId
ASP.NET Core	.AspNetCore.Session
Python (Django)	sessionid
Python (Flask)	session
Ruby on Rails	_session_id
Node.js (Express)	connect.sid
Laravel	laravel_session

If the specified cookie is not found in the request, persistence is not applied and the request is directed according to the load balancing algorithm.

Hash configuration parameters:

Parameter	Description
Hash key	The Smart Variable list that forms the persistence key (at least 1; duplicate entries are not accepted).
Hash key list size (required)	The capacity of the key → Backend Service table. The default is 3,000,000; the range is 10,000 – 100,000,000.
Hash key expire time	The time a record in the table is kept without a request. The default is 7 days; the range is 10 min – 365 days.

Scenario-based persistence recommendations:

Scenario	Recommended Persistence	Rationale
Stateless microservices	None	Session data is kept in a central store; persistence is unnecessary.
Legacy web applications	Current cookie	The existing session management is preserved; no application change is required.
New web applications	New cookie	It is application-independent and offers flexible configuration.
API Gateway / REST services	Hash (header-based key)	Provides consistent routing with a Smart Variable key derived from the token or API key header.
CDN / Cache layer	Hash (URL-based key)	The cache hit rate is increased by serving the same content from the same server.

Session Affinity Manager (SAM)

Session Affinity Manager (SAM) is a cookie-based and stateful session persistence method. Unlike the other persistence types, it keeps the mapping between the session ID and the Backend Service in a separate session mapping table; this table also holds per-session request and connection counters. In this way, sessions can be monitored, cleared and rebalanced among servers at runtime. SAM provides advanced session management, custom session ID formats and runtime session control.

SAM can be used only in HTTP-type vServices and with load balancing algorithms that are not self-persistent.

What Is SAM?

In the classic cookie-based methods (New cookie / Current cookie), the server identity is embedded directly in the cookie; in the Hash method, routing is based on a hash value calculated from an attribute of the request (source IP, header, URL parameter). In none of these methods is session state kept on the TR7 side.

SAM, on the other hand, generates a session ID for each session (or reads it from an existing cookie) and records this ID in the session mapping table together with the Backend Service it is assigned to. Thanks to this stateful structure, sessions can be listed, deleted and rebalanced one by one: a capability that does not exist in cookie-based stateless methods.

How Does It Work?

The source of the session ID is determined with the Cookie Source field:

• TR7 Generates: On the first request (if there is no cookie), a session ID is generated according to the selected Session ID Format, encoded securely and added to the response as a cookie. In subsequent requests, this cookie is read and decoded, and the request is directed through the session mapping table to the Backend Service to which the session is pinned.
• Current Cookie: The session ID is read from an existing cookie value produced by the application (Backend Service); TR7 does not produce a new cookie.

On the first request, the target Backend Service is determined according to the selected load balancing algorithm; in subsequent requests, the session is pinned to the same Backend Service through the mapping table. Requests that do not carry the session ID (for example, clients that do not send cookies) are not recorded in the mapping table and are distributed directly according to the load balancing algorithm.

Rebalance

SAM sessions can be rebalanced at runtime. Rebalancing is performed by deleting the selected sessions from the mapping table; the affected clients are reassigned to a Backend Service according to the load balancing algorithm on their next request. This operation is used to move sessions to other servers in a controlled way before a Backend Service is put into maintenance.

During rebalancing, which sessions will be moved is determined with a selector:

Selector	Behavior
First (Sequential)	The matching sessions are selected in order from the beginning.
Random	A random selection is made from the matching sessions.
Oldest (By expiry)	The sessions closest to expiring (the oldest) are selected.
Newest (By expiry)	The sessions furthest from expiring (the newest) are selected.
Least Connections	The sessions with the fewest connections are selected.

The Percent value determines what percentage of the matching sessions (1–100; default 100) will be rebalanced. The Selection field appears only when a value below 100 is entered; at 100%, all matching sessions are moved. The operation is started with a confirmation window (Rebalance Sessions?) that shows how many sessions will be cleared. In addition to rebalancing, sessions can be cleared for a single Backend Service (Clear) or for all tables (Clear All).

Adding or removing a server or a change in health status does not automatically redistribute the existing pinned sessions; pinning is preserved until the Max Idle time expires or the sessions are cleared/rebalanced.

Configuration Parameters

INFO

Cookie Source

Determines the source of the session ID. The default is TR7 Generates.

• TR7 Generates: The session ID is generated by TR7 and placed as a cookie.
• Current Cookie: The session ID is read from an existing cookie produced by the application.

The Session ID Format field and the reflection of the security flags on the cookie are valid only in the TR7 Generates mode.

INFO

Cookie Name Required

The name of the cookie to be used for session persistence. The field opens empty and must be filled in; TR7SID is shown as a gray placeholder. A unique name that does not conflict with existing application cookies should be selected.

INFO

Session ID Format Default: UUID

Determines the format of the session ID to be generated. It appears only when Cookie source = TR7 Generates is selected. The default selection in the form is UUID (the first option in the list); in old records saved with this field empty, the engine uses the IP-Timestamp-Random format.

Format	Content
UUID (default)	A standard UUID value is generated.
IP-Timestamp-Random	Consists of the combination of the source IP, a timestamp and a random value.
IP-Random	Consists of the combination of the source IP and a random value.
Custom Format	The session ID is created from the defined custom format keys (Custom format format keys).

When the Custom Format format is selected, the fields that form the session ID are defined with the Custom format format keys list (as written in the interface) (at least one key); each key can be a Smart Variable expression. Details are located on the Smart Variables (fx) page.

INFO

Max Life

The absolute lifetime of the session cookie (value + unit). The default is 24 hours. This duration determines the longest time the cookie will stay valid regardless of session activity; when it expires, the cookie becomes invalid.

INFO

Max Idle

The idle timeout of the session (value + unit). The default is 30 minutes. It determines the validity period of the record in the session mapping table; if no new request arrives during this time, the session record drops. It works independently of the Max Life value.

INFO

Security Flags

The security flags to be added to the generated session cookie (multiple selection). In the form, HttpOnly and Secure (HTTPS only) come checked by default. They are reflected on the cookie only in the TR7 Generates mode.

Flag	Description
HttpOnly (default)	Prevents access to the cookie from client scripts (JavaScript).
Secure (HTTPS only) (default)	Ensures that the cookie is sent only over HTTPS connections.
SameSite=Strict	Ensures that the cookie is sent only in requests made to the same site.
SameSite=Lax	Ensures that the cookie is sent in a limited way in cross-site navigations.

When SameSite=Strict and SameSite=Lax are selected together, Strict takes precedence.

Compatibility and Limitations

WARNING

• SAM can be used only in HTTP-type vServices; it does not exist in the L7 TCP and Network types.
• It works only with algorithms that are not self-persistent: Round robin, Weighted Round Robin, Least Connection, Least Response Time, Least Bandwidth, First, Random, Fastest, Fastest+. When a self-persistent algorithm (Source, URI, URL Param, HDR) is selected, the entire Persistence field is hidden.
• There must be at least two Backend Services in the related Backend Service group.
• The session mapping table has a fixed capacity of 1,000,000 records; it cannot be changed by the user.
• When Session ID Format is changed, the existing session mapping table is reset; active sessions are reassigned.

Use Cases

Scenario	Rationale
Applications in which sessions need to be monitored and managed at runtime	The session mapping table can be listed, cleared and rebalanced.
Controlled session migration before maintenance	With rebalancing, the sessions on a Backend Service can be moved gradually to the others.
Applications that require full control over the cookie format and security flags	The session ID format and the HttpOnly / Secure / SameSite flags can be configured in detail.
Environments where the application produces its own session cookie	With Cookie source = Current Cookie, the existing cookie is used as the session ID.

Related

• vService: common fields and general operating logic
• L7 TCP vService · Network vService: the other types
• Backend Services · Backend Groups: routing targets
• Conditions · Actions: content switching and traffic manipulation
• Profiles: cache, compression, log, report, timeout, vService limits
• SSL/TLS Certificates · TLS Security Profiles