Misconfigured timeouts produce silent outages, ghost disconnects and unnecessary wait in production.
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.
Our approach
TR7 manages timeouts through reusable named profiles rather than scattering individual settings across pools.
Named profiles are created and bound to 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, TCP, queue, tunnel and FIN axes are kept separate
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.
WebSocket tunnel timeout is independent from HTTP keepalive
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.
clientFIN and serverFIN limit half-closed connections
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.
Capabilities
Timeout Profiles let operators tune connection lifetime and wait behavior precisely across 9 independent fields to match every traffic type.
httpKeepaliveTimeout controls how long an idle HTTP connection stays open
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 limits slow header delivery and reduces slowloris risk
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 governs TCP connection wait time to the backend
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 sets how long to wait for a response from the backend
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 controls wait behavior when expecting data from the client
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 limits how long a client waits when the pool is at capacity
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 manages WebSocket and HTTP tunnel connections separately
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 controls how long a connection is held after the client closes
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 manages graceful drain time when the backend closes
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 same timeout profile can be bound to multiple 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 native generate pipeline translates profile fields into runtime timeout directives
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 timeout remains a separate control outside the traffic profile
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.
Operational depth
Timeout profiles are operated together with their value range, defaults, decimal support, tunnel semantics, FIN balance and pool binding model.
Value range
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.
Decimal support
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.
Production-safe defaults
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.
Tunnel semantics
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.
FIN balance
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.
Named profiles instead of presets
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.
When to use it
Balanced timeout profile for standard web applications
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.
Long WebSocket tunnel duration for real-time chat
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.
Raised serverTimeout for long-polling APIs
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.
Extended clientTimeout for large file uploads
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.
Aggressive timeout profile for a fast banking API
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.
Slow-attack defense profile for public-facing web
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.
Frequently asked questions
What does each of the 9 timeout fields control?
Why do WebSocket connections need a separate timeout profile?
Why do clientFIN and serverFIN values matter from a security perspective?
How is the same profile bound to multiple pools?
What is the difference between serverTimeout and queueTimeout?
Are there built-in timeout profile templates?
Model timeout management to match your traffic types
9-axis named timeout profiles for your web, API, WebSocket and upload pools. Let us walk through a live setup with your own configuration.