MQTT 端口怎么选：1883、8883、WebSocket 与 TLS 证书配置
按本机开发、设备上云和浏览器看板选择 MQTT 端口，逐步生成并配置 TLS、mTLS 证书，再用 Mqttable 的真实连接和消息截图验证。
设备在本地能发送消息，换成云端 Broker 却连不上，可以把连接信息放在一起检查：传输协议、Host、Port、TLS 设置和认证方式。只把 1883 改成 8883，不会自动给服务端或客户端启用加密。
下面按本机调试、设备上云和网页看板说明端口怎么选，再用 Mqttable 演示连接和消息收发。TLS 部分会从生成证书开始，说明每个文件应该放在哪里、表单应该怎么填。
左右滚动表格，查看其余列。
| 连接方式 | 常见端口或例子 | 需要哪些信息 | 常见场景 |
|---|---|---|---|
| MQTT/TCP，mqtt | 1883 | 对应的 MQTT Listener；如果要求认证，还需要账号 | 本机开发；经过明确评估的可信私有网络 |
| MQTT/TLS，mqtts | 8883 | TLS Listener、可信服务器证书、匹配的 Host；按要求配置账号 | 网关跨公网连接、云服务接入 |
| MQTT/WebSocket，ws | 8083（EMQX 默认） | WebSocket Listener、正确的 Path | 本地浏览器或看板开发 |
| MQTT/安全 WebSocket，wss | 8084（EMQX 默认） | WebSocket Listener、Path 和 TLS 信任设置 | HTTPS 看板、支持 WebSocket 的基础设施 |
| 443 上的原生 MQTT/TLS | 443，服务商明确支持时 | 服务商规定的 TLS、认证，有时还需要 ALPN | 明确提供 MQTT/TLS 443 接入的服务 |
| MQTT/QUIC | 比如 EMQX 的 14567/UDP | Broker 和客户端都支持 QUIC | 明确选用了 QUIC 的部署 |
IANA 注册表列出了 MQTT 的 1883 和 Secure MQTT 的 8883。EMQX 默认使用 8083 提供 WS、8084 提供 WSS，Mqttable 新建 Broker 时也会预填这两个端口。
8083/8084 是 EMQX 的默认配置，服务商可以指定其他端口，也可以通过 443 提供 WSS。连接时按服务端提供的地址填写。后面的 Mosquitto 实验将 WS/WSS 分别配置在 9001/9002，截图中的端口与这份实验配置对应。
端口也不决定 MQTT 版本。同一个 Listener 可以接受 MQTT 3.1.1 和 MQTT 5.0。IANA 表里出现 UDP 注册，不等于普通 MQTT/TCP 客户端可以直接改成 UDP：MQTT 5.0 要求底层提供有序、无损、双向连接，QUIC 必须由双方明确支持。
先看客户端运行在哪里：是在设备或程序里，还是在网页的 JavaScript 里；再看连接是否经过公网或共享网络。可以按下面三种场景选择。
程序和 Broker 都在同一台电脑上时，使用 mqtt://127.0.0.1:1883，先确认连接、订阅和消息内容。Broker 只监听本机即可，暂时不需要配置 TLS 证书。
局域网中的临时调试也可以使用 1883，但明文 MQTT 不会加密用户名、密码和消息。连接涉及共享网络或敏感数据时，改用下面的 TLS 方式。
家居网关上报状态、工厂采集器发送数据、远程设备接入云服务，都可以从服务商提供的 mqtts 地址开始。常见端口是 8883；如果服务商指定了其他端口，就按它的连接信息填写。
需要准备 Broker 域名、端口和 MQTT 账号，保持服务器身份验证开启。公网证书通常使用 System CA；私有 CA 则需要额外导入 CA 证书。TLS 会保护传输，账号和 Topic 权限仍按 Broker 的要求配置。
网页的 JavaScript 不能直接建立普通 MQTT/TCP 连接，需要使用 WebSocket。比如做一个在浏览器里显示温度数据的看板，就应该选择 ws 或 wss，并填写 WebSocket Path。
使用 EMQX 时，本地开发可以连接 WS/8083；HTTPS 看板使用 WSS/8084，或服务商提供的 WSS/443 地址。WSS 还需要正确的 TLS 信任设置。测试时，Mqttable 中选择的协议和端口应与这个看板实际使用的连接一致。
mTLS 是 TLS 上的客户端证书认证，不需要重新选择一种传输协议。先确定 mqtts 或 wss 端点，再按 Broker 要求配置客户端证书和配对私钥。
普通 TLS 和 mTLS 可以使用同一个端口；是否要求客户端证书由 Listener 配置决定。本文为方便对照，使用 8883 演示普通 TLS，8884 演示 mTLS。
没有测试 Broker 的读者，可以先完成后面的本地实验，再回到这里。实验配置同时启用了 1883 和 1884。
- 在 连接 → 新建 Broker 中填写名称，比如
Port Lab；协议选择mqtt，Host 填127.0.0.1，Port 填1883。Host 只填写域名或 IP，不粘贴完整 URL。 - 保存 Broker，添加 Client。使用唯一 Client ID，MQTT 版本选 5.0；本机实验的认证方式选择无。
- 连接 Client，订阅准确的 Topic
mqttable/ports/lab/1883，QoS 1，关闭 No Local。 - 等待成功的 SUBACK，再向同一 Topic 发布
{"sensor":"lab-sensor","temperature":23.5,"test":"1883"}，QoS 1，关闭 Retain。 - 在 Trace 中查找同一 Topic、相同 payload 的两条 PUBLISH：一条发送，一条接收。单独看到 PUBACK，不能证明订阅者收到消息。
当前协议是 mqtt。两条 PUBLISH 验证了本机消息闭环，不能证明传输已加密。
把 Broker 的端口改成 1884，重新连接，再用 mqttable/ports/lab/1884 重复验证。该 Listener 仍然使用明文 MQTT。下图的端口和连接测试结果说明可以自定义端口，不代表安全性提升。
协议仍然是 mqtt；客户端和 Listener 的协议、端口必须一致。
127.0.0.1 指 Mqttable Runtime 所在的机器。使用远程 Runtime 时，它不代表正在显示页面的电脑。Docker 的 1884:1883 映射也类似：宿主机上的客户端连接 1884，容器内部的 Broker 监听 1883。
打开 Mqttable 前，在部署的连接信息页面取得这些材料：
- Broker 的 Host，不要使用 HTTP Dashboard 地址。
- MQTT/TLS 或 WSS 的 Port；WSS 还需要 WebSocket Path。
- 在服务商认证设置里创建的 MQTT 用户名、密码。云控制台登录账号不一定就是 MQTT 账号。
- 服务商要求使用的 CA Certificate 或 CA bundle。
- 仅在要求客户端证书认证时，取得客户端证书和对应私钥。
EMQX Cloud Serverless 文档给出了 mqtts:8883 和 wss:8084，并要求配置 MQTT 认证和正确的 SNI。实际接入应使用自己部署的 Host，不要替换成公共 Broker 的地址。
在 Mqttable 中新建 Broker，协议选择 mqtts，填写服务商给出的 Host、Port，保持验证服务器身份开启。服务器证书链已被当前 Runtime 信任时，选择服务器证书信任 → 系统 CA（System CA）。mTLS 保持关闭，SNI 选择自动；服务商没有要求时，ALPN 留空。
服务商要求私有 CA 时，改选 Custom CA，上传提供的 CA Certificate，或选择已保存的引用。不要上传 server.key。有些服务商提供 CA 下载，但当前 Runtime 已经信任它的根证书，此时不一定需要上传；需要判断具体端点适用哪条信任路径。如果服务端漏发中间证书链，应修复服务端配置，不能靠关闭验证解决。Let's Encrypt 的兼容性说明区分了根信任和证书链缺失。
保存 Broker，再创建 Client，选择密码认证，填写 MQTT 用户名、密码或已保存的 Password Secret。连接后，在账号有权限的 Topic 上完成“先订阅，确认成功，再发布”的验证。
Broker 的“测试连接”不发送 MQTT 用户名和密码。 它使用当前 TLS 配置并测试 MQTT 版本。需要密码认证的服务，可能在 TLS 成功后拒绝这个探测。应保存 Broker，再到 Client 表单验证凭据，不要把所有认证拒绝都解释成证书错误。
使用系统 CA 完成连接测试，不需要上传证书。这里连接的是公共测试 Broker broker.emqx.io，消息对其他人可见，不要发送敏感数据。
本地实验需要 OpenSSL 3 和 Mosquitto。下面分别给出 macOS 和 Debian/Ubuntu 的安装方式；证书生成和 Listener 配置使用相同的 Bash 命令。
macOS 已安装 Homebrew 时：
brew install openssl@3 mosquitto
export PATH="$(brew --prefix openssl@3)/bin:$(brew --prefix)/sbin:$PATH"Debian/Ubuntu：
sudo apt update
sudo apt install openssl mosquitto mosquitto-clients执行 openssl version 和 mosquitto -h 检查版本。本教程的 OpenSSL 命令要求版本 3；可选的 WS/WSS Listener 还要求 Mosquitto 包含 WebSocket 支持，旧发行包可能需要在编译时启用 libwebsockets。如果包管理器已自动启动 Broker 服务，应先检查监听端口，不要再启动一个抢占相同端口的进程，也不要停止他人的 Broker。
在仓库之外创建一个新目录：
LAB_DIR=$(mktemp -d "${TMPDIR:-/tmp}/mqtt-ports-lab.XXXXXX") &&
cd "$LAB_DIR" &&
pwdmktemp 会创建新的私有目录，不覆盖已有目录。保留打印出来的真实路径，第二个终端和文件选择器都进入这个目录；macOS 文件选择器可以按 Command+Shift+G 输入目录路径。任何命令报错都应停止，不要继续执行下一段。目录权限和后面的 umask 会限制实验文件的访问。证书有效期只有 7 天，过期后重新生成，不能直接复用本文截图里的证书。
左右滚动表格，查看其余列。
| 文件 | 谁持有、用来做什么 | Mqttable 中如何配置 |
|---|---|---|
| ca.crt | 实验 CA 的公开证书，用来验证其签发的证书 | 放入 CA Certificate |
| ca.key | CA 的签发私钥，保留在签发方 | 不上传，不分发给客户端 |
| server.crt | Broker 的服务器身份，握手时发给客户端 | 通常不需要手动上传 |
| server.key | Broker 的配对私钥，只留在 Broker 一侧 | 不上传 |
| client.crt | mTLS 客户端的身份 | 放入 Client Certificate |
| client.key | 该客户端证书的配对私钥 | 放入 Private Key，只供该客户端使用 |
普通 TLS 需要客户端信任正确的 CA。mTLS 另外需要客户端自己的证书和私钥。生产环境应向 Broker 管理员或 PKI 管理人员取得材料；Mqttable 负责保存和使用凭据，不负责签发证书。
umask 077
mkdir -p certs
openssl req -x509 -newkey rsa:2048 -noenc -sha256 -days 7 \
-subj "/CN=Mqttable Port Lab CA" \
-addext "basicConstraints=critical,CA:TRUE" \
-addext "keyUsage=critical,keyCertSign,cRLSign" \
-keyout certs/ca.key -out certs/ca.crt执行后得到 certs/ca.crt 和 certs/ca.key。CA:TRUE 和签名用途标识这是一个 CA。7 天证书可能在界面显示“即将过期”，当前有效期内仍可使用。不要把实验 CA 安装到操作系统的全局信任库；Mqttable 的 Custom CA 可以只让这条 Broker 配置使用它。
openssl req -new -newkey rsa:2048 -noenc -sha256 \
-subj "/CN=localhost" \
-keyout certs/server.key -out certs/server.csr
cat > certs/server.ext <<'EOF'
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectAltName=DNS:localhost,IP:127.0.0.1
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
EOF
openssl x509 -req -in certs/server.csr \
-CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial \
-out certs/server.crt -days 7 -sha256 -extfile certs/server.ext最终证书覆盖 DNS:localhost 和 IP:127.0.0.1，客户端应使用其中一个地址连接。如果把 Broker 移到其他机器，需要重新签发包含实际域名或 IP 的证书；修改 Host 输入框不会修改证书。
CSR 是签发请求，不是最终证书。这里在 openssl x509 签发时明确传入 server.ext，把 SAN 和 serverAuth 用途写进最终证书。不能只填 CN，然后省略检查。OpenSSL 文档说明了 SAN 和扩展密钥用途。
openssl verify -CAfile certs/ca.crt -purpose sslserver certs/server.crt
openssl x509 -in certs/server.crt -noout -dates -ext subjectAltName
openssl x509 -in certs/server.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in certs/server.key -pubout -outform DER | openssl dgst -sha256预期看到 certs/server.crt: OK、两个 SAN，以及最后两行相同的公钥 SHA-256 摘要。比较的是公钥，不会打印私钥。再确认有效期与当前时间一致；不要从截图复制一份日后已经过期的证书。
仍在同一个实验目录执行。这里的 heredoc 结束标记没有加引号，是为了把 $PWD 展开成证书的绝对路径：
cat > mosquitto.conf <<EOF
persistence false
allow_anonymous true
listener 1883 127.0.0.1
protocol mqtt
listener 1884 127.0.0.1
protocol mqtt
listener 8883 127.0.0.1
protocol mqtt
certfile $PWD/certs/server.crt
keyfile $PWD/certs/server.key
tls_version tlsv1.2
require_certificate false
listener 8884 127.0.0.1
protocol mqtt
cafile $PWD/certs/ca.crt
certfile $PWD/certs/server.crt
keyfile $PWD/certs/server.key
tls_version tlsv1.2
require_certificate true
listener 9001 127.0.0.1
protocol websockets
listener 9002 127.0.0.1
protocol websockets
certfile $PWD/certs/server.crt
keyfile $PWD/certs/server.key
tls_version tlsv1.2
require_certificate false
EOF配置包含 1883/1884 的明文 MQTT、8883 的 TLS、8884 的 mTLS、9001 的 WS 和 9002 的 WSS。8884 Listener 已准备好验证后面生成的客户端证书。所有 Listener 都只绑定 127.0.0.1。
allow_anonymous true 是为了让本地证书实验不依赖 MQTT 密码配置，不会关闭 8884 的客户端证书要求。不能直接当作生产配置，这里也没有配置 Topic ACL。
普通 TLS 中，certfile 和 keyfile 提供 Broker 的服务器证书及私钥。mTLS Listener 的 cafile 告诉 Broker 信任哪个客户端证书签发方，require_certificate true 要求客户端必须提交有效证书。这个服务端 CA 用途，与 Mqttable 里的服务器信任设置不同。Mosquitto 配置手册说明了这些字段。
在这个终端启动：
mosquitto -c "$PWD/mosquitto.conf" -v预期看到 6 个端口的 Listener 启动信息，保留终端运行。出现 “Address already in use” 时，先确认端口由谁占用，不要不断重启重复进程。修改配置后，用 Ctrl+C 停止本次实验进程，再启动。证书权限问题不能用 chmod 777 解决。
本地实验可以复用两个 Broker 定义：Port Lab 用于明文 MQTT/WS，TLS Lab 用于 TLS/mTLS/WSS。修改协议、端口、Path 或 TLS 材料前先断开 Client，保存后重新连接；云端可以另建一个定义，不必给每个实验端口都保留新 Broker。
- 新建名为
TLS Lab的 Broker，协议选择 mqtts，Host 填 127.0.0.1，Port 填 8883。 - 保持验证服务器身份开启，服务器证书信任选择 Custom CA。
- 在 CA Certificate 中选择上传，上传
certs/ca.crt。也可以先在凭据页面添加 CA，标签填Ports Lab CA，然后在 Broker 表单选择已保存引用。 - **客户端认证（mTLS）**保持关闭，SNI 选择自动，ALPN 留空。
- 点击测试连接。本地匿名 Listener 应接受 MQTT 探测；保存 Broker，再添加并连接 Client。
CA 用来验证 Broker 的服务器证书。单独的连接测试结果证明 TLS 和 MQTT CONNECT，不能证明订阅者收到消息。
需要独立检查 TLS 时，在第二个终端进入实验目录执行：
printf '' | openssl s_client -connect 127.0.0.1:8883 -servername localhost \
-verify_ip 127.0.0.1 -CAfile certs/ca.crt -verify_return_error查找 Verification: OK 或 Verify return code: 0 (ok)。它没有发送 MQTT CONNECT，也没有验证 Topic 权限。消息验证仍需在 Mqttable 中先订阅，确认 SUBACK，再发布并对比发送、接收 PUBLISH。
普通 TLS 中，客户端验证 Broker；mTLS 中，Broker 还会验证客户端证书。服务器信任材料和客户端身份材料应分别配置。
在第二个终端进入同一实验目录，执行：
openssl req -new -newkey rsa:2048 -noenc -sha256 \
-subj "/CN=mqttable-lab-client" \
-keyout certs/client.key -out certs/client.csr
cat > certs/client.ext <<'EOF'
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature
extendedKeyUsage=clientAuth
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
EOF
openssl x509 -req -in certs/client.csr \
-CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial \
-out certs/client.crt -days 7 -sha256 -extfile certs/client.ext
chmod 600 certs/*.keyopenssl verify -CAfile certs/ca.crt -purpose sslclient certs/client.crt
openssl x509 -in certs/client.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in certs/client.key -pubout -outform DER | openssl dgst -sha256预期看到 certs/client.crt: OK 和两行相同的摘要。证书明确设置了 clientAuth 用途，不要拿 Broker 的 server.key 来当客户端私钥。
这里生成的是未加口令的实验私钥，通过文件权限限制访问。当前 Mqttable 会拒绝带口令加密的 PEM 私钥。如果组织提供的是加密私钥，应让管理员确认客户端可用的合规处理方式。不要把私钥原文写入终端记录、文章、截图或 MCP 参数。
- Broker 协议使用
mqtts，Host 填127.0.0.1，Port 填 8884。本实验中，这个端口对应require_certificate true的 Listener。 - 服务器验证保持开启，Custom CA →
ca.crt保持选中。 - 开启客户端认证（mTLS）。
- Client Certificate 上传
client.crt，Private Key 上传client.key，或分别选择对应的已保存引用。 - 保存 Broker、连接 Client，在
mqttable/ports/lab/mtls上完成同样的先订阅、后发布检查。
CA 验证服务器；客户端证书和配对私钥标识客户端。截图没有显示私钥原文。
Mqttable 把这些 TLS 材料绑定在 Broker 定义上，下面的 Clients 复用同一个证书身份。测试不同设备证书时，应分别配置 Broker 定义，不能只改 MQTT Client ID。
Client 表中的无认证指 MQTT 账号认证。本实验的 TLS Listener 仍会通过证书认证客户端；生产 Broker 是否还要求 MQTT 账号、允许哪些 Topic，需要按它的策略配置。
先收到成功的 SUBACK，再发布消息；Trace 中的发送、接收 PUBLISH 显示同一 Topic 和相同 payload。
再做一个负例：测试连接不配置客户端证书和私钥，仍保留正确 CA 和开启的服务器验证。实验的 8884 Listener 应拒绝连接。服务器证书验证成功后出现 “certificate required”，仍然是 mTLS 失败，不是安全连接成功。本轮 Mqttable 探测显示 Failed to send CONNECT: :closed；Mosquitto 日志确认没有收到客户端证书，OpenSSL 则报告 tlsv13 alert certificate required。单独一条连接关闭错误，不足以确定这个根因。
上面的 7 天 CA 只用于 loopback 实验。公网部署应向公共 CA 或组织认可的 PKI 取得覆盖真实 Broker 域名的服务器证书。Broker 的 certfile 应包含服务器证书在前、所需中间证书在后的证书链；keyfile 指向配对的服务器私钥，不向客户端分发。EMQX Listener 文档也说明了证书链顺序。
服务器使用公开可信的证书链时，客户端可以判断是否适用 System CA。私有 CA 场景应通过可信渠道分发指定的 CA Certificate/bundle，再配置 Custom CA。mTLS 场景另外给每个客户端分发自己的证书和私钥，并让 Broker 信任其签发方。通过 TLS 认证，不代表自动获得所有 Topic 的权限。
本文命令和 Mosquitto 配置使用 PEM。只看 .crt 或 .pem 后缀，不能判断它是 CA、叶子证书还是证书链。可以用下面的命令检查公开证书信息，不打印私钥：
openssl x509 -in certs/server.crt -noout -subject -issuer -dates -ext subjectAltName管理员提供 .p12/.pfx 包或加密私钥时，应按认可的流程取得受支持材料，不要把整个包随意上传到某个字段。确保 Broker 服务账号能读取证书和私钥，但不要让私钥对所有用户可读。生产环境还需要监控有效期并安排续期，不能直接复制这份匿名实验配置到公网。
本地实验的 WS 参数是：协议 ws，Host 127.0.0.1，Port 9001，WebSocket Path /mqtt。连接后重复消息闭环。WSS 则选择 wss，Port 9002，服务器验证开启，使用同一个 Custom CA，再重复检查。
WS 增加了 WebSocket 握手，但没有给本 Listener 加密。/mqtt 是本轮实际测试的 Path，不代表所有 Broker 都必须使用它。
WSS 同时需要正确的 WebSocket Path 和 TLS 设置。这组配置已通过连接测试。9002 是实验指定端口，不是统一的 WSS 标准端口。
接入服务商时，应填写它提供的准确端口和 Path。反向代理需要把 WebSocket Upgrade 转发给 WebSocket Listener，不能直接指向原生 MQTT/TCP Listener。HTTPS 页面也不应直接打开未加密的 ws 连接。
服务商通过 HTTPS 基础设施提供 WSS 时，443 很常见；但防火墙允许访问 443，不代表服务端或公司代理一定允许 WebSocket。应确认协议与组织策略，不要把 443 当成绕过网络管控的方法。
另一个例子是 AWS IoT：使用 X.509 认证的原生 MQTT 在 443 上要求 ALPN x-amzn-mqtt-ca。这里使用的是 MQTT/TLS，不是 WSS；其他认证方式的要求也不同。不能只看到 443 就把 Mqttable 协议改成 wss。
左右滚动表格，查看其余列。
| 观察到的结果 | 接下来检查 | 不要盲目改什么 |
|---|---|---|
| DNS 错误、超时、拒绝连接 | Host、DNS、Listener 进程、端口、防火墙、Docker/NAT 映射、Runtime 所在机器 | 证书不能修复尚未到达的 Listener |
| 连接立即关闭、协议错误 | mqtt/mqtts 是否错配，原生 MQTT 与 WS/WSS 是否混用 | 端口数字不会自动启用 TLS 或 WebSocket |
| Unknown CA、证书链验证失败 | CA/bundle 是否正确；服务端是否发送中间证书 | 不关闭服务器验证 |
| Hostname mismatch | Host 是否出现在证书 DNS/IP SAN 中 | 域名 SAN 不自动覆盖解析出的 IP |
| 证书过期、尚未生效 | 证书有效期、Runtime 和 Broker 的时钟 | 不关闭日期检查 |
| 要求或拒绝客户端证书 | mTLS 是否开启、客户端证书与私钥是否匹配、签发方是否受 Broker 信任 | CA 文件不能单独充当客户端身份 |
| MQTT CONNACK 拒绝认证 | Client 用户名、密码、账号状态、要求的认证方式 | TLS 已完成时，不继续盲目修改 CA |
| 已连接，但没有收到消息 | SUBACK、准确 Topic、ACL、QoS、No Local、订阅顺序 | CONNECT 成功不代表所有 Topic 都获准 |
| WS/WSS 出现 HTTP 404 或 Upgrade 失败 | Path、代理和 Listener 是否支持 WebSocket | /mqtt 不是通用固定路径 |
本轮故意使用错误 CA，TLS 验证按预期失败。应修正信任材料，保留服务器验证。
提交排障信息时，提供传输协议、脱敏的 Host/Port/Path、失败阶段、准确错误、版本，以及证书有效期和 SAN。不要提供密码、ca.key、server.key、client.key。公共 Broker 上不要订阅 # 来判断“有没有任何消息”，只使用自己的唯一测试 Topic。
可以把 Broker Listener 配置到另一个可用端口，并让客户端匹配。双方仍需使用相同协议。把明文 MQTT 从 1883 移到 1884，不会增加加密。
不一定。公开可信的服务器证书通常可以使用 System CA，不上传文件。私有 CA 通常需要额外配置 CA Certificate；只有要求 mTLS 时，才需要客户端证书和私钥。
账号可以认证 MQTT 客户端，但不会加密明文 TCP 连接。跨不可信网络时，应使用 TLS，并配置适当的 Topic 授权，不能只依赖密码。
需要证书覆盖该 IP，服务本身也允许这种连接方式。broker.example.com 的证书不会自动覆盖其解析出的 IP。云服务还可能依赖 SNI，优先使用提供的域名。
不能。它只证明被测试的连接阶段，不证明 Topic 授权或订阅者收到消息。应先订阅、确认 SUBACK，再向获准的 Topic 发布并检查接收 PUBLISH。
不需要。14567 是 EMQX 公共 Broker 的 QUIC Listener 例子。只有双方支持 QUIC、网络也允许对应 UDP 流量时才选择它。
下一次测试，可以直接拿自己 Broker 的连接信息，保持服务器验证开启，把一个获准 Topic 的消息链路走完。Mqttable Broker 与连接文档、TLS 文档、凭据文档和发布订阅文档说明了对应控件。第一次使用 MQTT 时，可以先按快速入门完成消息闭环。