先阅读迁移指南。本文提供配置与验收步骤，不代表所有固件或 Node-RED 版本均已认证兼容。使用私有测试 Broker 和合成数据进行验证。
ESP32 配置
若现有 MQTT 库支持所需协议和 TLS 校验，可继续使用。将 HiveMQ 域名替换为安全的 RunMQTT 域名，端口设置为 8883，复制完整的新设备用户名与密码。首次验证时保留 Topic 和消息格式，记录 MQTT 库、ESP32 框架及固件版本。
ESP-IDF 与 ESP-MQTT 用户应按已安装版本的 esp_mqtt_client_config_t 配置目标 URI 和新凭据，使用 ESP 证书包或正确的受信任根 CA 进行服务端验证。具体 API 请以对应版本的 ESP-MQTT TLS 示例为准。
Arduino 客户端使用 WiFiClientSecure，按 ESP32 core 支持的 API 加载正确的 CA 信任，再将安全传输交给现有 MQTT 客户端。不要沿用固定的旧 HiveMQ 证书，也不要用 setInsecure() 绕过迁移问题。证书验证前同步设备时钟。密码不能出现在串口日志、截图或提交的代码中。
不同 Arduino MQTT 库的包缓冲、QoS 和协议版本支持不同，例如只能以 QoS 0 发布的库不能用于 QoS 2 验收。须区分客户端限制与 Broker 能力。
Node-RED 配置
Node-RED MQTT cookbook说明了 MQTT 输入与输出节点共享的 Broker 配置。
- 备份现有 flow，私下保存旧 Broker 配置。准备新连接时停用命令发布者，避免重复执行动作。
- 为测试创建一个新的 MQTT Broker 配置。服务器填写 RunMQTT 安全域名，端口
8883，开启 TLS 与服务端证书校验。使用域名而非 IP，确保主机名校验有效。 - 在 Broker 配置的 Security 字段填入生成的设备用户名和密码。不同权限角色使用不同设备身份；并发连接的 Client ID 须唯一。
- 选择已部署 Node-RED 节点支持的 MQTT 版本。生产节点暂时保留原配置，用独立测试节点验证新连接。
- 创建 MQTT 输入节点，订阅
migration-check/nodered/state，QoS 1，连接到 Debug 节点并部署，等待显示已连接。 - 将 Inject 节点连接到 MQTT 输出节点，使用相同的新 Broker 配置。Topic 设为
migration-check/nodered/state，QoS 1，retain 关闭，注入唯一合成字符串。确认 Debug 收到相同值。输出节点显示已连接不能证明消息送达。 - 断开、重新部署并重复验证。使用受限测试身份检查禁止访问的 Topic，再用本地验证器独立检查相同端点。
仅为本次测试授予 migration-check/# 的发布与订阅权限。输入和输出节点可共享一个 Broker 配置，该连接也计入套餐。生产角色权限不同时，应创建不同配置与凭据。
浏览器客户端与 WSS
完整 URL 使用 wss://<broker>.tls-broker.runmqtt.com/mqtt。原生 TLS 的 8883 端口不能当成 WSS URL。检查路径、凭据、网络与代理支持，保持 TLS 校验开启。参阅已验证的 MQTT.js 示例。
设备群上线前验收
验证真实消息往返、Topic 拒绝、重启、断网、重启后的 TLS 信任及突发流量。按实际应用测试包大小和每客户端订阅数，确认重连后的当前状态与命令路由。保留旧配置至验收完成，再在 HiveMQ 退役前协调设备与后端分批切换。
保留消息和 QoS 2 需要 Growth 或 Scale。保留包标志存在已知兼容性限制，详见会话与投递。不要依据消息格式未变或一次连接成功推断完整兼容。