缓存绕过与keep-alive不直接冲突，本质是请求未抵达缓存层或连接复用配置错位：需通过日志比对、响应头验证、缓存键检查及redis抓包，确认是否真实命中缓存。
缓存绕过本身和 Keep-Alive 连接复用并不直接冲突，但二者在实际链路中常被误配或误判，导致“看起来像缓存没生效”，实则是请求根本没走到缓存层——比如被连接层拦截、重定向、或因连接异常触发了降级逻辑。排查关键不是找“冲突”，而是厘清请求是否真实抵达缓存服务，以及连接行为是否干扰了缓存命中路径。
一、确认缓存是否真的被绕过
先排除“假绕过”：表面看没走缓存，其实是前端/网关/客户端压根没发请求到缓存节点。
- 查访问日志比对：分别抓取 Nginx（或 API 网关）和缓存服务（如 Redis、OpenResty）的日志，确认同一请求 ID 或时间窗口内，Nginx 有记录但 Redis 无对应 get 操作——说明请求没到缓存，可能被路由跳过、被鉴权拦截、或被客户端直连后端绕开。
-
检查响应头：正常命中缓存的响应应含
X-Cache: HIT或类似标识；若返回X-Cache: MISS或无该头，再看Age头是否为 0、Cache-Control是否含no-store/private——这些是主动禁用缓存的信号，和 Keep-Alive 无关，但会掩盖真实问题。 -
验证缓存键生成逻辑：比如 URL 带动态参数（
?t=1726473728）、Header 中含Authorization但未纳入 key 计算，都会导致每次 key 不同，缓存永远不命中——这不是绕过，是无效缓存。
二、检查 Keep-Alive 是否引发非预期跳转或连接复用错误
Keep-Alive 本身不会让请求绕过缓存，但如果连接复用发生在错误的层级（如客户端复用了指向后端的连接，而非缓存代理），就等于“跳过了缓存中间件”。
-
确认代理链路是否启用 Keep-Alive：例如 OpenResty 查 Redis 时，必须调用
red:set_keepalive()；若只red:connect()+red:close()，每次都是新连接，虽不绕缓存，但性能差且易耗尽端口——容易被误认为“缓存不生效”，实则是连接不稳定导致重试或 fallback 到直连。 -
排查连接泄漏导致的隐式降级：当连接池中大量连接处于
CLOSE_WAIT或已失效，客户端可能自动新建连接并错误地指向后端服务（如配置了备用 upstream），从而跳过缓存层。用ss -tan | grep :6379查 OpenResty 到 Redis 的连接状态，若大量FIN_WAIT2或无连接，说明set_keepalive未正确调用或超时设得太短。 - 注意 HTTP/1.1 和 HTTP/2 的复用差异：HTTP/2 多路复用下，单个 TCP 连接可并发多个 stream；若网关（如 Nginx）与后端开启 HTTP/2，但缓存层（如旧版 Lua Redis 客户端）只支持 HTTP/1.1，可能因协议不匹配触发重试或直连——此时 Keep-Alive 正常，但缓存路径被破坏。
三、定位典型共现场景
以下情况常被当作“缓存绕过与 Keep-Alive 冲突”，实则是配置错位：
-
客户端 Keep-Alive + 服务端 Connection: close：浏览器发了
Connection: keep-alive，但后端（如 Tomcat）配置了connectionTimeout=5000且未显式返回Keep-Alive头，连接很快关闭。客户端下次请求可能因复用失败而重试，若重试逻辑里带了Cache-Control: no-cache，就会强制穿透缓存。 -
反向代理未透传缓存相关 Header：Nginx 默认不转发
Authorization、Cookie等字段，若缓存策略依赖这些字段生成 key，而代理又开启了 Keep-Alive 复用连接，会导致“看似复用成功，实则缓存 key 错乱”，表现就是随机 MISS。 -
连接池大小不足引发排队等待：Session 的
pool_maxsize=10，但并发请求 50，30 个请求阻塞等待连接；超时后部分请求 fallback 到直连数据库——监控看到 DB QPS 突增，误以为缓存被绕过，实则是连接池瓶颈诱发的降级。
四、快速验证步骤
不用重启服务，5 分钟内可完成基础判断：
- 用
curl -v -H "Connection: keep-alive" http://your-api/endpoint观察响应头是否有Connection: keep-alive及Keep-Alive: timeout=xx, max=yy；再对比关闭 Keep-Alive：curl -v -H "Connection: close" ...，看缓存命中率是否变化——若无差异，说明问题不在连接复用层。 - 在 OpenResty 或网关层加日志：
ngx.log(ngx.INFO, "cache_key: ", cache_key, " redis_get: ", res)，确认 key 生成和 Redis 调用是否被执行。 - 抓包看真实流向：
tcpdump -i any port 6379 -w redis.pcap，打开 Wireshark 检查是否有 Redis 协议交互；若完全无流量，说明请求根本没发往 Redis。
