Redis集群连接超时多因客户端未正确连接节点或代理问题：直连主节点发跨槽命令、代理转发卡顿、K8s Service轮询破坏粘性路由、健康检查误用HTTP导致连接堆积、SDK未启用集群模式、超时重试策略不当等。
Redis集群连接超时，先看客户端连的是谁
很多“集群超时”根本不是集群的问题，而是客户端压根没连对节点——比如直连了某个主节点，却发了跨槽命令；或连了集群代理（如Twemproxy、Codis、Redis Proxy），但代理本身卡在转发环节。这时候 redis-cli -c 能连通，业务却报 Read timed out，大概率是代理层出了问题。
- 用
redis-cli -h proxy_ip -p 6379 ping单独测代理是否响应正常，别只测后端 Redis 实例 - 检查代理日志里有没有
timeout、upstream connect timeout或no available backend类错误 - 确认代理是否开启了集群感知（例如 Codis 的
product_name配置、Twemproxy 不支持集群模式，强行用会出问题） - 如果用了 Kubernetes Service 做负载均衡，注意默认是轮询，而 Redis 集群客户端要求“粘性路由”——某些请求必须落到特定 slot 对应的节点，代理不支持哈希路由就会反复重定向甚至超时
负载均衡器把健康检查当成真实请求打爆了连接数
常见陷阱：在 Nginx / ALB / SLB 上配置了 HTTP 健康检查，探测路径设成 /health，但后端是 Redis ——结果健康检查 TCP 握手后不发任何 Redis 协议数据，就挂在那里。Redis 把它当空闲连接，timeout 0 时永不释放，timeout 300 时等 5 分钟才断，大量半开连接堆积，connected_clients 快顶到 maxclients，新请求直接被拒绝。
- 查连接来源：
redis-cli client list | grep -E 'addr=.*:|idle=' | awk -F'[ =]' '{print $2, $10}' | sort -k2 -n | tail -10，看是不是一堆相同 IP + 高 idle 值的连接 - 负载均衡器健康检查必须用 TCP 层（非 HTTP），且探测包要符合 Redis 协议：发
*1\r\n$4\r\nPING\r\n，收+PONG\r\n - 或者干脆关掉健康检查，改用集群自身
CLUSTER NODES+ 客户端重试逻辑兜底（更推荐）
客户端 SDK 没走集群协议，却硬连集群地址
典型错误：用 Jedis 或旧版 Lettuce 直接 new Jedis("cluster-ip", 6379)，以为这是个普通 Redis 实例。实际上集群地址只是入口，真正命令要根据 key hash 到具体节点，而普通客户端不会解析 MOVED / ASK 重定向响应，直接卡死在第一次请求超时。
- Jedis 必须用
JedisCluster构造器，传入 nodes 列表，不能只传一个 host - Lettuce 推荐用
RedisClusterClient+ClusterTopologyRefreshOptions，避免拓扑缓存过期后仍往下线节点发请求 - ioredis 要显式启用集群模式：
new Redis.Cluster([{ host: '1.1.1.1', port: 6379 }])，否则默认当单机用 - Spring Data Redis 从 2.6 开始默认启用集群自动发现，但若配置了
spring.redis.host却没配spring.redis.cluster.nodes，就会 fallback 成单机模式，导致超时
代理/客户端设置了超时，但没配重试和熔断
连接超时不是终点，而是信号。很多团队只调大 timeout=60000，结果慢请求把线程池堵死，下游全雪崩。真正的稳定性来自分层控制：网络层超时要短（1~3s），应用层重试要有退避，失败后要快速熔断。
- 客户端连接超时建议设为
2000ms，读写超时设为1000ms（集群跨节点跳转本就多一次 round-trip） - ioredis 设置：
retry_strategy返回 false 表示不重试，socket.connectTimeout和socket.timeout分开控制 - 不要依赖代理层重试（如 Envoy 的 retry_policy），Redis 命令幂等性差（
INCR、LPUSH重试会重复执行），重试逻辑必须由业务 SDK 控制，并区分命令类型 - 监控
redis_cluster_stats_keyspace_hits+redis_cluster_stats_keyspace_misses突降，往往比连接超时更早暴露代理或拓扑异常
最容易被忽略的是：集群节点扩缩容期间，客户端拓扑缓存未及时刷新，会导致持续几秒的 MOVED 重定向风暴——这不是超时配置能解决的，得靠客户端主动定时刷新或监听 CLUSTER NODES 变更事件。
