很多人把 Redis 装好就当作一个普通内存数据库直接开始set/get完全没意识到默认状态下 Redis 是没有访问控制这道门的。等到线上环境被挖矿脚本扫到、数据被 flush 掉或者某个小伙伴用keys *把生产库掏了个底朝天才想起来问“Redis 怎么设置密码”。这篇就专门把这件事讲透从配置文件到命令行、从 Windows 到 Docker、从单机到主从复制连带可视化工具连接一次讲清楚。这篇内容适合正在学习 Redis、刚接手项目需要加固缓存服务、或者已经被 Redis 安全坑过一回的开发者。看完你至少能独立完成 Redis 的密码认证配置并且知道为什么有些坑明明设置了密码还是被绕过。1. 为什么要给 Redis 设置密码搞懂它的访问控制机制很多人以为 Redis 设置密码就是“加个密码防止别人连接”这句话对但不完整。Redis 的密码机制几乎是唯一一层应用层防线配置项少、规则简单但如果理解错了容易配置了也等于白配。1.1 默认配置下 Redis 为什么是“裸奔”状态Redis 的默认配置里requirepass是空的这意味着任何知道 IP 和端口的人只要能通过网络访问到 6379 端口都可以直接连接执行命令。更麻烦的是Redis 默认监听0.0.0.0:6379如果你没改 bind 配置那就是对全网开放。这不是 Redis 设计上的疏忽而是它在设计时假设运行在可信内网环境。但现实是很多人图省事直接把 Redis 部署在云服务器默认配置上只靠云防火墙“硬扛”。一旦防火墙规则配置失误Redis 就变成了一个不设防的数据库攻击者可以执行flushall清库也可以通过CONFIG SET dir配合dbfilename写入文件甚至结合其他漏洞实现命令执行。这类事件里最常见的初始入口就是“Redis 未授权访问”。所以设置密码的第一个目的不是“防熟人”而是防住那些扫描全网 Redis 端口的自动化脚本。密码不需要多复杂只要别用空口令、别用123456就能挡掉 90% 以上的扫描流量。1.2 Redis 密码验证的工作方式requirepass 与 AUTHRedis 的密码机制核心就是一个配置项requirepass一串字符串。设置之后客户端每次连接都需要在发送任何数据读写命令之前先发送AUTH password命令完成验证。Redis 服务端收到AUTH命令后会做一次常量时间的字符串比较如果匹配就返回OK否则返回-ERR invalid password。这个验证状态跟连接绑定也就是说每个连接都需要验证一次Redis 不会因为某个连接验证过就放行其他连接。连接池里的连接在长连接复用场景下必须保证第一次连接没跑业务命令之前就完成 AUTH。另外Redis 6.0 引入的 ACL 功能比单纯的requirepass强大得多可以不只设一个密码还能细分到命令、键空间权限。不过 ACL 依赖用户系统配置文件写法也更复杂。大多数中小项目并不需要那么细的权限划分设置一个requirepass就能解决“不让别人乱连”的核心诉求。后面我们会提到 ACL 的适用场景但主力还是传统密码。2. 实操设置 Redis 密码的两种主流方式设置密码没有太多花哨两条路改配置文件和命令行动态改。我平时推荐第一种因为重启后依然有效第二种只适合临时调试或在线改配置。两者原理一样都是操作requirepass。2.1 方式一修改 redis.conf永久生效找到 Redis 安装目录下的redis.conf打开后搜索requirepass。默认情况下这一行是被注释掉的或者显示为# requirepass foobared。改成以下内容requirepass YourStrongPassword2024注意一个细节字符串里不需要加引号。如果密码里包含特殊字符比如!、#、$这些一定要小心。#在配置文件里是注释符号密码如果以#开头后面内容会被当成注释失效。我的建议是密码尽量只用字母、数字以及少数安全符号比如-、_、避开#和空格可以少踩很多解析的坑。保存后重启 Redis。用你自己的方式启动服务比如 Linux 下如果是systemctl restart redis或者redis-server /path/to/redis.conf。验证是否生效redis-cli -h 127.0.0.1 -p 6379 ping没有密码时会返回NOAUTH Authentication required。此时再执行redis-cli -a YourStrongPassword2024 ping注意-a参数会把密码明文显示在进程列表里存在安全隐患。更稳妥的方式是不带密码连接然后手动 AUTHredis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379 AUTH YourStrongPassword2024 OK 127.0.0.1:6379 ping PONG2.2 方式二命令行 CONFIG SET 临时设置如果你不想重启 Redis可以连上客户端后直接执行redis-cli 127.0.0.1:6379 CONFIG SET requirepass AnotherPassword这只对当前运行的实例生效不会写入配置文件。一旦 Redis 重启密码就没了又回到裸奔状态。它适合验证密码配置、临时保护一下或者为了在不停机的情况下将重启后要用的密码预先设好。这里还有一个小技巧如果你已经设置了密码但忘了又想临时再改一个前提是你必须知道旧密码。因为CONFIG SET requirepass这个操作本身也要经过 AUTH 认证。如果旧密码不知道只能通过修改配置文件重启或者找到配置备份来绕过不存在“知道 IP 就能免认证改密码”的漏洞除非你连的是本机且没有保护。CONFIG SET方式还有一个隐藏缺点它会在运行时修改内存配置如果你所在的 Redis 开启了appendonly或者你之后通过CONFIG REWRITE写入配置文件这个密码也会被写进去。但CONFIG REWRITE会把其他动态配置一并刷新改坏了不好定位所以我还是建议正式环境用改配置文件的方式。2.3 密码设置后客户端连接会发生什么变化设置密码后最直接的体感就是以前一把梭的连接命令全部失效。拿最常用的客户端举例。Redis 命令行客户端不带密码连接后收到的错误是NOAUTH Authentication required。Python 的redis-pyimport redis r redis.Redis(host127.0.0.1, port6379, passwordYourStrongPassword2024) r.set(foo, bar)如果密码正确一切照旧如果密码不对会抛redis.exceptions.AuthenticationError。Java 的 Lettuce 客户端RedisClient redisClient RedisClient.create(redis://:YourStrongPassword2024127.0.0.1:6379);Spring Data Redis 则在application.yml里设置spring: redis: host: 127.0.0.1 port: 6379 password: YourStrongPassword2024需要特别提醒很多框架的连接池会提前创建大量连接如果密码配置错误启动时不会立刻报错而是在第一个请求触发连接创建时疯狂报错。这类问题排查时优先检查密码是否包含特殊字符、是否被 URI 编码吃掉。比如密码里有符号在redis://:passwordhost这种 URI 里就要转义为%40否则 Redis 连接串会把密码中的当成分隔符解析直接错乱。3. 覆盖热门场景Windows、Docker、主从复制、可视化管理工具设置密码这件事在不同环境下有一点细微差别。接下来把大家问得最多的几个场景一次讲明白。3.1 Windows 安装 Redis 后如何设置密码Windows 下 Redis 有两种常见来源官方虽然不提供 Windows 版但微软维护过一个旧版本分支社区也流行 tporadowski 编译的 5.x 版本。无论哪种配置文件通常叫redis.windows.conf或者redis.conf。打开这个文件同样搜索requirepass按上面的方法改。注意 Windows 下 Redis 服务启动方式可能是直接双击redis-server.exe也可能是已注册为 Windows 服务。如果注册成服务改完配置文件后需要重启服务。以管理员身份打开 PowerShell 或 CMDnet stop redis net start redis或者直接Restart-Service Redis。我遇到不少人在 Windows 上用 Redis 时配置文件名称记不住直接拿别人的连接串去连结果总是 Connection refused。Windows 下启动命令如果不带配置文件路径Redis 会加载默认配置即无密码配置你在redis.windows.conf里改的密码根本没生效。所以无论是哪种启动方式一定要确保启动命令里指定了你改过的配置文件或者手动在服务属性里确认参数。还有一个 Windows 特有问题Redis 5.x 在 Windows 上默认是没有后台运行这个概念的你用redis-server.exe redis.windows.conf启动后命令窗口不能关。改密码时务必先关掉旧进程否则端口被占用新配置无法加载。3.2 Docker 容器里 Redis 设置密码的正确姿势Docker 部署 Redis 是现在最流行的方式尤其是新版 Redis 还带 Redis Stack 扩展。用容器跑 Redis 时官方镜像推荐用命令行参数启动而不是进入容器改配置文件。最直接的方法是在启动命令里加--requirepassdocker run -d --name redis \ -p 6379:6379 \ -v /myredis/conf/redis.conf:/etc/redis/redis.conf \ redis:7.2 redis-server /etc/redis/redis.conf --requirepass MyPass123不过我更建议在本地先写好配置然后挂载进容器因为用--requirepass这种参数会被docker inspect看到明文如果容器被分享给别人密码也就公开了。挂载配置文件的写法如下先在宿主机创建一份/data/redis/redis.confbind 0.0.0.0 protected-mode yes port 6379 requirepass MyPass123然后启动docker run -d --name redis \ -p 6379:6379 \ -v /data/redis/redis.conf:/etc/redis/redis.conf \ redis:7.2 redis-server /etc/redis/redis.conf注意容器内的 redis 用户权限和文件权限偶尔会导致配置无法读取如果你发现容器启动后密码没生效先检查挂载配置文件是否只读权限改成 644 即可。另外如果用的是 Docker Compose也一样services: redis: image: redis:7.2 container_name: redis ports: - 6379:6379 volumes: - ./redis.conf:/etc/redis/redis.conf command: [redis-server, /etc/redis/redis.conf]很多人会忽略 Docker 默认网络模式。如果你在容器里通过redis-cli连接同一个网络里的其他容器或宿主机也需要带密码没有例外。3.3 主从复制和哨兵/集群模式下密码配置要三处联动主从复制场景比单机稍微绕一点。主库设置了requirepass从库同步时也要用密码去连接主库。如果只给主库加密码从库没配从库重启后无法自动复制数据。从库配置文件里需要加两项masterauth master-password replicaof master-ip master-port如果主库和从库都有密码从库自己的requirepass仍然可以有masterauth和requirepass是两个独立配置。masterauth是从库连接主库时用的密码requirepass是别人连接从库时要输入的密码两者可以相同也可以不同。Redis 哨兵模式里除了每个 Redis 节点需要配置requirepass和masterauth哨兵本身也建议设置密码否则哨兵之间通信没有保护。Sentinel 配置文件里需要设置sentinel auth-pass master-name password。到了 Redis Cluster 集群情况又进一步。官方要求所有节点执行CONFIG SET masterauth password以及CONFIG SET requirepass password而且这两项必须同步设置到每个节点。如果用 Redis Cluster 的redis-cli --cluster create创建集群带上密码参数比较麻烦常见做法是先创建集群再逐台节点CONFIG SET。不过这种操作只在内存中生效必须补一条CONFIG REWRITE持久化到配置文件。我实际维护过的主从复制环境里最坑的不是密码设置而是主从切换后新主库如果没配置masterauth所有从库都会卡在握手阶段。所以建议无论当前是不是主库每一台 Redis 都加上masterauth和requirepass并且统一密码省得换主后抓瞎。3.4 可视化客户端怎么连接Redis Desktop Manager 与其他工具很多初学者习惯用一个可视化工具看键值最常被问到的是 Redis Desktop ManagerRDM以及它之后出现的 Another Redis Desktop Manager。先说 RDM 老版本。它连接 Redis 时在连接设置界面填写 Host、Port 和 Password 即可。如果你设了密码Auth 那一栏就是必填的。它的连接串格式类似redis://:passwordhost:port填入时注意密码不要带空格。Another Redis Desktop Manager 是开源替代品界面更现代连接方式类似。记住几个常见错误提示NOAUTH Authentication required表示你根本没填密码或者填的位置不对。ERR invalid password表示密码本身错误。Connection refused可能是端口没开、bind 限制了连接来源或者密码虽然对了但 Redis 没监听在你填的 IP 上。另外很多人喜欢用命令行redis-cli -a password --no-auth-warning去验证。这个写法没什么问题只是--no-auth-warning会隐藏掉明文密码警告但进程列表仍然能看到所以我还是建议日常验证用交互式 AUTH。4. 安全加固设置密码之后还该做哪些事才不算白设密码不是保险箱只是第一道锁。设置完密码后还需要结合 Redis 自身特性和部署环境把其他几个风险点一起堵上。4.1 密码选型策略与配置文件权限保护Redis 的requirepass对密码强度没有硬性要求甚至设一个八位纯数字都能通过。但我不建议这么做。Redis 密码是明文存储在配置文件里的如果真的被拖配置整个密码体系就崩塌了。推荐一个实践原则密码长度至少 16 位混合大小写字母、数字和符号。避免使用键盘顺序、常见短词组合。每半年定期更换一次密码尤其是有人离职时即换。配置文件redis.conf的权限改为仅当前用户可读写chmod 600 redis.conf。如果是容器环境不要将宿主机文件权限放得过大同时避免把docker-compose.yml提交到公开仓库否则密码跟着一起抛头露面。设置密码后别忘了检查protected-mode配置。Redis 的protected-mode默认是 yes作用是没有密码时只允许本机访问一旦设置了requirepass但同时又配了bind 0.0.0.0protected-mode 的效果会被削弱。安全上要求同时设置密码和合适的 bind二者不是互斥的。再提一句 ACL。Redis 6 如果业务上需要多个应用共用同一个 Redis又想互相隔绝键空间不要拿requirepass搞多层密码因为requirepass只有一个全局密码。这种情况可以考虑给不同应用创建不同用户并分配不同密码和权限。比如给应用 A 一个只读用户、给应用 B 一个只能操作特定前缀键的写用户配置写在redis.conf里user readonly on readonlyPassword ~cached:* get mget exists user writeonly on writePassword ~app1:* set get不过 ACL 会引入更复杂的排障成本普通小项目先用好全局密码就足够了。4.2 网络层访问控制bind、防火墙与 iptables密码本身防君子不防小人如果线下已经有人拿到密码或者密码太弱被爆破Redis 依然可能沦陷。所以网络层的封堵比密码更早、更有效。最核心的配置是bind。默认情况下 Redis 会监听所有网卡也就是*。你需要在redis.conf里明确指定只监听内网 IP 或回环地址bind 127.0.0.1 192.168.1.100如果没有特殊需求生产环境最简单的写法就是只绑定本机和内网专用 IP。云服务器上除了操作系统防火墙放行来自特定来源 IP 的 6379 端口还应该检查云平台安全组规则。注意安全组方向要分清入方向规则不要写 0.0.0.0/0指定业务来源网段即可。如果你用容器部署-p 6379:6379会把容器端口直接映射到宿主机所有网卡这种情况下 Redis 服务本身接收到的连接来源是宿主机的网关bind 内网 IP 与否都需要结合网络拓扑仔细测试。有条件就把 Redis 放内网不要暴露公网。4.3 常见错误排查NOAUTH 与 invalid password设置完密码之后连接报错是高频问题。把最常见的两类错误和成因列出来错误信息可能原因怎么办NOAUTH Authentication required客户端没发 AUTH 命令命令行交互先执行 AUTH或代码里配置 password 参数ERR Client sent AUTH, but no password is setRedis 实例没有配置 requirepass但客户端发了 AUTH检查配置文件是否被正确加载、是否有多个 redis.confERR invalid password密码输入错误确认密码里没有多余空格、特殊字符是否走了 URL 编码WRONGPASS invalid username-password pairRedis 6 使用了 ACL 用户但错误用户访问是先去除用户名只发 AUTH 密码或验证明体配置的用户名密码Connection refused端口未开、bind 限制或保护模式检查 systemctl status、netstat 或 docker logs排查顺序也很关键。先确认 Redis 进程运行正常再看配置加载路径是否为实际运行路径然后用本机回环地址验证 AUTH最后排查防火墙。很多人直接上来换密码却忽略了第一条redis-server启动时根本没加载你改过的配置文件。5. 忘了密码如何重置以及一些长期经验这部分没有太多高深技术但非常救命。5.1 忘记密码了怎么重置 Redis 密码既然密码写在配置文件里理论上我们可以临时绕过密码认证直接改回来。最可行的方案停掉 Redis在启动时取消密码认证等拿到权限后再重新设置。以 Linux 为例。先停掉 Redissystemctl stop redis然后用临时配置文件启动或者直接启动一个无认证的实例。为了不影响原数据最好不要直接跑默认配置而是在配置文件外追加--requirepass 或者指定一个只包含基础设置的新配置文件。更稳妥的办法是在原配置文件里临时屏蔽requirepass行启动并完成修改后再恢复。启动后用 redis-cli 连接此时因为没有密码可以执行redis-cli CONFIG SET requirepass NewPass2024 CONFIG REWRITECONFIG REWRITE会将当前内存中的配置写回 redis.conf包括新的密码。此时原配置文件里那行被注释掉的 requirepass 会被替换成新的明文密码。然后重启 Redis就恢复了正常认证状态。如果你连 CONFIG REWRITE 也嫌麻烦可以直接在配置文件里改requirepass手动改密码重启自然生效。记住重置流程中不要让 Redis 长期暴露在无认证状态尤其是公网环境几分钟内就可能被扫描脚本“光顾”。5.2 密码与性能认证开销到底有多大有人担心加了密码之后性能下降这里给个直观结论Redis 的 AUTH 验证是一次非常简单的内存字符串比较一次验证的开销大约是微秒级。在长连接场景下一个连接建立时会验证一次后续所有键操作不会再触发验证。就算每秒钟新建几千个连接验证的 CPU 开销也几乎可以忽略。真正影响性能的不是密码本身而是频繁用-a参数重连。我见过有的脚本为了省事每次执行一条命令都新建一个 redis-cli 进程等于每次都要认证一次。如果遇到这种场景优先改用连接池保持长连接。所以不要担心密码影响性能真正该担心的是没有密码带来的高风险。5.3 我在实际维护中的几点心得设置 Redis 密码这个操作虽然简单但它往往是一个项目从“能跑”到“规范”的分水岭。我在多个项目里做过同样的操作这里分享几个个人觉得容易踩但很少被写进文档的点第一密码不要和业务系统共用一套。有些团队把 MySQL 密码、Redis 密码、服务器 SSH 密码统一看起来好记实际上一次泄露导致全线暴露。我建议 Redis 用独立的密码别图省事。第二改完密码后一定记得验证主从复制和业务代码两边都同步调整。很多悲剧发生在“主库改密码从库没配”或者“代码改了运维不知道”。直接影响就是线上缓存全部 miss数据库被打爆。第三监控系统要同步。如果你用了 Prometheus 等监控 Redis exporter它连接 Redis 的配置里也要写上密码否则监控项全部变成NOAUTH导致抓不到指标。这个问题容易让人误判 Redis 故障实际上只是监控采集连接失败。第四配置文件里如果还开了多个实例每个实例都需要分别修改。特别是 Redis 哨兵和集群环境不要假设只改一台就全部生效要在所有节点上做同样的配置变更并使用统一密码策略管理。最后再放一个小技巧设置完密码后若发现redis-cli交互模式历史里有明文密码记录可以在 shell 里执行history -c清掉或者使用unset REDISCLI_AUTH如果你用过环境变量来避免下次误带。这个细节很冷门但每次我接手新环境时都会顺带处理避免以后手滑把密码打在日志里。安全这件事不在于单点做得多强而在于每一层都不留大洞。给 Redis 设置密码是其中最基础、成本最低的一个动作先把这一步做了再谈别的优化。