proxy_timeout是Nginx Stream模块中控制已建立连接空闲超时的核心参数，设为上下游最小wait_timeout的80%～90%，并启用proxy_socket_keepalive和系统TCP keepalive参数协同防闪断。
数据库连接闪断在 Nginx Stream 代理场景下，往往不是“连不上”，而是“连上了却突然断开”——这通常指向 proxy_timeout（空闲超时）配置不当，而非 proxy_connect_timeout。Stream 模块不处理 HTTP 语义，它只管 TCP/UDP 连接生命周期，因此调优必须紧扣长连接维持逻辑。
明确 proxy_timeout 的真实作用
proxy_timeout 是 Stream 模块中唯一控制已建立连接存活时长的核心参数。它定义：连接建立后，若在指定时间内上下游均无任何数据收发（即“空闲”），Nginx 就主动关闭该连接。
数据库客户端（如 MySQL JDBC、pgBouncer）常复用连接池，但若业务低峰期无查询，连接就进入空闲状态。若 proxy_timeout 小于客户端或数据库自身的 wait_timeout，Nginx 就会抢先断开连接，导致客户端下次使用时收到 “Connection reset” 或 “Lost connection” 错误——这就是典型的“闪断”。
关键点：
- 它不控制建连耗时（那是 proxy_connect_timeout 的事）
- 它不控制单次 SQL 执行时间（那是数据库层或应用层控制）
- 它只守“静默期”，是长连接的“心跳保活底线”
设置 proxy_timeout 的合理取值
必须与上下游两端的空闲超时对齐，建议按以下顺序确认并设为最小值的 80%～90%：
- 查 MySQL：
SHOW VARIABLES LIKE 'wait_timeout';（默认 28800 秒 = 8 小时） - 查 PostgreSQL：
SHOW tcp_keepalives_idle;及应用层连接池配置（如 HikariCP 的connection-timeout、idle-timeout） - 查客户端 SDK 默认行为（例如 Python psycopg3 默认 idle 超时为 30 分钟）
典型配置示例：
stream {
upstream pg_backend {
server 192.168.5.10:5432;
}
server {
listen 5433;
proxy_pass pg_backend;
proxy_connect_timeout 5s; # 建连阶段，内网设 3–5s 足够
proxy_timeout 1800s; # = 30 分钟，略小于数据库 wait_timeout（如 3600s）
}
}配合 TCP Keepalive 避免中间设备劫持
仅靠 proxy_timeout 不足以防止 NAT 网关、防火墙等中间设备因“长期无包”而静默回收连接。需启用操作系统级 TCP keepalive：
- 在 Nginx 配置中添加：
proxy_socket_keepalive on;（支持 1.15.3+） - 确保 Linux 内核参数合理：
net.ipv4.tcp_keepalive_time = 600（首次探测前空闲秒数）net.ipv4.tcp_keepalive_intvl = 60（重试间隔）net.ipv4.tcp_keepalive_probes = 3（失败后重试次数）
这样 Nginx 在连接空闲时会主动发 TCP ACK 探针，让中间设备认为连接活跃，避免被误杀。
验证闪断是否真正解决
不要只看 Nginx 日志有没有 error —— 闪断往往静默发生。推荐三步实证：
- 用
tcpdump -i any port 5433抓包，观察连接关闭是 FIN 正常挥手，还是 RST 强制中断；RST 多出现在proxy_timeout触发或中间设备回收时 - 在客户端开启连接日志（如 JDBC 加
&logger=com.mysql.cj.log.StandardLogger&profileSQL=true），捕获 “Connection reset” 发生前的最后空闲时长 - 压测低频长连接场景：启动一个连接，等待 >
proxy_timeout时间后再发 query，确认是否仍可用
