Introduction

If an Istio-managed TCP connection closes after almost exactly one hour, the first thing to suspect is idle timeout, not random packet loss. Istio's DestinationRule TCP connection pool settings include an idleTimeout, and the documented default for TCP connections is one hour when it is not set explicitly. In other words, the "one hour" detail is a strong diagnostic clue.

What the One-Hour Behavior Usually Means

A long-lived TCP connection is not the same as an active TCP connection. If no bytes are sent or received for a long period, Envoy may treat that socket as idle and close it.

That means a connection can stay open for hours if traffic keeps flowing, but still get closed around the one-hour mark if it is mostly silent.

So the first question is not "How old is the connection?" It is "Was the connection idle?"

Confirm the Idle Case First

Before changing mesh config, verify whether the disconnect happens only when the socket is silent. A quick test is to send heartbeats over the same TCP stream.

1import socket
2import time
3
4sock = socket.create_connection(("example-service", 9000))
5
6for _ in range(12):
7    sock.sendall(b"ping\n")
8    reply = sock.recv(1024)
9    print(reply.decode().strip())
10    time.sleep(300)
11
12sock.close()

If a connection with periodic traffic survives beyond an hour while a fully quiet connection does not, you are almost certainly dealing with idle timeout behavior.

The Istio Setting to Check

For TCP traffic, the relevant knob is trafficPolicy.connectionPool.tcp.idleTimeout on a DestinationRule.

1apiVersion: networking.istio.io/v1beta1
2kind: DestinationRule
3metadata:
4  name: tcp-service-policy
5spec:
6  host: tcp-service.default.svc.cluster.local
7  trafficPolicy:
8    connectionPool:
9      tcp:
10        connectTimeout: 5s
11        idleTimeout: 0s

Setting idleTimeout: 0s disables the timeout. You can also set a longer explicit duration instead of disabling it entirely:

idleTimeout: 4h

This is often safer than turning the timeout off globally.

When Keepalive Is Better Than Stretching Timeouts

Just because you can disable idle timeout does not mean you should. A silent socket still consumes resources, and extremely permissive timeout settings can make stale connections linger longer than necessary.

If the protocol supports it, application-level heartbeats are often the healthier solution. They prove the connection is still meaningful and help both sides detect broken paths earlier.

A lightweight heartbeat can be as simple as:

def heartbeat_frame() -> bytes:
    return b"HEARTBEAT\n"

In practice, many production systems combine moderate timeout settings with explicit heartbeats rather than choosing one or the other exclusively.

Remember the Entire Path

Istio may not be the only component that can close the connection. The path may also include:

• The client application
• The upstream server
• An ingress or egress gateway
• A cloud load balancer
• Another proxy outside the mesh

If the connection still dies after exactly one hour even after you change the Istio DestinationRule, the real limit may live somewhere else in that path.

Useful Commands for Inspection

When debugging, inspect the sidecar or gateway actually handling the traffic:

istioctl proxy-config listeners POD_NAME -n NAMESPACE
istioctl proxy-config clusters POD_NAME -n NAMESPACE
kubectl logs POD_NAME -c istio-proxy -n NAMESPACE

These commands help you confirm whether the proxy received a reset, applied a timeout, or inherited behavior from another layer.

If the flow crosses a gateway, inspect that gateway too. It is easy to focus only on the sidecar attached to the workload and miss the actual closing point.

Roll Out Narrowly

Timeout changes should be scoped carefully. Apply them to the specific service pair or workload that needs them rather than changing mesh-wide defaults immediately.

Longer idle lifetimes increase resource retention, so the operational question is not only "Does this stop the disconnect?" but also "What new cost does this create?"

That is why targeted DestinationRule changes are usually preferable to broad global changes during initial debugging.

Common Pitfalls

One common mistake is calling a connection "long-running" when it is actually idle for most of its lifetime. That wording hides the real cause.

Another issue is increasing timeouts without checking whether periodic traffic would solve the problem more cleanly. Heartbeats are often the better engineering answer.

Developers also sometimes edit the wrong layer. A sidecar DestinationRule will not fix a one-hour idle timeout enforced by a load balancer or gateway outside that path.

Finally, do not forget that idleTimeout is about inactivity, not absolute age. An active connection and an idle connection are treated very differently.

Summary

• A TCP connection closing after about one hour in Istio usually points to idle timeout behavior.
• The relevant setting is DestinationRule.spec.trafficPolicy.connectionPool.tcp.idleTimeout.
• The documented default TCP idle timeout is one hour when it is not set explicitly.
• Heartbeats are often a better fix than disabling timeouts completely.
• Check every layer in the connection path before concluding that Istio alone is responsible.