Redis 如何安全连接？绑定地址、ACL 与公网访问限制
先画出谁需要连接 Redis
本文适用于使用 ACL 的 Redis 7、8 系列自建实例，实际部署应选择仍获维护的补丁版本。开始修改前，记录应用、任务消费者、监控及管理入口分别在哪台机器，使用哪个账号。最容易遗漏的是后台任务：网站首页能打开，队列却可能已因权限收紧停止消费。
如果应用和 Redis 运行在同一主机且没有容器网络隔离，只监听回环地址通常足够；跨主机访问则应走受控私网或安全隧道，并限制来源。容器里的 localhost 指向容器自身，不能直接拿宿主机的同机方案套用。网络边界应按实际连接路径设计。
监听地址与来源限制分别检查
同机部署可在实际加载的配置文件中采用以下监听设置。先备份原配置，确认服务启动参数指向该文件，再安排变更窗口；这段配置不包含认证规则，不能单独构成完整安全方案。
bind 127.0.0.1
protected-mode yes
用 ss -lntp 核对监听地址和端口，并分别从应用所在环境与未授权来源检查连接。正确结果是应用路径可达、无关来源不可达。需要私网监听时，应绑定实际私网接口，同时在主机防火墙及平台支持的访问控制中限定应用来源；不要为了排错一次放开所有地址。
收到保护模式提示时，先确认连接路径是否符合设计，而不是关闭保护模式。认证提供额外控制，不能代替网络隔离；跨不可信链路还要使用 TLS 或安全隧道，因为普通认证本身不加密传输。Redis 安全文档
用应用需求推导 ACL
给网站缓存、队列和管理分别设置账号。先列出程序实际使用的数据类型与命令，再确定键名前缀。例如只读取 site:cache: 前缀字符串的组件，需要的权限与处理队列的消费者明显不同。给一个读缓存组件所有写命令，并不能提高连接可靠性。
ACL 能限制命令、键模式和发布订阅频道。制定规则时从拒绝全部命令出发，逐项增加实际需求；读缓存可考虑限定 GET、MGET 等必要命令及对应键前缀，但连接库可能另需 PING 等握手命令，应通过测试确定。不要把示例权限直接当作所有框架的通用清单。Redis ACL 规则
验证成功与拒绝两种结果
用应用的真实连接库验证新账号能够读取许可键，再在测试环境验证越界键与不应使用的操作被拒绝。网络超时先查路径，认证失败先查用户名和凭据，NOPERM 再查规则；混在一起排查往往导致误放宽权限。验证过程中避免输出密码、完整连接串或业务数据。
管理员可以核对 ACL 配置，但导出的权限信息也应限制存放范围。若使用独立 ACL 文件，应确认修改已按该部署方式保存；运行时修改与文件内容不一致，会在下次重启后产生意外。不要在不了解 aclfile 配置的情况下机械执行保存操作。
更换账号时保留恢复路径
先建立并验证新管理入口，再限制旧默认账号；应用采用新凭据后，检查新建连接和后台任务，不能只依赖原有连接池。设置用户为 off 不会自动使全部既有认证连接消失，因此撤销计划还要考虑旧连接的退出方式。
出现故障时，优先恢复已记录的单项规则或应用连接配置，保留网络来源限制。不要通过重新开放公网或授予所有命令来完成回退。最后记录账号用途、允许前缀、凭据轮换方式和负责人员，让下一次新增应用仍沿用相同边界。