Diagnóstico

¿OPC UA no conecta? Las 6 causas habituales

Casi todos los casos de «el cliente OPC UA no conecta» se reducen a una de seis cosas: endpoint equivocado, puerto bloqueado, modo de seguridad no coincidente, certificado no confiable, credenciales incorrectas o un problema de acceso a nodos. Recorra esta lista en orden y resolverá la gran mayoría de los fallos.

Primer paso:reproduzca la conexión con un cliente de referencia conocido y fiable comoUaExpertdesde la misma máquina y el mismo segmento de red que su pasarela. Si UaExpert conecta y su aplicación no, el problema está en su aplicación o en su configuración, no en el servidor.

1. URL de endpoint incorrecta

El endpoint debe ser exactamente correcto, incluidos esquema, host y puerto:

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 la IP enrutable o el nombre de host resoluble del servidor, no localhost salvo que esté en el propio servidor.
Confirme que el endpoint es alcanzable desde la ubicación real del gateway, no solo desde un portátil de ingeniería.
Algunos servidores anuncian un nombre de host que el cliente no resuelve: pruebe con la IP.

2. Puerto bloqueado / cortafuegos

OPC UA binario suele funcionar sobre TCP 4840 (los servidores pueden variar). Un timeout de TCP o un «connection refused» es casi sie

# 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

Si eso falla: abra el puerto en el cortafuegos del servidor o del sistema operativo, compruebe la VLAN y el enrutado, y confirme que ningún NAT reescribe la dirección que anuncia el servidor.

3. Discordancia de modo de seguridad

Cliente y servidor deben ponerse de acuerdo en una política de seguridad y un modo (None, Sign o Sign&Encrypt). Si el cliente pide una política que el servidor no ofrece (o al revés), el handshake falla. Liste primero los endpoints del servidor y elija uno que encaje.

Pruebas conSecurityMode = Noneestá bien para aislar un problema, pero nunca deje producción en None.

4. Certificado no confiable (el más habitual)

Con Sign o Sign&Encrypt, el cliente y el servidor intercambian certificados X.509 y cada uno debe confiar en el otro. Una primera conexión suele fallar porque el certificado del cliente está en la carpeta de rechazados del servidor (y/o al revés).

Intente la conexión una vez (será rechazada).
En el servidor, mueva el certificado del cliente de pki/rejected a pki/trusted/certs.
En el cliente, confíe en el certificado del servidor cuando se le pida.
Reconectar.

Compruebe también que el certificado no haya caducado y que su URI de aplicación coincida. Detalle completo: OPC UA seguridad & certificados.

5. Credenciales erróneas o ausentes

Si el servidor exige autenticación de usuario, una conexión anónima será rechazada. Confirme si espera anónimo, usuario/contraseña o un certificado de usuario, y facilite el correcto.

6. Acceso a nodos y expectativas

¿Está conectado pero fallan las lecturas o las escrituras? Confirme que la lista de nodos está completa y es estable, y aclare desde el principio si el requisito es de solo lectura o si se espera que el cliente escriba: el acceso de escritura suele estar restringido y debe habilitarse explícitamente.

Lista rápida

Síntoma	Causa más probable
Conexión rechazada / timeout	Puerto/cortafuegos (#2) o endpoint incorrecto (#1)
«BadSecurityChecksFailed» / error de handshake	Confianza de certificados (#4) o discordancia de modo (#3)
"BadIdentityTokenRejected"	Credenciales (#5)
Conecta bien, falla la lectura/escritura	Acceso y permisos de nodo (n.º 6)

Obtenga la lista de comprobación de conexión OPC UA

Una hoja imprimible con estas comprobaciones en orden: téngala junto al armario para la próxima puesta en marcha.

Consígalo en la página de herramientas →

Última actualización: 4 de septiembre de 2026 · Recurso educativo.