Redis主从认证必须同时配置主节点密码认证、从节点凭据携带和网络层隔离三者；仅设requirepass或masterauth均失败，主节点需启用强密码或ACL并禁用default用户，从节点masterauth须严格匹配且静态写入配置，同时绑定内网IP、限制防火墙、开启replica-read-only。
必须同时配置主节点密码认证 + 从节点凭据携带 + 网络层隔离，三者缺一不可；只设 requirepass 或只配 masterauth 都会失败。
主节点必须启用 requirepass 并禁用默认访问
主节点不设密码，从节点即使配了 masterauth 也无意义——它根本不会被校验。但设弱密码或全局密码（如 requirepass redis123）等于裸奔。
- 在
redis.conf中启用强密码：requirepass YourStrongPass!2026（长度 ≥12，含大小写字母、数字、符号） - 若使用 Redis 6.0+，强烈建议改用 ACL 替代
requirepass：ACL SETUSER replicator on >p@ssw0rd ~* +replconf +psync +ping -@all - 立即禁用默认用户：
ACL SETUSER default off nopass -@all，再执行ACL SAVE持久化 - 切勿保留
protected-mode no或bind 0.0.0.0，否则密码形同虚设
从节点必须正确设置 masterauth，且格式匹配主节点认证方式
masterauth 不是客户端登录密码，而是从节点向主节点发起复制握手时自动携带的身份凭证。填错、大小写不符、重启未持久化，都会导致日志反复出现 NOAUTH Authentication required，状态卡在 connecting。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若主节点用
requirepass：从节点配置masterauth YourStrongPass!2026（必须完全一致） - 若主节点用 ACL 用户
replicator：从节点配置masterauth "replicator:p@ssw0rd"（带引号，用户名+冒号+密码） - 静态写入配置文件最可靠；运行时设置需配合
CONFIG REWRITE，否则重启失效 -
masterauth只作用于复制连接，不影响从节点自身是否需要密码访问
绑定地址 + 防火墙 + replica-read-only 是最后一道防线
即使密码和 ACL 都正确，若主节点监听 0.0.0.0 且防火墙放行所有 IP，攻击者仍可暴力尝试密码、拉取 RDB 文件、甚至利用漏洞发起 RCE（如 CVE-2025-62507）。
- 主节点
bind必须限定为内网 IP，例如：bind 192.168.10.10（多网卡可用空格分隔） - 云服务器务必在安全组中仅放行从节点 IP 访问主节点
6379端口 - 从节点显式开启只读：
replica-read-only yes（Redis 7 默认开启，但显式声明更稳妥） - 主节点禁用危险命令：
rename-command FLUSHALL ""，避免从节点被攻陷后反向污染
验证通信是否真正安全，不能只看 INFO replication
role:slave 和 master_host 正确，只说明复制链路通了；不代表通信加密或防窃听——Redis 主从本身不加密传输，所有数据（包括 RDB 和命令流）都是明文。
- 检查
INFO replication中slave_read_only:1和master_link_status:up同时为 true - 抓包验证：在主节点执行
redis-cli set test 123，用tcpdump -i any port 6379 -A在中间节点捕获，确认 RDB 和命令内容是否明文可见 - 若合规要求传输加密，必须前置 TLS 代理（如 stunnel）或改用支持 TLS 的 Redis 发行版，原生 Redis 7.0 不支持
最容易被忽略的是：masterauth 值在 ACL 场景下必须带用户名前缀，且双引号不能丢；而生产环境里，很多人把 bind 和防火墙当成“以后再配”，结果密码再强也挡不住端口暴露。
