Redis 这东西几乎每个后端项目都会碰本地装完跑起来顺风顺水可一旦要把服务从测试机搬出去或者让同事从自己电脑上连一下十有八九会卡在连不上这三个字上。我自己第一次做这件事的时候改完配置直接redis-cli -h一把梭结果返回一串连接超时翻了半小时文档才发现是防火墙没开。后面又踩过 Docker 端口映射、密码改了没生效、云服务器安全组忘了放行一堆坑。这篇就把让 Redis 能被外网访问这件事从头到尾讲透包括配置怎么改、网络怎么通、怎么验证、以及最容易被忽略的安全加固。适合刚接手 Redis 运维的开发同学、需要做远程调试的测试同学还有自己搭小项目想从家里连服务器的那批人。读完之后你至少能做到知道每一步为什么这么改出了问题知道从哪一层开始查而不是盲目重启服务。1. 先搞清楚Redis 默认为什么只让本机连把 Redis 装好之后直接redis-cli敲命令一切正常。但如果你在另一台机器上执行redis-cli -h 服务器IP大概率是连不上的。这不是配置出错了而是 Redis 出厂状态下故意这么设计的。理解这个设计意图后面的每一步修改你才知道自己在动什么。1.1 bind 和 protected-mode 到底各管一段什么很多人以为外网不能连是一个开关控制的实际上至少有两个独立机制在拦你加上操作系统防火墙就是三层。第一层是bind指令。Redis 5 之后的默认配置文件里写的是bind 127.0.0.1 -::1意思是只监听本机回环地址。这个参数的作用对象是网卡Redis 只会绑定在你指定的那几个 IP 对应的网络接口上。换句话说如果服务器有内网网卡 172.16.0.10 和公网网卡 203.0.113.5而 bind 里只写了 127.0.0.1那么从任何非本机的地址发过来的包进程根本收不到内核在 TCP 层面就直接把连接拒绝了。这是最硬的一层。第二层是protected-mode。这个参数从 Redis 3.2 引入本意是给那些忘了配密码又暴露了端口的人兜底。它的判断逻辑挺有意思如果 protected-mode 是 yes并且配置里没有任何 bind 指令或者 bind 了通配地址 0.0.0.0同时又没有设置密码那么 Redis 会拒绝来自非回环地址的连接并返回一条明确的错误提示。反过来只要你设置了密码或者 bind 了明确的地址protected-mode 就不再是障碍。很多人以为 protected-mode 是万能开关其实它只是在完全裸奔的情况下才生效。第三层是操作系统防火墙和云平台安全组。前两层是 Redis 自己的事第三层是系统的事两者互不干涉。这三层是与的关系任何一层没放行连接都会失败。提示排查连接问题时一定要按这个顺序从下往上查先确认 Redis 在监听什么地址ss -lntp | grep 6379再确认防火墙放行了没最后才怀疑配置写错了。顺序反了会浪费大量时间。1.2 哪些场景真的需要放开外网访问不是所有情况都该把 Redis 往公网推。我见过最离谱的是有人为了图省事把生产库的 6379 直接对全网开放密码还是123456。这种做法风险极高后面会专门讲后果。真正合理的场景大概有这么几类。第一种是开发和测试环境你自己在本地写代码需要连公司测试机上跑着的 Redis这种场景下机器本身在同一个办公网或者通过内网隧道访问可以选择只绑定内网地址而不是真的暴露到公网。第二种是小团队自建服务测试机部署在云服务器上只有固定的几个出口 IP 需要访问这时候可以通过安全组做 IP 白名单比全网开放安全得多。第三种是跨机房或者异地部署的主从复制从节点需要连主节点的端口做同步这种一般走内网专线如果确实要走公网强烈建议配上 TLS 和对端认证。我自己给自己家里那台小主机上的 Redis 做远程访问用的就是固定 IP 白名单加超长密码方案端口也从 6379 改成了高位端口。虽然改端口只是减少被扫描到的概率但配合白名单实际暴露面已经非常小了。1.3 放开前必须守住的几条底线在动手改配置之前先问自己三个问题这个 Redis 里有没有不能丢的数据第二个问题是能不能接受它被任意人读写第三个问题是如果它被清空或者被灌入垃圾数据恢复成本是多少只要第一个问题的答案是有那就必须先备份。BGSAVE生成一份 RDB或者用redis-cli --rdb直接拉一份下来落到本地。我就遇到过同事为了远程调试方便开了公网第二天发现 key 全没了还多了一堆莫名其妙的键而偏偏那台机器上没开持久化数据彻底找不回来。底线原则我总结成一句话密码是必选项白名单是加分项改端口是顺手的事TLS 是数据敏感时的必选项。这四条不做到宁可不开放。另外还要明确一点Redis 6 虽然引入了 ACL但默认用户如果没有密码等于没保护别以为升级了版本就自动安全了。2. 配置文件改造把只认 127.0.0.1改成接受远程确认了需求、定好了安全策略接下来就是改配置。Redis 的配置有两种方式直接编辑redis.conf文件或者在运行时用CONFIG SET动态改。这两种方式的影响范围不同用错了会给你埋坑。2.1 bind 的三种写法与取舍逻辑打开redis.conf找到bind那一行通常长这样bind 127.0.0.1 -::1改成什么取决于你的网络环境一共有三种选择。第一种是绑定具体网卡 IP比如服务器内网地址是 172.16.0.10公网地址是 203.0.113.5只希望内网机器能访问bind 172.16.0.10这是最推荐的做法因为 Redis 只会在这一张网卡上监听从公网 IP 发来的连接在内核层面就被挡掉了等于天然做了一层隔离。缺点是如果你换了机器、网卡 IP 变了得回来改配置。第二种是绑定通配地址bind 0.0.0.0这表示监听所有网卡。这是最容易踩坑的写法因为一旦这样配Redis 就同时暴露在内网和公网上了。很多教程直接甩一句把 bind 改成 0.0.0.0 就行完全不提风险害人不浅。如果你确实要用这个写法请务必配合防火墙和安全组把可访问来源限制住。第三种是 Redis 6.2 之后支持的写法可以混写多个地址bind 127.0.0.1 172.16.0.10这样本机和内网都能连公网依然不行。我个人最常用这种因为运维脚本、监控程序一般在机器本地跑用 127.0.0.1 更稳定不受网卡变化影响。注意bind 后面的-::1前缀减号表示如果这个地址不可用也不会启动失败IPv6 环境下会用到。如果你的机器没开 IPv6去掉也无所谓但留着更保险。这里还有个细节容易忽略bind修改后必须重启 Redis 才生效CONFIG SET bind在多数版本上是不支持的因为重新绑定网卡涉及 socket 重建。我试过在 6.x 上执行CONFIG SET bind返回的是不支持。所以改这个参数请做好重启计划生产环境提前走一次SHUTDOWN SAVE或者BGSAVE。2.2 protected-mode 关闭的代价配置里还有一行protected-mode yes要不要关掉我的建议是如果你已经设置了密码这一行保持 yes 也没关系因为它只在无密码无 bind 时才拦截。但实际情况是很多人改了 bind 之后发现还是连不上于是无脑把 protected-mode 改成 no问题解决了但安全边界同时也消失了。它的触发条件是没有 bind 配置项 没有密码只要满足其中任意一条保护条件它就不拦截。所以正确的思路不是关掉它而是通过设置密码来满足它的放行条件让它自己失效。这样即使某天有人手滑清空了 bind 配置还有密码这层兜底。如果你确实要临时关闭运行时执行redis-cli CONFIG SET protected-mode no这个是可以动态生效的不用重启。但请记住这只是临时关闭重启后会恢复配置文件里的值。要在配置文件里永久关闭才需要改文件并重启。有个真实案例值得说一下。曾经有个团队在测试机上把 protected-mode 关了也没设密码觉得测试机而已没人看。结果某天发现机器 CPU 跑满上去一看 Redis 里多了一堆异常的键还被人写进了启动任务。虽然数据本身不敏感但机器被占用了资源。这就是典型的无密码裸奔后果跟环境是测试还是生产没关系扫描是全网无差别进行的。2.3 requirepass 与 ACL 用户认证这一步不能省设置密码有两种方式老式的requirepass和 Redis 6 引入的 ACL。老式写法在配置文件里就一行requirepass YourStrongPassword_2024改完重启或者用CONFIG SET requirepass动态设置。客户端连接时redis-cli -h 203.0.113.5 -p 6379 -a YourStrongPassword_2024这里有个安全小提醒命令行直接跟-a参数密码会出现在 shell 历史里也会在ps输出里短暂可见。更稳妥的做法是先用不带密码的方式连上再执行AUTHredis-cli -h 203.0.113.5 -p 6379 AUTH YourStrongPassword_2024或者用环境变量传给客户端很多语言的 SDK 都支持从环境变量读。ACL 的方式更适合多人多应用场景。比如你有两个服务要连同一个 Redis一个只需要读一个需要读写可以这样配user reader on ReadOnlyPass123 ~cache:* get mget user writer on ReadWritePass456 ~* all -dangerous这里~cache:*限定了这个用户只能访问 cache 前缀的键get mget是只允许这两个读命令。writer用户则通过-dangerous禁掉了所有危险命令组。这种做法比一个全局密码精细得多也符合最小权限原则。我个人的经验是小项目用 requirepass 就够了但只要有超过两个调用方就该上 ACL。因为一旦需要给某个调用方单独回收权限全局密码的做法只能改密码改完所有调用方都得同步更新牵一发动全身。提示密码长度建议 32 位以上包含大小写、数字和符号。别用生日、项目名这类可猜测的字符串。密码强度这件事在公网环境下真的不是矫情。2.4 顺带要调的几个参数除了上面三个核心参数还有几个参数在开放外网访问时值得一起调整。port端口号从 6379 改成高位端口比如 16379能减少被自动化扫描工具命中的概率。这个动作不构成真正的安全防护但属于低成本高收益的操作就像把家门从一楼搬到三楼不能防住有意针对你的人但能过滤掉大量随机试探。timeout默认是 0 表示连接永不超时。长期保持空闲的连接会占用文件描述符开放外网后可能有各种扫描器建立连接然后挂在那里建议设成 300 秒左右timeout 300tcp-keepalive默认 300这个可以保持它的作用是定期探测死连接并清理。maxclients默认 10000一般够用。但如果你把 Redis 暴露在公网扫描器短时间内建大量连接是常态可能需要观察connected_clients指标必要时往下调避免连接数被打满导致正常业务连不上。tcp-backlog默认 511高并发场景下可以调到 1024 甚至 2048不过这个参数调整需要同时看系统内核的somaxconn设置两边不匹配的话以较小值为准。最后是持久化相关。开放外网后风险上升建议至少开启 RDB 快照save 900 1这类配置保留着万一出问题还有一份数据可以回滚。AOF 视业务对数据完整性的要求决定不是必须。3. 网络与系统层改完配置还是连不上怎么办配置文件改完了服务也重启了ss -lntp看端口确实在监听 0.0.0.0但远程连还是超时。这时候问题基本不在 Redis 身上了得往下走看系统和网络。3.1 服务器防火墙规则的正确写法Linux 服务器上常见的是 firewalld 和 iptables 两套Ubuntu 系还可能用 ufw。先确认系统跑的是哪个。firewalld 环境下放行指定端口firewall-cmd --permanent --add-port6379/tcp firewall-cmd --reload firewall-cmd --list-ports但这样是全网放行。如果要限制来源 IP需要用富规则firewall-cmd --permanent --add-rich-rulerule familyipv4 source address198.51.100.23 port protocoltcp port6379 accept firewall-cmd --reloadiptables 环境iptables -A INPUT -p tcp -s 198.51.100.23 --dport 6379 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP注意顺序ACCEPT 必须在 DROP 前面因为 iptables 是从上往下匹配的命中就停。顺序写反了会导致白名单失效。另外 iptables 规则默认不持久化重启就丢需要iptables-save或者用iptables-persistent包保存。ufw 相对简单ufw allow from 198.51.100.23 to any port 6379 proto tcp这里有个坑我踩过有些系统同时装了 firewalld 和 iptables或者 Docker 启动时会自己往 iptables 里插规则导致你手动配的规则被覆盖或者失效。排查的时候建议用iptables -L -n --line-numbers把完整的规则链打出来看一遍别只看自己加的那条。注意不要为了图快直接iptables -F清空所有规则这会把你 SSH 的端口规则一起清掉如果当前会话一断就再也连不上了。要清也得先确保 SSH 放行规则存在或者用定时任务做兜底恢复。3.2 云服务器安全组与端口策略如果你用的是云主机除了系统防火墙还有一层云平台的安全组。这层在系统之外系统里怎么配都影响不到它。安全组没放行包在到达你的服务器之前就被云平台拦掉了。配置思路和防火墙类似但入口在控制台。添加一条入站规则协议 TCP端口 6379来源填你的固定 IP 加 /32 后缀表示单个地址比如198.51.100.23/32。如果办公网出口 IP 会变可以填一个网段但网段越大风险越高不建议直接填0.0.0.0/0。还有个细节不少云平台的安全组规则有优先级和拒绝规则如果你同时配了允许和拒绝要注意优先级数值数字小的先匹配。这个每家平台的实现不太一样配置前花两分钟看一眼文档说明比事后排查半天划算。动态出口 IP 的场景确实麻烦。我自己的处理方式是在家里路由器上固定了出口或者用云平台的 VPC 内网互通让本地开发机通过专线或内网连过去避免公网暴露。如果这些条件都不具备退而求其次的做法是定期更新白名单写个脚本从某个地方读取当前 IP 然后调用云平台 API 更新规则。这个方案能用但复杂度上去了适合有运维能力的团队。3.3 Docker 部署下的端口映射与常见误区Docker 环境下有两个独立的配置点很多人只改了一个自然连不上。第一个是docker run或者 compose 文件里的端口映射docker run -d --name redis -p 6379:6379 redis:7这里的6379:6379前半段是宿主机端口后半段是容器端口。如果写成127.0.0.1:6379:6379那就只有宿主机本机能访问公网依然不行。写成6379:6379默认等价于0.0.0.0:6379:6379所有网卡都监听。第二个是容器内 Redis 自己的 bind 配置。官方镜像默认的 redis.conf 里 bind 是0.0.0.0其实已经允许容器内所有接口了但有些自定义镜像或者挂载了自己的配置文件可能还是 127.0.0.1。这时候即使端口映射对了容器内部还是只监听回环宿主机转发进来的连接会被拒。用 compose 的话长这样services: redis: image: redis:7 command: [redis-server, /usr/local/etc/redis/redis.conf] ports: - 6379:6379 volumes: - ./redis.conf:/usr/local/etc/redis/redis.conf注意 command 里显式指定了配置文件因为如果只是挂载文件但没告诉 Redis 去读它配置是不生效的。这个坑我见过不止一次挂载了半天没效果就是因为没加 command。还有个容易忽略的点Docker 会修改宿主机的 iptables 规则来实现端口映射。如果你在宿主机上配了 iptables 白名单可能会发现 Docker 的规则优先级更高直接把流量转发进来了。这种情况需要在DOCKER-USER链里加限制规则而不是在INPUT链里。Docker 官方文档里对这条链有说明值得看一眼。验证容器内的监听情况docker exec -it redis_container ss -lntp如果显示的是0.0.0.0:6379说明容器内没问题如果是127.0.0.1:6379那就是配置文件的问题得改容器内的 bind。3.4 三段式验证本机、局域网、公网配置改完之后不要直接跳到公网测试按三段式来能快速定位问题出在哪一层。第一段服务器本机验证redis-cli -h 127.0.0.1 -p 6379 ping返回 PONG 说明 Redis 进程正常。这一步失败说明服务本身有问题跟网络无关。第二段同内网另一台机器验证redis-cli -h 172.16.0.10 -p 6379 ping成功说明 bind 和防火墙的内网部分没问题。失败就要看 bind 有没有包含内网地址防火墙有没有放行内网网段。第三段从公网或者你本地电脑验证redis-cli -h 203.0.113.5 -p 6379 -a YourPassword ping这三步走下来哪一段断了问题就在哪一段不用到处乱猜。图形化客户端这边Redis Desktop Manager现在叫 RESP.app配置时注意几个字段主机填公网 IP端口填你改后的端口密码填 requirepass 设的那个。如果连的是 ACL 用户用户名那一栏要填对默认用户是 default。连接失败时它的报错信息其实挺有用能区分是超时、拒绝还是认证失败比命令行更直观一些。提示如果你在本地测的时候用了代理工具记得确认流量走向。有时候明明配置没问题就是因为本地环境把流量导到了别处导致验证结果失真。测试时最好用直连方式避免中间层干扰判断。4. 安全加固让能连变成只有该连的人能连端口通了不代表事情做完了。开放外网访问之后Redis 就进入了被持续扫描的暴露面这一步才是真正决定你会不会出事的关键。4.1 危险命令重命名与禁用Redis 有几个命令一旦被外部调用破坏力很大。FLUSHALL清空所有数据库FLUSHDB清空当前库CONFIG可以改配置甚至写文件KEYS在数据量大时会阻塞主线程SHUTDOWN直接关服务。重命名的写法是在配置文件里rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG CONFIG_a8f3d9e1 rename-command KEYS rename-command SHUTDOWN 把命令重命名成空字符串就是彻底禁用的意思。给 CONFIG 换个随机名字只有知道你才知道这个名字的人能调用运维脚本里用新名字就行。这里有个实际操作上的取舍。禁用 FLUSHALL 之后万一真的需要清库怎么办我一般会把FLUSHDB保留但重命名成一个复杂字符串只在紧急情况下用并且记录在团队的运维手册里。全禁了到关键时刻反而手忙脚乱。还有一点要提醒rename-command修改后必须重启生效而且改了之后主从复制如果涉及命令传递要确认从节点也同步改了否则同步可能失败。这个坑比较隐蔽主从环境升级时要注意。4.2 最小权限 ACL 用户的完整配置Redis 6 的 ACL 是这几年最值得用的安全特性。基本语法是user 用户名 on/off 密码 ~键模式 命令 -命令举一个稍微完整点的例子假设你有一个业务只需要读写session:开头的键user session_svc on S3ss10n_Pss_2024 ~session:* session:* read write -dangerous~session:*限定可访问的键模式session:*限定可访问的频道模式用于发布订阅read write表示允许读写命令组-dangerous再从中剔除危险命令。这样即使这个账号的密码泄露攻击者也只能操作 session 相关的键且不能执行 FLUSH 这类破坏性操作损失被控制在有限范围内。创建和查看用户ACL SETUSER session_svc on S3ss10n_Pss_2024 ~session:* read write -dangerous ACL LIST ACL WHOAMI ACL GETUSER session_svc生产环境里我建议把 ACL 配置写进redis.conf的ACLFILE引用的外部文件里方便版本管理和审计而不是散在配置里。4.3 TLS 通道与端口收敛如果 Redis 传的是敏感数据比如用户凭证、支付相关信息那公网明文传输是不可接受的。Redis 6 开始原生支持 TLS配置如下tls-port 16379 port 0 tls-cert-file /etc/redis/tls/redis.crt tls-key-file /etc/redis/tls/redis.key tls-ca-cert-file /etc/redis/tls/ca.crt tls-auth-clients yesport 0表示关闭非加密端口只保留 TLS 端口。tls-auth-clients yes要求客户端也提供证书做双向认证安全性更高。客户端连接时redis-cli --tls --cacert /etc/redis/tls/ca.crt -h 203.0.113.5 -p 16379TLS 会带来一定的性能开销实测在普通业务量级下影响不大握手阶段的延迟增加比较明显但连接复用之后基本可以忽略。如果业务是超高频的小请求需要压测一下再决定。证书这块有个实用建议别用自签证书然后到处关校验很多客户端关了校验等于没加密的意义。要么用正规机构签发的要么在内网自建 CA 并把 CA 证书分发到各个客户端让校验真正生效。4.4 日志监控与异常告警加固做完不等于可以躺着。持续的监控能让你在出事之前发现问题。Redis 自带的INFO命令里有几个指标值得关注。connected_clients突然飙升往往是被扫描或者被攻击的信号total_connections_received的增速能反映连接模式是否正常rejected_connections大于零说明连接数被打满了keyspace_hits和keyspace_misses的比值能反映缓存是否有效。日志方面logfile参数指定日志路径loglevel notice是常用级别。关键是要关注包含Accepted、refused、possible security这类关键字的记录。Redis 在检测到可疑配置时也会往日志里写警告。再进一步可以开启慢查询日志slowlog-log-slower-than 10000 slowlog-max-len 128超过 10 毫秒的命令会被记录用SLOWLOG GET查看。开放外网之后如果有人在跑KEYS *这类命令慢查询日志里会看得很清楚。提示把这些指标接到现有的监控体系里设置阈值告警。连接数突增、拒绝连接数大于零、有大量认证失败这三类告警建议必配。等到用户反馈服务不可用再去查通常已经晚了一步。5. 排障实录那些年踩过的连接问题前面讲的是怎么配这一节讲配了还不行怎么办。我把这几年遇到过的典型问题整理成了速查形式。5.1 连接超时、拒绝连接、认证失败对照表光看报错信息其实能定位到大概方向关键是别把三类错误混在一起。超时通常是网络层没通拒绝连接是端口没监听或者被防火墙拦了认证失败则是配置正确但密码或用户名不对。下面这张表是我自己排障时常用的对照现象常见原因排查方向典型解决Connection timed out防火墙或安全组未放行检查系统防火墙和云安全组添加放行规则并重载Connection refused端口未监听或 bind 不含目标 IPss -lntp看监听地址修改 bind 并重启NOAUTH Authentication required未提供密码客户端未配置密码补上密码或 AUTH 命令WRONGPASS invalid username-password密码错误或用户不存在核对 requirepass 或 ACL 用户重设密码并同步客户端Connection reset by peer中间设备断开或 TLS 不匹配检查 TLS 配置与中间链路统一 TLS 客户端配置连接成功但命令报 NOPERMACL 权限不足ACL GETUSER查看权限补上对应命令或键模式这张表基本能覆盖八成的情况。剩下两成属于环境特有问题比如容器网络模式、多网卡路由选择这些需要单独分析。5.2 配置改了不生效的几种原因这个问题特别高频我总结了四种常见原因。第一种改了配置文件但没重启而且改的是不支持动态修改的参数。像 bind 这类只能重启生效CONFIG SET会直接返回错误。判断方法很简单CONFIG GET bind看运行时值和文件里的值是否一致。第二种改错了文件。系统上可能同时存在/etc/redis/redis.conf和源码目录里的redis.conf服务实际读的是启动命令里指定的那一个。用ps -ef | grep redis-server看启动参数里面会带配置文件的完整路径。第三种Docker 里挂载了配置文件但启动命令没引用。前面提过需要 command 里显式指定。或者容器里的路径写错了挂载到了别的地方。第四种被其他配置覆盖。比如你在命令行启动时传了--bind 127.0.0.1那么配置文件里的 bind 会被命令行参数覆盖。启动参数优先级高于配置文件。排查这类问题的通用方法先用CONFIG GET看运行时实际值如果运行时值和你期望的不一样再去确认启动命令和实际加载的文件路径。5.3 主从复制与集群场景下的外网访问主从复制场景下从节点的配置要比单机多考虑一层。从节点需要replicaof指向主节点replicaof 203.0.113.5 6379 masterauth YourMasterPassword masteruser repl_user如果主从跨公网建议单独开一个复制用户只给复制所需的最小权限user repl_user on Repl_Pss_2024 ~* psync replconf ping这样即使复制账号泄露攻击者也无法执行读写命令。集群模式下情况更复杂因为节点之间需要互相通信客户端的 MOVED 重定向返回的是节点的内网 IP从外网连会连不上。常见做法是让客户端通过内网访问或者用cluster-announce-ip和cluster-announce-port显式告诉集群对外宣告哪个地址。这两个参数在容器和 NAT 环境下特别重要cluster-announce-ip 203.0.113.5 cluster-announce-port 6379 cluster-announce-bus-port 16379不配的话集群内部通信正常但客户端拿到的重定向地址是容器内部 IP公网根本路由不到表现为能连上但一操作就超时。我个人在跨公网做 Redis 主从时的体会是能不走公网就不走。延迟带来的复制滞后会很明显网络抖动还可能触发全量同步数据量大的时候一次全量同步能跑很久期间主节点压力上升。如果必须走务必配好压缩和合理的repl-backlog-size并且监控复制延迟指标master_repl_offset和从节点的slave_repl_offset差值。提示跨公网复制建议先小规模压测一次观察同步耗时和主节点负载变化别直接上生产。全量同步期间的 fork 操作会消耗较多内存数据量大的实例要预留足够余量。最后再分享一个我自己的习惯。每次开放外网访问之后我都会做一次攻击者视角的自检从一台陌生网络环境的机器上尝试连接看没有密码、错误密码、正确密码三种情况下分别是什么反应用端口扫描工具看除了业务端口还有没有别的口暴露在外翻一遍 Redis 日志看有没有异常的认证失败记录。这套自检大概花十分钟但能提前发现大部分配置疏忽。还有一点配置变更一定要留记录。什么时候开的、开了多久、给谁开的、什么时候关的写在一个共享文档里。我见过测试环境开了公网之后就忘了关一放就是半年中间经历了三次服务器迁移愣是没人记得这个口子是干什么用的。这种遗忘的开放才是最难防的隐患。 Redis 外网访问配置与安全加固：bind、防火墙与Docker排障
Redis 这东西几乎每个后端项目都会碰本地装完跑起来顺风顺水可一旦要把服务从测试机搬出去或者让同事从自己电脑上连一下十有八九会卡在连不上这三个字上。我自己第一次做这件事的时候改完配置直接redis-cli -h一把梭结果返回一串连接超时翻了半小时文档才发现是防火墙没开。后面又踩过 Docker 端口映射、密码改了没生效、云服务器安全组忘了放行一堆坑。这篇就把让 Redis 能被外网访问这件事从头到尾讲透包括配置怎么改、网络怎么通、怎么验证、以及最容易被忽略的安全加固。适合刚接手 Redis 运维的开发同学、需要做远程调试的测试同学还有自己搭小项目想从家里连服务器的那批人。读完之后你至少能做到知道每一步为什么这么改出了问题知道从哪一层开始查而不是盲目重启服务。1. 先搞清楚Redis 默认为什么只让本机连把 Redis 装好之后直接redis-cli敲命令一切正常。但如果你在另一台机器上执行redis-cli -h 服务器IP大概率是连不上的。这不是配置出错了而是 Redis 出厂状态下故意这么设计的。理解这个设计意图后面的每一步修改你才知道自己在动什么。1.1 bind 和 protected-mode 到底各管一段什么很多人以为外网不能连是一个开关控制的实际上至少有两个独立机制在拦你加上操作系统防火墙就是三层。第一层是bind指令。Redis 5 之后的默认配置文件里写的是bind 127.0.0.1 -::1意思是只监听本机回环地址。这个参数的作用对象是网卡Redis 只会绑定在你指定的那几个 IP 对应的网络接口上。换句话说如果服务器有内网网卡 172.16.0.10 和公网网卡 203.0.113.5而 bind 里只写了 127.0.0.1那么从任何非本机的地址发过来的包进程根本收不到内核在 TCP 层面就直接把连接拒绝了。这是最硬的一层。第二层是protected-mode。这个参数从 Redis 3.2 引入本意是给那些忘了配密码又暴露了端口的人兜底。它的判断逻辑挺有意思如果 protected-mode 是 yes并且配置里没有任何 bind 指令或者 bind 了通配地址 0.0.0.0同时又没有设置密码那么 Redis 会拒绝来自非回环地址的连接并返回一条明确的错误提示。反过来只要你设置了密码或者 bind 了明确的地址protected-mode 就不再是障碍。很多人以为 protected-mode 是万能开关其实它只是在完全裸奔的情况下才生效。第三层是操作系统防火墙和云平台安全组。前两层是 Redis 自己的事第三层是系统的事两者互不干涉。这三层是与的关系任何一层没放行连接都会失败。提示排查连接问题时一定要按这个顺序从下往上查先确认 Redis 在监听什么地址ss -lntp | grep 6379再确认防火墙放行了没最后才怀疑配置写错了。顺序反了会浪费大量时间。1.2 哪些场景真的需要放开外网访问不是所有情况都该把 Redis 往公网推。我见过最离谱的是有人为了图省事把生产库的 6379 直接对全网开放密码还是123456。这种做法风险极高后面会专门讲后果。真正合理的场景大概有这么几类。第一种是开发和测试环境你自己在本地写代码需要连公司测试机上跑着的 Redis这种场景下机器本身在同一个办公网或者通过内网隧道访问可以选择只绑定内网地址而不是真的暴露到公网。第二种是小团队自建服务测试机部署在云服务器上只有固定的几个出口 IP 需要访问这时候可以通过安全组做 IP 白名单比全网开放安全得多。第三种是跨机房或者异地部署的主从复制从节点需要连主节点的端口做同步这种一般走内网专线如果确实要走公网强烈建议配上 TLS 和对端认证。我自己给自己家里那台小主机上的 Redis 做远程访问用的就是固定 IP 白名单加超长密码方案端口也从 6379 改成了高位端口。虽然改端口只是减少被扫描到的概率但配合白名单实际暴露面已经非常小了。1.3 放开前必须守住的几条底线在动手改配置之前先问自己三个问题这个 Redis 里有没有不能丢的数据第二个问题是能不能接受它被任意人读写第三个问题是如果它被清空或者被灌入垃圾数据恢复成本是多少只要第一个问题的答案是有那就必须先备份。BGSAVE生成一份 RDB或者用redis-cli --rdb直接拉一份下来落到本地。我就遇到过同事为了远程调试方便开了公网第二天发现 key 全没了还多了一堆莫名其妙的键而偏偏那台机器上没开持久化数据彻底找不回来。底线原则我总结成一句话密码是必选项白名单是加分项改端口是顺手的事TLS 是数据敏感时的必选项。这四条不做到宁可不开放。另外还要明确一点Redis 6 虽然引入了 ACL但默认用户如果没有密码等于没保护别以为升级了版本就自动安全了。2. 配置文件改造把只认 127.0.0.1改成接受远程确认了需求、定好了安全策略接下来就是改配置。Redis 的配置有两种方式直接编辑redis.conf文件或者在运行时用CONFIG SET动态改。这两种方式的影响范围不同用错了会给你埋坑。2.1 bind 的三种写法与取舍逻辑打开redis.conf找到bind那一行通常长这样bind 127.0.0.1 -::1改成什么取决于你的网络环境一共有三种选择。第一种是绑定具体网卡 IP比如服务器内网地址是 172.16.0.10公网地址是 203.0.113.5只希望内网机器能访问bind 172.16.0.10这是最推荐的做法因为 Redis 只会在这一张网卡上监听从公网 IP 发来的连接在内核层面就被挡掉了等于天然做了一层隔离。缺点是如果你换了机器、网卡 IP 变了得回来改配置。第二种是绑定通配地址bind 0.0.0.0这表示监听所有网卡。这是最容易踩坑的写法因为一旦这样配Redis 就同时暴露在内网和公网上了。很多教程直接甩一句把 bind 改成 0.0.0.0 就行完全不提风险害人不浅。如果你确实要用这个写法请务必配合防火墙和安全组把可访问来源限制住。第三种是 Redis 6.2 之后支持的写法可以混写多个地址bind 127.0.0.1 172.16.0.10这样本机和内网都能连公网依然不行。我个人最常用这种因为运维脚本、监控程序一般在机器本地跑用 127.0.0.1 更稳定不受网卡变化影响。注意bind 后面的-::1前缀减号表示如果这个地址不可用也不会启动失败IPv6 环境下会用到。如果你的机器没开 IPv6去掉也无所谓但留着更保险。这里还有个细节容易忽略bind修改后必须重启 Redis 才生效CONFIG SET bind在多数版本上是不支持的因为重新绑定网卡涉及 socket 重建。我试过在 6.x 上执行CONFIG SET bind返回的是不支持。所以改这个参数请做好重启计划生产环境提前走一次SHUTDOWN SAVE或者BGSAVE。2.2 protected-mode 关闭的代价配置里还有一行protected-mode yes要不要关掉我的建议是如果你已经设置了密码这一行保持 yes 也没关系因为它只在无密码无 bind 时才拦截。但实际情况是很多人改了 bind 之后发现还是连不上于是无脑把 protected-mode 改成 no问题解决了但安全边界同时也消失了。它的触发条件是没有 bind 配置项 没有密码只要满足其中任意一条保护条件它就不拦截。所以正确的思路不是关掉它而是通过设置密码来满足它的放行条件让它自己失效。这样即使某天有人手滑清空了 bind 配置还有密码这层兜底。如果你确实要临时关闭运行时执行redis-cli CONFIG SET protected-mode no这个是可以动态生效的不用重启。但请记住这只是临时关闭重启后会恢复配置文件里的值。要在配置文件里永久关闭才需要改文件并重启。有个真实案例值得说一下。曾经有个团队在测试机上把 protected-mode 关了也没设密码觉得测试机而已没人看。结果某天发现机器 CPU 跑满上去一看 Redis 里多了一堆异常的键还被人写进了启动任务。虽然数据本身不敏感但机器被占用了资源。这就是典型的无密码裸奔后果跟环境是测试还是生产没关系扫描是全网无差别进行的。2.3 requirepass 与 ACL 用户认证这一步不能省设置密码有两种方式老式的requirepass和 Redis 6 引入的 ACL。老式写法在配置文件里就一行requirepass YourStrongPassword_2024改完重启或者用CONFIG SET requirepass动态设置。客户端连接时redis-cli -h 203.0.113.5 -p 6379 -a YourStrongPassword_2024这里有个安全小提醒命令行直接跟-a参数密码会出现在 shell 历史里也会在ps输出里短暂可见。更稳妥的做法是先用不带密码的方式连上再执行AUTHredis-cli -h 203.0.113.5 -p 6379 AUTH YourStrongPassword_2024或者用环境变量传给客户端很多语言的 SDK 都支持从环境变量读。ACL 的方式更适合多人多应用场景。比如你有两个服务要连同一个 Redis一个只需要读一个需要读写可以这样配user reader on ReadOnlyPass123 ~cache:* get mget user writer on ReadWritePass456 ~* all -dangerous这里~cache:*限定了这个用户只能访问 cache 前缀的键get mget是只允许这两个读命令。writer用户则通过-dangerous禁掉了所有危险命令组。这种做法比一个全局密码精细得多也符合最小权限原则。我个人的经验是小项目用 requirepass 就够了但只要有超过两个调用方就该上 ACL。因为一旦需要给某个调用方单独回收权限全局密码的做法只能改密码改完所有调用方都得同步更新牵一发动全身。提示密码长度建议 32 位以上包含大小写、数字和符号。别用生日、项目名这类可猜测的字符串。密码强度这件事在公网环境下真的不是矫情。2.4 顺带要调的几个参数除了上面三个核心参数还有几个参数在开放外网访问时值得一起调整。port端口号从 6379 改成高位端口比如 16379能减少被自动化扫描工具命中的概率。这个动作不构成真正的安全防护但属于低成本高收益的操作就像把家门从一楼搬到三楼不能防住有意针对你的人但能过滤掉大量随机试探。timeout默认是 0 表示连接永不超时。长期保持空闲的连接会占用文件描述符开放外网后可能有各种扫描器建立连接然后挂在那里建议设成 300 秒左右timeout 300tcp-keepalive默认 300这个可以保持它的作用是定期探测死连接并清理。maxclients默认 10000一般够用。但如果你把 Redis 暴露在公网扫描器短时间内建大量连接是常态可能需要观察connected_clients指标必要时往下调避免连接数被打满导致正常业务连不上。tcp-backlog默认 511高并发场景下可以调到 1024 甚至 2048不过这个参数调整需要同时看系统内核的somaxconn设置两边不匹配的话以较小值为准。最后是持久化相关。开放外网后风险上升建议至少开启 RDB 快照save 900 1这类配置保留着万一出问题还有一份数据可以回滚。AOF 视业务对数据完整性的要求决定不是必须。3. 网络与系统层改完配置还是连不上怎么办配置文件改完了服务也重启了ss -lntp看端口确实在监听 0.0.0.0但远程连还是超时。这时候问题基本不在 Redis 身上了得往下走看系统和网络。3.1 服务器防火墙规则的正确写法Linux 服务器上常见的是 firewalld 和 iptables 两套Ubuntu 系还可能用 ufw。先确认系统跑的是哪个。firewalld 环境下放行指定端口firewall-cmd --permanent --add-port6379/tcp firewall-cmd --reload firewall-cmd --list-ports但这样是全网放行。如果要限制来源 IP需要用富规则firewall-cmd --permanent --add-rich-rulerule familyipv4 source address198.51.100.23 port protocoltcp port6379 accept firewall-cmd --reloadiptables 环境iptables -A INPUT -p tcp -s 198.51.100.23 --dport 6379 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP注意顺序ACCEPT 必须在 DROP 前面因为 iptables 是从上往下匹配的命中就停。顺序写反了会导致白名单失效。另外 iptables 规则默认不持久化重启就丢需要iptables-save或者用iptables-persistent包保存。ufw 相对简单ufw allow from 198.51.100.23 to any port 6379 proto tcp这里有个坑我踩过有些系统同时装了 firewalld 和 iptables或者 Docker 启动时会自己往 iptables 里插规则导致你手动配的规则被覆盖或者失效。排查的时候建议用iptables -L -n --line-numbers把完整的规则链打出来看一遍别只看自己加的那条。注意不要为了图快直接iptables -F清空所有规则这会把你 SSH 的端口规则一起清掉如果当前会话一断就再也连不上了。要清也得先确保 SSH 放行规则存在或者用定时任务做兜底恢复。3.2 云服务器安全组与端口策略如果你用的是云主机除了系统防火墙还有一层云平台的安全组。这层在系统之外系统里怎么配都影响不到它。安全组没放行包在到达你的服务器之前就被云平台拦掉了。配置思路和防火墙类似但入口在控制台。添加一条入站规则协议 TCP端口 6379来源填你的固定 IP 加 /32 后缀表示单个地址比如198.51.100.23/32。如果办公网出口 IP 会变可以填一个网段但网段越大风险越高不建议直接填0.0.0.0/0。还有个细节不少云平台的安全组规则有优先级和拒绝规则如果你同时配了允许和拒绝要注意优先级数值数字小的先匹配。这个每家平台的实现不太一样配置前花两分钟看一眼文档说明比事后排查半天划算。动态出口 IP 的场景确实麻烦。我自己的处理方式是在家里路由器上固定了出口或者用云平台的 VPC 内网互通让本地开发机通过专线或内网连过去避免公网暴露。如果这些条件都不具备退而求其次的做法是定期更新白名单写个脚本从某个地方读取当前 IP 然后调用云平台 API 更新规则。这个方案能用但复杂度上去了适合有运维能力的团队。3.3 Docker 部署下的端口映射与常见误区Docker 环境下有两个独立的配置点很多人只改了一个自然连不上。第一个是docker run或者 compose 文件里的端口映射docker run -d --name redis -p 6379:6379 redis:7这里的6379:6379前半段是宿主机端口后半段是容器端口。如果写成127.0.0.1:6379:6379那就只有宿主机本机能访问公网依然不行。写成6379:6379默认等价于0.0.0.0:6379:6379所有网卡都监听。第二个是容器内 Redis 自己的 bind 配置。官方镜像默认的 redis.conf 里 bind 是0.0.0.0其实已经允许容器内所有接口了但有些自定义镜像或者挂载了自己的配置文件可能还是 127.0.0.1。这时候即使端口映射对了容器内部还是只监听回环宿主机转发进来的连接会被拒。用 compose 的话长这样services: redis: image: redis:7 command: [redis-server, /usr/local/etc/redis/redis.conf] ports: - 6379:6379 volumes: - ./redis.conf:/usr/local/etc/redis/redis.conf注意 command 里显式指定了配置文件因为如果只是挂载文件但没告诉 Redis 去读它配置是不生效的。这个坑我见过不止一次挂载了半天没效果就是因为没加 command。还有个容易忽略的点Docker 会修改宿主机的 iptables 规则来实现端口映射。如果你在宿主机上配了 iptables 白名单可能会发现 Docker 的规则优先级更高直接把流量转发进来了。这种情况需要在DOCKER-USER链里加限制规则而不是在INPUT链里。Docker 官方文档里对这条链有说明值得看一眼。验证容器内的监听情况docker exec -it redis_container ss -lntp如果显示的是0.0.0.0:6379说明容器内没问题如果是127.0.0.1:6379那就是配置文件的问题得改容器内的 bind。3.4 三段式验证本机、局域网、公网配置改完之后不要直接跳到公网测试按三段式来能快速定位问题出在哪一层。第一段服务器本机验证redis-cli -h 127.0.0.1 -p 6379 ping返回 PONG 说明 Redis 进程正常。这一步失败说明服务本身有问题跟网络无关。第二段同内网另一台机器验证redis-cli -h 172.16.0.10 -p 6379 ping成功说明 bind 和防火墙的内网部分没问题。失败就要看 bind 有没有包含内网地址防火墙有没有放行内网网段。第三段从公网或者你本地电脑验证redis-cli -h 203.0.113.5 -p 6379 -a YourPassword ping这三步走下来哪一段断了问题就在哪一段不用到处乱猜。图形化客户端这边Redis Desktop Manager现在叫 RESP.app配置时注意几个字段主机填公网 IP端口填你改后的端口密码填 requirepass 设的那个。如果连的是 ACL 用户用户名那一栏要填对默认用户是 default。连接失败时它的报错信息其实挺有用能区分是超时、拒绝还是认证失败比命令行更直观一些。提示如果你在本地测的时候用了代理工具记得确认流量走向。有时候明明配置没问题就是因为本地环境把流量导到了别处导致验证结果失真。测试时最好用直连方式避免中间层干扰判断。4. 安全加固让能连变成只有该连的人能连端口通了不代表事情做完了。开放外网访问之后Redis 就进入了被持续扫描的暴露面这一步才是真正决定你会不会出事的关键。4.1 危险命令重命名与禁用Redis 有几个命令一旦被外部调用破坏力很大。FLUSHALL清空所有数据库FLUSHDB清空当前库CONFIG可以改配置甚至写文件KEYS在数据量大时会阻塞主线程SHUTDOWN直接关服务。重命名的写法是在配置文件里rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG CONFIG_a8f3d9e1 rename-command KEYS rename-command SHUTDOWN 把命令重命名成空字符串就是彻底禁用的意思。给 CONFIG 换个随机名字只有知道你才知道这个名字的人能调用运维脚本里用新名字就行。这里有个实际操作上的取舍。禁用 FLUSHALL 之后万一真的需要清库怎么办我一般会把FLUSHDB保留但重命名成一个复杂字符串只在紧急情况下用并且记录在团队的运维手册里。全禁了到关键时刻反而手忙脚乱。还有一点要提醒rename-command修改后必须重启生效而且改了之后主从复制如果涉及命令传递要确认从节点也同步改了否则同步可能失败。这个坑比较隐蔽主从环境升级时要注意。4.2 最小权限 ACL 用户的完整配置Redis 6 的 ACL 是这几年最值得用的安全特性。基本语法是user 用户名 on/off 密码 ~键模式 命令 -命令举一个稍微完整点的例子假设你有一个业务只需要读写session:开头的键user session_svc on S3ss10n_Pss_2024 ~session:* session:* read write -dangerous~session:*限定可访问的键模式session:*限定可访问的频道模式用于发布订阅read write表示允许读写命令组-dangerous再从中剔除危险命令。这样即使这个账号的密码泄露攻击者也只能操作 session 相关的键且不能执行 FLUSH 这类破坏性操作损失被控制在有限范围内。创建和查看用户ACL SETUSER session_svc on S3ss10n_Pss_2024 ~session:* read write -dangerous ACL LIST ACL WHOAMI ACL GETUSER session_svc生产环境里我建议把 ACL 配置写进redis.conf的ACLFILE引用的外部文件里方便版本管理和审计而不是散在配置里。4.3 TLS 通道与端口收敛如果 Redis 传的是敏感数据比如用户凭证、支付相关信息那公网明文传输是不可接受的。Redis 6 开始原生支持 TLS配置如下tls-port 16379 port 0 tls-cert-file /etc/redis/tls/redis.crt tls-key-file /etc/redis/tls/redis.key tls-ca-cert-file /etc/redis/tls/ca.crt tls-auth-clients yesport 0表示关闭非加密端口只保留 TLS 端口。tls-auth-clients yes要求客户端也提供证书做双向认证安全性更高。客户端连接时redis-cli --tls --cacert /etc/redis/tls/ca.crt -h 203.0.113.5 -p 16379TLS 会带来一定的性能开销实测在普通业务量级下影响不大握手阶段的延迟增加比较明显但连接复用之后基本可以忽略。如果业务是超高频的小请求需要压测一下再决定。证书这块有个实用建议别用自签证书然后到处关校验很多客户端关了校验等于没加密的意义。要么用正规机构签发的要么在内网自建 CA 并把 CA 证书分发到各个客户端让校验真正生效。4.4 日志监控与异常告警加固做完不等于可以躺着。持续的监控能让你在出事之前发现问题。Redis 自带的INFO命令里有几个指标值得关注。connected_clients突然飙升往往是被扫描或者被攻击的信号total_connections_received的增速能反映连接模式是否正常rejected_connections大于零说明连接数被打满了keyspace_hits和keyspace_misses的比值能反映缓存是否有效。日志方面logfile参数指定日志路径loglevel notice是常用级别。关键是要关注包含Accepted、refused、possible security这类关键字的记录。Redis 在检测到可疑配置时也会往日志里写警告。再进一步可以开启慢查询日志slowlog-log-slower-than 10000 slowlog-max-len 128超过 10 毫秒的命令会被记录用SLOWLOG GET查看。开放外网之后如果有人在跑KEYS *这类命令慢查询日志里会看得很清楚。提示把这些指标接到现有的监控体系里设置阈值告警。连接数突增、拒绝连接数大于零、有大量认证失败这三类告警建议必配。等到用户反馈服务不可用再去查通常已经晚了一步。5. 排障实录那些年踩过的连接问题前面讲的是怎么配这一节讲配了还不行怎么办。我把这几年遇到过的典型问题整理成了速查形式。5.1 连接超时、拒绝连接、认证失败对照表光看报错信息其实能定位到大概方向关键是别把三类错误混在一起。超时通常是网络层没通拒绝连接是端口没监听或者被防火墙拦了认证失败则是配置正确但密码或用户名不对。下面这张表是我自己排障时常用的对照现象常见原因排查方向典型解决Connection timed out防火墙或安全组未放行检查系统防火墙和云安全组添加放行规则并重载Connection refused端口未监听或 bind 不含目标 IPss -lntp看监听地址修改 bind 并重启NOAUTH Authentication required未提供密码客户端未配置密码补上密码或 AUTH 命令WRONGPASS invalid username-password密码错误或用户不存在核对 requirepass 或 ACL 用户重设密码并同步客户端Connection reset by peer中间设备断开或 TLS 不匹配检查 TLS 配置与中间链路统一 TLS 客户端配置连接成功但命令报 NOPERMACL 权限不足ACL GETUSER查看权限补上对应命令或键模式这张表基本能覆盖八成的情况。剩下两成属于环境特有问题比如容器网络模式、多网卡路由选择这些需要单独分析。5.2 配置改了不生效的几种原因这个问题特别高频我总结了四种常见原因。第一种改了配置文件但没重启而且改的是不支持动态修改的参数。像 bind 这类只能重启生效CONFIG SET会直接返回错误。判断方法很简单CONFIG GET bind看运行时值和文件里的值是否一致。第二种改错了文件。系统上可能同时存在/etc/redis/redis.conf和源码目录里的redis.conf服务实际读的是启动命令里指定的那一个。用ps -ef | grep redis-server看启动参数里面会带配置文件的完整路径。第三种Docker 里挂载了配置文件但启动命令没引用。前面提过需要 command 里显式指定。或者容器里的路径写错了挂载到了别的地方。第四种被其他配置覆盖。比如你在命令行启动时传了--bind 127.0.0.1那么配置文件里的 bind 会被命令行参数覆盖。启动参数优先级高于配置文件。排查这类问题的通用方法先用CONFIG GET看运行时实际值如果运行时值和你期望的不一样再去确认启动命令和实际加载的文件路径。5.3 主从复制与集群场景下的外网访问主从复制场景下从节点的配置要比单机多考虑一层。从节点需要replicaof指向主节点replicaof 203.0.113.5 6379 masterauth YourMasterPassword masteruser repl_user如果主从跨公网建议单独开一个复制用户只给复制所需的最小权限user repl_user on Repl_Pss_2024 ~* psync replconf ping这样即使复制账号泄露攻击者也无法执行读写命令。集群模式下情况更复杂因为节点之间需要互相通信客户端的 MOVED 重定向返回的是节点的内网 IP从外网连会连不上。常见做法是让客户端通过内网访问或者用cluster-announce-ip和cluster-announce-port显式告诉集群对外宣告哪个地址。这两个参数在容器和 NAT 环境下特别重要cluster-announce-ip 203.0.113.5 cluster-announce-port 6379 cluster-announce-bus-port 16379不配的话集群内部通信正常但客户端拿到的重定向地址是容器内部 IP公网根本路由不到表现为能连上但一操作就超时。我个人在跨公网做 Redis 主从时的体会是能不走公网就不走。延迟带来的复制滞后会很明显网络抖动还可能触发全量同步数据量大的时候一次全量同步能跑很久期间主节点压力上升。如果必须走务必配好压缩和合理的repl-backlog-size并且监控复制延迟指标master_repl_offset和从节点的slave_repl_offset差值。提示跨公网复制建议先小规模压测一次观察同步耗时和主节点负载变化别直接上生产。全量同步期间的 fork 操作会消耗较多内存数据量大的实例要预留足够余量。最后再分享一个我自己的习惯。每次开放外网访问之后我都会做一次攻击者视角的自检从一台陌生网络环境的机器上尝试连接看没有密码、错误密码、正确密码三种情况下分别是什么反应用端口扫描工具看除了业务端口还有没有别的口暴露在外翻一遍 Redis 日志看有没有异常的认证失败记录。这套自检大概花十分钟但能提前发现大部分配置疏忽。还有一点配置变更一定要留记录。什么时候开的、开了多久、给谁开的、什么时候关的写在一个共享文档里。我见过测试环境开了公网之后就忘了关一放就是半年中间经历了三次服务器迁移愣是没人记得这个口子是干什么用的。这种遗忘的开放才是最难防的隐患。