rename-command仅是字符串映射，非权限控制，防误操作有效但防攻击无效；必须禁用flushall/flushdb，重命名config等高危命令，并配合protected-mode、requirepass和bind内网ip才能构建有效纵深防御。

redis.conf 中 rename-command 的真实作用边界

rename-command 不是权限控制，它只是字符串映射层的障眼法。命令名变了，但功能完全保留；一旦攻击者通过 CONFIG GET rename-command 或配置文件泄露得知新名字，照样能执行。Redis 7.0 的 ACL 系统才是正解，rename-command 仅适合防低级误操作或自动化扫描器的浅层识别。

哪些命令必须重命名或禁用（按风险排序）

以下命令在生产环境若未处理，极易引发数据清空、配置篡改或远程代码执行：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• FLUSHALL 和 FLUSHDB：禁用最稳妥，直接设为空字符串 rename-command FLUSHALL ""
• CONFIG：必须重命名，不能禁用（否则无法热重载配置），例如 rename-command CONFIG "cfg_9a2f"
• SHUTDOWN、DEBUG、MODULE：全部建议重命名，尤其 MODULE 在 Redis 7.0+ 支持动态加载，风险极高
• SAVE 和 BGSAVE：非必要不启用 AOF 时可禁用，避免阻塞主线程触发雪崩

重命名后如何验证是否生效

别只看配置文件改了就以为完事。必须连上实例实测：

• 用原命令名测试应返回 (error) ERR unknown command
• 用新命令名测试应能正常执行（如 cfg_9a2f GET port）
• 检查客户端连接池是否缓存了旧命令名 —— 某些 SDK（如 Jedis 4.x）会预编译命令字节码，重命名后需重启应用
• 注意 redis-cli 的自动补全仍显示原名，这是客户端行为，不影响服务端实际拦截

比重命名更关键的三件事

很多人花时间调 rename-command，却忽略真正起决定性作用的配置：

• protected-mode yes：Redis 7.0 默认开启，但若配置了 bind 或 requirepass，它会自动关闭 —— 必须显式确认为 yes
• requirepass 密码强度要够，且所有客户端连接字符串必须带 -a 或 AUTH，否则重命名毫无意义
• bind 必须明确指定内网 IP，绝不能留 bind 0.0.0.0 或注释掉，否则防火墙和重命名都形同虚设

重命名命令本身不难，难的是它永远只是纵深防御里最外一层。漏掉 protected-mode 开关、密码没生效、或者 bind 写错一个 IP，整个策略就归零。