BadTcpEndpointUrlInvalid
BadEndpoint path
BadTcpEndpointUrlInvalid is the transport-level rejection of the endpoint URL in your Hello message, and in practice it is the path part that is wrong: opc.tcp://host:4840/UA/MyServer versus a bare slash. The host and port are fine - fix the path using the URL returned by GetEndpoints.
What you actually see
The TCP connection is accepted and then closed immediately with an error frame, so the client reports a failure in well under a second with no certificate dialog.
Why it happens
- Wrong path segment on the endpoint URLThis is the defining cause. The listener on port 4840 may serve several endpoint paths, or exactly one. Sending Hello with /UA/MyServer to a server that serves only / - or the reverse - is rejected at the transport layer before any secure channel exists.
- Path copied from a different vendor or versionVendors choose different conventions, and paths change between firmware or product versions. Configuration inherited from another site, or from an older PLC firmware, is a common source of a stale path.
- Multiple applications behind one portAn aggregating server or a host running several UA applications distinguishes them by path. Asking for a path that no longer exists - because the downstream application was renamed or removed - fails here rather than at the URL parse stage.
- Reverse connect endpoint URL mismatchIn reverse connect the endpoint URL presented by the server in the ReverseHello must match exactly the URL used to create the client. Some servers do not use an FQDN, so specifying an FQDN on the client side breaks the match and the exchange is rejected.
- Case or trailing-slash differencesComparison is not guaranteed to be forgiving. /UA/MyServer, /ua/myserver and /UA/MyServer/ can all be treated as distinct by a strict listener.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Confirm the socket is opennc -vz host 4840 must succeed. This code only appears after a successful TCP connection, so a refused socket points somewhere else entirely.
- Get the authoritative path from GetEndpointsCall GetEndpoints against opc.tcp://host:4840 with security None. The returned EndpointUrl values contain the exact paths the listener serves. Copy one character for character.
- Retry with the discovered pathChange only the path in your configuration and reconnect. If the bare discovery URL works but your configured URL does not, the path was the problem and nothing else needs touching.
- For reverse connect, drop the FQDN if the server does not use oneConfigure the client's expected endpoint URL to match exactly what the server puts in its ReverseHello. If the server sends a short hostname, do not specify the FQDN on the client side either.
- Check the capture if it still failsWith the Wireshark OPC UA dissector, look at the HEL frame and the ERR frame that follows. The Hello carries the endpoint URL as a string, so you can see byte for byte what the client sent.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | Discovery finds the correct path automatically when you add the server by its base URL. Manually entered endpoint URLs with a guessed path are the usual way to hit this. |
| Eclipse Milo | The public demo server at opc.tcp://milo.digitalpetri.com:62541/milo shows the pattern clearly: the /milo path is required and the same host and port with a bare slash will not serve you. |
| node-opcua | The public sample at opc.tcp://opcuademo.sterfive.com:26543 uses a bare path. Servers built with node-opcua take a resourcePath option, which is exactly the path segment that must match. |
| open62541 (C) | The server's customHostname and the URL you build must agree on the path. open62541 servers commonly serve a bare path, so adding one from habit causes this. |
| OPC Publisher | Endpoint URLs in published-nodes entries are used verbatim. A wrong path fails silently as an endpoint that never connects, so check the module log rather than expecting a visible error. |
| Wireshark OPC UA dissector | Decodes the Hello and Error frames of the UACP handshake, which is the only place the offending URL string is visible when the client log truncates it. |
What it looks like in the log
Transport error: BadTcpEndpointUrlInvalid - the server does not recognize the QueryString specified
Hello rejected for endpointUrl opc.tcp://plc01:4840/UA/MyServer; served paths are /
ReverseHello endpointUrl opc.tcp://plc01:4840 does not match configured opc.tcp://plc01.plant.local:4840Confirm the fix
Connect with the discovered EndpointUrl and confirm the Hello is answered with an Acknowledge and a secure channel opens. A capture showing HEL followed by ACK rather than ERR is the proof.
Stop it happening again
Never hand-write endpoint paths into configuration. Discover once at commissioning, store the discovered URL, and re-discover after firmware upgrades that may change the path.
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.