Redis集群总线端口16379不校验密码，requirepass仅作用于客户端端口6379；其安全依赖绑定内网IP、显式配置cluster-announce-ip/port及防火墙严格限制访问源。
Redis集群总线端口（16379）不认密码，别指望requirepass拦住扫描
requirepass只校验客户端端口（6379），对集群总线端口（16379）完全无效。攻击者直连16379就能执行CLUSTER NODES、伪造心跳、触发故障转移——哪怕你所有节点都配了强密码，也拦不住。
常见错误现象：安全扫描工具扫出16379端口开放，返回完整节点列表；或日志里出现大量来自陌生IP的cluster meet请求。
-
requirepass必须写在配置文件中，且前后不能加引号；含$、@、#等字符时，命令行启动会截断，实际生效密码可能不对 - 某节点漏配或配错
requirepass，CLUSTER NODES会显示noauth，导致槽分配失败甚至集群不可用 - 集群模式下
protected-mode yes默认失效——只要配了bind或requirepass，它就自动退出，不拦截任何连接
真正起作用的三道硬防线：绑定 + 广播地址 + 防火墙
集群安全不是靠“设个密码”糊弄过去，得从网络层卡死入口。缺一不可。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 所有节点
redis.conf必须显式写bind 10.0.1.50（内网IP），绝不能留空、不能写bind 0.0.0.0或bind :: - 必须显式配置
cluster-announce-ip 10.0.1.50和cluster-announce-port 6379，否则节点可能广播公网地址，把攻击面重新暴露出去 - 防火墙规则要同时放行
6379和16379端口，且仅允可信内网IP访问；云环境优先用安全组，物理机用iptables或nftables
为什么代理层或bind 127.0.0.1挡不住集群攻击
把Redis绑到127.0.0.1再套一层反向代理，看似安全，实则失效——代理转发后源IP变成127.0.0.1，防火墙白名单形同虚设；而bind本身只控制TCP连接入口，不区分已连接客户端能发什么命令。
- 集群节点间通信依赖真实内网IP，
bind 127.0.0.1会导致节点无法互相发现，集群启动失败 - 即使你用HAProxy解析Redis协议做订阅级拦截，
PSUBSCRIBE因通配符特性极难稳定识别，且纯文本协议无固定包头，解析易出错 - 试图用
CLIENT LIST定时CLIENT KILL清理恶意连接，属于事后补救——连接已建立，输出缓冲区可能已被拖垮
升级到Redis 8.2.3并禁用高危命令
Redis 8.2.3修复了CVE-2025-62507（远程代码执行漏洞），必须升级。同时，rename-command要用于禁用真正危险的操作。
- 在配置文件中写
rename-command FLUSHALL ""和rename-command CONFIG ""，避免攻击者通过CONFIG SET dir写入webshell -
maxclients需按业务实际设上限（如maxclients 500），防止连接数耗尽导致拒绝服务 - 别忽略
mem_fragmentation_ratio监控——RSS内存可能比used_memory高30%~50%，maxmemory预留buffer不足会直接触发OOM Killer
