JedisConnectionException需分层排查：客户端配置（timeout、池参数）、网络通路（防火墙、bind配置）、服务端状态（connected_clients、idle连接）、连接池使用（close缺失、maxTotal不足），并依据Caused by精确锁定TCP握手、读超时、池耗尽或Broken pipe等根因。
JedisConnectionException 超时不是单一原因，得按链路分层查：客户端配置、网络通路、服务端状态、连接池使用这四块必须挨个过一遍，漏掉任何一层都可能白忙活。
看报错类型再决定排查方向
同一异常名，背后原因天差地别，先盯住堆栈末尾的 Caused by：
-
java.net.ConnectException: Connection timed out→ 连不上 Redis 服务端，问题在 TCP 握手阶段，重点查网络和 Redis 是否存活 -
java.net.SocketTimeoutException: Read timed out→ 连接已建立，但命令发出去后没等到响应，可能是 Redis 卡住、慢查询、大 key 或客户端socketTimeout设得太小 -
Could not get a resource from the pool→ 不是网络或 Redis 问题，是本地连接池没资源了，要么池子太小，要么连接没释放 -
Broken pipe (Write failed)→ 连接已被服务端关闭（比如timeout 3600配置），但客户端还拿着旧连接往里写，典型空闲连接未清理
检查客户端连接池是否耗尽
这是最常被忽略的“假超时”——明明 Redis 没问题，但你的应用拿不到连接。关键看两个指标：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
netstat -an | grep :6379 | grep ESTAB | wc -l查本机 ESTABLISHED 连接数，接近maxTotal（默认 8）就说明池子撑不住了 - 确认代码里每次
jedis.get()后是否都执行了jedis.close()；用 try-with-resources 最稳妥，否则连接永远不归还 - 如果用了
JedisPool，检查maxWaitMillis是否设得太小（比如 100ms），导致高并发下等不及就直接抛Could not get a resource
验证 Redis 服务端连接状态
别轻信“Redis 很稳”的说法，自己登上去看：
- 执行
redis-cli -h <host> -p <port> -a <auth> INFO clients</auth></port></host>，重点关注connected_clients和maxclients—— 若两者相等，说明连接数已打满，新请求必然超时 - 执行
redis-cli CLIENT LIST | awk '{print $2}' | cut -d= -f2 | cut -d: -f1 | sort | uniq -c | sort -rn看哪些 IP 建了大量连接，很可能是某台应用机器泄漏了连接 - 查
idle字段：如果大量连接idle超过服务端timeout值（如 3600 秒），它们随时会被踢，客户端却还在复用，就会触发Broken pipe
绕不开的网络与基础配置
很多超时其实在连接建立前就失败了，这些点必须手动确认：
- Redis 配置里
bind是否绑定了127.0.0.1却让远程 Java 应用去连？要改成0.0.0.0或具体内网 IP - Linux 上用
systemctl status firewalld或ufw status确认防火墙没拦6379端口；Windows 则查高级安全防火墙入站规则 - 客户端初始化
Jedis时，connectionTimeout和soTimeout不能只图省事设成 2000ms；读写密集场景建议分开设，比如soTimeout=5000，避免单次慢查询拖垮整个池
真正麻烦的从来不是报错本身，而是同一类异常在不同时间、不同机器上由完全不同的原因触发——比如上午是 maxclients 打满，下午变成某台机器的 socketTimeout 设太小，而夜里又冒出一批 Broken pipe。所以每次排查，都要带着时间戳和 host 维度的日志一起看，别只盯着异常字符串。
