Redis公网部署避坑指南：从裸奔到穿盔甲的实战记录

上周帮朋友公司排查一个诡异的Redis性能问题，发现他们直接把6379端口裸暴露在公网上，连个防火墙规则都没配。这让我想起刚工作那会儿自己部署Redis时踩过的坑，今天就把这些年总结的公网环境部署Redis的正确姿势分享给大家。

1. 为什么Redis默认配置很危险？

Redis的默认配置redis.conf里有几个”要命”的设定：

• 默认监听所有网卡（0.0.0.0）
• 默认无密码保护
• 默认允许危险命令（比如FLUSHALL）

我第一次部署时就中招了——某天发现数据库莫名其妙被清空，查日志才发现是被人用redis-cli -h 我的IP连上来执行了FLUSHALL…

2. 基础安全三板斧

# 修改redis.conf关键配置
bind 127.0.0.1  # 只允许本地访问
requirepass yourStrongPassword123!
rename-command FLUSHALL ""  # 禁用危险命令

但现实情况往往是：必须开放公网访问（比如跨机房同步）。这时候就需要进阶方案：

3. 公网环境下的生存法则

我的实战经验是分三步走：

1. 改端口：不用默认6379，改成随机高位端口（比如16379）
2. 加白名单：用iptables/IPset限制可访问IP
3. 上TLS：Redis 6.0+支持加密传输，配置示例：

# 生成证书（生产环境建议用正规CA）
openssl req -x509 -newkey rsa:4096 -nodes -keyout redis.key -out redis.crt -days 365

# redis.conf配置
tls-port 16379
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key

4. 那些年我踩过的坑

说几个真实案例：

• 密码复杂度不够：某次用redis123当密码，3天后被暴力破解
• 忘记限制内存：公网Redis被注入超大key导致OOM
• ACL配置失误：给子账号开放了CONFIG权限导致被提权

现在我的检查清单一定会包含：

# 内存限制+保护模式
maxmemory 2gb
maxmemory-policy volatile-lru
protected-mode yes

# 使用ACL精细化控制
acl setuser workeruser on >workerpass ~cache:* +get +set

5. 终极方案：VPN/跳板机

对于特别敏感的环境，我的建议是：不要让Redis直接暴露在公网。通过WireGuard组网，或者用SSH隧道访问：

# SSH端口转发示例
ssh -L 6379:localhost:6379 user@redis-server

最近帮客户做安全审计时发现，90%的Redis安全问题其实都可以通过禁止公网直连来避免。

最后提醒：改完配置一定要redis-cli auth yourpassword测试下，别像我当年那样改完conf文件就自信满满下班，结果半夜被报警短信吵醒…