Context
A pooled connection works immediately after creation, sits unused, then fails on its next request. Behind Azure Standard Load Balancer, an idle-flow timeout may be part of the explanation. Investigate the actual rule, whether TCP reset is enabled, and how the client detects stale connections before changing application retry behavior.
Define which connection becomes idle
Draw the client, load balancer, backend, and any intervening proxy or firewall. Record the five-tuple and whether the flow is inbound, an inbound NAT mapping, or outbound through a configured rule. Different devices can maintain independent state and timeout values.
Measure inactivity between network packets, not between user clicks. A background protocol heartbeat can keep a connection active while the application appears idle. Conversely, a TCP connection that remains open in a process may have no surviving state in an intermediary.
Inspect the saved rule configuration
Read the intended rule's current idle timeout and TCP reset setting. Azure documents different supported ranges by rule type, so verify the current values and supported service behavior instead of copying a universal timeout from an old deployment.
TCP reset on timeout can give applications a more explicit signal that a flow has ended. It does not make a timed-out business operation safe to repeat. A packet-level close and the business outcome of a previous request are separate facts.
Review other intermediaries before attributing the failure to the load balancer. The shortest effective state timeout on the path can dominate behavior. A longer Azure rule timeout will not retain a connection that another firewall already discarded.
Coordinate keepalive and pool lifecycle
Check whether TCP keepalive is enabled on the relevant sockets and when probes actually begin. Operating-system defaults can be much longer than the network's idle-flow lifetime. Application heartbeats and TCP keepalive also have different semantics; use the mechanism supported by the protocol and client library.
Set connection-pool idle retirement or validation behavior with the path's lifetime in mind. A pool should avoid repeatedly returning a known-dead socket to unrelated requests. Bound reconnection attempts and include jitter so a common idle interval does not cause every worker to reconnect simultaneously.
Do not retry a write simply because the connection was reset. If the operation might already have committed, use a stable operation identity and an outcome lookup or reconciliation rule. Reconnection restores transport; it does not provide exactly-once application effects.
An illustrative overnight failure
A business API keeps database connections overnight. The first morning request receives a transport error, while immediately repeated requests succeed with new connections. The pool retains sockets longer than the effective idle state on the network path and does not validate them before reuse.
The team captures the idle interval and confirms which intermediary expires the flow. It tests an appropriate keepalive configuration and a pool retirement policy, then validates both overnight recovery and burst reconnection load. A permanent loop that retries every failed statement would have created a separate correctness risk.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| First request after inactivity fails | Stale pooled socket | Effective path timeout and pool policy |
| Failure occurs during continuous traffic | Another boundary | Packet loss, service health, or capacity |
| Many clients reconnect together | Synchronized expiry | Jitter and bounded pool recovery |
| Transport reset follows a write | Outcome uncertain | Business operation lookup |
A focused operator exercise
Create a test connection through the intended load-balancing rule. Record its initial success, leave it quiet across the configured idle boundary, and observe the next exchange. Repeat with TCP reset and the proposed keepalive or pool settings in a controlled environment.
Test both a harmless read and a uniquely identified write whose connection is interrupted after submission. Confirm the application reconnects without blindly duplicating the write. Capture the actual idle duration, reset evidence, client error, and accepted recovery behavior rather than relying only on a successful ping.
Make idle behavior part of the contract
Document which component owns keepalive settings, how pools retire sockets, and the maximum reconnect effort per request. Include long-idle scenarios in release tests for services with overnight or weekend usage patterns.
Monitor first-request failures, reconnect rate, pool wait time, and application outcomes together. If a timeout increase reduces symptoms, still confirm it fits connection-capacity and failure-detection requirements. Longer retention can increase the number of state entries held during an outage.
Frequently asked questions
Does enabling TCP reset prevent idle disconnects?
It changes how timeout termination is signaled. Configure idle lifetime, keepalive, and client recovery together.
Is a successful retry proof that the original write failed?
No. A connection can fail after the server commits. Reconcile the logical operation using an application-level identity.
Continue the investigation
- Azure Load Balancer SNAT: Find the Busy Backend
- Azure App Service Outbound Timeouts: Investigate SNAT Pressure and Client Pooling
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Network Architecture & Operations to discuss implementation, validation and operational handover.
Technical reference
Configure load balancer TCP reset and idle timeout - Azure Load Balancer | Microsoft Learn