Redis作为一款高性能的内存数据库，默认安装完成后是不需要任何密码就可以直接连接操作的。这种设计在本地开发和测试环境里确实方便，但一旦Redis实例暴露在公网或者不可信的网络环境中，就等于把数据完全敞开了。攻击者不仅可以读取全部数据，还能利用FLUSHALL命令清空数据库，甚至通过修改数据文件获取服务器权限。requirepass是Redis内置的密码认证机制，配置简单却能有效阻挡绝大多数未授权访问，是Redis安全加固的第一道防线。
requirepass的两种配置方式
设置Redis访问密码主要有两种途径：一种是修改配置文件后重启服务，另一种是通过CONFIG SET命令动态修改。两种方式各有适用场景，下面分别详细介绍。
第一种是配置文件方式。打开Redis的配置文件redis.conf，找到或新增一行requirepass配置，后面跟上你要设置的密码：
# 编辑配置文件 vim /etc/redis/redis.conf # 找到 requirepass 所在位置，取消注释并设置密码 requirepass YourStrong@Password123 # 保存后重启Redis服务 systemctl restart redis
重启完成后，再次连接Redis执行任何命令都会收到错误提示：(error) NOAUTH Authentication required。这说明密码已经生效，必须先认证才能操作。配置文件方式的好处是永久生效，即使Redis重启密码依然存在，适合长期稳定运行的生产环境。缺点是需要重启服务，会造成短暂的不可用。
第二种是命令行动态设置。如果不想重启服务，可以直接在redis-cli中执行命令：
# 连接Redis（此时还未设置密码） redis-cli # 动态设置密码，立即生效，无需重启 127.0.0.1:6379> CONFIG SET requirepass YourStrong@Password123 OK # 验证密码是否生效 127.0.0.1:6379> CONFIG GET requirepass (error) NOAUTH Authentication required. # 需要先认证 127.0.0.1:6379> AUTH YourStrong@Password123 OK 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) "YourStrong@Password123"
需要注意的是，动态设置只保存在内存中，Redis重启后密码就会丢失。因此推荐的做法是：先用CONFIG SET让密码立即生效，再同步修改redis.conf保证重启后依然有效，两者结合既不影响线上服务，又不会留下安全隐患。另外，CONFIG GET requirepass会直接回显密码明文，在生产服务器上操作时要避免被旁人看到屏幕内容。
客户端如何进行密码认证
密码设置完成后，所有客户端连接都需要先通过认证。redis-cli提供了两种方式，第一种是在连接时直接带上-a参数：
redis-cli -h 127.0.0.1 -p 6379 -a YourStrong@Password123 127.0.0.1:6379> PING PONG
使用-a参数虽然方便，但存在一个明显的安全问题：密码会出现在shell的历史记录中，通过history命令或者ps命令查看进程参数都有可能泄露密码。更推荐的做法是先连接再手动执行AUTH命令：
redis-cli 127.0.0.1:6379> AUTH YourStrong@Password123 OK 127.0.0.1:6379> PING PONG
在各类编程语言的客户端中，密码认证通过连接参数或连接字符串传入。以Python的redis-py库和Java的Jedis为例：
import redis
# Python客户端带密码连接
r = redis.Redis(
host='127.0.0.1',
port=6379,
password='YourStrong@Password123',
decode_responses=True
)
print(r.ping()) # 输出 True
import redis.clients.jedis.Jedis;
public class RedisDemo {
public static void main(String[] args) {
// Java客户端带密码连接
Jedis jedis = new Jedis("127.0.0.1", 6379);
jedis.auth("YourStrong@Password123");
System.out.println(jedis.ping()); // 输出 PONG
jedis.close();
}
}
如果代码中使用了连接池，只需在初始化连接池时配置一次密码，后续从池中取出的连接都会自动完成认证，不需要每次单独调用AUTH。
主从架构与集群中的密码问题
单机场景下配置requirepass比较直接，但一旦涉及主从复制或者哨兵、集群架构，密码的配置就有几个容易踩坑的地方。
首先是主从之间的认证。当master设置了requirepass后，slave节点在执行主从同步时也需要提供密码，否则会报错。这个密码通过masterauth参数配置。两边的配置关系是：master上设置requirepass管的是客户端访问，slave上设置masterauth管的是连接master做数据同步。常见的做法是master和slave同时设置requirepass和masterauth，且两个密码保持一致，这样无论后续角色如何切换，认证都不会中断：
# master节点配置 requirepass YourStrong@Password123 # slave节点配置 requirepass YourStrong@Password123 masterauth YourStrong@Password123
其次是哨兵架构。哨兵节点本身需要通过密码访问Redis实例，同时哨兵还要负责故障转移，切换后新的master也需要被哨兵以密码连接。因此哨兵配置文件中要加上sentinel指令形式的密码配置：
# sentinel.conf 中配置 sentinel monitor mymaster 192.168.1.100 6379 2 sentinel auth-pass mymaster YourStrong@Password123
如果哨兵没配置auth-pass，就会出现哨兵能监控到master但无法执行故障转移的情况，报错信息通常是NOAUTH。这是生产环境非常典型的问题，部署时一定要提前验证故障转移流程。
对于Redis Cluster集群，各节点之间通信同样遵循requirepass的设置，使用redis-cli创建集群时需要加上-a参数传入密码，各语言客户端的连接字符串中也统一带上密码即可，整体逻辑与单机一致。
requirepass之外的安全加固建议
需要明确一点：requirepass只能防止未授权访问，它并不是完整的安全方案。首先，密码在redis.conf中是明文存储的，任何能读到配置文件的人都能拿到密码，所以配置文件的权限要收紧，比如设置为600并仅限Redis运行用户可读。其次，密码本身的强度要够高，避免使用弱密码，因为Redis认证的验证速度很快，攻击者可以高速暴力尝试。
除了密码之外，还有几项加固措施建议一并落实。第一是绑定内网地址，在配置文件中设置bind 127.0.0.1或者内网IP，杜绝公网直接访问；如果确实需要远程访问，建议通过防火墙白名单限制来源IP。第二是修改默认端口6379，虽然这不是真正的安全手段，但能过滤掉大量低水平的自动化扫描。第三是保持protected-mode处于开启状态，这个模式在未设置密码且未绑定地址时会拒绝远程连接，是最后一层兜底保护。第四是禁用或重命名危险命令：
# 重命名高危命令，设置为空字符串表示完全禁用 rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command CONFIG "CONFIG_a1b2c3d4" rename-command KEYS ""
重命名CONFIG命令时要特别小心，因为这会影响你自己日常的运维操作和某些客户端框架的功能，重命名后的命令名要记牢。另外，Redis 6.0之后引入了ACL访问控制列表，支持为不同用户设置不同的用户名、密码和命令权限，比单一的requirepass精细得多，新项目可以直接使用ACL来替代。最后别忘了及时更新Redis版本，历史上多个严重的未授权访问漏洞都在新版本中修复，运行一个不再维护的旧版本本身就是风险。
总结来说，requirepass配置简单、见效快，是Redis安全的基础配置，但它只是纵深防御中的一环。把密码认证、网络隔离、权限收紧和版本更新结合起来，才能真正保障Redis实例的数据安全。
Redis密码认证requirepass配置Redis安全设置修改时间：2026-09-07 23:44:37