应执行redis-cli连接后运行FLUSHALL和CONFIG GET requirepass命令，若均返回“ERR unknown command”则确认禁用；需排除拼写错误、空格、多实例配置错位等问题。
Redis 被清空不是漏洞，是配置裸奔——禁用 FLUSHALL、CONFIG 等命令 + 强密码 + 内网绑定，三者缺一不可。
如何确认危险命令是否已被禁用？
改完 redis.conf 后必须验证，不能只靠“保存了就安心”。攻击者常利用未禁用的 CONFIG 命令动态开启 save 或写入 Webshell，比清库更隐蔽。
- 用
redis-cli -h 127.0.0.1 -p 6379连上后直接执行FLUSHALL，应返回(error) ERR unknown command `FLUSHALL` - 执行
CONFIG GET requirepass，如果返回(error) ERR unknown command `CONFIG`，说明CONFIG也已禁用 - 若仍能执行，检查配置文件里是否有拼写错误（如写成
rename-comand）、是否多加了空格、或是否改错了非主实例的配置文件（比如宝塔装了多个 Redis 实例）
requirepass 密码设置的实操陷阱
设了密码 ≠ 安全。很多用户用 requirepass 123456 或 requirepass redis123，结果被秒破；还有人把密码写在 shell 脚本里硬编码，等于贴在门上。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 生成密码务必用
openssl rand -base64 18 | tr '+/' '-_' | tr -d '\n'，避免含换行或 Base64 填充字符（如 =）引发解析失败 - 密码中不要出现
#或;，否则会被redis.conf当作注释截断（例如requirepass abc#def实际只生效abc） - 改完后检查
redis.conf文件权限：应为600（chmod 600 /www/server/redis/redis.conf），防止其他用户读取密码
bind 和 protected-mode 必须协同生效
单独开 protected-mode yes 没用——它只在没设密码且 bind 为空时起作用。一旦你配了密码，Redis 就默认信任所有来源，此时若 bind 0.0.0.0 还开着，公网扫描器连上就能执行命令。
- 必须把
bind行明确改成bind 127.0.0.1（最安全），或仅加内网段如bind 127.0.0.1 172.16.0.0/12，绝不能留bind 0.0.0.0或注释掉整行 - 删掉配置里所有形如
# bind 0.0.0.0的注释行，防止误启——宝塔某些模板会偷偷带这种“默认开放”注释 - 重启后立刻从外网测试：
telnet your-server-ip 6379应超时或拒绝连接；本地用redis-cli ping必须返回PONG
重命名 vs 彻底禁用危险命令
有人觉得“重命名 FLUSHALL 成 FLUSHALL_BAK 更灵活”，但实际等于留后门——只要攻击者拿到配置文件或通过 CONFIG GET（若没禁用）查到新名字，照样清库。
- 禁用写法必须是
rename-command FLUSHALL ""，引号间**不能有空格**，否则 Redis 启动失败 - 禁用列表建议至少包含：
FLUSHALL、FLUSHDB、CONFIG、DEBUG、KEYS、MONITOR - 别碰
EVAL和SCRIPT——除非你业务真用 Lua 脚本，否则一并禁用可防更多 RCE 链路
真正容易被忽略的是：宝塔面板里改完配置点【保存】后，很多人忘记点【服务】→【重启】，或者重启了但没验证。Redis 不像 Nginx，改配置不重启=白改。另外，如果你用 Docker 或自建脚本启 Redis，这些配置项全得手动塞进启动参数里，宝塔的修改对它们无效。
