MQTT连接报错：Connection refused 详解

当MQTT客户端连接遭遇“Connection refused: not authorized”错误时，问题核心几乎总是服务端ACL（访问控制列表）配置不当或客户端认证凭据（如用户名、密码/Token、Client ID）与Broker安全策略不匹配；本文系统梳理了五大关键排查方向——从ACL规则是否精准放行客户端ID与主题权限、用户名密码是否符合Broker强制格式（如use-token-auth + access_token）、ACL功能是否真正启用并正确加载、Client ID是否被隐式禁止或遗漏授权，到深度解读Broker日志中的ACL拒绝详情——帮你快速定位根因、绕过试错盲区，高效恢复MQTT连接。

如果您尝试建立MQTT连接，但收到“Connection refused: not authorized”错误提示，则该问题通常与服务端ACL（访问控制列表）配置错误或客户端认证凭据不匹配直接相关。以下是针对此问题的多种排查与修复方法：

一、验证ACL规则是否允许当前客户端ID及主题权限

ACL机制用于限制客户端可订阅/发布的主题范围及操作类型。若Broker配置了ACL但未显式放行该客户端ID或其请求的主题，则会返回状态码5（Not Authorized）。需确认ACL文件中是否存在对应条目，并确保其语法格式正确、加载生效。

1、定位Broker的ACL配置文件路径，例如Mosquitto默认为acl_file /etc/mosquitto/acl.conf。

2、检查该文件中是否包含形如user client_id_abc的用户声明段落。

3、在该用户段下确认是否存在允许连接的规则，例如topic readwrite #或更精确的topic read sensor/+/temperature。

4、重启Broker服务使ACL变更生效：systemctl restart mosquitto。

二、核对客户端CONNECT报文中用户名与密码是否符合ACL匹配条件

部分Broker（如EMQX、ThingsBoard）要求用户名必须为特定格式（如use-token-auth），密码字段则必须严格等于设备级Token。若ACL基于用户名进行策略匹配，而客户端传入了空用户名、错误字符串或使用了API Key代替Token，均会导致拒绝授权。

1、确认客户端代码中username字段值是否为Broker明确要求的固定字符串，例如"use-token-auth"。

2、确认password字段是否为平台为该设备单独生成的access_token，而非应用级密钥或空字符串。

3、检查Broker日志中是否出现类似ACL check failed for user 'xxx', topic 'sensor/temp' 的记录，以定位匹配失败点。

三、检查Broker是否启用ACL功能且配置文件被正确加载

即使ACL文件存在并编辑正确，若Broker未启用ACL模块或配置路径错误，所有连接请求仍将绕过ACL校验，但某些场景下可能因默认拒绝策略触发Not Authorized响应。需确保ACL功能处于激活状态且路径无拼写错误。

1、打开Broker主配置文件（如/etc/mosquitto/mosquitto.conf）。

2、查找acl_file指令行，确认其值指向真实存在的ACL文件路径。

3、确认配置中未设置allow_anonymous true且未注释掉acl_file行。

4、执行mosquitto -c /etc/mosquitto/mosquitto.conf -t验证配置语法有效性，避免因格式错误导致ACL未加载。

四、比对客户端ID是否被ACL策略显式禁止或遗漏授权

ACL不仅可基于用户名，也可基于client ID进行细粒度控制。若Broker配置中存在pattern write $SYS/broker/connections/+类通配规则，但未覆盖实际使用的client ID格式（如缺少前缀d:或a:），则可能导致隐式拒绝。

1、提取客户端实际发送的CONNECT报文中的Client Identifier字段值。

2、在ACL文件中搜索该client ID是否出现在user或pattern语句中。

3、若使用pattern匹配，确认通配符+和#使用符合层级规范，例如sensor/+/data不匹配sensor/room1/humidity。

4、临时添加一条宽泛规则测试，例如user default后接topic #，观察是否仍报Not Authorized。

五、审查Broker日志中ACL匹配过程的具体拒绝原因

多数现代MQTT Broker（如EMQX、Mosquitto 2.0+）在ACL拒绝时会在日志中输出详细上下文，包括匹配的用户名、client ID、目标主题及最终决策依据。这是判断是否为ACL配错最直接的证据来源。

1、启用Broker调试日志级别，例如Mosquitto中设置log_type all并重启。

2、复现连接失败操作，立即查看最新日志行。

3、筛选含acl、auth、deny、not authorized关键字的条目。

4、定位到形如[ACL] Deny user 'device_001' access to topic 'control/cmd' (mode=2)的记录，确认拒绝源是否来自ACL模块。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~