Redis ACL 权限怎么排查：ACL GETUSER、命令类别与最小授权验证

Redis 从“大家共用一个密码”切到 ACL 用户后，最常见的故障不是密码错，而是用户能正常登录，却没有访问目标 key 或执行目标命令的权限。线上看到 NOAUTH Authentication required、WRONGPASS 或 NOPERM 时，先把认证状态、用户可用性、命令类别和 key 匹配规则分开梳理，排查速度会快很多。

排查 Redis ACL 时，先确认当前连接实际登录的是哪个用户名，再检查该用户是否启用、允许哪些命令类别和 key 模式，最后用只读测试验证规则有效性；不要直接给业务用户加上全部命令权限。

先分清是认证失败还是授权失败

Redis 客户端报出错误的第一步不是直接复制粘贴一条全权限配置，而是判断请求卡在权限校验的哪一层。

这三类错误的处理方向完全不同。把 NOPERM 当成密码错误，会反复修改密钥做无效尝试；把 NOAUTH 当成命令权限问题，则会在还没登录成功时反复调整 ACL 规则。

用 ACL WHOAMI 和 ACL GETUSER 还原当前权限

管理员连接 Redis 后，先确认当前操作的身份：

ACL WHOAMI
ACL GETUSER report_reader

ACL WHOAMI 返回当前连接的用户名。应用使用连接池时，这一步尤其重要：配置文件看起来已经改过，连接池里留存的旧连接可能仍然在使用旧用户身份。

ACL GETUSER 返回用户是否启用、是否设置密码、允许的命令类别、被排除的命令，以及允许访问的 key 模式。重点关注四个字段：

• flags：是否包含 on，是否有只读等基础限制。
• passwords：认证规则是否已经正确配置。
• commands：允许和拒绝的命令或命令类别范围。
• keys：业务 key 的匹配范围。

例如用户只允许 +@read，访问 cache:product:1 仍可能失败，因为命令类别校验和 key 模式校验是两道独立的门槛。

命令类别和 key 模式要同时对上

一个报表用户通常只需要读取 report: 前缀下的 key，可以按这个思路配置测试用户：

ACL SETUSER report_reader resetkeys on +@read ~report:*

这条规则的含义是清空旧的 key 规则、启用用户、允许全部读命令，同时把 key 访问范围限制为 report: 开头的资源。实际生产配置还要结合运行版本、客户端命令实现和业务读写方式核对，不能只看一条规则“看起来合理”就直接上线。

如果业务需要写入报表缓存，再针对具体命令单独增加写权限，同步单独评估删除、脚本、配置和管理类命令的开放必要性。命令类别适合快速起步，但它覆盖的范围可能比业务实际需要更宽，发布前应通过调用清单逐项收窄权限边界。

用 ACL CAT 和 ACL LOG 找到被拒绝的具体动作

不确定某个命令属于哪个类别时，可以直接查询官方命令类别列表：

ACL CAT read
ACL CAT write

这能帮助你把“应用需要调用什么操作”直接翻译成符合 Redis 规范的权限规则。不要凭命令名字猜测所属类别，尤其是带有删除、脚本、管理含义的命令。

权限拒绝发生后，再查看 ACL 日志，通常能直接看到被拒绝的用户名、触发的命令和目标 key。日志适合定位真实请求，但不应把包含用户信息的内容直接贴到公开文章、工单或公共聊天中。线上排查只保留必要字段，完成后清理调试输出。

修改 ACL 前后的验证顺序

先创建或选择完全隔离的测试用户，用应用实际使用的用户名和 key 前缀做全流程验证：

1. 使用测试用户登录，执行 ACL WHOAMI 确认登录身份正确。
2. 读取一个允许范围内的 key，确认操作正常返回。
3. 读取一个不允许前缀的 key，确认得到权限拒绝提示。
4. 执行业务不需要的写入或管理命令，确认操作仍被拦截。
5. 让应用新建连接，确认连接池没有保留旧的认证状态。

验证时不要拿生产业务 key 做破坏性试验。读路径可以使用专门的测试 key；写权限则通过代码审查、命令清单和隔离实例共同确认合规性。

默认用户和回滚边界

修改默认用户是高风险动作。它可能影响仍在使用旧密码的脚本、监控、备份任务和临时运维连接。更稳妥的迁移顺序是先创建新用户，完成应用灰度验证，再逐步收紧旧用户的权限，最后才考虑禁用旧入口。

每次 ACL 变更都应保留变更前后的规则快照、操作人、操作时间和对应的回滚命令。回滚不是简单地“恢复一个密码”，还要同步恢复 flags、commands 和 keys 三组权限配置。

相关问题

能登录 Redis 但不能 GET，通常是什么原因？

优先检查当前用户是否允许执行读命令，以及目标 key 是否匹配系统允许的模式。认证成功只说明身份校验通过，不代表所有业务资源都可以直接访问。

只加 +@read 就够了吗？

不够。还要配置对应的 key 访问模式，并确认客户端实际调用的命令确实属于被允许的类别范围。

ACL 权限改完为什么应用还报旧错误？

检查连接池是否复用了旧连接，滚动重建连接后再用 ACL WHOAMI 和一个测试 key 验证规则是否已经生效。

最后的判断

Redis ACL 的难点不在于记住几条配置命令，而在于把身份、命令和 key 三件事拆开独立验证。先定位错误层级，再读取用户实际生效的规则，最后用最小权限测试和可回滚变更完成上线，通常比临时放开全部权限更省时间。