send_timeout是写入阶段超时机制，用于切断长时间无响应连接，需配合TCP keepalive、写操作超时判断、errno监控等实现完整熔断；误设会导致连接堆积或误杀，应按场景合理配置并验证。
调优 send_timeout 可以在写入阶段辅助识别并切断长时间无响应的连接，但它本身不是“自动熔断”的完整方案，而是一个关键的超时配合机制。真正的僵尸连接熔断需要结合连接状态检测、写操作上下文和主动关闭逻辑。下面从原理和实操两个层面说明如何有效利用它。
理解 send_timeout 的真实作用
send_timeout（常见于 Nginx、某些数据库驱动或自研网络库）定义的是：向客户端发送响应数据时，两次成功写操作之间的最大等待时间。它不控制整个请求耗时，也不触发“主动探测”，只在持续写入过程中起效。
例如：Nginx 向后端转发大文件时，若后端缓慢返回、网络卡顿或客户端接收缓冲区满且不消费，Nginx 会在连续 send_timeout 秒内无法完成一次 write 系统调用时，直接关闭该连接。
⚠️ 注意：它对“已建立但完全不发数据”的空闲连接无效（那是 keepalive_timeout 的职责），也不适用于仅读不写的场景。
与写入阶段熔断强相关的配置组合
单靠 send_timeout 不足以实现稳健的僵尸连接识别。需搭配以下机制：
-
启用 TCP keepalive 并调低参数：如
tcp_keepalive_time=60、tcp_keepalive_intvl=10、tcp_keepalive_probes=3，让内核在应用层无感知时探测对端是否存活； -
在业务写逻辑中嵌入可中断的超时判断：例如使用带 deadline 的 I/O（Go 的
conn.SetWriteDeadline()、Java 的Socket.setSoTimeout()），在每次write()前检查整体写入耗时是否超限； -
监控 send() 返回值与 errno：若反复返回
EAGAIN/EWOULDBLOCK或EPIPE，说明对端异常关闭或接收窗口长期为 0，此时应立即清理连接； - 避免长轮询式写入：将大响应拆分为多个小块，并在每块之间检查连接健康状态（如心跳标志、超时计时器），而非依赖单次 send_timeout 覆盖全程。
典型误用与规避建议
常见错误是把 send_timeout 设得过大（如 300s），期望“等它自己恢复”，结果导致连接堆积、线程/文件描述符耗尽；或设得太小（如 1s），在弱网或高延迟场景下误杀正常慢连接。
合理做法：
- 对实时性要求高的接口（如 API JSON 响应），设为 5–15 秒；
- 对流式传输（如视频切片、日志推送），按单次 chunk 写入预期耗时 × 2～3 倍设定，如平均写 200ms，则设 500ms–1s；
- 始终开启
tcp_nodelay on（禁用 Nagle 算法），避免小包合并导致超时误判； - 记录被
send_timeout中断的连接日志（含 client IP、URI、耗时），用于后续分析是否为真实僵尸或网络抖动。
验证是否生效的简单方法
可在测试环境模拟僵尸连接：
- 用
iptables在客户端侧丢弃服务端发来的 SYN-ACK 后所有包（模拟半开连接）； - 或用
tc netem delay 10000ms制造极端延迟； - 发起一个持续写入的请求（如上传大文件或 SSE 流），观察服务端连接数是否在
send_timeout触发后快速回落，且无残留 CLOSE_WAIT 或 TIME_WAIT 异常堆积。
若连接未及时释放，说明底层 socket 没有正确响应 timeout，需检查是否被阻塞在用户态缓冲、是否禁用了 SO_LINGER、或是否遗漏了 close() 调用。
