iOS端MQTT发布报错：mqttDidDisconnect: Socket closed by remote peer求助

Question #

我在iOS端集成MQTT功能时，发布消息阶段出现报错：mqttDidDisconnect: "Socket closed by remote peer"。请问该问题是源于服务器端还是请求发送端？

以下是相关代理代码：

func mqttDidPing(_ mqtt: CocoaMQTT) { print("mqttDidPing") }
func mqttDidReceivePong(_ mqtt: CocoaMQTT) { print("mqttDidReceivePong") }
func mqtt(_ mqtt: CocoaMQTT, didPublishAck id: UInt16) { print("didPublishAck : \(id)") }
func mqtt(_ mqtt: CocoaMQTT, didPublishComplete id: UInt16) { print("didPublishComplete: \(id)") }
func mqtt(_ mqtt: CocoaMQTT, didSubscribeTopic topic: String) { print("didSubscribeTopic: \(topic)") }
func mqtt(_ mqtt: CocoaMQTT, didUnsubscribeTopic topic: String) { print("didUnsubscribeTopic: \(topic)") }
func mqttDidDisconnect(_ mqtt: CocoaMQTT, withError err: Error?) { print("mqttDidDisconnect: \(err?.localizedDescription ?? "")") }
func mqtt(_ mqtt: CocoaMQTT, didConnectAck ack: CocoaMQTTConnAck) { print("didConnectAck: \(ack)") }
func mqtt(_ mqtt: CocoaMQTT, didPublishMessage message: CocoaMQTTMessage, id: UInt16) { print("didPublishMessage: \(message) and \(id)") }
func mqtt(_ mqtt: CocoaMQTT, didReceiveMessage message: CocoaMQTTMessage, id: UInt16) { print("didReceiveMessage: \(message) and \(id)") }
func mqtt(_ mqtt: CocoaMQTT, didReceive trust: SecTrust, completionHandler: @escaping (Bool) -> Void) { print("didReceive trust") }

Answer #

这个问题其实不能直接一刀切说是服务器或客户端的锅，得结合具体场景和排查结果来看，先给你拆解一下这个错误的可能原因：

大概率源于服务器端的场景 #

• 消息大小超限：很多MQTT服务器（比如Mosquitto、EMQ）会设置单条消息的大小上限，如果你发布的消息超过这个限制，服务器会直接断开连接来拒绝这条消息
• 权限不足：客户端使用的账号没有对应发布主题的权限，服务器在验证权限不通过后会主动关闭连接
• 协议版本不兼容：比如客户端用了MQTT 5.0，但服务器只支持3.1.1，握手后服务器可能直接断开
• 服务器保活超时：客户端没在规定的keepAliveInterval时间内发送PINGREQ，服务器判定连接失效，主动关闭Socket
• 服务器资源过载：服务器CPU/内存占用过高，会主动清理一些连接来释放资源，你的连接刚好被选中

可能源于客户端（发送端）的场景 #

• 网络异常触发：比如客户端突然切换WiFi/蜂窝网络，底层网络栈会关闭原有Socket，这时也会抛出这个错误
• 消息格式非法：你发布的消息包含了MQTT协议不允许的字符，或者序列化出现问题，导致服务器无法解析，进而断开连接
• 保活设置不合理：如果把keepAliveInterval设置得太短，客户端来不及发送PINGREQ，服务器就会认为连接超时关闭
• SSL/TLS验证问题：如果使用了加密连接，客户端的证书配置错误（比如证书过期、不被服务器信任），服务器会断开连接，有时候也会表现为这个错误

快速排查建议 #

1. 先查服务器日志：这是最直接的方式，如果能拿到MQTT服务器的日志，里面会明确记录断开连接的具体原因（比如"message too large"、"permission denied"）
2. 测试最小消息：先发布一个只有几个字符的测试消息，看是否还会断开，排除消息大小问题
3. 验证权限配置：确认客户端的账号确实拥有目标主题的发布权限，可以用MQTTX这类工具测试相同账号的发布能力
4. 抓包分析：用Wireshark抓MQTT的网络包，看断开前的协议交互——如果服务器先发送了DISCONNECT报文，那基本是服务器端的问题；如果是客户端这边先出现网络中断，那就是客户端侧的问题

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