1. 三种场景的设计思路先搞清楚该用哪种方案先聊聊为什么这个话题值得单独写一篇。很多人第一次碰 Redis 密码认证都是被安全扫描逼的服务器上开了 6379 端口扫出来一堆未授权访问漏洞然后临时抱佛脚去设置密码。但等你真正动手就会发现同一个设置密码的操作在配置文件、Docker、命令行三种环境下处理方式完全不一样踩坑点也不一样。最尴尬的情况是明明在命令行执行成功转头容器一重启密码就没了或者在配置文件里加了 requirepass结果 Redis 根本没加载那个配置文件白改一场。所以我建议先想清楚一个问题你现在的 Redis 到底是什么运行状态这决定了该用哪种方案也决定了要不要同时处理其他参数。这里先给出一个简单的决策逻辑如果你用的是传统方式安装系统包管理器安装、手动编译安装、云厂商镜像等Redis 进程通过 redis.conf 启动那么稳妥的做法是改配置文件因为这是一切的基础CONFIG REWRITE 最终也会写回这里。如果你的 Redis 跑在 Docker 容器里那要分两种情况一种是容器启动时通过命令参数临时指定密码优点是简单快捷、不用管配置文件缺点是容器重启后可能丢失取决于你怎么启动的另一种是挂载自定义 redis.conf这种方式可控性最强适合生产环境。如果只是想临时改一下、应急调试、或者不想重启 Redis 进程那就直接用 CONFIG SET在线生效不用中断业务。一句话总结配置文件方案管持久命令行方案管即时Docker 方案管部署形态。三者不是互斥的组合起来才是完整解法。还有个小细节需要提前说明。在 Redis 6 及以上版本中官方更推荐用 ACL 来做精细权限控制requirepass 属于传统老办法。但现实中绝大多数场景只是需要设一个访问密码挡住未授权请求requirepass 依然是最简单、最直接的选择。本文不展开 ACL所有操作都围绕 requirepass 展开这样对中小型项目、个人服务器、测试环境完全够用。2. 配置文件方式传统部署的稳定之选2.1 先确认 Redis 到底用的哪个配置改配置文件之前最大的坑就是找错配置文件。很多人装了 Redis 之后完全不记得路径随手一搜“redis.conf”找到一份就改结果改完发现进程根本没加载那份文件密码没生效还浪费了十几分钟排查。我自己的习惯是先用命令确认 Redis 当前的配置来源redis-cli -p 6379 CONFIG GET dir redis-cli -p 6379 CONFIG GET requirepass第一条命令返回的是 Redis 的工作目录第二条返回的是当前生效的 requirepass 值默认是空字符串。注意CONFIG GET 拿到的是当前进程实际加载的值比你自己猜配置文件路径可靠得多。然后通过进程信息确认启动方式ps -ef | grep redis-server如果看到类似这样的输出redis-server /etc/redis/redis.conf那就说明 Redis 启动时显式指定了配置文件这种最省心直接改这个文件即可。如果只是 redis-server 不带路径启动说明用的是默认配置这种情况下系统里通常没有一份真正的 redis.conf 被加载但你依然可以手动创建一份或者用下面的 CONFIG REWRITE 方式生成一份。补充一个经验不同安装方式的默认路径差异很大Ubuntu/Debian 用 apt 安装的通常在 /etc/redis/redis.confCentOS 用 yum 安装的在 /etc/redis.conf 或 /etc/redis/redis.conf手动编译的在 /usr/local/bin 目录或者你自己下载解压的目录里。拿不准的时候别瞎猜用前面两条命令确认最靠谱。2.2 修改 requirepass 的完整步骤找到配置文件后打开并定位到 SECURITY 段落。典型的配置长这样# Require clients to issue AUTH PASSWORD before executing any other # commands. # requirepass foobared把这一行的注释符号 # 去掉并把 foobared 换成你自己的密码requirepass YourStrongPassword2025这里有两个重要经验要分享。第一密码别用弱密码但也不要无脑用看上去很复杂的随机串因为有些特殊字符会在客户端连接、命令行传参、配置解析时制造麻烦。我的做法是用 openssl 生成一段大小写加数字组合的密码尽量避开 # $ 这类在 shell 和 URL 里有特殊含义的字符openssl rand -base64 24这种生成的密码接近 32 位包含字母数字和 / 符号如果你担心 / 也有转义问题可以再从里面挑一部分字符或者用下面这个更干净的方式cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 24第二requirepass 这行其实写在配置文件的哪个位置并不重要Redis 解析配置不依赖行号顺序但建议还是放在 SECURITY 小节里这样后续维护的人一眼能看到。如果你有强迫症非要验证一下是否真的被 Redis 认可保存后用配置文件重启即可。2.3 保存、重启与验证修改完配置文件后重启 Redis 让配置生效。传统方式安装的 Redis 一般这样操作sudo systemctl restart redis # 或者 sudo service redis-server restart如果你是用源码手动编译的没有 systemd 服务可以直接停掉进程再重启redis-cli shutdown redis-server /path/to/redis.conf重启后别急着跑业务先用 redis-cli 验证密码是否真的起作用了。注意这一步很多人犯迷糊不改密码的时候直接 redis-cli ping 就能得到 PONG改完密码后直接 ping 会得到 NOAUTH 错误。这是正常现象说明密码生效了。正确的验证姿势是redis-cli -a 你的密码 ping如果看到 PONG说明密码认证已生效。另外我还习惯加一个 --no-auth-warning 参数不然 redis-cli 每次连接都会给你弹一行警告Using a password with -a or -u option on the command line interface may not be safe。这个警告在脚本里使用还可以通过 --no-auth-warning 消掉手动执行时忽略也无妨。这里还有个小坑重启 Redis 之后依赖 Redis 的应用会集体断开连接如果你的应用没有配置自动重连逻辑重启瞬间会报一堆连接错误。所以强烈建议在维护窗口做这个操作或者先通知相关同事。3. Docker 容器方式注意镜像是无配置文件状态3.1 方式Adocker run 直接传参快速但不一定持久Docker 下最省事的办法是直接在启动命令里通过 redis-server 后面跟参数的方式来设置密码。举个例子docker run -d \ --name redis-test \ -p 6379:6379 \ redis:7 \ redis-server --requirepass YourStrongPassword2025注意看镜像是 redis:7后面带的 redis-server --requirepass 这段不是 docker run 的参数而是传给容器内 redis-server 启动命令的参数相当于你在容器里执行了redis-server --requirepass YourStrongPassword2025这种方式的优点是大大简化容器配置不用准备配置文件适合测试、临时环境。缺点是如果容器被删除重建命令参数没带上密码自然也就没了。所以如果你用 docker run 的方式一定要把密码写进部署脚本或编排文件里别手敲完看一眼以为完事了。验证方法docker exec -it redis-test redis-cli -a 你的密码 --no-auth-warning ping输出 PONG 即验证成功。这个场景还有一个容易忽略的点容器内的 redis-server 虽然支持传参但如果你是基于自定义镜像打得包或者你的容器内有自定义 redis.conf 且它优先级更高那直接用 docker run 传参可能不生效。别问我为什么会知道有一次就是因为容器内已经拷贝了一份 redis.confrequirepass 写进配置文件里是空值外部传参根本没覆盖到。3.2 方式B挂载自定义配置文件生产环境首选如果你追求可控性挂载一份自己写的 redis.conf 是更规范的方案。步骤很简单第一步提前在宿主机上准备好配置文件比如放在 /data/redis/conf/redis.conf里面写好requirepass YourStrongPassword2025第二步启动容器时通过 -v 挂载进去docker run -d \ --name redis-test \ -p 6379:6379 \ -v /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf \ redis:7 \ redis-server /usr/local/etc/redis/redis.conf这里注意一个关键点redis-server 后面跟的是容器内部的配置文件路径不是宿主机的路径。挂载时把宿主机文件映射到容器内的某个路径然后让 redis-server 用那个容器内路径启动这样才算把配置真正加载了。很多人在这里挂载路径写错了导致 Redis 找不到配置文件启动后还是默认配置密码无效。还有个细节宿主机目录权限不能有问题否则容器里读不到配置文件容器启动会直接报错退出。建议使用前先 docker logs 容器名 确认日志中没有报错。用这套方式后续想改密码直接改宿主机的 redis.conf然后 docker restart 容器即可。配置文件和容器解耦升级迁移都方便。3.3 docker-compose 写法多容器部署更友好如果项目里用了 docker-compose可以这样写services: redis: image: redis:7 container_name: redis-server ports: - 6379:6379 command: redis-server /usr/local/etc/redis/redis.conf volumes: - /data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf启动docker-compose up -d注意compose 中如果同时写了 command 和镜像默认启动命令存在冲突以 command 为准。我见过一些项目在 compose 里既不挂载配置也不写 command直接裸跑一个 redis:latest然后到处找人问为什么 Redis 没有密码这种属于部署姿势问题补上 command 或挂载配置就能解。最后补充一句关于网络层面的建议。在云服务器上跑 Redis 容器不管用哪种方式密码只是第一道防线千万记得在安全组/防火墙里限制 6379 端口的访问来源只放行内网 IP 或特定出口 IP。密码 网络隔离双管齐下才稳妥。否则即使设了密码遇到暴力破解也是麻烦事。4. 命令行方式应急与热修改的利器4.1 CONFIG SET 动态设置不用重启有些场景下你不能重启 Redis。比如业务高峰期间重启会导致缓存瞬间清空、连接闪断影响比较大。这时候用命令行方式在线改密码是最优解。redis-cli CONFIG SET requirepass YourStrongPassword2025命令执行后会返回 OK。注意这里是 CONFIG SET不是 SET别搞混。设置成功后当前进程立即生效不需要重启。但是——这里的但是很重要——如果你用的是默认配置且进程不是通过 redis.conf 启动的这个修改只对当前内存中的配置生效。想确认随时可以用 CONFIG GET requirepass 查看当前值。这种方式最适合的临时场景是你怀疑 Redis 已经被外部扫描来不及改配置文件重启先在线设个密码挡住未授权访问事后再找维护窗口把配置固化。4.2 持久化问题CONFIG REWRITE 的边界在线修改完之后下一个问题是怎么让它永久生效答案是执行 CONFIG REWRITEredis-cli -a 你的密码 --no-auth-warning CONFIG REWRITE这条命令会把当前进程中的有效配置重写回 redis.conf。但这里需要理解一个边界只有当 Redis 启动时使用了配置文件CONFIG REWRITE 才有地方可写。如果进程是裸启动redis-server 不带参数执行 CONFIG REWRITE 会报错ERR The server is running without a config file另外还要注意如果配置文件路径对应的目录没有写权限CONFIG REWRITE 也会失败。所以在线改完密码后安全起见还是要把密码同步到配置文件里不然哪天进程一重启密码又变回原来的空状态那就等于白设。这里顺便提一个非常有用的技巧如果某次你忘了当前 Redis 密码但 Redis 处于 protected-mode 且没有外网暴露你可以直接 CONFIG SET requirepass 新密码因为本机回环地址默认有免认证权限。等设置完后再用新密码重新认证即可。这个技巧应急时很好用。4.3 三种方式的对比与组合策略为了让你更直观地理解这三种方式的差异我整理了一个速查表设置方式生效方式持久性适用场景注意点修改 redis.conf重启后生效持久生产环境常规配置需要维护窗口重启会断开连接docker run 传参容器启动时生效看容器生命周期测试/临时环境容器重建后密码可能丢失挂载配置到容器重启容器后生效持久生产容器化部署需要提前准备配置文件CONFIG SET立即生效不持久应急、热修改需配合 CONFIG REWRITE 固化我个人的组合策略是生产环境第一次部署时直接用配置文件方案把密码固化如果线上 Redis 因为历史原因没有密码我会用 CONFIG SET 先应急设一个再找时间改配置重启容器化项目一律走挂载配置文件方案禁止在 docker run 里裸传密码原因很简单外人扫到你的启动命令历史就能看到明文密码而且密码散落在各种脚本里不好统一管理。5. 常见问题与排查技巧实录5.1 设完密码后主从复制断了这是很经典的一个场景。你给主库设置了 requirepass但忘了从库需要 masterauth 才能认证连接主库。结果从库日志里一直报MASTER - REPLICA sync started with MASTER Error condition on socket for SYNC: NOAUTH Authentication required.解决方法是在所有从库的配置文件中加一行masterauth YourStrongPassword2025如果是 Docker 启动的从库在启动命令或 compose 的 command 中追加相同参数redis-server --requirepass YourStrongPassword2025 --masterauth YourStrongPassword2025一句话总结requirepass 是管别人怎么访问我masterauth 是管我怎么访问我的主库一个都不能少。复制场景里所有节点的密码最好保持一致别搞差异化不然排查起来相当折腾。5.2 客户端连接报错NOAUTH HELLO must be called with auth这个错误在 Redis 6 及以上经常出现。原因在于Redis 6 之后的客户端在连接时会先发送 HELLO 命令进行协议握手如果在要求认证的实例上这一步就必须带上 AUTH 信息。所以当你用旧版的 redis-cli 或者旧版客户端库连接时可能会看到类似NOAUTH HELLO must be called with auth解决办法很简单升级客户端库到较新版本。或者在使用连接参数时显式提供密码。比如在 Java 的连接代码里Jedis jedis new Jedis(127.0.0.1, 6379); jedis.auth(YourStrongPassword2025);在 Python 的 redis-py 里import redis r redis.Redis(host127.0.0.1, port6379, passwordYourStrongPassword2025)顺便提醒一句很多项目在本地开发时为了省事不配置密码生产环境一加密码所有服务全部连不上。这种情况不是 Redis 的问题是应用配置缺了密码参数。排查时优先看应用的日志确定是 NOAUTH 错还是连接超时错前者就是认证问题后者再去查网络。5.3 密码特殊字符引发的假失败如果你用 openssl rand 生成的密码里恰好包含了感叹号、单双引号等字符在命令行里很容易被 shell 吃掉。举个例子redis-cli -a pssw0rd!23如果密码末尾是感叹号在双引号里可能触发历史扩展bash 默认开启导致命令执行异常。我见过有人因此在脚本里排错排了半个多小时最后发现是密码里有 $ 符号被当成了变量。我的建议是手动设置密码时统一只用大小写字母和数字长度拉长到 20 位以上强度完全够又省心。如果一定要用特殊字符那么在传入时务必用单引号包裹并且在配置文件里注意不要和注释符冲突。5.4 设置密码后 redis-cli 操作频繁提醒安全警告当你用redis-cli -a 密码执行命令时Redis 会提示密码暴露在命令行中。这在交互式操作时无所谓但在脚本中如果被系统审计记录密码确实有泄露风险。我的做法是脚本中优先使用环境变量传参。比如export REDIS_PASSWORDYourStrongPassword2025 redis-cli -a $REDIS_PASSWORD --no-auth-warning ping或者用 Redis 的 --askpass 方式交互输入密码避免命令行历史留下痕迹。虽然没有完美的方案但至少别把密码明文硬编码在提交到代码仓库的脚本里。5.5 一回事忘干净密码丢了怎么办最后聊一个应急场景密码彻底忘了怎么办不用慌如果 Redis 没有配置 protected-mode yes 且绑定地址是 127.0.0.1 或者内网那么本机通过回环地址访问时很多版本默认是“只允许本机无需认证直连”的你可以直接在本机执行redis-cli CONFIG SET requirepass 新密码即可重置。如果连本机都必须认证那就只能停掉 Redis 进程临时加一行requirepass跳过认证启动再重新设置密码。具体做法redis-server --requirepass newPassword看起来像绕了一圈但其实核心思路就一个只要你能以某种方式进入 Redis 的未认证状态或拥有配置文件修改权限密码就能重置。别慌这是个可控的故障。写在最后的一点个人体会密码这个东西在防护体系里永远是最基础但最容易被忽视的一环。我见过太多 Redis 裸奔的案例不是大家不知道要设密码而是设密码这个动作因为部署方式不一样产生了各种不确定性。写这篇文章就是想把配置、容器、命令行三种场景拆开把各自的边界讲清楚避免你在以为设置了但实际没生效的状态里浪费时间。实际操作中还有一个心得可以分享不要只依赖密码日志要开、端口要限制、定期要排查。密码是一道门锁但门锁挡不住所有坏人网络隔离和访问控制才是更厚实的墙。每次部署 Redis 前花十分钟把这几件事一起做好后面运维能省一大半麻烦。