Reconnecting server due to connection loss

Hi @TA_12423679 ,

Step 1: Prove whether the drop is network or server

1. From the OPC UA client machine, run a continuous ping to the Kepware server IP for 10 to 15 minutes.

2. At the same time, trigger the issue and note the exact timestamp when the “Reconnecting server due to connection loss” appears.

3. If ping shows packet loss or latency spikes at the same timestamp, this is network path instability. Move to Step 2.

4. If ping is clean, move to Step 3.

Step 2: Eliminate firewall or NAT idle timeouts

1. Check if traffic crosses any firewall, router, VPN, or NAT device between client and Kepware.

2. On that device, look for TCP idle session timeout rules. OPC UA is long lived TCP. Many environments drop “idle” sessions even though they are valid.

3. Fix: create a rule exception for Kepware OPC UA port (default 49320 unless changed) to allow long lived sessions, or increase TCP idle timeout to at least 30 to 60 minutes.

4. Retest. If reconnects stop, root cause is infrastructure timeouts.

Step 3: Fix OPC UA session and subscription timeouts (most common)

On the OPC UA client configuration:

1. Increase Session Timeout to 30 minutes or higher.

2. Increase Subscription Lifetime to at least 10x the Publishing Interval.

3. Set KeepAlive Count to a reasonable value (example: 10).

4. Set Publishing Interval to something stable (example: 1000 ms) and avoid very low values unless needed.

On Kepware OPC UA Server configuration:

1. Open OPC UA Configuration in Kepware.

2. Increase Session Timeout limit if the client is requesting a higher value.

3. Verify Max Subscriptions and Max Sessions are not being hit.

4. Apply changes and retest.

Expected outcome: If reconnect frequency drops or stops, this was a UA timeout mismatch.

Step 4: Check certificates and trust chain (silent disconnect driver)

1. On Kepware, open the OPC UA Configuration and check Trusted Clients.

2. Confirm the client certificate is trusted and not in Rejected.

3. Confirm the certificate is not expired and the system time on both machines is correct.

4. If the client certificate changed recently, re trust it and retest.

Step 5: Validate Kepware is not resource constrained at the moment of drop

1. On the Kepware server, check CPU and memory when the reconnect happens.

2. Look at Kepware logs around that timestamp for resource warnings or UA server messages.

3. If CPU is pegged, reduce UA load: fewer monitored items per subscription, fewer subscriptions, increase publishing interval.

Step 6: Confirm this is not an OPC UA client bug

1. Test with a second OPC UA client (UAExpert or Kepware OPC Quick Client for UA).

2. If the second client stays stable while the original client reconnects, root cause is the original client’s UA stack or settings.

Thanks,