Redis ACL LOG 如何查看认证失败记录：用户名、来源地址与清空时机

Redis 服务出现间歇性登录失败时，先别急着改用户权限。用管理员连接执行 ACL LOG 1，通常就能看到最近一条事件的原因、用户名和客户端信息；如果记录已经确认完毕，再用 ACL LOG RESET 清空，避免旧事件干扰下一轮观察。

排查顺序可以固定为：制造一次可控失败，读取 ACL LOG 1，核对 reason、username 与 client-info，最后按维护窗口决定是否执行 ACL LOG RESET。

Redis ACL LOG 记录的到底是哪类事件

Redis 内置的 ACL LOG 命令可以直接查询最近的认证失败记录，每条记录都会对应存储尝试登录的用户名、客户端来源IP、触发失败的原因、发生时间戳这些字段，队列满了之后旧记录会自动覆盖，也可以手动调用参数主动清空全部日志。

ACL LOG 面向的是 ACL 安全事件。Redis 官方文档列出的典型情况包括 AUTH 或 HELLO 认证失败，以及用户试图执行被禁止的命令、访问被禁止的键或订阅被禁止的频道。它的价值在于把“谁失败了”和“为什么失败”放在同一条记录里。

先用一个可控失败验证日志链路

下面的实验不要直接在生产业务用户上做。准备一条临时连接，使用明确错误的凭据触发一次失败；示例中的用户名和密码是占位文本，不要替换成真实凭据。

AUTH audit-user wrong-password
ACL LOG 1

预期先看到 WRONGPASS，再看到一条数组回复。重点不是复制整段输出，而是确认 reason 为 auth，username 是本次连接提交的用户，object 通常指向 AUTH。

为什么还要看 client-info

username 只能说明哪个 Redis 用户参与了认证，不能单独证明请求来自哪台应用。事件中的 client-info 会带出连接 ID、地址、逻辑库、当前命令等客户端字段。把它和应用实例的连接池日志对照，才能判断是密码配置错误、连错实例，还是某个旧进程仍在反复重试。

用 count 缩小窗口，避免被旧记录带偏

默认调用会返回最近最多 10 条记录，日常只想确认刚刚发生的失败时，用 ACL LOG 1 或 ACL LOG 3 更容易阅读。Redis 文档说明这些条目按最近事件开始展示；同类事件还可能通过计数聚合，因此“看到一条”不一定代表只发生过一次。

ACL LOG 3

如果返回的是权限拒绝，把 reason 和 object 先记下来：命令拒绝回到用户的命令规则，键拒绝回到键模式，频道拒绝回到发布订阅频道规则。这里别急着给用户加上 +@all，先验证应用实际需要的最小命令集合。

什么时候可以执行 ACL LOG RESET

ACL LOG RESET 的作用是清空安全事件日志，返回 OK。它适合在已经记录证据、修复配置并准备重新观察时使用，不适合拿来掩盖尚未解释的失败。

ACL LOG RESET
ACL LOG 1

清空后立即读取通常没有可用的新条目；真正的验收动作是让修复后的应用完成一次正常认证，再确认没有新的 reason=auth。若仍有失败，优先按 client-info 找连接来源，而不是重复执行 RESET。

常见问题

ACL LOG 能替代 Redis 的所有审计日志吗？

不能。它聚焦近期 ACL 安全事件，适合快速定位认证和权限拒绝；需要长期留存时，应结合应用日志、网络入口和正式审计方案。

ACL LOG 1 为什么可能看见 count 大于 1？

同类事件可能聚合计数。count 是返回条目数量，不是失败次数总和。

执行 ACL LOG RESET 后能恢复旧记录吗？

不能把 RESET 当作可回滚操作。需要留证时先复制关键字段和时间，再清空。

收尾检查

一套够用的现场动作只有三步：用可控失败确认链路，读取 ACL LOG 1 并核对 reason、username、client-info，修复后观察新事件，确认无误再清空。这样既能保留定位依据，也不会因为旧记录堆积而误判。