先分清故障停在哪一层
“连不上”和“连上后收不到消息”需要检查不同位置。先记录MQTTX提示、发生时间、连接协议和目标服务，再按下表缩小范围。不要同时修改地址、账号和主题，否则即使恢复通信，也难以判断是哪项配置起作用。
| 现象 | 优先检查 | 判断依据 |
|---|---|---|
| 连接一直超时 | 地址解析、端口、网络路径 | 还没有进入认证阶段 |
| 连接被拒绝 | 协议、认证信息、服务端日志 | 记录返回原因 |
| 连接反复掉线 | Client ID重复、网络波动 | 观察服务端连接与断开时间 |
| 已连接但无消息 | 订阅结果、主题、发布权限 | 用两客户端交叉验证 |
| 有消息但设备不动作 | 设备主题、报文及执行回执 | 消息收到不等于负载执行 |
第一步：核对协议、地址和端口
按目标服务的接入文档填写MQTT、MQTTS或WebSocket连接方式。TLS连接还需匹配证书与域名。端口能够建立TCP连接，并不能证明协议选择正确；网页能打开也不能证明MQTT监听端口可用。Windows可用PowerShell的Test-NetConnection检查目标主机和指定端口是否可达。
本地EMQX和物联地带属于不同服务，认证配置与主题规则分别管理。不要把本地教程中的连接信息直接用于平台设备。首次搭建可先阅读Windows EMQX与MQTTX安装教程。
第二步：检查认证与Client ID
核对用户名和密码的大小写、复制时的首尾空格，以及账号是否属于当前服务。两个调试客户端分别使用不同的Client ID；如果新客户端连接后旧客户端立刻断开，应先检查标识是否重复。
EMQX Cloud的连接设置可参阅MQTTX官方连接说明。其中服务地址与认证方式由具体部署决定，不能据此推断其他平台的账号规则。
第三步：先用两个客户端验证主题
让客户端A订阅自己有权限访问的主题，客户端B向完全相同的主题发布一条带时间标记的消息。确认A收到后交换角色，再逐项加入设备主题和业务报文。主题区分大小写，层级与斜杠也需要一致。
发布操作显示成功时，还需查看订阅端是否真正收到；若无消息，分别检查订阅是否被接受、发布是否被授权、两个客户端是否连接同一个服务。QoS描述消息投递级别，不能代替设备动作确认。协议细节可查阅OASIS MQTT 3.1.1规范。
第四步：把消息结果与设备状态对应起来
客户端之间发布订阅正常后，再加入设备。对接物联地带时，按设备SN和接口文档区分控制主题、状态主题及响应内容。先选择单个设备、单个通道，记录命令时间与状态回传时间，再扩展到批量控制。
通道命令可用设备指令生成器选择生成；HTTP、MQTT和Webhook的职责见物联地带API接入指南。设备响应和现场反馈应分别判断，不能把服务端已接收当成现场负载已运行。
第五、六步：保留日志，再扩展到项目
每轮只改变一个条件，记录连接时间、Client ID、订阅主题、消息内容与错误提示。分享排查记录时去除账号凭据，保留设备型号、软件版本和故障现象即可。连接及消息验证完成后，再增加断线重连、并发设备和业务联动。
工程项目可按联网方式选择以太网IO或网络继电器，把通信验证、状态读取和负载控制分开验收。命令生成工具用于整理报文，实际输出仍由具体型号和接线决定。
配图许可
配图原作者：豪哥追求卓越，原文Windows系统下本地MQTT服务器搭建，图片按CC BY-SA 4.0许可使用。
常见问题
MQTTX显示已连接，为什么还收不到消息？
连接、订阅授权和发布授权是不同环节。核对主题、权限及目标服务，再用两个不同Client ID交叉验证。
QoS设为2就能保证设备执行吗？
不能。QoS用于MQTT消息投递，设备执行结果仍需状态或回执确认。
