curl: (56) Recv failure: Connection was reset 常见原因有哪些？

Question

**问题：** `curl: (56) Recv failure: Connection was reset` 是生产环境中高频出现的网络错误，表明 TCP 连接在数据接收阶段被对端（或中间设备）异常中断。常见原因包括：① 服务端进程崩溃、主动关闭连接或超时强制断连；② 防火墙、WAF（如 Cloudflare）、Nginx 等中间代理因请求头过大、超时配置过短（如 `proxy_read_timeout`）、TLS 协议不匹配或安全策略触发重置；③ 客户端 TLS 版本/密码套件与服务端不兼容，导致握手后数据传输阶段被拒绝；④ 网络路径中存在不合规的 NAT 设备或运营商 DPI 干预；⑤ 服务端资源耗尽（如文件描述符满、内存不足）导致 accept 队列溢出或连接被内核 RST。该错误**不反映 DNS 或 TCP 握手失败（那是 curl 7 或 35 错误）**，而是明确指向“已建立连接但收包时被重置”，需结合服务端日志、tcpdump 抓包及中间件配置协同排查。

Answer 1

```html

一、现象层：精准识别错误语义与边界条件

curl: (56) Recv failure: Connection was reset 是 libcurl 在 recv() 系统调用返回 ECONNRESET 时抛出的错误码，严格对应 TCP 层收到对端发送的 RST 数据包——这意味着连接已成功完成三次握手（排除 curl 错误 7/DNS、35/TLS handshake），但服务端或中间设备在应用层数据传输过程中单向强制终止连接。

关键判据：非握手失败、非路由不可达、非证书校验失败；而是“连接存活但收包瞬间被重置”。此阶段 curl 已完成 TLS 握手、HTTP 请求发送，正等待响应 body 或 headers 流式接收。

二、链路层：五段式故障域映射模型

基于网络栈与部署拓扑，将问题收敛至以下 5 类可验证域：

1. 服务端进程层：Worker 崩溃、SIGPIPE 未捕获、gRPC/HTTP/2 stream reset、超时 kill（如 Spring Boot server.tomcat.connection-timeout）
2. 反向代理层：Nginx proxy_read_timeout/proxy_buffering off + 大响应体、Cloudflare “Error 520/521”、Envoy 的 stream_idle_timeout
3. TLS 协商后断连层：服务端启用 TLS 1.3 Early Data 但客户端不支持、BoringSSL 与 OpenSSL 密码套件交集为空、ALPN 协议协商失败（如 h2 vs http/1.1）
4. 网络中间件层：运营商 DPI 注入 RST、企业防火墙深度检测（DPI）触发连接清洗、CGNAT 设备状态表老化（典型表现：偶发性、仅特定地域/IP 段）
5. 内核资源层：服务端 net.ipv4.ip_local_port_range 耗尽、net.core.somaxconn 过小导致 accept 队列溢出、OOM Killer 杀死进程后残留 RST

三、诊断层：三位一体协同取证法

证据类型	采集命令/工具	关键线索示例
服务端日志	journalctl -u nginx --since "2024-06-01 10:00" | grep -i "reset\|timeout\|upstream"	Nginx error.log 中出现 upstream prematurely closed connection while reading response header
TCP 抓包分析	tcpdump -i any 'host example.com and port 443' -w curl_56.pcap	Wireshark 中观察到服务端 IP 在 HTTP/2 HEADERS 帧后立即发出 TCP RST（无 FIN）

四、验证层：可复现的最小化排查路径

执行以下命令序列，逐层剥离干扰：

# 1. 绕过 DNS 和 TLS，直连 IP + 端口（确认是否为 TLS 层问题）
curl -v --resolve example.com:443:192.0.2.1 https://example.com/api/test

# 2. 强制降级 TLS 版本（排除 TLS 1.3 兼容性）
curl -v --tlsv1.2 https://example.com/api/test

# 3. 关闭 HTTP/2，回退至 HTTP/1.1（规避 h2 流控异常）
curl -v --http1.1 https://example.com/api/test

# 4. 添加调试头，触发 WAF 日志记录（如 Cloudflare cf-cache-status）
curl -v -H "X-Debug: true" https://example.com/api/test

五、根治层：生产环境加固清单

graph LR
A[客户端发起 HTTPS 请求] --> B{TLS 握手成功？}
B -->|Yes| C[发送 HTTP 请求]
B -->|No| D[curl 35 错误 → 排查 TLS]
C --> E{服务端响应流式传输中}
E -->|RST 包到达| F[检查 Nginx proxy_read_timeout]
E -->|RST 包到达| G[检查服务端 GC 压力 / fd limit]
E -->|RST 包到达| H[检查 Cloudflare Security Level / Rate Limiting]
F --> I[调高至 ≥ 300s 并启用 proxy_buffering]
G --> J[ulimit -n 65536 && sysctl -w net.core.somaxconn=65535]
H --> K[临时关闭 WAF 规则验证]

六、监控层：SLO 可观测性增强建议

在 Prometheus + Grafana 栈中新增以下指标：

• nginx_upstream_responses_total{code=~"5xx", upstream=~".*reset.*"}
• process_max_fds{job="backend"} / process_open_fds{job="backend"}（FD 使用率 >85% 预警）
• go_goroutines{job="backend"} > 10000（协程泄漏信号）
• 通过 eBPF（如 bpftrace）捕获内核 RST 事件：bpftrace -e 'tracepoint:tcp:tcp_send_reset { printf("RST from %s:%d → %s:%d\\n", args->saddr, args->sport, args->daddr, args->dport); }'

七、案例层：真实生产事故归因模板

某金融客户 API 群体性 56 错误归因报告节选：

• 时间窗口：2024-05-22T14:12–14:28 UTC
• 影响范围：全部 iOS App 客户端（Android 正常）
• 根本原因：iOS 17.4+ 默认启用 TLS 1.3 Early Data，而服务端 Nginx 1.20.2 未配置 ssl_early_data on，导致服务端在收到 0-RTT 数据后静默 RST
• 验证方式：tcpdump 显示客户端发送 Early Data 扩展后，服务端立即返回 RST；curl 加 --no-early-data 后 100% 成功
• 修复方案：升级 Nginx 至 1.25.3 + 启用 ssl_early_data，并同步更新 ALPN 协议列表

```