Redis protected-mode保护模式是什么？如何正确配置保障安全？

Redis从3.2版本开始引入了protected-mode（保护模式）这个安全机制，目的是防止Redis实例在缺乏防护的情况下暴露在公网上被任意访问。然而不少使用者对它的工作原理存在误解：有人以为开了保护模式就万事大吉，也有人遇到远程连接被拒绝后直接粗暴关闭它。本文将详细拆解protected-mode的触发条件、判断逻辑以及正确的配置方式，帮助你理解这个机制背后的安全设计。

protected-mode的触发条件与工作原理

protected-mode并不是一个独立的防火墙，而是一个内置的访问控制开关。它在服务端启动时判断当前实例是否处于"无防护"状态，判断依据是两个条件同时成立：第一，服务端没有通过bind指令显式绑定具体的外部网卡地址（即bind未配置，或者只绑定了127.0.0.1等回环地址之外的情况）；第二，没有设置访问密码，也就是没有配置requirepass，同时也没有开启ACL用户认证体系。

当这两个条件同时满足时，Redis会自动进入保护模式。此时服务端虽然监听端口，但对来自非回环地址（非127.0.0.1、非::1）的连接请求只允许执行AUTH和QUIT等极少数命令，其他任何命令都会被拒绝，并返回类似"DENIED Redis is running in protected mode"的错误提示。这意味着只有本机的客户端可以正常操作数据，远程连接即使TCP层能建立，命令层也会被拦截。

这个设计的背景是历史上大量Redis实例被部署在公网上且未设置密码，导致攻击者可以直接通过Redis写入SSH公钥或计划任务实现入侵。protected-mode相当于给这类粗心部署加了一道默认防线。需要特别注意的是，一旦你设置了密码或者显式配置了bind指向外部地址，protected-mode就不再拦截任何连接，此时实例的安全性完全取决于你的密码强度和网络暴露面。

如何正确开启、关闭与验证保护模式

protected-mode默认是开启状态，可以在redis.conf配置文件中显式控制。相关的核心配置如下：

redis.conf 中的相关配置
# 绑定地址：只允许本机访问
bind 127.0.0.1
# 保护模式：yes 开启，no 关闭
protected-mode yes
# 设置访问密码
requirepass YourStrongPassword123

验证方式有几种。第一种是登录后执行CONFIG GET protected-mode查看当前状态。第二种是在远程机器上用redis-cli直接连接，观察是否出现protected mode的报错信息。也可以临时通过命令调整：

# 运行时查看保护模式状态
redis-cli CONFIG GET protected-mode

# 远程连接测试（在另一台机器上执行）
redis-cli -h 服务器公网IP -p 6379 ping
# 若处于保护模式，会返回 DENIED 错误说明拦截生效

关于关闭protected-mode，正确的姿势是：先通过bind限定允许访问的来源地址，再设置强密码，最后才将protected-mode设为no并重启服务。如果你只是简单地把protected-mode设为no，而不做任何其他防护，等于把一个无密码的数据库直接暴露给全网，这是非常危险的操作，历史上大量Redis勒索和数据删除事件都源于此。

常见部署场景下的安全配置建议

场景一：纯本机使用。最安全的做法是bind 127.0.0.1加上protected-mode yes，这样外部根本无法建立连接，连端口都探测不到，适用于缓存与业务同机部署的情况。

场景二：内网多机访问。这是最常见的需求，业务服务器需要远程连接Redis。推荐配置是显式绑定内网网卡IP，配合密码认证，示例如下：

# 绑定本机回环地址和内网IP
bind 127.0.0.1 192.168.1.100
# 关闭保护模式（因为已有密码和明确绑定）
protected-mode no
# 设置强密码，建议使用长随机字符串
requirepass一个不少于20位的随机密码
# 更彻底的方案是使用ACL创建受限用户
# user business on >密码 ~cache:* +get +set -@dangerous

场景三：Docker容器部署。这里有一个经典的坑：容器内使用bind 0.0.0.0并映射端口到宿主机时，如果宿主机有公网IP且云服务器安全组放行了6379端口，Redis就完全暴露了。此时必须确保设置了密码，并建议配合云厂商的安全组只放行可信来源IP，而不是依赖protected-mode兜底。

此外还有几条通用建议：生产环境永远不要使用无密码配置；密码建议配合ACL体系按业务分配不同权限的账号；通过网络层手段（iptables、安全组、VPC内网隔离）限制6379端口的可达范围；定期审计CONFIG GET相关配置，避免配置被意外回退。protected-mode只是Redis安全体系的第一道门，它解决的是"忘记设防"的问题，真正的安全需要密码、网络隔离、权限最小化多层措施共同保障。

总结一下，protected-mode在Redis未绑定外部地址且未设置密码时自动生效，拦截所有远程命令请求，这是一个保护粗心运维的兜底机制。理解它的触发条件后，你应该根据实际部署场景正确组合bind、requirepass和ACL配置，而不是简单粗暴地关闭它。安全的本质是层层设防，让每一层都发挥作用，Redis实例才能既好用又安全。

Redis protected-modeRedis安全配置Redis远程访问修改时间：2026-09-02 06:52:27