When a timeout is set incorrectly, the failure is not always obvious. If a serverTimeout is fixed at 30 seconds, long-polling requests return 504. If connectTimeout is too long, clients waiting to reach a down backend stall for seconds before retrying — triggering retry cascades. If tunnelTimeout is too short, WebSocket connections drop without cause and users experience ghost disconnects.
Most systems present timeout settings as a flat list. Operators cannot clearly tell which value controls the HTTP request phase, which governs backend response time, which applies to WebSocket tunnels and which affects FIN wait. The result is either all values set too high — creating connection leaks — or all set too low, cutting legitimate user traffic.
WebSocket and long-lived connections are where this problem is most visible. HTTP keepalive is meaningful in the 30–120 second range, but a WebSocket session may remain open for hours. Without a separately managed tunnelTimeout, real-time applications are constrained by ordinary HTTP idle behavior.
TCP teardown behavior also matters. When clientFIN and serverFIN are not controlled, half-closed connections can exhaust the file descriptor pool. On public-facing services this compounds with slow-close attack patterns and turns into a resource exhaustion problem.
TR7 Timeout Profiles collect 9 independent timeout axes in a single named profile, ensuring every pool applies the correct wait, drain and connection-close behavior for its traffic type.
TR7 manages timeouts through reusable named profiles rather than scattering individual settings across pools.
An operator defines a profile name and groups 9 timeout values inside it. The same profile can be bound to multiple pools, giving web, API or WebSocket pools a consistent shared timeout standard.
HTTP request, keepalive, connect, server, client, queue, tunnel, clientFIN and serverFIN are each managed as a distinct field. Every field is tuned according to its own traffic semantics; no timeout value is used as a substitute for another.
Long-lived connections such as WebSocket and HTTP CONNECT are managed through tunnelTimeout separately. Chat, live-streaming and event-stream connections do not get constrained by the HTTP idle timer and will not close unnecessarily.
How long a connection is held after a TCP close signal is configured independently for client and server sides. This reduces FIN-WAIT-style resource consumption risk and enables more aggressive drain policies on public-facing services.
Timeout Profiles let operators tune connection lifetime and wait behavior precisely across 9 independent fields to match every traffic type.
httpKeepaliveTimeout defines how long an HTTP/1.1 keep-alive connection remains open between requests. The default is 120 seconds. Setting it too high wastes resources on idle connections; too low increases reconnection cost. It is tuned against the backend's idle connection budget.
httpRequestTimeout is the time allowed for the client to complete the request line and headers. The default is 30 seconds. Clients that send headers very slowly can be cut off at this threshold. It is an important defense point against slowloris-style patterns on public-facing services.
connectTimeout defines how long TR7 waits when establishing a TCP connection to a backend. The default is 20 seconds. If set too long, a down or unreachable backend stalls clients unnecessarily. API scenarios that require fast failure responses benefit from a lower connectTimeout.
serverTimeout is the time allowed for the backend to produce a response. The default is 90 seconds. It can be set low for fast APIs and raised for heavy reporting, long-polling or slow-query endpoints. An incorrectly low value causes working but slow requests to receive 504.
clientTimeout is the wait time for data to arrive from the client. It applies to request body upload, pipelined requests and slow-client scenarios. The default is 90 seconds. It can be raised for large file uploads and lowered to reduce slow-client risk on public APIs.
queueTimeout defines how long a request waits in the pool queue when connection capacity is full. The default is 60 seconds. When exceeded, the request is returned with an error and the client is not held indefinitely. This value should be considered alongside maxconn limits and application SLAs.
tunnelTimeout defines the idle time for WebSocket and HTTP CONNECT tunnel connections. The default is 120 seconds; for real-time applications this can be raised to 3600 seconds or more. Because this timeout is independent of HTTP keepalive, long-lived connections are not constrained by web traffic settings. It is critical for chat, live notification and stream applications.
clientFIN sets how long the connection is kept after a FIN signal from the client. The default is 3 seconds. Lower values prevent half-closed connections from consuming file descriptors. This is especially important on public-facing services to reduce FIN-WAIT resource pressure.
serverFIN limits connection behavior after a FIN signal from the backend. The default is 6 seconds. Keeping serverFIN higher than clientFIN allows more tolerance for graceful drain during backend shutdown. This setting directly affects connection close quality in high-traffic backend pools.
The profile-pool binding model allows the same timeout standard to be shared across multiple pools. All web pools can point to the web profile, API pools to the api profile and WebSocket pools to the websocket profile. A single profile change centrally updates the timeout behavior of every pool bound to it, reducing configuration duplication and drift.
The 9 profile fields are converted to the corresponding runtime timeout directives — connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin and server-fin. Operators manage values through the profile rather than writing individual directives, creating a consistent bridge between the GUI and runtime behavior.
Health check timing is managed through its own timeout field and is independent of the traffic timeout profile. This separation matters: probe latency and production traffic wait behavior do not mix. A backend health check can be kept short while the actual endpoint serverTimeout remains long, allowing service health and user traffic to be monitored with different semantics.
Timeout profiles are operated together with their value range, defaults, decimal support, tunnel semantics, FIN balance and pool binding model.
Timeout fields are configurable from 0 to 60,000 seconds. This range spans from sub-second defensive settings to sessions exceeding 16 hours, providing enough flexibility for long-poll and persistent connection requirements.
httpKeepaliveTimeout accepts decimal values. A value such as 0.5 seconds allows more precise idle keepalive behavior. The remaining 8 timeout fields are treated as whole-number seconds.
Default values provide a safe starting point suitable for most web and API traffic. httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 and serverFIN 6 seconds are appropriate baselines. For specialized traffic types, these values should be adjusted per profile.
tunnelTimeout applies to tunneled connections such as WebSocket and HTTP CONNECT. It is not the same as the HTTP request or keepalive timeout. Setting it too low on long-lived connections produces disconnect issues.
In the default model, serverFIN is more tolerant than clientFIN. This leaves more room for graceful drain during backend shutdown. On public-facing services, both values can be set more aggressively to reduce half-closed connection resource consumption.
TR7 does not impose ready-made presets. Operators create their own named profiles according to their scenario — web, api, websocket, longpoll or upload can be defined to match the organization's standards. Binding a pool to the appropriate profile is preferred over per-service individual overrides.
A web profile can be created close to the default values. Keepalive preserves the user experience while request and FIN timeout values limit slow or half-closed connections. The same profile can be bound to multiple web pools.
Chat applications need WebSocket connections to stay open without frequent drops. Inside a websocket profile, tunnelTimeout is set to a long value such as 3600 seconds while other HTTP timeouts remain at their defaults. Long-lived connections are no longer constrained by the HTTP keepalive window.
A long-polling endpoint may wait several minutes for the backend to respond. Setting serverTimeout to 300 seconds in a longpoll profile supports a 5-minute wait window. Without this, a standard API timeout cuts the requests too early.
Data from the client may arrive slowly during large POST body or file upload traffic. In an upload profile, clientTimeout and, if needed, httpRequestTimeout can be raised to 600 seconds. This prevents legitimate but slow upload operations from being cut off.
When a banking API expects a quick backend response, tight values such as connectTimeout 2 seconds and serverTimeout 5 seconds can be used. A slow or down backend does not stall clients for long. Retry and failover behavior is triggered earlier.
A defensive profile can use low values such as httpRequestTimeout 5 seconds and clientFIN/serverFIN 1 second. This structure limits slow-header delivery and half-closed connection consumption patterns. It reduces the attack surface on public-facing services.
9-axis named timeout profiles for your web, API, WebSocket and upload pools. Let us walk through a live setup with your own configuration.