proxy_timeout是nginx stream模块中控制连接空闲超时的核心参数,设为上下游最小空闲超时值的80%~90%,需配合so_keepalive和proxy_responses 1使用,防止静默断连。

proxy_timeout 是 Nginx Stream 模块中防止长连接“静默断开”的关键参数,它不控制建连快慢,也不管 SQL 执行多久,只守一条线:连接建立后,若上下游连续空闲超过该时间,Nginx 就主动关闭连接。很多所谓“连接闪断”,其实不是连不上,而是连上了、用了一次、然后空了几分钟,就被 Nginx 先掐断了——而数据库或客户端还在等它。
proxy_timeout 设多少才不被提前断开
-
查清上下游两端的空闲超时值,取其中最小值的 80%~90%
- MySQL:
SHOW VARIABLES LIKE 'wait_timeout';(默认 28800 秒) - PostgreSQL:查
tcp_keepalives_idle+ 应用连接池配置(如 HikariCP 的idle-timeout) - Redis 客户端:Jedis 默认 30 分钟,Lettuce 可设
idleInPoolTimeout - 客户端 SDK:Python
psycopg3默认 idle 超时为 1800 秒(30 分钟)
- MySQL:
-
示例取值逻辑:
- 若 MySQL
wait_timeout = 3600s(1 小时),客户端池设idle_timeout = 1800s - 则
proxy_timeout建议设1500s(25 分钟)或1620s(27 分钟) - 不要设成
3600s,否则可能比客户端先超时;也不要设太小(如 10s),导致正常空闲也被杀
- 若 MySQL
-
配置写法(必须在
stream块内,不能嵌套在http中):stream { upstream pg_cluster { server 10.0.1.20:5432; } server { listen 5433; proxy_pass pg_cluster; proxy_connect_timeout 5s; proxy_timeout 1500s; # ← 核心防闪断参数 } }
必须配合 TCP Keepalive 防中间设备劫持
仅调 proxy_timeout 不够。云上 NAT 网关、企业防火墙常有 5~10 分钟无流量自动回收连接的策略,它们看不见应用层心跳,只看 TCP 包。这时需启用底层探测:
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
在
listen行加so_keepalive=300s:15s:4:- 空闲 300 秒(5 分钟)后开始发 keepalive 探测
- 每 15 秒发一次,连续 4 次无响应才断
- 总探测窗口 = 300 + 15×4 = 360 秒 →
proxy_timeout必须 ≥ 360s
-
同时系统级开启 TCP keepalive(推荐):
echo 'net.ipv4.tcp_keepalive_time = 300' >> /etc/sysctl.conf echo 'net.ipv4.tcp_keepalive_intvl = 15' >> /etc/sysctl.conf echo 'net.ipv4.tcp_keepalive_probes = 4' >> /etc/sysctl.conf sysctl -p
特殊协议要额外注意响应确认
MySQL/PostgreSQL 握手阶段只返回一个极小 greeting 包,Nginx 默认会等“完整响应”,容易卡住或误判失败:
- 加
proxy_responses 1;:只要后端发来至少 1 字节,就认为连接就绪并透传 - 不要加
tcp_nodelay off(默认是 on);对高频短查询建议显式tcp_nodelay on;减少小包延迟 -
proxy_buffer_size建议设256k~1m,避免大结果集(如 mysqldump)被截断
WebSocket 或极长连接场景怎么设
- 若代理 WebSocket、IoT 长连、或客服信令通道,
proxy_timeout可设为1d(86400 秒) - 同时必须配
so_keepalive=on(内核自动保活),不能依赖应用层 ping/pong -
proxy_responses 1仍要保留,因 WebSocket 建连后不返回 HTTP 响应体,只靠 TCP 连通性判断
不复杂但容易忽略










