SocketTimeoutException不是Redis宕机，而是应用等待响应超时；connect timed out表示TCP连接未建立，需检查网络、端口、Redis监听配置；read timed out表示连接已建但响应慢，应排查Redis负载、慢查询及客户端超时设置。
SocketTimeoutException 不是 Redis 本身挂了，而是你的应用在等它响应时“失去耐心”了——得先分清是连不上，还是连上了但读/写太慢。
怎么区分 connect timed out 和 read timed out？
错误信息里带 connect timed out，说明 TCP 连接根本没建起来；带 Read timed out 或 Command timed out，说明连接已建立，但 Redis 没在规定时间内返回结果。
-
connect timed out：优先查网络通路（防火墙、端口、IP 绑定）、Redis 是否监听正确地址（bind配置是否含127.0.0.1或0.0.0.0）、服务是否真在运行（redis-cli -h x.x.x.x -p 6379 ping） -
Read timed out：重点看 Redis 负载（redis-cli info memory | grep used_memory_human）、慢查询（redis-cli slowlog get 5）、客户端超时设置是否过短 - 注意：
spring.redis.timeout控制的是整个命令的总耗时（从发请求到收响应），不是连接建立时间；Lettuce 还有单独的connect-timeout和socket-timeout，但 Spring Boot 默认不暴露后者
Spring Boot 的 timeout 配置到底影响什么？
spring.redis.timeout 是最常被误设的参数。设成 0 并不会“永不超时”，反而会让 Lettuce 立即判定超时——这是 Netty 底层行为，不是 Spring 的逻辑。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 开发环境建议设为
5000（5 秒），生产环境根据业务容忍度设3000–10000 - 这个值只作用于单个 Redis 命令（比如一次
GET或SET），不影响连接池获取连接的过程 - 如果频繁出现
RedisCommandTimeoutException，大概率是连接空闲太久被服务端断开，而 Lettuce 默认不发心跳——得配clientName+ 启用keepAlive（需 Lettuce 6.1+）或加定时validateConnection()
防火墙和 Redis 服务端配置常被忽略
本地跑得好，上服务器就报 SocketTimeoutException？十有八九是这两处卡住。
- Linux 上检查 iptables 是否放行 6379：
sudo iptables -L -n | grep 6379；若没放行，执行sudo iptables -I INPUT -p tcp --dport 6379 -j ACCEPT并保存 - Redis 默认开启保护模式（
protected-mode yes），一旦bind不包含客户端 IP，就会拒绝外部连接——要么改bind为0.0.0.0（慎用于生产），要么关掉protected-mode no - 云服务器还要看安全组规则，确保入方向开放 6379 端口，且源 IP 范围匹配你的应用服务器
真正难搞的不是超时数字本身，而是超时背后那个“沉默的中间态”：连接建好了但卡在内核缓冲区、Redis 正在逐出大量 key、Lettuce 连接池里混着失效连接却没及时清理……这些都不会直接报错，只会让超时反复发生。
