Redis 暴露公网有多危险？从端口检查到补救步骤

Redis 暴露公网有多危险？从端口检查到补救步骤

Redis 不该裸奔在公网。它常被当成缓存、队列或会话存储，一旦无密码、弱密码或老版本暴露出去，轻则数据被删，重则被写入计划任务或当成攻击跳板。本文不讲复杂安全理论，只给一套小服务器能立刻执行的检查和补救清单。

先判断有没有暴露

在服务器本机看监听地址：

ss-lntp|grep6379dockerps--format'table {{.Names}}\t{{.Ports}}'

如果看到0.0.0.0:6379或:::6379，说明它可能对外开放。再检查云厂商安全组、系统防火墙和 Compose 端口映射。很多人以为自己只在 Docker 内部用 Redis，结果写了：

ports:-"6379:6379"

这会把 Redis 暴露到宿主机端口。多数应用场景根本不需要这样做。

配置和成本建议

Redis 本身省资源，但安全边界不能省。个人应用缓存 1 核 2G 足够，小团队服务建议 2 核 4G 起步，内存要给业务留余量，不要让 Redis 把系统挤到 swap。更重要的是限制访问来源。

我会把带 Redis 的轻量应用放在雨云服务器 rainyun-com的 2 核 4G 机型上，缓存、队列和 Web 服务同机运行比较稳。注册填优惠码2026off领 5折，配置够用之后，把安全组和备份做好才是关键。

正确的 Compose 写法

如果 Redis 只给同一个 Compose 里的应用用，不要写ports，让它只在内部网络暴露：

services:redis:image:redis:7restart:unless-stoppedcommand:["redis-server","--appendonly","yes","--requirepass","change-this-password"]volumes:-./redis-data:/dataapp:image:example/app:stableenvironment:REDIS_URL:redis://:change-this-password@redis:6379/0

如果确实需要远程连接，优先走 VPN 或内网，不要直接开公网。必须开放时，只允许固定 IP 访问，并使用强密码和最小权限网络。

已经暴露了怎么办

先收口入口，再判断是否被动过：

1. 立刻在安全组和防火墙关闭6379/tcp公网访问。
2. 删除 Compose 里的 Redisports映射。
3. 修改 Redis 密码和应用连接串。
4. 查看日志、计划任务、可疑进程和 SSH 登录记录。
5. 如果机器已经出现异常进程，优先重装或从干净备份恢复。

不要只改密码就算修好。暴露过的服务要按“可能被碰过”处理，至少检查系统层面有没有异常。

验证是否安全

从另一台外网机器测试：

nc-vz你的服务器IP6379

预期结果应该是连接失败或超时。然后在应用内部确认功能正常，比如登录、任务队列、缓存刷新是否可用。安全收口不能以业务不可用为代价，所以外部拒绝和内部可用都要验证。

常见误区

“Redis 有密码就能暴露公网”是误区。密码可能泄露，老版本可能有风险，弱密码会被撞。另一个误区是只看系统防火墙，不看云安全组；云服务器通常有两层入口，漏一层都可能出事。

还有人把 Redis 数据目录和应用数据一起公开备份，这也不合适。缓存可以丢，队列和会话则要看业务性质，别把所有 Redis 数据都当无价值临时文件。

总结

Redis 安全的核心原则很简单：能不暴露就不暴露，能内网访问就不用公网，必须公网访问就只放行固定来源。