Redis 认证失败：NOAUTH、WRONGPASS 和 NOPERM
NOAUTH 查有没有发送认证，WRONGPASS 查凭据与用户状态，NOPERM 查 ACL。测试时使用与应用相同的实例和账号。
Redis 报 NOAUTH、WRONGPASS 或 NOPERM，不能都按密码错误处理。先找到应用实际连接的实例，再查认证是否发送、凭据是否接受，以及命令是否在账号权限内。
不要把三个错误都当成密码错
| 错误 | 下一步 |
|---|---|
| NOAUTH | 检查这条连接是否发送了认证信息 |
| WRONGPASS | 核对用户名、密码和用户启用状态 |
| NOPERM | 检查命令、键或频道的 ACL 权限 |
Redis 6 起支持 ACL 用户。AUTH password 使用默认用户，指定业务账号需要用户名和密码；requirepass 管理的是默认用户的密码，不能替代任意自定义用户的配置。
用和应用相同的目标测试
客户端支持 --askpass 时，可交互输入密码，不把它写进命令行。地址、端口和用户名按实际替换：
redis-cli -h 127.0.0.1 -p 6379 --user app --askpass PING
云服务或启用 TLS 的实例需要匹配 TLS 与 CA 设置，不能照搬本地明文地址。PONG 只说明这条连接获准执行 PING；业务读写权限仍要用实际账号检查。若账号不允许 PING，却允许需要的业务命令，也不能仅凭 PING 失败判断认证没修好。
应用在容器里时，localhost 可能指应用容器自己。比较命令行与应用的主机、端口、用户名和秘密来源，注意连接 URI 的特殊字符编码，避免测试的是另一台正常实例。
设置了环境变量，为什么配置文件没变
容器里存在 REDIS_PASSWORD，不能证明挂载的 redis.conf 已经完成变量替换。Compose 展开 YAML、shell 展开命令、启动程序读取配置文件，是不同阶段。是否有模板生成步骤，需要按使用的镜像和启动脚本判断。
假设服务名为 redis，先读取实际启动命令与挂载路径：
docker compose ps
docker inspect --format '{{json .Config.Cmd}}' \
"$(docker compose ps -q redis)"
docker inspect --format '{{json .Mounts}}' \
"$(docker compose ps -q redis)"
启动参数可能含秘密，仅在受控环境查看。确认编辑的文件确实被加载，并核对有无前置模板处理。若已经证实服务端将占位符作为实际密码，修复配置生成过程；再加一个同名环境变量，也未必会替换文件内容。
改认证之前保留管理通道
管理员分别核对用户启用状态、密码、业务必要的命令和键范围。ACL 运行时修改如何持久化，要按目标版本确认，否则重启可能恢复旧规则。
保存原配置和数据位置，安排服务端与客户端凭据同步，让应用重新建立连接后验证最小业务权限。不要通过关闭认证、开放公网端口或删除数据卷来处理认证失败。
应用、数据库和缓存共用 VPS 时，可以先按Docker 服务器的部署条件整理私有网络、内存与备份。认证错误应先在现有实例修复；只有容量确实不够，或需要单独隔离缓存，才需要考虑新增服务器。
Redis 与应用共机，内存要容纳数据、持久化或恢复过程以及其他服务，磁盘还要放持久化文件和备份。可比较 雨云 RCS 的应用与内存选项，需要云资源网络组合时可查看 ECS 的地域与实例。若只是 NOAUTH、WRONGPASS 或 NOPERM，在原实例按认证和 ACL 修复；确需隔离 Redis 时再确认内网与最小访问范围。
