QuickFix C++结合sTunnel连接LMAX UAT的SSL通信故障排查问询

根据你提供的配置、日志和测试结果，我能看到几个关键问题点，大概率是这些导致了连接被重置（Connection reset by peer）：

1. TLS版本配置过低 #

你的sTunnel配置里指定了sslVersion = TLSv1，但目前几乎所有正规交易场所都已经禁用了老旧的TLSv1协议（存在安全漏洞），LMAX UAT环境肯定也不支持。当sTunnel尝试用TLSv1握手时，LMAX的服务器会直接断开连接，这就是你看到“连接重置”的核心原因之一。

2. 不必要的客户端证书配置 #

你生成并配置了cert = /etc/stunnel/stunnel.pem，但LMAX的FIX over SSL服务不需要客户端证书认证（除非你和LMAX特别约定过双向认证）。sTunnel作为客户端连接LMAX时，只需要验证LMAX的服务器证书即可，主动发送自己的证书会导致LMAX服务器拒绝连接，进而重置会话。

修复步骤 #

第一步：修改sTunnel配置文件 #

编辑/etc/stunnel/stunnel.conf，调整以下内容：

pid = /var/run/stunnel4/stunnel.pid
[LMAX-UAT]
client = yes
accept = 127.0.0.1:143
connect = fix-order.london-uat.lmax.com:443
# 升级到LMAX支持的TLS版本，推荐TLS1.2或更高
sslVersion = TLSv1.2
verify = 2
CApath = /etc/ssl/certs/
# 移除不必要的客户端证书配置
# cert = /etc/stunnel/stunnel.pem
checkhost = fix-order.london-uat.lmax.com

第二步：重启sTunnel服务 #

sudo systemctl restart stunnel4.service

第三步：验证sTunnel连接状态 #

启动客户端前，先查看sTunnel的实时日志，确认没有握手错误：

journalctl -u stunnel4.service -f

当客户端发起连接后，如果日志里出现类似SSL negotiation successful的信息，说明sTunnel已经成功和LMAX建立SSL通道。

额外排查点 #

• 确认LMAX UAT的Endpoint正确性：再次核对官方文档，确保fix-order.london-uat.lmax.com:443是当前有效的FIX over SSL地址。
• 检查QuickFix的HeartBtInt和108（HeartbeatInterval）字段是否一致：你的QuickFix配置HeartBtInt=15，LOGON报文中108=15是对的，这部分没问题。
• 白名单确认：虽然你说IP已加入白名单，但可以让LMAX那边再核对一次你的公网出口IP（sTunnel所在服务器的公网IP）。

从Wireshark的结果来看，你能看到发往LMAX的数据包但没有返回，说明问题确实出在SSL握手阶段（sTunnel和LMAX的连接层面），而不是LOGON报文格式——因为如果是报文格式问题，LMAX至少会返回一个拒绝的FIX消息，而不是直接重置TCP连接。

内容的提问来源于stack exchange，提问作者p.luck