Redis以高性能和简单易用著称，但它默认的配置在安全方面相当宽松。FLUSHALL、FLUSHDB、CONFIG、KEYS这些命令如果被误用或者被攻击者利用，轻则造成线上服务卡顿，重则导致整个数据库被清空且无法恢复。本文主要讲解如何通过禁用和重命名危险命令的方式，配合其他安全措施，把Redis实例的风险降到可接受的水平。
为什么FLUSHALL是最危险的命令
FLUSHALL的作用是清空当前实例中所有数据库的数据，执行速度极快，一条命令下去，几十万条数据瞬间消失，而且Redis的持久化机制并不保证能完整恢复。更麻烦的是，这条命令本身不需要任何确认，语法就是简单的FLUSHALL，误触的概率并不低。
实际场景中这类事故并不少见。有的运维人员在生产环境连错了实例，本来想清理测试库，结果执行的命令落到了生产机器上；也有开发人员写自动化脚本时把清空操作写死在代码里，脚本一跑数据全没了。除了误操作，历史上有大量攻击事件都是利用Redis未授权访问漏洞，攻击者连上6379端口后直接执行FLUSHALL清空数据，再写入恶意内容实现进一步渗透。
与FLUSHALL类似的还有FLUSHDB，它清空的是当前选中的数据库。虽然影响范围小一些，但如果业务只用了db0，两者效果基本等同。另外KEYS命令虽然不删数据，但在生产环境大key量场景下执行会阻塞主线程，同样属于应该被严格管控的危险命令。
使用rename-command禁用或重命名危险命令
Redis提供了rename-command配置项，可以把某个命令重命名成一个新名字，也可以设置成空字符串让命令彻底失效。这是官方推荐的做法，配置写在redis.conf文件中即可。修改配置后需要重启Redis实例才能生效。
彻底禁用的写法如下，命令被设置成空字符串后，任何客户端调用都会直接报错：
# 编辑 redis.conf，在文件末尾添加以下配置 # 禁用FLUSHALL，任何调用都会返回错误 rename-command FLUSHALL "" # 禁用FLUSHDB rename-command FLUSHDB "" # 禁用CONFIG命令，防止攻击者修改dir等配置 rename-command CONFIG ""
如果业务确实需要这些命令，比如偶尔要做数据清理，更稳妥的方式是重命名，把命令改成一个只有少数人知道的复杂名字：
# 把FLUSHALL重命名为一个难以猜测的字符串 rename-command FLUSHALL fLuShAlL_9x8y7z_2024 # 把CONFIG重命名 rename-command CONFIG cOnFiG_a1b2c3 # KEYS也一样处理，避免误用导致阻塞 rename-command KEYS kEyS_q9w8e7
重命名后的命令在客户端调用时必须使用新名字，原来的FLUSHALL就不再有效。需要注意几个细节：第一，改名后自己团队的管理脚本、监控工具如果依赖原命令名，都要同步更新；第二，新名字不要写在代码里到处传播，最好只保留在受控的运维文档中；第三，如果使用了Redis Cluster，重命名命令必须在所有节点保持一致，否则集群管理命令会出问题。
验证配置是否生效很简单，重启后用redis-cli测试：
redis-cli 127.0.0.1:6379> FLUSHALL (error) ERR unknown command 'FLUSHALL' 127.0.0.1:6379> fLuShAlL_9x8y7z_2024 OK
只靠禁用命令还不够，多层防护必须配合
禁用危险命令只能堵住一部分风险，如果Redis本身暴露在公网上且没有密码，攻击者依然可以用SET写入数据、用SAVE落盘恶意文件。所以完整的防护方案需要多层配合。
第一层是网络隔离。配置文件中的bind指令只监听内网地址，配合防火墙限制6379端口的访问来源，只允许应用服务器所在的网段连接。这一点比任何命令级别的限制都重要，绝大多数Redis入侵事件都是因为实例直接暴露在公网。
# 只监听内网IP，禁止监听所有网卡 bind 192.168.1.10 # 关闭保护模式的替代方案是不安全的，保持开启 protected-mode yes
第二层是密码认证。通过requirepass设置强密码，客户端连接后必须先执行AUTH才能执行其他命令。密码要足够复杂，避免被简单字典爆破。如果用的是低版本Redis，注意配置文件中密码是明文存储的，要严格控制配置文件的读取权限。
第三层是权限与账号管理。Redis 6.0之后引入了ACL功能，可以创建不同用户并精确控制每个用户能执行的命令和能访问的key模式。相比全局重命名命令，ACL的粒度更细，比如可以给应用账号只开放读写命令，给运维账号开放管理命令，这是新版Redis更推荐的安全方案。
# Redis 6+ ACL配置示例 user appuser on >AppPassWord123 ~app:* +@read +@write -@dangerous user admin on >AdminPassWord456 ~* +@all
上面配置中，appuser只能访问以app:开头的key，只能执行读写类命令，dangerous类命令被显式禁止；admin则拥有全部权限。这种方式既不影响正常业务，又把危险操作限制在了少数管理者手中。
被清空后的补救与日常预防
即使做了各种防护，也要假设最坏情况会发生。如果开启了AOF持久化，且配置了appendfsync everysec，FLUSHALL会被记录成一条命令写在AOF文件末尾。这时候可以先停掉Redis，打开AOF文件删除末尾的FLUSHALL相关记录，再重启实例，之前的数据就能恢复。如果只有RDB快照，那么只能恢复到最近一次快照时的数据，中间的增量会丢失。
所以日常运维中要养成几个习惯：生产环境务必开启持久化并定期把RDB文件备份到异地；主从架构下确认从节点不会因为故障切换导致数据被主库的清空操作连带覆盖；给开发和运维人员做培训，让每个人清楚FLUSHALL这类命令的破坏力；关键操作前先执行DUMP或INFO确认连接的实例信息，避免连错环境。
总结一下，防护Redis危险命令的核心思路是：网络层先隔离，认证层加密码，命令层用rename-command或ACL限制高危操作，数据层靠持久化和备份兜底。这几层措施叠加起来，才能真正避免一条命令毁掉整个数据库的事故。
Redis禁用FLUSHALLRedis安全配置rename-command修改时间：2026-09-03 04:20:54