Web应用连接Mosquitto时Nginx代理WebSocket报502问题咨询

核心错误点 #

现有配置无法连通的核心原因是混淆了原生MQTT TCP流与MQTT over WebSocket的协议差异：

• 你当前在ServerB部署的Nginx stream流代理，仅处理裸TCP封装的原生MQTT流量，无HTTP协议解析能力，无法识别WebSocket连接发起时的HTTP Upgrade握手请求
• 你配置的HTTP反向代理规则用proxy_pass http://转发HTTP协议流量到1883端口的原生MQTT TCP服务，两端协议完全不匹配，握手必然失败

问题答复 #

1. 原有方案的协议适配逻辑存在错误，但Web应用经该架构接收MQTT消息的需求完全可实现，缺失的核心环节是MQTT WebSocket协议适配：
   浏览器无法直接发起裸TCP连接，所有基于浏览器的MQTT客户端都走MQTT over WebSocket协议——该协议先通过HTTP发起升级请求，升级完成后才在WebSocket帧里封装MQTT报文，和1883端口跑的裸TCP MQTT报文封装格式完全不同，不能直接复用原生MQTT的代理链路。
2. 502 Bad Gateway错误和Web应用代码里是否指定订阅MQTT主题无关。
   502是网关层错误，触发阶段是Nginx和后端服务建立连接、做协议握手的环节，此时WebSocket连接尚未建立成功，根本还没走到MQTT协议交互、发送订阅报文的流程，不可能是订阅逻辑缺失导致的。

可落地修正方案 #

• 先在ServerA的Mosquitto配置中单独开启WebSocket监听，不要和原生MQTT的1883端口复用，示例配置：

# 原有原生MQTT监听保留
listener 1883
protocol mqtt

# 新增WebSocket监听，端口可自定义，示例用9001
listener 9001
protocol websockets

重启Mosquitto后，先用本地MQTT WebSocket测试工具直连ServerA:9001，确认WebSocket链路下可以正常连接、收发TEST主题消息。

• 调整ServerB的Nginx配置，两类代理分开配置互不干扰：
  • 原有stream块下的1883端口TCP代理保留，继续为mosquitto_pub/mosquitto_sub这类原生MQTT客户端提供服务
  • 调整原有的443端口下的WebSocket反向代理规则，将proxy_pass的后端地址改为Mosquitto的WebSocket监听地址http://serverA:9001，其余WebSocket代理头配置保留即可
• 前端Web应用将wss连接地址指向wss://serverB/webapp/websocket，等连接状态返回成功后，再在代码中执行订阅TEST主题的逻辑即可。

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