Troubleshooting

OPC UA won't connect? The 6 usual causes

Almost every "OPC UA client can't connect" case comes down to one of six things: the wrong endpoint, a blocked port, a security-mode mismatch, an untrusted certificate, bad credentials, or a node-access problem. Work down this list in order and you'll fix the large majority of failures.

First move: reproduce the connection with a known-good reference client such as UaExpert from the same machine and network segment as your gateway. If UaExpert connects and your app doesn't, the problem is in your app/config, not the server.

1. Wrong endpoint URL

The endpoint must be exactly right, including scheme, host and port:

opc.tcp://192.168.10.20:4840        # correct
opc.tcp://plc-server:4840/UADiscovery
http://192.168.10.20:4840           # wrong scheme
192.168.10.20                        # missing scheme/port
  • Use the server's routable IP or resolvable hostname, not localhost unless you're on the server.
  • Confirm the endpoint is reachable from the actual gateway location, not just an engineering laptop.
  • Some servers advertise a hostname the client can't resolve: try the IP explicitly.

2. Port blocked / firewall

OPC UA binary usually runs on TCP 4840 (servers may differ). A TCP timeout or "connection refused" is almost always network/firewall:

# is the port open from where the client runs?
nc -vz 192.168.10.20 4840
# or
Test-NetConnection 192.168.10.20 -Port 4840   # PowerShell

If that fails: open the port on the server/OS firewall, check VLAN/routing, and confirm no NAT is rewriting the address the server advertises.

3. Security-mode mismatch

Client and server must agree on a security policy and mode (None, Sign, or Sign&Encrypt). If the client asks for a policy the server doesn't offer (or vice-versa), the handshake fails. List the server's endpoints first and pick a matching one.

Testing with SecurityMode = None is fine to isolate a problem, but never leave production on None.

4. Certificate not trusted (the most common)

With Sign or Sign&Encrypt, the client and server swap X.509 certificates and each must trust the other. A first connection typically fails because the client's certificate is sitting in the server's rejected folder (and/or vice-versa).

  1. Attempt the connection once (it will be rejected).
  2. On the server, move the client's certificate from pki/rejected to pki/trusted/certs.
  3. On the client, trust the server's certificate when prompted.
  4. Reconnect.

Also check the certificate hasn't expired and that its application URI matches. Full detail: OPC UA security & certificates.

5. Bad or missing credentials

If the server requires user authentication, an anonymous connection will be refused. Confirm whether it expects anonymous, username/password, or a user certificate, and supply the right one.

6. Node access & expectations

You're connected but reads/writes fail? Confirm the node list is complete and stable, and clarify up front whether the requirement is read-only or the client is expected to write: write access is often restricted and must be enabled explicitly.

Quick checklist

SymptomMost likely cause
Connection refused / timeoutPort/firewall (#2) or wrong endpoint (#1)
"BadSecurityChecksFailed" / handshake errorCertificate trust (#4) or mode mismatch (#3)
"BadIdentityTokenRejected"Credentials (#5)
Connect OK, read/write failsNode access / permissions (#6)

Get the free OPC UA connection checklist

A printable one-pager of these checks in order: keep it by the panel for the next commissioning.

Grab it on the tools page →

Last updated 4 September 2026 · Educational resource.

Free download
OPC UA Troubleshooting & Integration Checklist
The field-tested checklist engineers use to diagnose certificates, ports and namespace problems fast, plus a Python (asyncua) client template.
Get the free checklist →
Free, no course, no login