ZeroMQ C++发布者崩溃重启后与Python端通信失效如何排查

你遇到的故障是ZMQ跨语言部署场景下的典型问题，核心是半开TCP连接残留叠加套接字默认配置不合理，按以下优先级逐一排查修复即可，不需要重启系统：

• 给所有ZMQ套接字显式配置连接回收参数
  所有参与通信的套接字（C++端PUB、Python端PUB/SUB、代理侧XPUB/XSUB）必须手动设置两个核心参数：
  • ZMQ_LINGER设为100（单位毫秒），避免套接字关闭时无限阻塞，保证进程正常/异常退出时都能及时向对端发送TCP断开帧，不会残留死连接
  • 强制开启TCP Keepalive探测：ZMQ_TCP_KEEPALIVE=1，ZMQ_TCP_KEEPALIVE_IDLE=30，ZMQ_TCP_KEEPALIVE_INTVL=5，ZMQ_TCP_KEEPALIVE_CNT=3，整套配置下45秒内就能检测到对端进程已经退出，自动清理半开连接，不需要等操作系统默认2小时的keepalive超时。
    C端如果是强制终止进程、且代码里没有做正常退出时的zmq_close/zmq_ctx_term逻辑，默认ZMQ_LINGER值为-1（无限等待），进程退出时不会给代理发FIN包，代理侧会一直保留这个无效连接，这是你第一次重启C进程后通信中断的直接原因
• 检查C++端的连接逻辑，避免TCP四元组冲突
  不要犯两个常见低级错误：
  1. 不要给C++端的PUB套接字调用bind()对接代理，正确逻辑是代理侧固定bind XSUB、XPUB两个端口，所有publisher/subscriber统一用connect()对接对应端口
  2. 不要在connect的URL里指定固定源端口，让操作系统自动分配临时源端口即可。如果固定了源端口，上次进程异常退出后，（源IP、源端口、目的IP、目的端口）的TCP四元组会在内核留存最长120秒的TIME_WAIT条目，哪怕重启代理、重启C++进程，新连接的SYN包会被内核直接丢弃，表现为连接假死，直到四元组超时或者重启机器清空内核连接表，这也是你全量重启程序仍然不通的核心原因。
• 修正代理配置，避免订阅消息丢失
  如果你是调用原生zmq_proxy()跑代理，给XPUB套接字设置ZMQ_XPUB_VERBOSE=1，确保代理重启后能正确转发所有订阅消息，不会错误过滤publisher发来的内容；如果是自己实现的代理转发逻辑，要保证XSUB收到的订阅/退订消息完整转发到XPUB侧，XPUB收到的订阅消息完整转发到XSUB侧，不要自行过滤丢弃。
• 修复C++端启动阶段的消息丢失问题
  ZMQ_PUB套接字调用connect()后存在毫秒级的握手延迟，如果connect之后立刻发消息，会因为连接未建立直接丢包。可以在connect完成后加200ms延迟，或者给PUB套接字设置ZMQ_IMMEDIATE=1，禁止消息发往未完成握手的无效连接。

故障验证方法：下次复现问题时，直接查看本地回环上对应代理端口的TCP连接状态，如果看到大量处于CLOSE_WAIT/TIME_WAIT状态、对应进程PID已经不存在的残留连接，就可以确认是上述问题，参数配置完成后即可恢复。

内容的提问来源于stack exchange，提问作者bobku123