proxy_timeout是Nginx stream模块专用于TCP/UDP代理的空闲超时参数，控制连接建立后无数据收发的最大等待时间，超时即断连以释放资源；必须配置在stream块内，单位支持s/ms，合理值需依后端心跳或空闲策略设定。
proxy_timeout 是 Nginx stream 模块中专用于 TCP/UDP 代理场景的核心空闲超时参数，它决定连接建立后、无任何数据收发的最长等待时间。超过该时限，Nginx 会主动关闭连接，释放文件描述符与 worker 资源，防止长空闲连接堆积导致资源耗尽。
作用范围很明确：只管“静默期”
它不参与以下环节：
- TCP 连接建立过程（那是
proxy_connect_timeout的职责） - 数据传输中的卡顿或慢响应（TCP 层本身无读写超时概念，需靠应用层协议或 keepalive 机制感知）
- 客户端到 Nginx 的连接管理（那是
keepalive_timeout管的）
简单说：只要上游和 Nginx 之间这条 TCP 连接上连续 proxy_timeout 秒没传一个字节，Nginx 就断开它。
配置位置与基本写法
必须写在 stream 块内，不能放在 http 块里：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
stream {
upstream mysql_backend {
server 192.168.1.10:3306;
}
<pre class="brush:php;toolbar:false;">server {
listen 3307;
proxy_pass mysql_backend;
proxy_timeout 30s; # 关键配置：30秒无活动即断连
}}
单位支持 s（秒）、ms（毫秒），例如 proxy_timeout 5000ms。不写单位会被忽略。
设多少才合理？看业务类型和后端行为
没有万能值，关键看上游服务是否主动保活或发心跳：
- 数据库代理（如 MySQL、PostgreSQL）：后端通常不发心跳，依赖连接空闲检测。建议设为 30–60 秒，略短于数据库自身的 wait_timeout（如 MySQL 默认 28800 秒，但实际应按连接池策略调低）
- 长连接网关或消息中间件（如 Kafka、Redis Pub/Sub）：若客户端有定期 ping 或业务心跳，可设为 心跳间隔 × 2～3 倍，例如心跳 10 秒，设
proxy_timeout 30s - 无心跳、纯被动通信的设备接入（如 IoT 终端）：需配合后端健康探测，避免过早断连，可放宽至 2–5 分钟，但务必同步提升系统级连接数限制
必须配套的几件事
单设 proxy_timeout 效果有限，还需：
-
检查并调高系统限制：确认
fs.file-max和 Nginx 用户的ulimit -n≥ 65536，否则空闲连接未释放前就可能 hit limit -
配合
worker_connections：在events块中设好每个 worker 最大连接数（如worker_connections 4096），避免单个进程过载 - 启用连接复用（如适用）：虽然 TCP 层不复用，但若后端支持（如 Redis 的 pipeline），可通过减少建连频次间接降低空闲连接压力
-
监控验证：用
ss -tan | grep :3307 | wc -l观察连接数趋势；查 Nginx error log 是否频繁出现upstream timed out（注意不是这个参数触发的，而是 connect 或 read 阶段）
