Nginx Stream模块的proxy_timeout是控制已建立TCP连接空闲超时的核心参数，从连接建立完成开始计时，双向无数据则超时关闭，默认600秒，需根据业务场景（如数据库、MQTT）调大以避免误断；其不理解HTTP语义，仅透传字节流。
nginx 的 TCP 代理（通过 stream 模块）本身不理解 HTTP 协议，它只转发原始字节流，因此对“长时间未响应连接”的处理逻辑与 HTTP 代理不同——它依赖底层 TCP 连接状态和超时机制，而非响应头或 body 语义。
stream 模块的 timeout 控制核心是 proxy_timeout
proxy_timeout 是 stream 块中唯一用于控制连接空闲时长的关键参数，它作用于已建立的 TCP 连接：
- 它从连接建立完成（三次握手成功）后开始计时
- 只要连接上**没有数据收发**（即双向静默），计时持续；一旦有任意方向的数据流动，计时重置
- 超时后，nginx 主动关闭该 TCP 连接，释放 worker 资源
- 默认值为 10 分钟（600 秒），对多数长连接场景偏短，如数据库连接池、MQTT、SSH 转发等需手动调大
keepalive 并非 TCP 层保活，而是连接复用机制
注意：stream 模块中的 keepalive 指令（如 keepalive 32;）不是发送 TCP keepalive 探针，而是指“每个 worker 进程为 upstream 保留的空闲连接池大小”：
- 它仅在 upstream 使用域名且配置了
resolve时生效，用于复用已解析的后端连接 - 它不干预连接是否被系统内核断开，也不替代
proxy_timeout - 若后端真正无响应（如进程卡死但 TCP 连接未断），仅靠
keepalive无法探测或清理
真正的连接健康依赖操作系统与协议层
nginx stream 不主动发 TCP keepalive 包（如 SO_KEEPALIVE），是否启用取决于：
- Linux 内核参数：
net.ipv4.tcp_keepalive_time（默认 7200 秒）、_interval和_probes - 上游服务是否开启并正确响应 keepalive 探针
- 中间网络设备（防火墙、NAT 网关）是否静默丢弃长空闲连接
若需更激进的连接探测，应在后端服务侧配置短周期 keepalive，或在 nginx 所在主机上调小内核 keepalive 时间（如设为 600 秒），让内核提前发现僵死连接并通知 nginx 关闭。
配合日志与监控定位挂起连接
当出现“连接未响应”现象时，应检查：
- nginx error 日志中是否有
upstream timed out或connection reset by peer记录 - 使用
ss -tni或netstat -tnp查看连接状态：若大量处于ESTABLISHED但retrans计数增长，说明网络或后端丢包/无响应 - 对比
proxy_timeout设置与实际业务最长空闲间隔，避免过早断连（如 Redis PUB/SUB 场景可能数小时无数据）
