BadConnectionClosed (0x80AE0000) — The secure channel was closed

The transport underneath the session went away. The session may still be recoverable on a new channel, which is why a client that treats this as fatal reconnects more often than it needs to.

Start free OPC UA → canonical

Diagnosis

When you hit this

Idle timeout on a firewall or NAT device sitting between client and server.
Server restart, failover, or a certificate rotation that invalidated the channel.
Keep-alive interval longer than the negotiated session timeout, so the server reaps a session the client believes is live.

Resolution

How to fix it

Set keep-alive below the session timeout
A common working ratio is keep-alive at roughly a quarter of the session timeout. Defaults from two different SDKs frequently violate this.
Attempt session reactivation first
The UA stack can reactivate an existing session on a fresh secure channel, which is far cheaper than a full reconnect and preserves subscriptions.
Look for a middlebox
If the drop interval is suspiciously regular — exactly 30 or 60 minutes — a firewall idle timer is closing it, not the server.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.