谁发起连接
常规 OPC UA 连接由客户端主动连服务器，因此要求客户端能路由到服务器的端口。当设备位于客户网络内部、地址转换之后或只允许出网的网段时，这条路径走不通。反向连接把发起方向倒过来：客户端先告知一个可被访问的监听地址，服务器主动发起到该地址的连接，之后按标准流程建立安全通道与会话。它改变的只是谁先发起，信任模型与加密要求完全不变，两端证书仍需互信。
基本信息
| 发起方 | 服务器主动连回客户端 |
|---|---|
| 客户端配置 | 提供反向连接地址列表与等待超时 |
| 服务器配置 | 指定要连接的目标地址，需支持该机制 |
| 支持情况 | 不同产品与版本支持程度不一，需查产品文档 |
| 安全模型 | 与常规连接相同，双向证书校验，不可省略 |
| 网络要求 | 设备侧需要具备到目标地址的出网能力 |
典型使用场景
- 设备被隔离在客户网络内，厂外系统无法直接访问设备端口
- 云端或中心平台统一管理现场设备，现场只允许出网
- 临时调试：现场网络策略严格，用反向连接接入两小时后再关闭
- 多台设备经同一出口入网，中心侧统一维护监听地址与证书
- 受控远程维护：出网目标地址被限制为固定的中心节点
- 排错对比：正向不通但反向可用时，可判定是入站策略问题
正向与反向对照
| 维度 | 正向连接 | 反向连接 |
|---|---|---|
| 发起方 | 客户端 | 服务器 |
| 需开放入站端口 | 服务器侧 | 客户端侧 |
| 地址配置在 | 客户端 | 服务器配目标，客户端配监听 |
| 证书校验 | 双向 | 双向，无简化 |
| 典型场景 | 常规集成 | 设备在隔离网或地址转换之后 |
| 排查起点 | 服务器端口可达性 | 设备出网能力与客户端监听可达性 |
配置与排查要点
配置与排查要点
# 客户端：登记反向连接监听地址与超时时间，开放对应入站端口
# 服务器：配置要连接的目标地址，通常与客户端证书中的标识对应
# 证书：反向连接地址的主机名必须与客户端证书标识一致，否则校验失败
# 排查顺序：设备能否出网 → 目标端口是否可达 → 证书是否互信 → 策略是否匹配
# 注意：并非所有产品都实现该机制，先在测试环境验证再上生产反向连接的诊断难度高于正向：链路上多了一层不可见的方向反转，出现握手失败时先确认两端是否真的走到了发起连接这一步。
让设备具备出网能力本身就是一次安全暴露：应把目标地址与端口限制到最小集合，并防止设备侧配置被非授权修改。