最近连续碰了几次“Redis 设置密码无效”的排查客户给过来的现象都很统一conf 里明明写了requirepass xxx服务也重启过了但客户端不带密码居然还能正常读写。说实话这类问题一大半不是 Redis 本身出了问题而是配置文件加载链路和启动方式被忽略掉了。这篇文章把我踩过的、帮别人踩过的坑整体梳理一遍覆盖配置文件、启动参数、重启方式、客户端连接池这几条链路一次性讲清楚。1. 先搞清楚现象为什么你改了密码客户端照样畅通无阻先别急着喷 Redis说它不支持密码。绝大多数“设置密码无效”都是下面几个原因里的一个配置文件改错了、启动了不止一个实例、命令行参数覆盖了配置文件、改了配置之后没有真正重启或者客户端复用了旧连接。这几种情况表面看起来都像是“密码没生效”但排查思路完全不一样。1.1 最常见的“假设置”改错了配置文件这个坑真的低级但发生频率最高。尤其 Windows 上玩 Redis 的朋友解压安装包之后目录里同时存在redis.windows.conf、redis.windows-service.conf、甚至还有一份redis.conf。很多人习惯性地找到redis.conf改结果平时跑的服务加载的是redis.windows.conf改了半天自然没反应。Linux 上也一样。用 apt 装的 Redis配置文件通常在/etc/redis/redis.conf用源码编译装的可能还在/usr/local/redis/下用 Docker 跑的配置文件就完全取决于挂载卷怎么映射了。我后来养成一个习惯改配置前先执行ps -ef | grep redis看进程启动参数里到底指向哪个 conf确认无误再动文件。另外还有一个隐蔽点Redis 启动时会读取配置文件里的dir参数默认是/var/lib/redis或当前工作目录这决定了 RDB 和 AOF 文件的路径。有些人在不同目录下放了多份配置进程加载的dir和你修改的文件不在同一个版本管理目录里这也容易造成“我明明改了咋就无效”的错觉。1.2 启动命令行参数悄悄覆盖了配置比改错文件更隐蔽的是命令行覆盖。Redis 支持这种启动方式redis-server /etc/redis/redis.conf --requirepass mypass命令里的requirepass优先级高于配置文件进程启动后你去看配置文件里写的# requirepass foobared被注释的那行其实根本没起作用。这种用法常见于一些部署脚本、容器启动命令和云平台自动初始化脚本里。更麻烦的是一些老旧的启动脚本会写成这样redis-server /etc/redis/redis.conf 看起来是加载了 conf但脚本前面的某些环境变量又把requirepass传进去了导致最终生效的是脚本里的密码而不是 conf 里的密码。排查的时候如果只看 conf永远找不到问题。docker 场景还有一个变种docker run时通过-e环境变量或命令行直接传redis-server --requirepass xxx容器内部的/usr/local/etc/redis/redis.conf虽然也在但根本没被作为唯一配置来源读取。这时候想在宿主机上改 conf 来改密码同样无效。所以排查的第一步永远是确认启动命令和加载路径别用“想当然”代替事实。2. 排查链路先确认 Redis 进程到底加载了哪个配置文件遇到“密码无效”我建议按下面这套链路走一遍十分钟内基本能定位到一个具体原因。2.1 用 CONFIG GET 直接向 Redis 要答案与其猜来猜去不如直接问 Redis 自己。先用redis-cli连接执行redis-cli -p 6379 CONFIG GET requirepass如果返回1) requirepass 2) 那说明当前进程里压根没有认证密码别管你配置文件里写了什么现实就是现实。如果返回了一串字符串说明认证是生效的那你所谓的“无效”可能另有原因比如客户端连接的其实是另一个实例。CONFIG GET也能查很多其他相关项比如CONFIG GET masterauth CONFIG GET protected-mode CONFIG GET bind其中protected-mode值得单独记一下。如果它返回yes而bind又设置为127.0.0.1那么本地连接在没有密码的情况下会被允许远程连接会被拒绝。很多人误以为“没有密码连上去”就是密码没生效其实是因为本地回环地址免密访问被保护模式放行了。把客户端也跑在本机时这种错觉特别常见。这里有个操作细节如果已经设置了密码CONFIG GET这类管理命令在未认证状态是不给执行的会直接返回NOAUTH Authentication required。所以如果执行CONFIG GET requirepass时提示需要认证说明密码确实已经生效了你反而应该先用AUTH认证AUTH yourpassword CONFIG GET requirepass这一步虽然简单但它是整个排查链路里最少被人想到、却又最有效的一步。2.2 从启动命令反推配置来源确认进程当前状态之后再反推它到底怎么启动的。这一步能直接过滤掉“改错文件”和“命令行覆盖”两个坑。ps -ef | grep redis-server看输出redis 12345 1 0 14:30 ? 00:00:01 redis-server 0.0.0.0:6379如果ps的输出末尾带了路径比如/etc/redis/redis.conf那说明启动时加载的就是这份。如果只显示redis-server 0.0.0.0:6379没有 conf 路径那你大概率连配置文件都没加载进去。如果是 systemd 管理的服务还可以看systemctl cat redis-server重点查看ExecStart这一行确认是否带了--config /xxx/redis.conf以及是否附加了--requirepass参数。即使输出的命令看起来正常也不能百分百放心还要检查是否有 override 文件systemctl status redis-server systemctl list-dependencies redis-server看看/etc/systemd/system/redis-server.service.d/override.conf这类文件是否存在。我碰到过一次override 文件里硬生生定义了ExecStartredis-server --requirepass oldpass把主配置里的新密码全部顶掉了排查了很久才发现。容器场景就用 Docker 侧的命令确认docker inspect container_id | grep -A5 Config docker inspect container_id | grep -A10 Mounts重点看Cmd里有没有redis-server加--requirepass的参数再看Mounts里宿主机配置文件的映射路径是否正确避免出现宿主机/data/redis.conf和容器内/usr/local/etc/redis/redis.conf对不上号的情况。3. 修改配置后必须正确重启这一步比你想象的更容易翻车很多人修改完配置直接执行systemctl restart redis-server十分钟后兴奋地验证——还是无效。问题往往出在“你以为重启了其实没有”或者“你重启的是另一个实例”。3.1 三种常见启动方式下的重启姿势systemd 管理的服务systemctl restart redis-server重启后确认状态systemctl status redis-server注意看Active:行是否显示active (running)以及启动时间是否刚刚更新。如果没更新说明你可能重启失败了或者有别的实例占用着端口。手工启动的 Redis手工启动时最常用的正确关闭方式是使用SHUTDOWN命令redis-cli -p 6379 SHUTDOWN这里有个新手容易困惑的细节如果 Redis 是以 systemd 或 Docker 的restart: always方式托管的执行SHUTDOWN后管家进程会自动把它重新拉起来你看到进程还存在就误以为“重启失败”。实际上它是在被拉起来之后又重新加载了旧配置或者被拉起来时加载的配置路径变了。遇到这种情况建议先看进程的 PID 是否发生变化。Docker 容器docker restart container_id3.2 重启之后别急着下结论重启完先别急着连客户端按顺序做三件事第一检查端口监听是否正常连接是否马上被拒redis-cli -p 6379 PING如果提示NOAUTH Authentication required那说明密码已经生效只是你没把密码传进去。这时候用-a参数指定密码redis-cli -p 6379 -a yourpassword PING输出PONG说明服务和密码都工作正常。第二再查一遍CONFIG GET requirepass确认最终值这是最可信的“当前生效状态”。第三确认dir目录下没有多个实例共用一份数据文件。如果/var/lib/redis下面有dump.rdb且appendonly.aof也在不妨看一眼CONFIG GET appendonly是否开启。有些场景下旧数据恢复过程中会把某些配置项恢复成旧值这一点在有意外的崩溃恢复时尤其值得留意。4. 真实业务场景中“密码无效”的几个隐蔽原因前面三条讲的是最基础的排查链路。下面这些坑才是真正在业务环境里折磨人的不是配置文件的问题而是“生态”层面带来的问题。4.1 连接池把旧连接缓存起来了这是线上环境最常见的“假密码无效”现象。服务端配置和密码都改好了客户端用新密码也能连但正在跑着的应用报的还是老错误甚至不带密码的连接依然在正常工作。原因很简单你的应用连接的是 Redis 连接池连接池里的连接是在改密码之前就建立的。连接是长连接Redis 不会因为密码变了就把客户端踢掉除非你主动执行CLIENT KILL或者重启 Redis。所以改完密码后旧连接依旧在读写数据看起来就跟“密码没生效”一样。处理方法是双管齐下redis-cli -p 6379 -a newpassword CLIENT LIST可以看到每个客户端的地址和连接状态。找到旧应用的客户端 IP 后可以按地址杀掉redis-cli -p 6379 -a newpassword CLIENT KILL 192.168.1.100:56789更彻底的方式是让业务侧把连接池对象重建。比如 Jedis 里换了密码之后需要新建JedisPool只修改实例上的密码字段是不够的。我这里给个最简单的示意JedisPool pool new JedisPool(new JedisPoolConfig(), 127.0.0.1, 6379, 2000, your-new-password);改完配置后重启应用是最省心的策略尤其是那些使用 Spring Boot 的长连接应用。lettuce 作为连接池底层时连接池默认会复用底层连接不重启应用很难立刻让所有连接切换到新密码。4.2 主从 / 哨兵模式下的 masterauth 没同步改单机 Redis 改个requirepass很简单但一旦上了主从复制或哨兵模式“密码无效”就容易变得诡异起来。主从复制场景下从节点去连接主节点时主节点要求认证从节点必须有masterauth配置否则复制链路会中断# 在主从节点上都建议配置 requirepass newpass123 # 从节点必须有 masterauth指向主节点的密码 masterauth newpass123只改了requirepass但忘记改masterauth就会遇到一种很尴尬的现象主节点密码生效了从节点却一直报MASTER timeout或者一直处于down状态看起来像是“密码整个失效了”。哨兵模式还多一层redis-sentinel连接 Redis 节点时也需要认证。哨兵配置文件里要配置sentinel auth-pass master-name password。如果你改了 Redis 密码但哨兵的配置没同步更新那么哨兵大概率会拿旧密码去连接主节点结果就是主节点看起来“没有密码”哨兵频繁报-NOAUTH。这跟“设置密码无效”是同一类问题不是密码没设上而是保障密码认账的周边组件没跟上。Redis Cluster 也一样节点间握手和迁移数据都需要认证。建议所有节点统一用同样的requirepass和masterauth减少各种因密码不一致导致的诡异问题。4.3 Docker 环境下改了宿主机配置文件却没映射进容器Docker 跑 Redis 是现在的主流方式但也是个重灾区。最简单的docker run部署如果只做了端口映射没做配置文件挂载那你宿主机上改什么都不会影响容器内docker run -d --name redis \ -p 6379:6379 \ -v /data/redis.conf:/usr/local/etc/redis/redis.conf \ redis:7 redis-server /usr/local/etc/redis/redis.conf看到没要想让容器加载宿主机那份配置必须在启动时同时做两件事第一把文件挂载到容器内指定路径第二启动命令指向这个路径。很多人的-v挂载了但最后redis-server后面没有指定配置文件路径容器依然用的是默认无密码启动。docker compose 场景类似version: 3 services: redis: image: redis:7 container_name: redis-demo ports: - 6379:6379 volumes: - ./redis.conf:/usr/local/etc/redis/redis.conf command: [redis-server, /usr/local/etc/redis/redis.conf]这里最容易犯的错是只写了volumes没写command或command里路径和volumes挂载目标不一致。我习惯每次改完都进容器里验证一下docker exec -it redis-demo redis-cli -p 6379 CONFIG GET requirepass输出是空那就是真的没加载配置文件别再折腾宿主机文件了先调整启动参数和挂载关系。5. 实操复盘一套直接照着抄的处理流程下面这套流程是我现在排查“Redis 密码无效”时的标准动作分享出来可以直接复制。5.1 第一步摸清现状和版本先确认版本redis-server --version版本不同ACL 的默认行为有差异。Redis 6 之前只有requirepassRedis 6 开始引入 ACL 用户体系。如果一个实例用了 ACL 配置比如user someone on password ~* allcommands而你只在requirepass里改密码那对使用自定义用户名的应用来说仍然会提示认证失败看着也像“密码无效”。同时确认当前运行实例的端口、是否有多个实例。别只盯一个端口不同端口各自独立认证你改的是 6379 的配置但业务连的可能是 6380。5.2 第二步定位并修改配置文件再次强调先确认启动命令里加载的 conf 路径ps -ef | grep redis-server然后备份再改cp /etc/redis/redis.conf /etc/redis/redis.conf.bak.$(date %Y%m%d)修改这一段# 取消注释并设置密码不要设置太简单生产环境建议 32 位以上混合字符串 requirepass your-new-password-here改完之后顺便校验一下语法。Redis 本身没有一个官方的redis-conf-check工具但你可以通过启动时是否报错来判断。如果你不想直接重启先使用CONFIG SET在线热更新redis-cli -p 6379 -a oldpassword CONFIG SET requirepass your-new-password-here这能立刻让密码生效但要记住CONFIG SET只改内存不写文件如果后面不同步修改配置文件下一次重启又会变成配置文件里的旧值很多人在这上面吃过亏。5.3 第三步重启服务确认无误后按你的部署方式重启systemctl restart redis-serverDocker 的话docker compose up -d # 或者 docker restart redis-demo重启完第一时间验证redis-cli -p 6379 -a your-new-password-here PING如果这一步能返回PONG那服务端侧就彻底解决了。如果提示ERR Client sent AUTH, but no password is set说明当前实例根本不需要密码你重启后加载的配置仍然没有你加的那行requirepass回到第二步检查路径和启动参数。5.4 第四步联调客户端并确认服务端没问题最后一步就是客户端侧了。命令行客户端redis-cli -p 6379 -a your-new-password-hereRedis Desktop Manager / Another Redis Desktop Manager这类可视化客户端连接的时候底部会有一个整行密码输入框填进去再测试连接。注意很多可视化工具为了快速测试会走redis-cli类似的无密码路径或者在 GUI 里不填写密码也能点 Test这种情况下没报错不代表认证成功要看工具返回是否实际做了 AUTH。特别提醒如果工具连接列表里保存了旧密码它会一直用旧密码尝试导致你改完密码后觉得“客户端连不上了”。这时候要删除连接配置重新建一个连接别在原连接上只改 IP 不动密码。业务代码端以 Java 为例LettuceConnectionFactory factory new LettuceConnectionFactory(); factory.setHostName(127.0.0.1); factory.setPort(6379); factory.setPassword(your-new-password-here);改完代码后重启应用观察日志有没有NOAUTH或连接报错。如果没有报错那整个链路就干净了。6. 常见问题速查表把我在多个项目里遇到的“密码无效”现象和原因整理成一张表方便大家直接对照。现象可能原因解决方法命令行客户端连本机不用密码也能读写requirepass根本没生效可能改错文件或没加载配置文件CONFIG GET requirepass看当前值检查启动命令和 conf 路径配置改了重启后密码丢失只CONFIG SET没写文件或.conf文件不在启动加载路径中将requirepass写入文件并用文件路径启动服务重启后连不上报NOAUTH密码已生效客户端用的还是旧密码、旧连接客户端带新密码连接或重建连接池不报错但连接一直通过业务仍用旧连接连接池复用了长连接CLIENT LIST定位旧连接CLIENT KILL杀掉或重启应用哨兵模式下主从切换后出现认证失败只改了requirepass没改masterauth/sentinel auth-pass同步修改各节点的masterauth和哨兵配置Docker 内改了宿主机配置无效容器启动时没挂载配置文件或command指向路径不对调整-v挂载和command参数使容器加载正确的 conf用同一个连接工具访问两个 Redis 实例时混乱改了其中一个的密码另一个实例密码没改或端口混淆确认每个连接对应的端口、密码必要时重新建连接配置Redis 6 使用 ACL 后应用报认证失败只改requirepass没有处理 ACL 用户密码按 ACL 用户体系修改对应user的密码或调整客户端用户名7. 最后分享一点排查心得我个人在实际操作中养成的一个习惯是每次改完 Redis 密码都在同一个终端里打两行命令一行是CONFIG GET requirepass一行是AUTH newpass输出都正常再关终端。这么做的好处是它把“配置生效了”和“认证可用”两步拆得很清楚不会混在一起。还有一个小技巧如果一台服务器上跑了好几个 Redis 实例排查“密码无效”之前先带端口跑一遍redis-cli -p 6379 -a password info server | grep redis_version把每个端口的确认结果列出来避免把 A 实例的问题带到 B 实例去解决。这个习惯帮我省了很多时间。最后再补一句线上改密码务必在低峰期操作先热更新CONFIG SET验证业务兼容性再把新密码写进配置文件最后重启。整个过程准备好回滚方案——旧配置文件备份放在原位万一新密码引发客户端大面积连接失败能秒级切回。
最近连续碰了几次“Redis 设置密码无效”的排查客户给过来的现象都很统一conf 里明明写了requirepass xxx服务也重启过了但客户端不带密码居然还能正常读写。说实话这类问题一大半不是 Redis 本身出了问题而是配置文件加载链路和启动方式被忽略掉了。这篇文章把我踩过的、帮别人踩过的坑整体梳理一遍覆盖配置文件、启动参数、重启方式、客户端连接池这几条链路一次性讲清楚。1. 先搞清楚现象为什么你改了密码客户端照样畅通无阻先别急着喷 Redis说它不支持密码。绝大多数“设置密码无效”都是下面几个原因里的一个配置文件改错了、启动了不止一个实例、命令行参数覆盖了配置文件、改了配置之后没有真正重启或者客户端复用了旧连接。这几种情况表面看起来都像是“密码没生效”但排查思路完全不一样。1.1 最常见的“假设置”改错了配置文件这个坑真的低级但发生频率最高。尤其 Windows 上玩 Redis 的朋友解压安装包之后目录里同时存在redis.windows.conf、redis.windows-service.conf、甚至还有一份redis.conf。很多人习惯性地找到redis.conf改结果平时跑的服务加载的是redis.windows.conf改了半天自然没反应。Linux 上也一样。用 apt 装的 Redis配置文件通常在/etc/redis/redis.conf用源码编译装的可能还在/usr/local/redis/下用 Docker 跑的配置文件就完全取决于挂载卷怎么映射了。我后来养成一个习惯改配置前先执行ps -ef | grep redis看进程启动参数里到底指向哪个 conf确认无误再动文件。另外还有一个隐蔽点Redis 启动时会读取配置文件里的dir参数默认是/var/lib/redis或当前工作目录这决定了 RDB 和 AOF 文件的路径。有些人在不同目录下放了多份配置进程加载的dir和你修改的文件不在同一个版本管理目录里这也容易造成“我明明改了咋就无效”的错觉。1.2 启动命令行参数悄悄覆盖了配置比改错文件更隐蔽的是命令行覆盖。Redis 支持这种启动方式redis-server /etc/redis/redis.conf --requirepass mypass命令里的requirepass优先级高于配置文件进程启动后你去看配置文件里写的# requirepass foobared被注释的那行其实根本没起作用。这种用法常见于一些部署脚本、容器启动命令和云平台自动初始化脚本里。更麻烦的是一些老旧的启动脚本会写成这样redis-server /etc/redis/redis.conf 看起来是加载了 conf但脚本前面的某些环境变量又把requirepass传进去了导致最终生效的是脚本里的密码而不是 conf 里的密码。排查的时候如果只看 conf永远找不到问题。docker 场景还有一个变种docker run时通过-e环境变量或命令行直接传redis-server --requirepass xxx容器内部的/usr/local/etc/redis/redis.conf虽然也在但根本没被作为唯一配置来源读取。这时候想在宿主机上改 conf 来改密码同样无效。所以排查的第一步永远是确认启动命令和加载路径别用“想当然”代替事实。2. 排查链路先确认 Redis 进程到底加载了哪个配置文件遇到“密码无效”我建议按下面这套链路走一遍十分钟内基本能定位到一个具体原因。2.1 用 CONFIG GET 直接向 Redis 要答案与其猜来猜去不如直接问 Redis 自己。先用redis-cli连接执行redis-cli -p 6379 CONFIG GET requirepass如果返回1) requirepass 2) 那说明当前进程里压根没有认证密码别管你配置文件里写了什么现实就是现实。如果返回了一串字符串说明认证是生效的那你所谓的“无效”可能另有原因比如客户端连接的其实是另一个实例。CONFIG GET也能查很多其他相关项比如CONFIG GET masterauth CONFIG GET protected-mode CONFIG GET bind其中protected-mode值得单独记一下。如果它返回yes而bind又设置为127.0.0.1那么本地连接在没有密码的情况下会被允许远程连接会被拒绝。很多人误以为“没有密码连上去”就是密码没生效其实是因为本地回环地址免密访问被保护模式放行了。把客户端也跑在本机时这种错觉特别常见。这里有个操作细节如果已经设置了密码CONFIG GET这类管理命令在未认证状态是不给执行的会直接返回NOAUTH Authentication required。所以如果执行CONFIG GET requirepass时提示需要认证说明密码确实已经生效了你反而应该先用AUTH认证AUTH yourpassword CONFIG GET requirepass这一步虽然简单但它是整个排查链路里最少被人想到、却又最有效的一步。2.2 从启动命令反推配置来源确认进程当前状态之后再反推它到底怎么启动的。这一步能直接过滤掉“改错文件”和“命令行覆盖”两个坑。ps -ef | grep redis-server看输出redis 12345 1 0 14:30 ? 00:00:01 redis-server 0.0.0.0:6379如果ps的输出末尾带了路径比如/etc/redis/redis.conf那说明启动时加载的就是这份。如果只显示redis-server 0.0.0.0:6379没有 conf 路径那你大概率连配置文件都没加载进去。如果是 systemd 管理的服务还可以看systemctl cat redis-server重点查看ExecStart这一行确认是否带了--config /xxx/redis.conf以及是否附加了--requirepass参数。即使输出的命令看起来正常也不能百分百放心还要检查是否有 override 文件systemctl status redis-server systemctl list-dependencies redis-server看看/etc/systemd/system/redis-server.service.d/override.conf这类文件是否存在。我碰到过一次override 文件里硬生生定义了ExecStartredis-server --requirepass oldpass把主配置里的新密码全部顶掉了排查了很久才发现。容器场景就用 Docker 侧的命令确认docker inspect container_id | grep -A5 Config docker inspect container_id | grep -A10 Mounts重点看Cmd里有没有redis-server加--requirepass的参数再看Mounts里宿主机配置文件的映射路径是否正确避免出现宿主机/data/redis.conf和容器内/usr/local/etc/redis/redis.conf对不上号的情况。3. 修改配置后必须正确重启这一步比你想象的更容易翻车很多人修改完配置直接执行systemctl restart redis-server十分钟后兴奋地验证——还是无效。问题往往出在“你以为重启了其实没有”或者“你重启的是另一个实例”。3.1 三种常见启动方式下的重启姿势systemd 管理的服务systemctl restart redis-server重启后确认状态systemctl status redis-server注意看Active:行是否显示active (running)以及启动时间是否刚刚更新。如果没更新说明你可能重启失败了或者有别的实例占用着端口。手工启动的 Redis手工启动时最常用的正确关闭方式是使用SHUTDOWN命令redis-cli -p 6379 SHUTDOWN这里有个新手容易困惑的细节如果 Redis 是以 systemd 或 Docker 的restart: always方式托管的执行SHUTDOWN后管家进程会自动把它重新拉起来你看到进程还存在就误以为“重启失败”。实际上它是在被拉起来之后又重新加载了旧配置或者被拉起来时加载的配置路径变了。遇到这种情况建议先看进程的 PID 是否发生变化。Docker 容器docker restart container_id3.2 重启之后别急着下结论重启完先别急着连客户端按顺序做三件事第一检查端口监听是否正常连接是否马上被拒redis-cli -p 6379 PING如果提示NOAUTH Authentication required那说明密码已经生效只是你没把密码传进去。这时候用-a参数指定密码redis-cli -p 6379 -a yourpassword PING输出PONG说明服务和密码都工作正常。第二再查一遍CONFIG GET requirepass确认最终值这是最可信的“当前生效状态”。第三确认dir目录下没有多个实例共用一份数据文件。如果/var/lib/redis下面有dump.rdb且appendonly.aof也在不妨看一眼CONFIG GET appendonly是否开启。有些场景下旧数据恢复过程中会把某些配置项恢复成旧值这一点在有意外的崩溃恢复时尤其值得留意。4. 真实业务场景中“密码无效”的几个隐蔽原因前面三条讲的是最基础的排查链路。下面这些坑才是真正在业务环境里折磨人的不是配置文件的问题而是“生态”层面带来的问题。4.1 连接池把旧连接缓存起来了这是线上环境最常见的“假密码无效”现象。服务端配置和密码都改好了客户端用新密码也能连但正在跑着的应用报的还是老错误甚至不带密码的连接依然在正常工作。原因很简单你的应用连接的是 Redis 连接池连接池里的连接是在改密码之前就建立的。连接是长连接Redis 不会因为密码变了就把客户端踢掉除非你主动执行CLIENT KILL或者重启 Redis。所以改完密码后旧连接依旧在读写数据看起来就跟“密码没生效”一样。处理方法是双管齐下redis-cli -p 6379 -a newpassword CLIENT LIST可以看到每个客户端的地址和连接状态。找到旧应用的客户端 IP 后可以按地址杀掉redis-cli -p 6379 -a newpassword CLIENT KILL 192.168.1.100:56789更彻底的方式是让业务侧把连接池对象重建。比如 Jedis 里换了密码之后需要新建JedisPool只修改实例上的密码字段是不够的。我这里给个最简单的示意JedisPool pool new JedisPool(new JedisPoolConfig(), 127.0.0.1, 6379, 2000, your-new-password);改完配置后重启应用是最省心的策略尤其是那些使用 Spring Boot 的长连接应用。lettuce 作为连接池底层时连接池默认会复用底层连接不重启应用很难立刻让所有连接切换到新密码。4.2 主从 / 哨兵模式下的 masterauth 没同步改单机 Redis 改个requirepass很简单但一旦上了主从复制或哨兵模式“密码无效”就容易变得诡异起来。主从复制场景下从节点去连接主节点时主节点要求认证从节点必须有masterauth配置否则复制链路会中断# 在主从节点上都建议配置 requirepass newpass123 # 从节点必须有 masterauth指向主节点的密码 masterauth newpass123只改了requirepass但忘记改masterauth就会遇到一种很尴尬的现象主节点密码生效了从节点却一直报MASTER timeout或者一直处于down状态看起来像是“密码整个失效了”。哨兵模式还多一层redis-sentinel连接 Redis 节点时也需要认证。哨兵配置文件里要配置sentinel auth-pass master-name password。如果你改了 Redis 密码但哨兵的配置没同步更新那么哨兵大概率会拿旧密码去连接主节点结果就是主节点看起来“没有密码”哨兵频繁报-NOAUTH。这跟“设置密码无效”是同一类问题不是密码没设上而是保障密码认账的周边组件没跟上。Redis Cluster 也一样节点间握手和迁移数据都需要认证。建议所有节点统一用同样的requirepass和masterauth减少各种因密码不一致导致的诡异问题。4.3 Docker 环境下改了宿主机配置文件却没映射进容器Docker 跑 Redis 是现在的主流方式但也是个重灾区。最简单的docker run部署如果只做了端口映射没做配置文件挂载那你宿主机上改什么都不会影响容器内docker run -d --name redis \ -p 6379:6379 \ -v /data/redis.conf:/usr/local/etc/redis/redis.conf \ redis:7 redis-server /usr/local/etc/redis/redis.conf看到没要想让容器加载宿主机那份配置必须在启动时同时做两件事第一把文件挂载到容器内指定路径第二启动命令指向这个路径。很多人的-v挂载了但最后redis-server后面没有指定配置文件路径容器依然用的是默认无密码启动。docker compose 场景类似version: 3 services: redis: image: redis:7 container_name: redis-demo ports: - 6379:6379 volumes: - ./redis.conf:/usr/local/etc/redis/redis.conf command: [redis-server, /usr/local/etc/redis/redis.conf]这里最容易犯的错是只写了volumes没写command或command里路径和volumes挂载目标不一致。我习惯每次改完都进容器里验证一下docker exec -it redis-demo redis-cli -p 6379 CONFIG GET requirepass输出是空那就是真的没加载配置文件别再折腾宿主机文件了先调整启动参数和挂载关系。5. 实操复盘一套直接照着抄的处理流程下面这套流程是我现在排查“Redis 密码无效”时的标准动作分享出来可以直接复制。5.1 第一步摸清现状和版本先确认版本redis-server --version版本不同ACL 的默认行为有差异。Redis 6 之前只有requirepassRedis 6 开始引入 ACL 用户体系。如果一个实例用了 ACL 配置比如user someone on password ~* allcommands而你只在requirepass里改密码那对使用自定义用户名的应用来说仍然会提示认证失败看着也像“密码无效”。同时确认当前运行实例的端口、是否有多个实例。别只盯一个端口不同端口各自独立认证你改的是 6379 的配置但业务连的可能是 6380。5.2 第二步定位并修改配置文件再次强调先确认启动命令里加载的 conf 路径ps -ef | grep redis-server然后备份再改cp /etc/redis/redis.conf /etc/redis/redis.conf.bak.$(date %Y%m%d)修改这一段# 取消注释并设置密码不要设置太简单生产环境建议 32 位以上混合字符串 requirepass your-new-password-here改完之后顺便校验一下语法。Redis 本身没有一个官方的redis-conf-check工具但你可以通过启动时是否报错来判断。如果你不想直接重启先使用CONFIG SET在线热更新redis-cli -p 6379 -a oldpassword CONFIG SET requirepass your-new-password-here这能立刻让密码生效但要记住CONFIG SET只改内存不写文件如果后面不同步修改配置文件下一次重启又会变成配置文件里的旧值很多人在这上面吃过亏。5.3 第三步重启服务确认无误后按你的部署方式重启systemctl restart redis-serverDocker 的话docker compose up -d # 或者 docker restart redis-demo重启完第一时间验证redis-cli -p 6379 -a your-new-password-here PING如果这一步能返回PONG那服务端侧就彻底解决了。如果提示ERR Client sent AUTH, but no password is set说明当前实例根本不需要密码你重启后加载的配置仍然没有你加的那行requirepass回到第二步检查路径和启动参数。5.4 第四步联调客户端并确认服务端没问题最后一步就是客户端侧了。命令行客户端redis-cli -p 6379 -a your-new-password-hereRedis Desktop Manager / Another Redis Desktop Manager这类可视化客户端连接的时候底部会有一个整行密码输入框填进去再测试连接。注意很多可视化工具为了快速测试会走redis-cli类似的无密码路径或者在 GUI 里不填写密码也能点 Test这种情况下没报错不代表认证成功要看工具返回是否实际做了 AUTH。特别提醒如果工具连接列表里保存了旧密码它会一直用旧密码尝试导致你改完密码后觉得“客户端连不上了”。这时候要删除连接配置重新建一个连接别在原连接上只改 IP 不动密码。业务代码端以 Java 为例LettuceConnectionFactory factory new LettuceConnectionFactory(); factory.setHostName(127.0.0.1); factory.setPort(6379); factory.setPassword(your-new-password-here);改完代码后重启应用观察日志有没有NOAUTH或连接报错。如果没有报错那整个链路就干净了。6. 常见问题速查表把我在多个项目里遇到的“密码无效”现象和原因整理成一张表方便大家直接对照。现象可能原因解决方法命令行客户端连本机不用密码也能读写requirepass根本没生效可能改错文件或没加载配置文件CONFIG GET requirepass看当前值检查启动命令和 conf 路径配置改了重启后密码丢失只CONFIG SET没写文件或.conf文件不在启动加载路径中将requirepass写入文件并用文件路径启动服务重启后连不上报NOAUTH密码已生效客户端用的还是旧密码、旧连接客户端带新密码连接或重建连接池不报错但连接一直通过业务仍用旧连接连接池复用了长连接CLIENT LIST定位旧连接CLIENT KILL杀掉或重启应用哨兵模式下主从切换后出现认证失败只改了requirepass没改masterauth/sentinel auth-pass同步修改各节点的masterauth和哨兵配置Docker 内改了宿主机配置无效容器启动时没挂载配置文件或command指向路径不对调整-v挂载和command参数使容器加载正确的 conf用同一个连接工具访问两个 Redis 实例时混乱改了其中一个的密码另一个实例密码没改或端口混淆确认每个连接对应的端口、密码必要时重新建连接配置Redis 6 使用 ACL 后应用报认证失败只改requirepass没有处理 ACL 用户密码按 ACL 用户体系修改对应user的密码或调整客户端用户名7. 最后分享一点排查心得我个人在实际操作中养成的一个习惯是每次改完 Redis 密码都在同一个终端里打两行命令一行是CONFIG GET requirepass一行是AUTH newpass输出都正常再关终端。这么做的好处是它把“配置生效了”和“认证可用”两步拆得很清楚不会混在一起。还有一个小技巧如果一台服务器上跑了好几个 Redis 实例排查“密码无效”之前先带端口跑一遍redis-cli -p 6379 -a password info server | grep redis_version把每个端口的确认结果列出来避免把 A 实例的问题带到 B 实例去解决。这个习惯帮我省了很多时间。最后再补一句线上改密码务必在低峰期操作先热更新CONFIG SET验证业务兼容性再把新密码写进配置文件最后重启。整个过程准备好回滚方案——旧配置文件备份放在原位万一新密码引发客户端大面积连接失败能秒级切回。
