How to Fix OPC UA Session Timeout Loops

Back to Blog

First Checks: Which Layer Is Expiring?

Read the actual error codes before changing any settings, because OPC UA tells you which layer failed. Errors about an invalid or unknown session mean the server discarded the client's session, usually because its timeout elapsed without a request. Errors about the secure channel being invalid or its token expired mean the channel renewal did not happen in time. A plain TCP disconnection with no protocol error at all points below OPC UA entirely, at a firewall, NAT gateway, or cellular link quietly killing the idle connection. Each of these produces the same operator-visible symptom - a reconnect loop - but each has a different fix, and the error codes are the cheapest way to tell them apart.

Also note the rhythm. A drop at a fixed interval every time is a timeout somewhere, and the interval is a fingerprint: match it against the client's session timeout, the secure channel lifetime, and the site's firewall idle timeout to find the guilty layer. Irregular drops that correlate with network load or link quality point instead at an unstable transport underneath a correctly configured stack.

Session Timeouts and Keep-Alive Traffic

An OPC UA session is kept alive by activity. The client requests a session timeout at creation, the server may revise it, and the session survives only as long as requests arrive inside that window. A healthy client with an active subscription refreshes the session automatically, because publish requests are constant traffic. The classic loop happens with clients that only read occasionally: the client sits quiet, the session expires server-side, and the next read fails, triggering a reconnect - which works, runs quietly past the timeout again, and fails again. From the outside this looks like a flaky server when it is actually a client with no keep-alive behavior.

The fix is to guarantee traffic inside the session window. Most client stacks offer a keep-alive read or automatic session renewal; enabling it, or simply keeping a subscription with a slow publish interval alive, holds the session open indefinitely. If the session timeout the server grants is shorter than requested - servers are free to revise it downward - the client must honor the revised value rather than its requested one, and a client library that ignores the revision will loop no matter what the configuration says. Comparing requested versus granted timeout in the connection log is a thirty-second check that catches this.

Secure Channel Renewal and Network Idle Cutoffs

Underneath the session, the secure channel encrypts and signs traffic using keys tied to a security token with a finite lifetime, and the client stack is responsible for renewing the token before it lapses - typically it renews when a majority of the lifetime has elapsed, well before expiry. Renewal is normally invisible, which is exactly why a failure looks mysterious. Renewals can fail when the connection is saturated, when a server is overloaded at the renewal moment, or when a buggy stack simply misses its window, and the result is a channel-level error and a full reconnect. Persistent channel-renewal failures are usually a load or software-version problem rather than a configuration one, and stack updates on either end have a track record of resolving them.

Between client and server, middleboxes have their own opinions. Firewalls and NAT gateways drop TCP flows that idle past their timeout, and cellular carriers are notoriously aggressive about it. An OPC UA connection with long publish intervals and no other traffic can look idle enough to be culled, and neither endpoint learns of the drop until the next send fails. Where the network path cannot be trusted to preserve idle connections, shorten the publish or keep-alive interval so real traffic flows more often than the shortest idle timeout along the path, or enable TCP keep-alives at the OS level. Outbound-connecting architectures behind NAT should assume this problem exists until proven otherwise.

Server Session Limits and When to Escalate

Servers cap concurrent sessions, and embedded servers in PLCs and gateways often cap them low. A client that crashes without closing its session leaves an orphan that occupies a slot until the session timeout finally reaps it, and a reconnect-looping client can fill every slot with its own ghosts, locking itself out with too-many-sessions errors. The signature is reconnects that fail for a while and then suddenly succeed - the orphans expired. Fixes are clean shutdown handling in the client, shorter session timeouts so orphans reap faster, and checking the server's session capacity against how many clients genuinely need it.

Escalate with evidence: client and server logs around one loop cycle, the granted timeouts for session and channel, and a note of every firewall or NAT hop in the path. For a monitoring platform such as Merobix, which holds long-lived subscriptions to many servers, this class of problem is designed out by maintaining continuous publish traffic and reconnecting with backoff - but the same server-side limits still apply, so an embedded server that must serve several clients at once deserves a capacity check during commissioning rather than after the first lockout.

Frequently Asked Questions