“recv() failed (104: Connection reset by peer)”明确表示Nginx已建立连接并发出请求，但后端服务在处理中主动发送TCP RST强制断连，本质是后端假死（如GC停顿、goroutine泄漏、事件循环阻塞等）而非宕机，需结合upstream_response_time、抓包及后端线程堆栈综合定位。
“recv() failed (104: Connection reset by peer)” 是 Nginx 错误日志中极具指向性的关键指纹，它不表示网络中断或配置错误，而是明确提示：Nginx 已成功建立连接并发送请求，但在等待响应时，后端服务主动断开了 TCP 连接。这种行为在安全后端（如 Java Spring Boot、Go Gin 或 Node.js 服务）中，往往不是宕机，而是进入了“假死”状态——进程仍在运行，但已丧失响应能力。
识别假死而非宕机的核心证据
真正宕机时，Nginx 日志通常报 connect() failed 或 Connection refused；而 recv() failed (104) 说明三次握手已完成、请求已送达，但后端在处理中途异常终止连接。这常见于以下假死场景：
- JVM 因 GC 停顿过长（尤其是 Full GC 超过 proxy_read_timeout），线程全部阻塞，无法回写响应，OS 内核强制 RST 断连
- Go 服务因 goroutine 泄漏耗尽内存，触发 runtime panic 后未优雅退出，监听 socket 被内核回收
- Spring Boot 应用中某个接口调用外部 HTTPS 接口未设 timeout，线程池被占满，新请求排队超时后被底层 net/http server 主动 close
- Node.js 事件循环被 CPU 密集型同步操作阻塞（如大数组排序、正则回溯爆炸），无法处理已建立的连接
结合 upstream_response_time 与 request_time 锁定假死窗口
Nginx access_log 中的 $upstream_response_time 和 $request_time 是判断假死时间点的关键：
- 若 $upstream_response_time 显示为 “-”，说明后端根本没返回任何字节，大概率是进程卡死或崩溃前已断连
- 若 $upstream_response_time 有数值（如 2.345），但远小于 $request_time（如 6.789），说明 Nginx 等待响应超时后主动关闭连接，而该数值即为后端实际存活并尝试响应的时间长度
- 在同一秒内集中出现多个 recv() failed 且 $upstream_response_time 集中在某毫秒值（如 3000ms±10ms），极可能对应后端设置了统一的硬超时（如 Tomcat 的 connectionTimeout 或 Spring 的 server.connection-timeout）
验证假死：绕过 Nginx 直连后端抓取真实状态
仅查 Nginx 日志不够，必须穿透代理确认后端真实行为：
- 用 curl -v http://127.0.0.1:8080/actuator/health（Spring Boot）或 curl -v http://localhost:3000/health（Node.js）测试健康端点——返回 200 不代表服务可用，需观察响应延迟是否突增
- 执行 ss -tnp | grep :8080 查看 ESTABLISHED 连接数是否持续高位堆积，且 Recv-Q 列非零，说明内核接收队列积压，应用层未读取
- 对 Java 进程执行 jstack -l <pid> > jstack.log，搜索 WAITING 或 BLOCKED 线程，重点关注数据库连接池获取、锁竞争、外部 HTTP 调用等堆栈
- 对 Go 进程执行 kill -SIGABRT <pid> 触发 goroutine dump，查看是否存在大量 select 或 chan receive 阻塞态
针对性加固：从配置到代码层切断假死链路
单纯调大 timeout 只是掩盖问题，需从机制上预防假死传导至 Nginx：
- Nginx 层启用 proxy_next_upstream error timeout http_503，避免单点假死拖垮整个 upstream 组
- 后端服务启动时配置 livenessProbe（K8s）或 HealthIndicator（Spring），确保探针能真实反映请求处理能力，而非仅进程存活
- 所有外部依赖调用必须设置 connect/read/write timeout，Java 推荐使用 OkHttp + connectionPool，Go 推荐 http.Client with Timeout Transport
- 限制单次请求最大执行时间：Spring Boot 配置 server.tomcat.max-connections=1000 和 server.tomcat.accept-count=1000，避免 accept queue 溢出丢包
