Redis怎么排查偶发的连接重置报错_检查中间件如Twemproxy或代理的超时设置-Redis-PHP中文网

“connection reset”报错来自tcp层，是rst包导致的连接强制关闭；需通过tcpdump抓包看rst源ip定位发起方——redis服务端、twemproxy代理或防火墙/slb设备。

redis怎么排查偶发的连接重置报错_检查中间件如twemproxy或代理的超时设置

Connection reset 报错到底来自哪一层？先定位断连发起方

“Connection reset”不是 Redis 服务端主动返回的错误码，而是 TCP 连接被对端（服务端或中间件）强制关闭后，客户端 read/write 系统调用收到 RST 包的表现。它不等于 Connection refused（端口没监听），也不等于 Timeout（超时未响应）。关键要判断：这个 RST 是 Redis server 主动发的？还是 Twemproxy / Envoy / 自研代理发的？或是防火墙/NAT 设备干的？

最直接的办法是抓包：

tcpdump -i any port 6379 -w redis_reset.pcap
<p>然后过滤 RST 包：<code>tcpdump -r redis_reset.pcap 'tcp[tcpflags] & tcp-rst != 0'</code></p>
<p>看 RST 包的源 IP —— 如果是 Redis 服务器 IP，说明服务端主动断连；如果是 Twemproxy 所在机器 IP，问题就在代理层；如果源 IP 是客户端本地网关或云厂商 LB，则可能是网络设备策略。</p>

<h3>Twemproxy 的 timeout 配置怎么查、怎么改？</h3>
<p>Twemproxy（nutcracker）本身没有全局“连接空闲超时”，但它有三类关键超时参数，都可能触发 RST：</p>

server_retry_timeout：单次向后端 Redis 发起连接失败后，重试前等待毫秒数。设太小（如 100）+ 后端偶发抖动 → 连接风暴 → 被服务端限流或拒绝
server_failure_limit：连续多少次失败后，将该 Redis 节点标记为 down。默认 2，若后端偶发 Connection reset 又快速恢复，这里容易误判导致流量切走再切回，加剧抖动
redis_timeout：命令级超时（毫秒），超时后 Twemproxy 主动 close socket 并返回 error。注意：它不会发 RST，但若客户端未正确处理超时后的 socket 状态，后续复用该连接就会遇到 RST

检查当前配置：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

nutcracker -t -c /etc/nutcracker.yml
<p>修改后必须 reload（<code>kill -HUP $(cat /var/run/nutcracker.pid)</code></p>

），不能仅改配置文件就生效。

为什么改了 Redis 的 `timeout` 还是偶发重置？

Redis 的 timeout 参数（单位秒，默认 0 表示永不过期）只控制“无命令交互”的空闲连接是否关闭。但它不覆盖以下场景：

Twemproxy 或其他代理自身维护连接池，有自己的空闲检测逻辑（比如每 30 秒 ping 一次，超时则 close），这个行为与 Redis timeout 无关
Linux 内核的 net.ipv4.tcp_fin_timeout（默认 60 秒）会影响 TIME_WAIT 状态回收，但一般不直接导致 RST
云厂商 SLB / ALB / CLB 常有默认 4 分钟空闲超时，且强制发送 RST（不是 FIN），这个比 Redis 和 Twemproxy 都更“霸道”
客户端 SDK 如 redis-py 的连接池设置了 max_idle_time，若小于 Redis timeout，连接会在客户端侧先 close，下次复用时发现 socket 已失效，也可能表现为 reset

所以光调大 Redis 的 timeout 不够，得同步确认链路中所有中间节点的空闲超时设置，并保证它们逐级递增（例如：SLB=300s > Twemproxy=240s > Redis=180s > 客户端连接池=120s）。

如何验证是不是代理层在发 RST？

绕过 Twemproxy 直连 Redis，复现相同压测路径：

临时改客户端配置，把 host 指向某台 Redis 实例直连地址（确保该实例负载可承受）
观察是否还有偶发 Connection reset；如果没有，基本锁定 Twemproxy 或其上游
再用 redis-cli -h twemproxy_host -p 22122 --no-auth-warning 手动连 Twemproxy，执行 PING 后等 5 分钟，再输一次 PING —— 如果第二次报错，说明 Twemproxy 主动断了空闲连接

注意：Twemproxy 默认不打印连接关闭日志，需编译时加 -DDEBUG 或用 strace -e trace=close,shutdown -p $(pgrep nutcracker) 观察它何时调用 close()。

真正难搞的是多层代理嵌套（比如 SLB → Twemproxy → Redis），RST 的源头容易被掩盖。抓包 + 逐层绕过测试，比查日志更可靠。