MQTT客户端显示“连接超时”，第一步应确认使用的是原生MQTT TCP、TLS上的MQTTS，还是MQTT over WebSocket。HTTP代理擅长转发HTTP请求；要承载原生MQTT，通常需要支持CONNECT到Broker端口，或使用SOCKS代理。WebSocket方案则要求Broker明确开启对应监听。
一、三种常见传输路径
| 方式 | 常见协议 | 代理要求 |
|---|---|---|
| 原生MQTT | TCP | SOCKS或支持目标端口的CONNECT |
| MQTTS | TLS over TCP | TCP隧道、SNI与证书链 |
| MQTT over WebSocket | WS或WSS | HTTP升级、路径和空闲超时 |
二、普通HTTP代理为何可能拒绝Broker端口
很多HTTP代理只允许CONNECT到少数端口，例如常见HTTPS端口。MQTT Broker使用的端口若未获批准，代理可能返回403、502或直接断开。不要尝试绕过组织出口策略，应由管理员按业务需求评估并放行特定目标与端口。
三、SOCKS5适合什么情况
SOCKS5可转发通用TCP连接，更适合不基于HTTP的协议。仍需确认客户端库是否支持SOCKS、认证方式和远端DNS解析。将SOCKS端口配置成HTTP代理，握手格式不匹配，通常会立即失败。
四、WebSocket连接要检查哪些参数
Broker必须启用WebSocket监听，并明确路径、端口和是否使用TLS。客户端连接到错误路径时可能收到404；代理未正确转发Upgrade头时，握手无法升级；建立后又可能被代理空闲超时关闭。
WebSocket分层排查可参考代理下WebSocket频繁断线。
五、TLS与SNI如何影响MQTTS和WSS
客户端应验证Broker证书链和域名。通过IP连接但证书只为域名签发，会出现名称不匹配。企业代理若只做TCP隧道，不应改变端到端证书；若进行受控TLS检查，则客户端需要合法信任链。不要关闭证书验证。
六、代理认证与Broker认证是两层
HTTP代理可能返回407，需要代理凭据；MQTT CONNECT报文中的用户名、密码或证书用于Broker认证。两套凭据不能混用。日志应分别记录代理阶段和MQTT CONNACK原因码，并对秘密做脱敏。
七、Keep Alive为何影响断线
MQTT Keep Alive用于让Broker发现失效客户端，客户端会在无其他数据时发送PINGREQ。代理、NAT和负载均衡器还各有空闲超时。Keep Alive应小于关键链路空闲回收时间并留有余量，但不宜过短，否则会放大设备与Broker负载。
八、自动重连不能无限加速
网络中断时，成千上万设备如果立即重连，会形成重连风暴。客户端应采用带抖动的指数退避、连接上限和服务端配额。恢复后还要确认订阅、会话和未确认消息状态，不能只看到TCP重连成功。
九、会话与QoS如何影响消息恢复
MQTT版本、Clean Start或Clean Session、会话过期间隔、QoS和客户端持久化共同决定离线消息及未完成传输。代理重置连接不会自动保证业务消息不丢或不重复。消费端应根据业务需要设计幂等和消息去重。
十、DNS和双栈需要检查什么
客户端本地解析、SOCKS远端解析和代理上游解析可能得到不同结果。IPv6目标若代理不支持，也可能出现IPv4成功、IPv6超时。应记录Broker域名解析、实际连接地址和代理协议，不要长期关闭IPv6掩盖配置问题。
双栈旁路见IPv4代理与IPv6直连排查。
十一、建议测试矩阵
- 分别测试原生TCP、TLS和WebSocket监听；
- 记录DNS、TCP、CONNECT、TLS与MQTT CONNACK时间；
- 验证代理错误凭据和Broker错误凭据；
- 保持连接超过各层常见空闲时间；
- 模拟断线，观察退避、会话和订阅恢复；
- 检查QoS消息是否重复或丢失；
- 记录脱敏客户端ID、节点与配置版本。
十二、结论
MQTT代理故障的关键是传输方式。原生TCP、MQTTS和WebSocket对代理的要求不同；明确路径后，再检查认证、TLS、Keep Alive和会话恢复，才能判断连接稳定性，而不是只看一次握手是否成功。
