Ignition OPC UA can display an Internal Error while creating a client connection even though the decisive failure occurs earlier in the data path. For opc.tcp://10.3.141.1:62541/discovery, the gateway log reports Bad_ConnectionRejected followed by Connection refused. That means the operating system rejected the TCP connection before OPC UA discovery, certificate exchange, endpoint selection, authentication, or tag browsing began.
Follow the packet. The Ignition OPC UA client opens a socket to the selected host and port. The operating system routes that request through loopback for localhost or through the network interface for 10.3.141.1. A server listener must be bound to the matching interface on port 62541. Only then can the client request the discovery endpoints.
Where does the connection attempt stop?
| Stage | Request or condition | Observed result | Diagnostic meaning |
|---|---|---|---|
| Client configuration | opc.tcp://localhost:62541/discovery |
Internal Error page | The browser message alone does not locate the failure. Read the gateway log. |
| Client configuration | opc.tcp://10.3.141.1:62541/discovery |
Internal Error page | The address uses the host network interface rather than the local loopback path. |
| TCP connection | Connect to 10.3.141.1:62541
|
Bad_ConnectionRejected and Connection refused
|
No process accepted the connection on that address and port. Check server state and bind addresses first. |
| Gateway web interface | Render the discovery wizard |
MarkupNotFoundException for ChooseDiscoveryServerStep
|
The web wizard also encountered a rendering or packaged-resource failure. This can obscure the underlying connection refusal. |
A refusal differs from a timeout. A timeout usually sends the investigation toward routing, filtering, or an unreachable host. A refusal means the destination stack responded but found no accepting listener for that address and port, or actively rejected the socket. Because the failure precedes OPC UA messaging, changing certificates, security policies, user credentials, or exposed tags cannot correct this specific log result.
Why can localhost and the network-card address behave differently?
A listening service accepts traffic only on the addresses to which its socket is bound. Binding the OPC UA server to one interface does not automatically make it reachable through every other interface. This matters even when client and server run on the same device.
| Client address | Path | Required listener | Use case |
|---|---|---|---|
localhost |
Local loopback inside the device | The OPC UA server must accept local loopback traffic on 62541. |
An Ignition client connecting to an OPC UA server on the same gateway. |
10.3.141.1 |
Host IP stack and named network interface |
10.3.141.1 must be included in the server bind addresses. |
Testing the interface-specific endpoint or serving clients that reach this address. |
0.0.0.0 as a bind address |
All available IPv4 interfaces | The listener accepts connections through each applicable interface. | Clients on other machines need access and interface-specific binding is unnecessary. |
For a connection that never leaves the gateway, use localhost. It removes the network-card address from the dependency chain and remains independent of interface initialization after a device reset. For remote clients, publish an endpoint through an address that the server actually binds and that the remote client can route to.
Which binding approach fits the connection path?
| Approach | Advantages | Constraints | Recommendation |
|---|---|---|---|
| Localhost-only internal connection | Shortest path; no external interface or cable dependency; suitable after network-interface resets | Remote machines cannot use the loopback name to reach this server | Preferred for the internal Ignition-to-Ignition connection |
| Bind a specific interface address | Limits the listener to the selected interface; endpoint matches the stated host address | The address must remain assigned after restart, and every required interface must be listed | Use when remote access must enter through 10.3.141.1 specifically |
Bind 0.0.0.0
|
Accepts connections through all applicable IPv4 interfaces; avoids maintaining a list of individual local addresses | Expands the interfaces on which the service listens; network filtering and access controls must match the intended exposure | Use when multiple interfaces or other machines need access |
The recommended split is simple: configure the internal client with opc.tcp://localhost:62541/discovery, then configure the server bind addresses separately for external consumers. If a Kepware OPC UA client on another computer must connect, add 10.3.141.1 or use 0.0.0.0 according to the required interface scope. A local Node-RED integration and a remote client need not share the same endpoint hostname merely because they reach the same OPC UA server.
How should the physical and socket layers be checked?
Layer one first, but apply it to the path actually used. A localhost connection does not traverse the network cable or switch. Its first meaningful checks are process state, socket binding, and port availability. A remote connection adds interface state, link, addressing, routing, and filtering before OPC UA discovery.
| Symptom | Likely layer | Check | Correction |
|---|---|---|---|
| Both local and interface-address connections are refused | Server process or listener | Confirm that the OPC UA server is running and listening on port 62541. |
Start or restart the server component and recreate its listener. |
localhost works but 10.3.141.1 is refused |
Bind configuration | Compare the configured bind addresses with 10.3.141.1. |
Add the interface address or bind to 0.0.0.0. |
| Local access works but a remote client cannot connect | Interface, route, or filtering | Confirm the remote client targets the reachable server address and port, then inspect the route and firewall path. | Correct the network path without changing OPC UA security settings prematurely. |
| The web page says Internal Error while the log says connection refused | Gateway UI plus TCP listener | Treat the log exception as the diagnostic record. | Restore the listener first, then retest the wizard. |
The log reports only MarkupNotFoundException
|
Gateway web resources | Record the component name, installed build, and whether the error survives a gateway restart. | Move from network diagnosis to build integrity, module state, and the supported software update path. |
How do you restore the OPC UA connection?
-
Choose the path. For an OPC UA client on the same Ignition gateway, select
localhost. For a client on another computer, select the address assigned to the server interface that faces that client. -
Confirm the address after the device reset. Verify that
10.3.141.1is still assigned to the intended network card. A dedicated address still depends on the interface being initialized and configured correctly. -
Set the server bind address. Add
10.3.141.1when the listener should accept traffic only through that interface. Use0.0.0.0when the server should listen through all applicable IPv4 interfaces. Retain local access required by the internal connection. - Restart after changing the binding. Recreate the OPC UA server listener so the operating system applies the selected address and port combination.
-
Test the listener before discovery. Confirm that the server is running on port
62541and that the gateway log no longer recordsConnection refused: /10.3.141.1:62541. -
Create the internal client connection. Enter
opc.tcp://localhost:62541/discoverywhen both components reside on the same gateway. Continue only after the discovery wizard returns endpoints. - Test the external path independently. From the other computer, target the reachable interface address. A successful local test proves the server process is available; it does not prove the remote route, firewall path, or interface binding.
-
Inspect gateway logs immediately if the wizard fails. Separate
Bad_ConnectionRejectedfromMarkupNotFoundException. The first directs work to the socket path; the second directs work to the gateway web resources and installed build.
Why did exposing tags appear to trigger the error?
Exposing tags changes what the OPC UA server presents after a session reaches its address space. It does not create a TCP listener on a missing bind address. The logged sequence stops at 10.3.141.1:62541, before discovery and before any client can browse exposed tags.
Treat the timing as a change-correlation clue, not as the network mechanism. Record the server bind configuration, listener state, gateway restart, and device reset as separate events. If enabling tag exposure is followed by another failure, compare the log before and after the change. A new address-space or permission error belongs to the OPC UA layer; another Connection refused remains a listener problem.
How should the two gateway exceptions be separated?
The installation used v8.0.6RC1 and logged a missing HTML resource for ChooseDiscoveryServerStep inside opc-ua-gateway-8.0.6-rc1.jar. That exception belongs to the web discovery wizard. It can turn a connection problem into a generic Internal Error page instead of presenting a useful diagnostic message.
Work the exceptions in path order. First clear Bad_ConnectionRejected by restoring a listener on the requested address and port. Then reload the discovery wizard. If discovery traffic succeeds but MarkupNotFoundException remains, check module integrity and the supported update path for the release-candidate build. Reinstalling certificates or changing endpoint security does not replace a missing web markup resource.
After recovery, test through both intended paths. The internal connection should discover through localhost. Any remote connection should discover through the bound interface address. A connected client state, successful endpoint discovery, and the absence of new refusal or markup exceptions prove that both the socket path and gateway UI are functioning.
FAQ
What happens if the OPC UA bind addresses omit 10.3.141.1?
A request to opc.tcp://10.3.141.1:62541/discovery can be rejected because no listener accepts that address and port. Add 10.3.141.1 or use 0.0.0.0 when all applicable IPv4 interfaces must accept connections.
What happens if I use localhost instead of the network-card address?
The request stays inside the gateway and avoids dependencies on the external interface, route, and cable. Use opc.tcp://localhost:62541/discovery for an internal client, provided the server accepts loopback traffic.
What happens if Internal Error remains after correcting the listener?
Read the next gateway exception. If MarkupNotFoundException still names ChooseDiscoveryServerStep, check the OPC UA module resources and supported update path for v8.0.6RC1; the final verification is successful endpoint discovery and a connected client state with no new Bad_ConnectionRejected entry.