What do the values in the Timeouts profile (HTTP Keepalive Timeout, HTTP Request Timeout, Connect, Server, Client, Queue, Tunnel(Websocket) Timeout, Client FIN, Server FIN) mean?

Short answer

The Timeouts profile defines a time limit for each stage of the connection: the client sending the request, connecting to the Backend Service, the data flow on both sides, waiting in the queue, the WebSocket tunnel and the closing of the connection. The values are in seconds (0–60,000); the defaults are HTTP Keepalive Timeout 120, HTTP Request Timeout 30, Connect Timeout 20, Server Timeout 90, Client Timeout 90, Queue Timeout 60, Tunnel(Websocket) Timeout 120, Client FIN 3 and Server FIN 6 seconds. vServices with no profile assigned work with these defaults; changes are applied without dropping open connections.

How Does It Work?

A request passes through several stages on its way from the client to the Backend Service and back. Each stage has its own time limit; when the time runs out, TR7 terminates the connection or the request at that stage. Server timeout and Client timeout limit not the total duration but the longest silence between two pieces of data: as long as data flows, the connection is not cut.

Field	Default	What it limits	When the time runs out
HTTP Keepalive Timeout	120 s	The time waited after a response for the client to send a new request on the same connection	The idle client connection is closed
HTTP Request Timeout	30 s	The complete receipt of the first line and headers of the request (the body is not included; on a WAF-enabled vService (when Wait for Body for a Time is not checked) or while Debug Mode is on, the body is included too)	The request is rejected
Connect Timeout	20 s	Establishing the connection to the Backend Service	The attempt is considered failed; it is retried up to Max. Failed Connection Retries times
Server Timeout	90 s	The longest silence between two pieces of data on the Backend Service side	If it runs out before the response arrives, 504 to the client
Client Timeout	90 s	The longest silence between two pieces of data on the client side	The client connection is closed
Queue Timeout	60 s	The longest time the request can wait in the Backend Service queue	503 to the client
Tunnel(Websocket) Timeout	120 s	How long a connection that has turned into a tunnel (e.g. WebSocket) stays open while there is no data in either direction; once the tunnel is established, it replaces Client timeout and Server timeout	The tunnel is closed
Client FIN	3 s	Holding the half-closed connection after the client initiates the close	The connection is closed
Server FIN	6 s	Holding the half-closed connection after the Backend Service initiates the close	The connection is closed

The Timeouts Profile in TR7

• Where: The profile is created on the Load Balancer → Profiles → Timeouts screen (How to add) and selected in the Timeout box in the Details panel of the vService (How to add to a vService). The fields in the form come empty; a field left empty uses the default (profile add form).
• vService type: HTTP and L7 TCP. On L7 TCP, HTTP Keepalive Timeout and HTTP Request Timeout are not applied; the Network vService has no Timeout box (scope of the timeout values).
• Default: If the box is unchecked or the profile in use is deleted, the vService works with the defaults above (Delete).
• Value 0: Removes the time limit (scope of the timeout values); it is not recommended because idle connections are not closed.
• Effect of the change: The Timeouts fields do not restart the vService; saving is applied without dropping open connections. If the profile is used in more than one vService, the change is reflected in all of them; first, the Used in tab in the preview of the profile is checked (Used in tab). In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
• Tarpit: Connect timeout also determines the holding time of the Tarpit behavior, which holds the request for a while and then rejects it.
• Monitoring: Which time ran out is seen in the Termination State column on the Debug Mode Logs screen (e.g. Client timeout, Server timeout and its stage); Debug Mode Logs are generated only while the HTTP vService is in Debug mode.
• WEB-CLI: The profile is created with lb timeouts add name rapor-servisi --serverTimeout 300 and bound with lb service update id <vService> --timeout rapor-servisi (WEB-CLI examples).

Common Misconceptions

• "Server timeout is the total duration of the operation." It is the longest silence in the data flow; as long as data flows, the connection is not cut.
• "HTTP request timeout never affects uploads." This time normally covers the headers of the request and the silence during an upload is limited by Client timeout; however, on a WAF-enabled vService (while Wait for Body for a Time is not checked) and while Debug Mode is on, receiving the body is also included in this time, and large or slow uploads can be cut off within it.
• "For WebSocket, Client and Server timeout are increased." After the tunnel is established, the decisive time is Tunnel(Websocket) timeout.
• "Timeouts are also used on the Network vService." The Network vService has no Timeout box.
• "HTTP keepalive timeout applies in every case." If the Close after Every Request mode is selected in the HTTP TCP Multiplexing action, this time has no function.

How it is done in the documentation

• Timeouts · What Is the Timeouts Profile?
• Timeouts · The Scope of the Timeout Values
• Timeouts · Profile Add Form
• Timeouts · Operational Best Practices

Related questions

• Why is the request cut off during long operations (report, file upload); which timeout should I increase?
• My WebSocket connections drop after a certain time; what should I do?
• How does the queue work; how long do requests wait at most?