“read: connection reset by peer”表明TCP连接已建立但在读取时被对端强制重置，需从健康检查干扰、Pod优雅终止、客户端连接管理、内核参数四方面排查：确认是否LB TCP探针导致；检查preStop与SIGTERM处理；核对客户端超时与服务端不匹配；验证ipvs timeout及TIME_WaiT等内核参数。
proxy 的四层健康检查行为所致：
- 若后端服务未提供 http 健康检查接口，而负载均衡器（如 Traefik、nginx Ingress 或云厂商 SLB）配置的是 TCP 健康检查，则探测会建立 TCP 连接后立即关闭，服务端 accept 后 read 时就会收到 RST；
- 此时日志中报错集中出现在固定时间间隔（如每 5–10 秒）、源 IP 是集群内节点地址段（如 10.42.x.x、192.168.x.x），且无对应 access 日志或业务处理痕迹；
- 解决方式：要么改用七层健康检查（需业务暴露 /healthz 等接口），要么在日志中过滤掉来自 kube-system 或 LB 组件 IP 段的请求，避免误判。
检查 Pod 优雅终止与连接复用冲突
K3s 环境下滚动更新频繁，若应用未正确处理 SIGTERM，极易触发此错误：
- 旧 Pod 进入 Terminating 状态后，k3s 会发 SIGTERM，但若进程未关闭长连接（如 gRPC、HTTP/2、数据库连接池中的空闲连接），这些连接仍保留在客户端（如其他 Pod 或 Ingress）；
- 新 Pod 启动后可能复用相同 IP（尤其在 nodePort 或 hostNetwork 场景），导致客户端继续向该 IP 发包，新 Pod 收到不属于自己的连接数据，直接 RST；
- 验证方法：查 Pod 事件（
kubectl describe pod xxx），看是否有快速重建；再抓包确认 RST 是否由新 Pod 主动发出（tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0 and host）；' - 修复动作：在容器 lifecycle 中添加 preStop sleep 10，并在代码中监听 SIGTERM，调用
server.Shutdown()或清空连接池。
排查客户端连接管理与超时配置
报错出现在 “read” 阶段，说明连接已建立，但服务端尝试读取时对端已关闭——常见于客户端侧异常：
- 上游服务（如另一个 Pod）使用了短连接但未正确 close，或设置了过短的 idle timeout（例如 HTTP 客户端 keep-alive 超时设为 30s，而 K3s service 的 ipvs 转发超时为 900s），导致连接在服务端还“活着”时，客户端已静默断开；
- 客户端是浏览器或移动端时，用户切后台、锁屏、弱网切换也会引发此类 RST，但通常伴随 499 状态码（nginx 客户端主动关闭），需结合 access 日志交叉判断；
- 检查客户端 SDK 配置：如 java 的 okhttp 设置 connectTimeout=5s、readTimeout=10s，但服务端处理耗时波动大，客户端等不及就断连；建议将 readTimeout 设为服务端最大预期响应时间的 1.5 倍以上。
验证底层资源与内核参数适配性
K3s 默认轻量，某些默认内核参数在高并发场景下易诱发 RST：
- 检查 net.ipv4.tcp_fin_timeout（默认 60s）和 net.ipv4.ip_local_port_range，若连接回收慢或端口耗尽，新连接可能复用 TIME_WAIT 状态的四元组，触发 RST；
- K3s 节点若启用了 ipvs，确认 ipvs timeout 设置合理：
ipvsadm -l --timeout，TCP session 默认 900s，若应用层心跳间隔 >900s，连接会被 ipvs 清除，后续发包即 RST； - elasticsearch、redis 等中间件客户端需显式设置 keepAlive 时间（如 ES 的
keepAliveStrategy），确保小于 ipvs timeout（建议 ≤600s）； - 临时验证：在出问题 Pod 内执行
ss -s查看 TIME_WAIT 数量是否突增，或cat /proc/net/nf_conntrack | wc -l看连接跟踪表是否打满。