BadServerNotConnected
BadServer state
BadServerNotConnected means the operation was attempted with no live connection to the server behind it. On a client it usually means code called a service before connecting or after disconnecting. On a gateway or aggregating server it means the upstream server it proxies is unreachable, and the fix is upstream, not local.
What you actually see
Either every call from a client fails instantly with no network activity at all, or a subset of tags on a gateway go bad together while the rest of the address space stays healthy.
Why it happens
- The client never connected, or already disconnectedApplication code holds a client object and calls Read or Browse on it without a completed connect, or after a shutdown path ran. There is no traffic on the wire at all, which is the giveaway: a capture on port 4840 shows nothing.
- The upstream server behind a gateway is downAggregating servers, SCADA OPC UA connections and tunnellers expose remote data as local nodes. When the upstream connection is lost, the items are marked with a connection-level Bad status rather than a device error. The address space still exists; the data behind it does not.
- Reconnect in progressDuring a reconnect the client has state but no usable connection. Requests submitted in that window fail immediately. Well-behaved clients queue or reject them explicitly; application code that does not check connection state sees a burst of this code on every blip.
- Redundancy failoverIn a redundant pair the client may be pointed at the standby, or mid-failover between the two. Until the failover completes, requests have nowhere to go.
- Connection configured but never enabledSCADA and collector platforms let you define a server connection that is disabled, misconfigured or never started. The tag references resolve locally and fail at read time with a connection error rather than a configuration error.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Check the client's own connection state firstRead the state from the SDK before blaming the network. If the state is disconnected or connecting, no packet was ever sent and no amount of server-side investigation will help.
- On a gateway, work the upstream legIdentify which upstream server the failing nodes come from and test it independently with UaExpert or opcua-commander from the gateway host. Prove TCP reachability, then GetEndpoints with security None, then a session.
- Read the server status of the real sourceServer_ServerStatus_State and StartTime on the upstream server tell you whether it restarted, is shutting down, or is in a non-running state such as Suspended or Failed.
- Gate application work on a connected stateExpose connection state to application code and refuse or queue operations while disconnected, instead of letting every worker discover it independently. This removes most of the log noise from this code.
- Confirm which member of a redundant pair you are onCompare the ApplicationUri and server certificate thumbprint of the connection you actually got with the one you expected, and check the redundancy support information the server publishes before assuming failover worked.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| Ignition | The OPC UA connection status - Connected, Faulted, Disconnected - is shown per connection in the gateway. Tags fed by a faulted connection carry a connection-level bad quality while unrelated tags stay good, which localises the problem immediately. |
| KEPServerEX | As a gateway it distinguishes its own UA server layer from its device channels. This code points at the UA client side or at the server interface, whereas device-layer trouble surfaces as BadNoCommunication or BadNotConnected on individual items. |
| asyncua (Python) | Calling client methods outside the connected context, or after an exception left the client half-torn-down, raises here. Use the async context manager and check that connect actually completed. |
| UA-.NETStandard (C#) | A Session object retained after its channel is gone will fail this way until the reconnect handler re-binds it. Treat connection state as observable rather than assuming the object is usable. |
| OPC Publisher | Endpoints that never establish produce no telemetry and this class of error in the module log rather than a visible alarm. Check the log per endpoint after any configuration change. |
What it looks like in the log
BadServerNotConnected: no connection to opc.tcp://plc01:4840
Read rejected locally: client state is Disconnected, request not sent
Upstream connection to opc.tcp://line2-agg:4840 is down; 412 items marked badConfirm the fix
Confirm the client reports a connected state and a session id, then read Server_ServerStatus_CurrentTime successfully from the same code path that was failing.
Stop it happening again
Model connection state explicitly in client and gateway configuration, alarm on the connection rather than on each tag, and monitor upstream legs of aggregating servers separately from the aggregator itself.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.