前阵子帮朋友在一台 Linux 服务器上部署 EMQX照着官方文档装完MQTTX 也能正常收发消息一切看起来都很顺利。直到我习惯性地抓了把包才发现 1883 端口上跑的 MQTT 报文全是明文——用户名、密码、Topic、Payload 一眼就能看完。那一刻我突然意识到如果只是本地玩一玩这个无所谓可一旦 broker 暴露到公网这跟把设备控制权直接送人没什么区别。这篇文章就记录一下我在 Linux 上从零安装 EMQX到启用 SSL/TLS 加密连接的完整过程包括证书怎么生成、配置怎么写、踩了哪些坑还有一些安全加固的细节。不管你是刚接触 MQTT 的新手还是已经在用 EMQX 但一直没做加密的老手这篇文章应该都能帮你少走点弯路。1. 环境准备与版本选择1.1 为什么选择 EMQX 5.x 而不是 4.x先说版本选择。目前 EMQX 官方主推的是 5.x相比 4.x 变化非常大不是简单的小版本升级。最直观的差别是配置方式4.x 用 Erlang 风格的配置格式看着像mqtt.listener.tcp.external {}这种结构5.x 改成了 HOCON 格式和现代很多配置框架比如 Play Framework、Akka保持一致的风格阅读起来更清晰也支持更灵活的嵌套和覆盖。另外一个重要的变化是 Dashboard。5.x 的 Web 管理界面做得相当精致内置了实时指标、客户端列表、订阅关系管理、甚至还有在线调试工具。对于团队协作来说这比 4.x 时代要直观得多。还有一点很关键5.x 在集群能力上做了大幅增强通过emqx ctl命令可以很方便地组建多节点集群。虽然单机部署用不到但如果你有扩容打算从 5.x 开始会平滑很多。所以我建议直接上 EMQX 5.x目前最新的 5.x 稳定版大概在 5.5 左右具体以官方发布为准。1.2 系统要求和初始化建议官方文档给出的最低配置是 1 核 512MB但我建议生产环境至少 2 核 2GB如果并发连接数比较多直接上 4 核 8GB 不亏。因为 EMQX 底层是 Erlang/OTP 虚拟机虽然单机性能很强但内存占用并不算小我看到过不少人在 512MB 的小鸡上部署 EMQX 导致 OOM 的案例。操作系统方面优先选择 Debian 12、Ubuntu 22.04 LTS、CentOS Stream 9 这类主流发行版。我个人最常用的组合是 Ubuntu 22.04 LTS因为 EMQX 官网对 Ubuntu 的包支持最好apt 源也很稳定。系统初始化阶段有几个小建议关掉不需要的 systemd 服务减少安全暴露面。确保防火墙规则是在系统层面控制的不要裸奔。给服务器配置一个稳定的主机名因为证书里通常要写域名或 IP后面做 SSL/TLS 时用得着。预留好证书文件目录统一放在/opt/emqx/etc/certs/下防止后面权限混乱。1.3 端口规划这是很多人容易忽略的一步先规划好才能避免后面改来改去。EMQX 默认会监听以下端口端口协议用途1883MQTT/TCP明文 MQTT 连接8883MQTT/TLS加密 MQTT 连接8083MQTT/WebSocketWeb 端明文连接8084MQTT/WebSocket/TLSWeb 端加密连接18083HTTPDashboard 管理界面我的方案是1883 只保留给内网或测试环境用生产环境强制走 8883 的 TLS 加密连接。8083 同理能不开就不开如果前端要连 WebSocket就用 8084。2. 安装 EMQX从 Docker 到二进制包2.1 Docker Compose 部署最省心如果你用的服务器本来就跑着 Docker那用 Compose 部署 EMQX 是最快的方案。我给出一个适合单机生产的docker-compose.ymlversion: 3.8 services: emqx: image: emqx/emqx:5.5.0 container_name: emqx restart: always ports: - 1883:1883 - 8883:8883 - 8083:8083 - 8084:8084 - 18083:18083 environment: - EMQX_DASHBOARD__DEFAULT_PASSWORDyour_strong_password volumes: - emqx-data:/opt/emqx/data - emqx-log:/opt/emqx/log - ./certs:/opt/emqx/etc/certs:ro volumes: emqx-data: emqx-log:注意我把证书目录挂载了进去这样后面生成好证书后直接放到宿主机的./certs/就能生效。Dashboard 的默认密码也可以通过环境变量在容器创建时改掉比启动后再进界面改要安全一些。启动命令很简单docker compose up -d然后访问http://服务器IP:18083应该就能看到 Dashboard。2.2 APT 仓库安装传统服务器推荐如果不希望引入 Docker 依赖用官方 APT 仓库安装也很方便。Ubuntu 下的安装流程是curl -s https://assets.emqx.com/scripts/install-emqx-deb.sh | sudo bash sudo apt-get install emqx sudo systemctl enable emqx sudo systemctl start emqx安装完成后检查一下运行状态sudo systemctl status emqx emqx ctl status只要看到Node emqx127.0.0.1 is started就说明安装成功。这种方式的好处是 EMQX 会作为 systemd 服务来管理开机自启、日志集中、崩溃自动重启都是现成的。2.3 二进制包安装和目录结构还有一种方式就是直接下载官方编译好的二进制包解压就能用。这种方式适合那些对系统环境有特殊要求、不想改动系统目录结构的场景。# 下载 EMQX 5.5.0 的 Ubuntu 包 wget https://github.com/emqx/emqx/releases/download/v5.5.0/emqx-5.5.0-ubuntu22.04-amd64.tar.gz tar -xzf emqx-5.5.0-ubuntu22.04-amd64.tar.gz -C /opt cd /opt/emqx ./bin/emqx start解压出来的/opt/emqx目录结构如下/opt/emqx ├── bin/ # 可执行文件包括 emqx、emqx_ctl 等 ├── etc/ # 配置文件主要看 emqx.conf 和 certs/ 子目录 ├── data/ # 运行时数据、heatmap、mnesia 等 ├── log/ # 日志文件 ├── lib/ # Erlang 模块和依赖库 └── plugins/ # 插件存放目录需要明确的是如果你用 APT 安装安装路径通常也是/opt/emqx所以后续配置文件的路径是一致的。2.4 验证安装成功无论用哪种方式装好都建议在浏览器里打开 Dashboard 验证一下地址是http://IP:18083默认账号密码是admin/public。登进去后的第一件事就是把默认密码改掉这个习惯真的很重要。其次用系统命令确认端口在监听ss -tlnp | grep -E 1883|8883|8083|8084|18083看到这些端口有监听状态说明 EMQX 已经正常工作了。3. MQTT 与 EMQX 核心概念速览3.1 MQTT 协议为什么适合物联网在配置安全之前先花点时间梳理一下 MQTT 本身的机制因为后面排查问题时你会频繁和这些概念打交道。MQTT 是基于发布/订阅模型的轻量级消息协议和传统的客户端/服务器请求响应模式完全不同。MQTT 中有三个核心角色Broker、Publisher、Subscriber。Publisher 把消息发到一个主题上Subscriber 根据自己的关注订阅主题Broker 负责转发消息。这种解耦带来的好处是发布端不需要知道订阅端是谁订阅端也不依赖于发布端在线。QoS服务质量是另一个必懂的概念分为 0、1、2 三个等级QoS 0最多一次消息发出后不关注对方是否收到延迟最低但可能丢。QoS 1至少一次保证对方能收到但可能收到重复消息。QoS 2恰好一次通过四次握手保证消息不重不漏开销最大。主题结构上用/做层级分隔比如device/001/temperature和device/002/humidity。订阅时可以带通配符device//temperature匹配所有设备下的温度主题device/#匹配所有子层级。理解这些概念对排查连接问题和设计 Topic 很重要尤其是后面做 TLS 加密的时候你依然要确认消息的路由逻辑是否正常。3.2 EMQX 的 Listener 机制EMQX 把每个端口的监听行为抽象成了一个Listener监听器。你可以理解为一个 Listener 就是系统的耳朵它负责在某一个端口上接收特定协议类型的客户端连接。EMQX 5.x 默认配置了多个 Listener分别是 TCP、SSL、WebSocket 等。在emqx.conf里这些配置以listeners.tcp.default、listeners.ssl.default这样的键来组织。我们启用 SSL/TLS 的本质就是调整或新增一个 SSL 类型的 Listener让它监听 8883 端口并加载证书文件。3.3 认证方式从匿名到用户名密码EMQX 默认是匿名访问的。也就是说任何客户端只要知道 broker 地址和端口就能不提供任何凭证直接连接、订阅任意主题这是一个巨大的安全隐患尤其是当你的 broker 暴露在公网时。我建议这样做先在 Dashboard 的访问控制 - 认证里添加一个密码认证数据源比如使用内置数据库Built-in Database创建几个测试账号。这样我们在验证 TLS 加密的时候也可以顺便把认证打开一举两得。配置很简单在 Dashboard 里选择认证添加认证器选择内置数据库然后创建用户名和密码。客户端连接时必须在 CONNECT 包里带上用户名密码否则会被拒绝连接。4. SSL/TLS 证书准备自签名还是 CA 签发的4.1 三类证书方案怎么选启用 TLS 加密的核心是证书。根据你的部署场景有三种常见选择公网可信 CA 证书像 Lets Encrypt、ZeroSSL 这类免费 CA 签发的域名证书优点是浏览器和客户端默认信任不需要额外配置。缺点是要求你有域名并且需要验证域名所有权。自签名证书自己生成的证书部署免费、生成快适合内网测试环境。缺点是客户端连接时必须显式指定信任该证书或 CA否则会报证书校验失败。私有 CA 证书自己搭一套 CA 体系给内网环境统一签发证书。方案最完整但管理成本高适合有运维团队的企业场景。结合大多数人的实际场景我下面重点演示自签名证书的生成方式。虽然它是自签名但只要在客户端把 CA 证书配好安全性和 CA 签发的证书在传输加密层面没有本质区别。4.2 生成自签名证书的详细过程我用一套两层结构先创建一个私有 CA再用这个 CA 给服务器签发证书。这样可以模拟完整的 CA 签发流程后面如果你要管理多个设备也可以基于同一套 CA 签发证书客户端只需要信任这个 CA 就能统一验证。第一步生成 CA 私钥和 CA 证书mkdir -p /opt/emqx/etc/certs cd /opt/emqx/etc/certs # 生成 CA 私钥 openssl genrsa -out ca.key 2048 # 生成 CA 自签证书 openssl req -x509 -new -nodes -key ca.key -days 3650 -out ca.crt \ -subj /CCN/STBeijing/LBeijing/OMyIoT/CNMyIoT Root CA这里有几个参数值得解释一下genrsa -out ca.key 2048生成 2048 位的 RSA 私钥。2048 位是目前的最低推荐标准低于这个位数比如 1024在 2024 年的环境下已经非常不安全。-days 3650CA 根证书有效期 10 年。自签名的 CA 是自己信任自己的体系时间长一点方便管理。CNMyIoT Root CACommon Name建议写一个能表达身份的标识方便以后人眼识别。第二步生成服务器的私钥和证书签名请求CSR并用 CA 签发服务器证书# 生成服务器私钥 openssl genrsa -out server.key 2048 # 生成证书签名请求 openssl req -new -key server.key -out server.csr \ -subj /CCN/STBeijing/LBeijing/OMyIoT/CNbroker.example.com # 用 CA 签发服务器证书有效期 825 天并加入 SAN 扩展 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out server.crt -days 825 -sha256 \ -extfile (printf subjectAltNameIP:192.168.1.100,DNS:broker.example.com)这里的-extfile (printf ...)是为证书添加 SANSubject Alternative Name扩展。SAN 是什么简单说它是现代证书里用来记录这个证书适用于哪些域名/IP的字段。以前的证书主要看 CN但现在浏览器和客户端都优先看 SAN如果证书里没有包含当前访问的域名或 IP即使 CN 匹配也会校验失败。所以你需要把服务器的实际 IP 和域名都写在这个 SAN 列表里逗号分隔。比如我用的是IP:192.168.1.100和DNS:broker.example.com你可以替换成自己的。4.3 顺手处理扫描器报的 CVE-2016-2183 告警不少人做完 TLS 配置后用工具扫一遍会看到SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)【原理扫描】这种告警这里顺便把这个常见问题讲透。CVE-2016-2183 对应的是 SWEET32 攻击原理是 3DESTriple DES算法在 CBC 模式下存在理论上的生日攻击风险。当加密套件里包含基于 3DES 的套件时扫描器就会报这个漏洞。修复思路不是升级 EMQX而是让 TLS 服务端不要支持 3DES 算法。先检查系统 OpenSSL 是否支持 3DESopenssl ciphers -v ALL | grep -i 3des如果支持最简单的办法是使用高版本的 OpenSSL。OpenSSL 3.x 已经默认把 3DES 降级到安全级别 0 以下很多情况下会自动禁用。在 EMQX 层面你也可以显式指定只使用高强度加密套件。以 EMQX 5.x 为例在emqx.conf里加入ciphers配置listeners.ssl.default.ssl_options { ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 }这段配置只启用了 ECDHE AES-GCM 这类现代强套件完全排除了 3DES 和 CBC 系的老算法。处理完后再用扫描器扫一遍告警就会消失。4.4 私钥文件权限不容忽视证书生成完之后目录里会有这几个文件ca.key、ca.crt、server.key、server.crt、server.csr。其中server.key是服务器私钥泄露了就等于你的加密通道形同虚设。务必执行chmod 600 server.key ca.key chmod 644 server.crt ca.crt还要确认/opt/emqx/etc/certs/目录对 EMQX 运行用户有读权限不然 EMQX 启动时会报错提示无法读取证书文件。5. 启用 SSL/TLS 监听器配置实操5.1 双端口方案明文内网、加密公网我推荐的做法是1883 明文端口保留给内网/测试环境8883 加密端口用于对外服务。这不是偷懒而是很务实的设计。内网设备之间通信如果网络环境可控走明文能降低设备端的运算开销而且排查问题更方便。公网流量一律走 8883 加密。这样即使 1883 被暴露由于绑定的是内网 IP公网根本访问不到。在 EMQX 5.x 中可以通过设置 bind 地址来实现listeners.tcp.default { bind 127.0.0.1:1883 }把 1883 端口绑定到回环地址相当于只有本机自己能访问公网完全不可达。如果内网其他机器需要访问 1883就绑定到内网网卡 IP比如192.168.1.100:1883。5.2 编辑 emqx.conf 配置 SSL ListenerEMQX 5.x 的主配置文件是/opt/emqx/etc/emqx.conf我们需要在其中添加或修改listeners.ssl.default配置块。如果你用 APT 安装直接编辑这个文件即可。下面是完整的 SSL Listener 配置listeners.ssl.default { bind 0.0.0.0:8883 ssl_options { cacertfile /opt/emqx/etc/certs/ca.crt certfile /opt/emqx/etc/certs/server.crt keyfile /opt/emqx/etc/certs/server.key verify verify_none } }解释一下各项含义bind监听地址和端口0.0.0.0:8883表示所有网卡上的 8883 端口都接受 SSL 连接。cacertfileCA 证书路径用于验证客户端证书如果开启双向认证时使用。即使目前verify_none把它填上也不亏。certfile服务器证书路径。keyfile服务器私钥路径。verify客户端证书验证策略。verify_none表示不强制客户端提供证书只做单向认证这是我们最常用的模式。如果开启verify_peer还需要客户端提供证书那就是双向认证配置复杂度高不少大多数场景用不上。5.3 修改配置后重启并验证修改完配置后需要重启 EMQXsudo systemctl restart emqx然后检查 8883 端口是否在监听ss -tlnp | grep 8883如果能看到 LISTEN 状态就说明 SSL Listener 已经成功启动。再进一步用openssl s_client这个瑞士军刀工具来验证证书链和 TLS 握手openssl s_client -connect localhost:8883 -showcerts如果配置正确输出里会包含完整的证书链信息以及类似SSL handshake has read ... bytes的消息。如果报错比如unable to verify the first certificate通常就是证书链不完整或者 CA 不匹配。5.4 验证加密套件是否安全顺手检查一下当前服务端支持的加密套件openssl s_client -connect localhost:8883 -cipher HIGH:!aNULL:!eNULL:!3DES:STRENGTH如果握手成功就说明服务端已经只接受上述强加密套件。这正是处理 CVE-2016-2183 之后应有的效果。6. 客户端连接验证图形化与命令行双管齐下6.1 用 MQTTX 验证加密连接MQTTX 是目前最流行的 MQTT 图形化客户端支持 Windows、macOS、Linux界面简洁对调试很友好我一直在用。新建连接时按以下方式配置NameEMQX-TLS-TestHostmqtts://你的服务器IP端口8883Username / Password你在 Dashboard 里创建的用户名密码点击 SSL/TLS启用 TLS选择CA 证书然后选中ca.crt文件如果使用 CA 签发的证书MQTTX 默认就能信任不需要额外导入。用自签名证书时导入 CA 是必须的否则客户端会因为不信任服务端证书而拒绝连接。客户端启动并连接成功后MQTTX 界面会显示绿色的 connected 状态。这时候你可以随便订阅一个主题比如test/topic然后通过 Dashboard 里的消息工具或者另一个客户端发布消息验证一下。6.2 用命令行工具测试更可靠有时候图形化界面能连上但不代表所有场景都正常。我建议用命令行工具再做一次严格验证这也能排查掉图形化工具隐藏的兼容性处理。安装 Mosquitto 客户端工具sudo apt-get install mosquitto-clients -y订阅端mosquitto_sub -h 你的服务器IP -p 8883 --cafile /opt/emqx/etc/certs/ca.crt \ -u testuser -P testpassword -t test/topic -v发布端另开一个终端mosquitto_pub -h 你的服务器IP -p 8883 --cafile /opt/emqx/etc/certs/ca.crt \ -u testuser -P testpassword -t test/topic -m hello emqx tls这里值得提醒的是--cafile必须指定为服务端自签名证书对应的 CA 文件即ca.crt不能是server.crt。因为客户端要验证的是服务端证书是否由该 CA 签发所以它需要的是 CA 的公钥证书。如果证书校验失败命令行客户端通常会报OpenSSL Error: certificates verify failed这时候去检查客户端传的 CA 文件是否和服务端证书匹配。6.3 抓包确认加密效果最后一步用tcpdump抓包看看到底有没有加密tcpdump -i any port 8883 -A抓包内容里应该全是乱码看不到任何明文 MQTT 报文。拿同样的方法抓一下 1883 端口对比就非常直观了1883 端口上的 topic、payload 一目了然。这其实就是第 1 节开头说的裸奔现象。tcpdump如果没有装先执行sudo apt-get install tcpdump -y6.4 双向认证mTLS扩展思路如果你对安全要求更高可以考虑启用双向认证mTLS。简单来说客户端连接时除了验证服务端证书服务端也会要求客户端出示证书。EMQX 5.x 启用双向认证的配置改成listeners.ssl.default.ssl_options { verify verify_peer fail_if_no_peer_cert true }同时生成客户端证书并导入到客户端侧。这个方案的优点是可以做到设备级的身份认证比用户名密码更可靠。缺点是证书管理成本高每一台设备都要签发和安装证书所以适合对安全要求严格的场景比如车联网、金融物联网终端等。如果你只是普通个人项目单向认证 用户名密码已经足够。7. 常见问题排查与避坑指南7.1 证书链不完整导致握手失败这是自签名证书最常踩的坑。场景是这样的你拿openssl s_client测试服务端正常但客户端连接时就报unable to verify the first certificate。原因通常是服务端只发了叶子证书server.crt没有发送中间 CA 证书或者根 CA 证书。尤其在公网 CA 签发的场景下根证书需要在系统信任库里有记录但中间证书需要服务端主动下发。解决办法是把 CA 证书和服务器证书合并成一个文件cat server.crt ca.crt server_chain.crt然后把emqx.conf里的certfile指向这个合并文件。7.2 防火墙/安全组拦截 8883 端口云服务器上即使系统防火墙放行了云厂商的安全组没有放行 8883一样连不上。测试时先确认系统侧sudo ufw status # 或者 sudo firewall-cmd --list-all如果需要放行sudo ufw allow 8883/tcp然后去云厂商控制台的安全组策略里检查入方向规则确认 8883 端口已放行。7.3 EMQX 读取证书文件报权限错误日志里出现这类关键字{error,{failed_to_read_certfile,/opt/emqx/etc/certs/server.crt}}多数情况是证书文件权限不对。EMQX 运行用户无法读取私钥文件或者私钥文件权限太高被 OpenSSL 拒读。核对一下ls -l /opt/emqx/etc/certs/至少保证server.key只能被属主读写server.crt和ca.crt对所有用户可读。注意如果私钥是 root 创建的而 EMQX 以 emqx 用户运行需要调整属主或添加读权限。7.4 客户端时间不同步导致证书过期证书校验失败还有一个隐藏原因客户端本地时间不正确。如果客户端机器的系统时间和实际时间差了好几天哪怕证书明明还在有效期内也会被判定为过期。排查方法很快在客户端机器上执行date如果时间不对启用 NTP 同步sudo timedatectl set-ntp true这个坑我见过挺多次很多人纠结证书配置半天最后发现是时间问题。7.5 不同版本 EMQX 的配置差异我上面写的是 EMQX 5.x 的配置写法。如果你还在用 4.x配置方式会有所不同。4.x 的 SSL Listener 通常在etc/emqx.conf里这就是一个巨大的差异5.x 中已经统一为 HOCON 结构。升级或者迁移时建议直接看对应版本的官方文档不要盲目照抄配置文件。具体来说4.x 的配置通常在emqx.conf中通过listener.ssl.external这类键来配置和 5.x 的listeners.ssl.default结构完全不同。7.6 常见错误码速查表整理一份我在调试过程中遇到的高频错误码方便大家对照排查错误码/报错可能原因排查方式unable to verify the first certificate证书链不完整客户端不信任 CA合并证书链检查客户端 CA 导入self-signed certificate客户端没有导入服务器证书对应的 CA在 MQTTX 中指定ca.crt并勾选 Verifyconnection closed端口没监听、防火墙拦截执行ss -tlnp检查云安全组certificate verify failed客户端时间不对或 CA 不匹配检查系统时间确认 CA 一致性key file permission error私钥权限过宽或无法读取确认chmod 600 server.key7.7 Dashboard 自身也别裸奔很多人的 EMQX 加密连接配好了但 Dashboard 管理界面还是裸奔在 HTTP 上这其实是一个更严重的风险点。攻击者登录 Dashboard 后可以随意查看客户端数据、甚至修改配置。EMQX 5.x 的 Dashboard 支持使用现有证书启用 HTTPS。在 Dashboard 的设置里选择 SSL上传证书和密钥就能启用 HTTPS 访问。配置完后记得用https://你的IP:18083访问不要再用 HTTP。另外 Dashboard 的管理员密码至少要 12 位以上并且不要使用常见的弱口令。这个细节很多人会忽略但真的非常关键。8. 生产环境选型建议与个人体会8.1 生产环境证书选型优先考虑公网 CA如果 EMQX 部署在公网环境有域名我强烈建议优先使用 Lets Encrypt 之类的公共 CA 证书而不是自签名证书。原因很简单客户端不需要额外配置 CA所有标准的 MQTT 客户端开箱即用省掉了不少部署成本。Lets Encrypt 的证书有效期是 90 天需要自动化续期。你可以用 certbot 配合定时任务或者 webhook 来实现证书的自动更新更新后再同步到 EMQX。这类自动化方案网上资料很多这里不展开。自签名证书更适合的场景是内网环境、测试环境或者设备端可以高度定制化接入的场景。就算用自签名也要把证书有效期、轮换周期提前规划好避免设备端证书过期导致大面积断连事故。8.2 个人经验先抓包再优化我的建议是无论配置再完美最后一步永远用抓包工具确认一次加密效果。这不是形式主义而是因为在 MQTT/TLS 混合部署的场景里经常会出现客户端明明用了 8883 端口但实际连接走了明文代理的情况。抓包验证一下才能真正确认流量已经被加密。8.3 关于 EMQX 日志定位问题的技巧遇到连接问题时先看 EMQX 的日志输出。日志文件一般在/opt/emqx/log/下运行日志默认级别是 warning。如果你想看到更细的接入过程可以把日志级别临时调到 debugemqx_ctl log set-level debug调完之后连接一次日志里会显示完整的握手流程和报错原因。排查完记得调回 warning否则日志量会非常大。8.4 最后一个小技巧定期备份配置和证书配置文件emqx.conf和certs/目录务必定期备份最好能和 EMQX 的数据目录一起纳入到整体的备份策略里。我见过不止一次服务器迁移时数据拷走了但证书忘拷结果新环境 TSL 完全起不来的情况。一个简单的 tar 命令就能搞定tar czf emqx-backup.tar.gz /opt/emqx/etc/emqx.conf /opt/emqx/etc/certs每次变更配置、更新证书后马上备份一次熟练了之后也就是一秒钟的事但是关键时刻能救大命。