redis-cli 5.0.5 连接 Redis 6+ 时为何频繁报错“NOAUTH Authentication required”？

Question

**问题描述：** 使用 redis-cli 5.0.5（发布于2019年）连接 Redis 6.0+ 实例时，即使已通过 `-a` 参数指定密码或执行 `AUTH` 命令，仍频繁报错 `NOAUTH Authentication required`。根本原因在于：Redis 6 引入了**ACL（Access Control List）机制**，默认启用且要求显式认证；而 redis-cli 5.0.5 **不支持 Redis 6 的新认证协议流程**——它在连接后未自动发送 `AUTH` 命令（尤其在非交互模式下），且无法解析 Redis 6 返回的 `AUTH ` 多参数响应格式（旧版仅支持 `AUTH `）。此外，若服务端配置 `requirepass` 已被 ACL 取代（如仅配置 `user default on >mypass ~* &* +@all` 而未设 `requirepass`），旧客户端将因无传统密码字段而认证失败。该兼容性断层导致看似“已传密码”，实则认证请求未被正确识别或未及时触发。

Answer 1

```html

一、现象层：典型错误复现与日志特征

在生产环境中，运维或开发人员常执行如下命令：

redis-cli -h 192.168.1.100 -p 6379 -a "mypass" INFO

却持续收到响应：NOAUTH Authentication required。即使补发 AUTH mypass，仍报错；而改用 redis-cli --version 查得客户端为 redis-cli 5.0.5（2019年发布），服务端为 Redis 6.2.6 或更高版本。该现象在 Shell 脚本批量调用、CI/CD 流水线、Prometheus Exporter 等非交互场景中高频出现。

二、协议层：Redis 认证机制演进断点分析

维度	Redis ≤5.0（Legacy）	Redis ≥6.0（ACL Era）
认证触发时机	连接建立后自动发送 AUTH 命令（若 -a 存在）	必须显式发送 AUTH 命令；且支持多参数格式：AUTH <username> <password>
默认用户模型	单全局密码（requirepass）	ACL 用户体系，默认用户 default 需显式启用（on）并授权
响应协议兼容性	仅接受 +OK 或 -ERR，无结构化字段	返回 OK 或结构化错误（如 WRONGPASS），但旧客户端无法解析新协议握手帧

三、实现层：redis-cli 5.0.5 的三大兼容性缺陷

1. 缺失 ACL 用户上下文感知：源码中 cliAuth() 函数仅构造 AUTH <pass> 单参数命令，未适配 AUTH default <pass> 双参数语法；
2. 非交互模式下 AUTH 发送时机错位：在 redis-cli -a xxx COMMAND 场景中，5.0.5 在发送业务命令后才尝试认证（顺序颠倒），违反 Redis 6+ 的“先认证、后操作”强制策略；
3. ACL 初始化检测缺失：未主动查询 ACL LIST 或 ACL WHOAMI，导致无法动态判断是否需用户名参数，亦无法 fallback 到传统认证路径。

四、配置层：服务端 ACL 与 requirepass 的共存陷阱

当管理员执行如下 ACL 配置（常见于 Redis 6+ 官方推荐实践）：

ACL SETUSER default on >mypass ~* &* +@all

此时 requirepass 配置项已被废弃——若未显式保留 requirepass mypass，则旧客户端因无法匹配任何密码字段而彻底失能。该配置在 redis.conf 中不可见，仅存在于运行时内存，加剧排障难度。

五、诊断流程：四步精准定位法（Mermaid 流程图）

graph TD
  A[观察错误：NOAUTH] --> B{检查 redis-cli 版本？}
  B -->|≤5.0.5| C[确认不支持 ACL 认证协议]
  B -->|≥6.0.0| D[跳过客户端问题]
  C --> E[检查服务端是否启用 ACL？]
  E -->|CONFIG GET aclfile 或 ACL LIST| F[是否存在 default 用户且 on？]
  F -->|否| G[补充 requirepass 或修复 ACL]
  F -->|是| H[强制升级客户端或代理层]

六、解决方案矩阵：按环境约束分级落地

• 紧急止血（Runtime）：在 Redis 6+ 服务端临时启用向后兼容——在 redis.conf 中追加 requirepass "mypass" 并 CONFIG REWRITE；
• 中期治理（Deployment）：统一客户端基线——将所有 redis-cli 升级至 6.0.0+（推荐 7.0.15 或 7.2.5 LTS），其内置 --user default 参数与智能 AUTH 调度；
• 长期架构（Infrastructure）：引入协议网关层（如 redis-proxy 或 Envoy Redis Filter），在网关侧完成 ACL → Legacy 密码的协议翻译，解耦客户端升级节奏。

七、延伸思考：从 Redis ACL 看分布式系统协议演进范式

此问题本质是“协议语义升级未同步传播”的典型案例。类似断层亦见于 gRPC-Web（HTTP/2 → HTTP/1.1 适配）、Kafka SASL/SCRAM v2 协议变更、PostgreSQL 14+ 的 client_min_messages 行为变更等。它警示我们：基础设施组件的 API 兼容性承诺 ≠ 协议兼容性承诺；微小的 wire format 改动（如 AUTH 多参数）可能引发跨代际级联故障。资深工程师必须建立“协议栈纵深认知”——不仅知其然（怎么连），更要知其所以然（握手帧如何构建、状态机如何迁移）。

```