Redis集群内网丢包的典型现象是节点间反复显示fail或noaddr，但单点ping通；cluster nodes中connected节点长期不更新ping-sent/pong-recv时间；日志频繁出现IOERR、Connection refused或timeout，而ping和telnet网络层看似正常。
Redis集群内网丢包的典型现象是什么
集群节点间反复显示 fail 或 noaddr，但 redis-cli -p 6379 ping 单点通；cluster nodes 输出里有节点状态为 connected 却长期不更新 ping-sent/pong-recv 时间；日志中频繁出现 IOERR、Connection refused 或 timeout，但网络层 ping 和 telnet 看似正常。
为什么内网也会丢包——不是物理链路问题
内网丢包多数不是交换机或网卡故障，而是策略型丢弃：
- 防火墙或云安全组只开了客户端端口（如
6379），漏掉了集群总线端口16379（6379 + 10000） - NAT网关或SLB对长连接空闲超时回收过激，导致集群心跳 TCP 连接被静默断开
- 内核
net.ipv4.tcp_fin_timeout或net.netfilter.nf_conntrack_tcp_timeout_established设置过短，在高并发下提前清理连接跟踪表项 - 某些私有云平台对非标准端口（如
16379）默认限速或限流
怎么验证是集群总线端口被拦
在任一节点上执行：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -p 6379 cluster nodes | grep -v myself
挑出一个疑似失联节点的 IP（如 192.168.5.20），然后直接测它的总线端口：
- Linux：
telnet 192.168.5.20 16379或nc -zv 192.168.5.20 16379 - Windows：
Test-NetConnection 192.168.5.20 -Port 16379 - 若失败，再查本机防火墙：
sudo iptables -L INPUT -n | grep 16379；没结果就说明未放行 - 云环境必须检查安全组「入方向」规则，源地址填其他所有节点 IP 段，端口填
16379
内核参数和 Redis 配置必须同步调
光开防火墙不够，全连接队列溢出一样会导致总线连接被静默丢弃：
- 临时调大：
sudo sysctl -w net.core.somaxconn=65535 - 持久化：写入
/etc/sysctl.d/99-redis.conf并执行sudo sysctl --system - Redis 层必须配
tcp-backlog 65535（6.2+ 版本），老版本需确认 glibc 支持或重新编译 - 验证是否生效：
ss -lnt | grep :16379的Send-Q列应显示65535，不是128或511 - 如果
ss -lnt | grep :16379的Recv-Q长期 > 0，说明 Redis 主线程处理不过来，要查慢命令、AOF fsync 延迟或bgrewriteaof阻塞
真正容易被忽略的是：集群总线通信不走密码认证，所以 protected-mode yes 会直接拒绝握手；bind 只写 127.0.0.1 也会让其他节点连不上——这两项不改，即使端口通了也建立不了集群拓扑。
