ibm mq java客户端从v6升级至9.3后，原无认证配置的连接突然报mqrc_not_authorized（2035），主因是新版默认启用mqcsp身份验证；通过启用兼容模式可快速恢复旧版行为。
ibm mq java客户端从v6升级至9.3后，原无认证配置的连接突然报mqrc_not_authorized（2035），主因是新版默认启用mqcsp身份验证；通过启用兼容模式可快速恢复旧版行为。
在IBM MQ Java客户端v6时代，当应用未显式设置用户名/密码时，底层会发送一个空MQCSP（MQ Connection Security Parameters）结构，部分MQ服务器（尤其是较老版本或以兼容模式运行的队列管理器）会将其视作“匿名连接”，并允许通道（如SVRCONN）以默认系统用户（如Linux下的mqm）身份执行操作——这虽不安全，但在旧环境中“恰好可用”。
然而，自MQ v9.1起，IBM对连接认证逻辑进行了明确强化：新版MQ Java客户端（9.3+）默认启用MQCSP认证机制，即使应用代码未调用setUserId()或setPassword()，客户端也会构造并发送一个含空凭据的MQCSP结构。此时，若队列管理器启用了CHLAUTH规则、MCAUSER未显式配置，或CONNAUTH被启用，该空MQCSP将触发严格校验，最终拒绝连接并返回2035 MQRC_NOT_AUTHORIZED。
✅ 根本原因不是服务端变更，而是客户端认证行为的默认值变更——这是IBM文档中所指的“clarified authentication”。
解决方案：启用向后兼容模式
最轻量、非侵入式的修复方式是禁用MQCSP认证的自动启用，还原v6时代的连接行为。只需在JVM启动参数中添加：
<code class="bash">-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=N</code>
此系统属性强制客户端跳过MQCSP构造流程，回归使用传统（无凭证）连接方式，与旧版行为一致。
⚠️ 注意事项：
- 该配置仅影响Java客户端行为，无需修改MQ服务器配置（如
CHLAUTH、CONNAUTH或MCAUSER），适用于紧急上线场景； - 若应用后续需对接启用了强认证的队列管理器（如TLS+客户端证书场景），应为不同连接分别配置
MQEnvironment或MQConnectionFactory，避免全局关闭认证； - 长期建议：对无认证连接进行最小化加固，例如配置
MCAUSER('appuser')并限制该用户的对象权限，而非完全依赖网络层隔离； - 验证方式：启用客户端日志（
-Dcom.ibm.mq.cfg.traceFile=/tmp/mqtrace.log -Dcom.ibm.mq.cfg.traceLevel=3），确认日志中不再出现MQCSP相关构造记录。
通过这一单行JVM参数调整，即可在不改动业务代码、不重启MQ服务的前提下，立即恢复对旧MQ服务器的兼容访问，保障双环境（无认证 + TLS双向认证）并行支持，顺利推进产品发布。
