proxy_read_timeout建议从30秒起调，避免默认60秒过长导致504误判；需确保小于后端read timeout至少3–5秒，并配合location块按场景精细化配置。
proxy_read_timeout 设置多少才不算瞎调？
这个值不是越大越好，也不是越小越安全。它控制的是 Nginx 等待后端响应体第一个字节的超时时间，一旦后端卡在业务逻辑、数据库慢查询或锁等待里，proxy_read_timeout 就会直接切断连接，返回 504 Gateway Timeout。
常见错误现象：接口偶尔 504，但后端日志显示请求其实成功了——说明响应发出来了，只是晚了几秒，被 Nginx 丢弃了。
- 默认是 60 秒，对大多数 HTTP API 已偏长；真实业务中建议从
30开始试，逐步收紧 - 若后端有明确耗时场景（如导出大报表、异步任务轮询），单独用
location块覆盖，避免全局拉高风险 - 注意：它不控制 TCP 连接建立、SSL 握手或请求头发送阶段，那些由
proxy_connect_timeout和proxy_send_timeout管 - 改完必须 reload，
nginx -t && nginx -s reload，热重载不生效
upstream keepalive 连接池真能复用？别只配数字
keepalive 指令本身只是声明“每个 worker 进程最多缓存多少个空闲长连接”，但真正复用的前提是后端也支持 HTTP/1.1 + Connection: keep-alive，且不主动断连。
常见错误现象：Nginx 日志里频繁出现 upstream sent no valid HTTP/1.0 header 或连接数暴涨——其实是 keepalive 连接被后端静默关闭，Nginx 不知道，还往里发请求。
- 后端是 Go（net/http）或 Python（uvicorn）默认支持，但 Java Spring Boot 2.x+ 需确认
server.connection-timeout没设为 -1（即永不超时），否则可能僵死 -
keepalive 32是合理起点，超过 100 容易挤占 worker 连接资源，尤其高并发时 - 必须配合
proxy_http_version 1.1和proxy_set_header Connection ''，否则 Nginx 默认发 HTTP/1.0 请求，带Connection: close，根本不会走 keepalive
timeout 组合错配会导致 upstream timed out 根本不报错
当 proxy_read_timeout 大于后端服务自身的 read timeout（比如 Tomcat 的 connectionTimeout），Nginx 会等满自己的超时时间，而此时后端早已关掉 socket，导致 Nginx 收不到 FIN 包，最终触发 upstream timed out (110: Connection timed out) —— 这个错误码实际是底层 connect/read 系统调用失败，和配置的 timeout 名称不完全对应。
常见错误现象：日志里报 upstream timed out，但没写明是 connect 还是 read，查起来像黑盒。
- 务必让后端的 read timeout 比 Nginx 的
proxy_read_timeout至少小 3–5 秒，留出网络抖动余量 - 检查后端是否启用了 TCP keepalive（如 Linux 的
net.ipv4.tcp_keepalive_time），否则空闲连接可能被中间防火墙悄无声息地干掉 - 用
tcpdump抓包看 FIN 包走向，比光看 Nginx 日志更准：如果后端先发 FIN，Nginx 却还在等，就是后端提前断连；如果 Nginx 发 RST，大概率是它自己超时放弃
keepalive_requests 和 keepalive_timeout 容易被当成摆设
这两个参数常被忽略，但它们决定连接池里单个连接的生命长度。keepalive_requests 是复用次数上限，keepalive_timeout 是空闲时间上限。任何一个触达，连接就会被 Nginx 主动关闭，不等后端。
常见错误现象：压测时连接数缓慢上涨，但 netstat -an | grep :80 | wc -l 居高不下，怀疑连接泄漏——其实是 keepalive 连接堆积，但没被及时回收。
-
keepalive_requests 100是稳妥值，太高（如 1000）会让单连接承载过多请求，放大后端某次卡顿的影响范围 -
keepalive_timeout 60s足够，太长（如 300s）会拖慢连接回收，尤其在后端扩缩容时，旧 IP 的连接可能挂很久才断 - 它们只对启用
keepalive的 upstream 生效，普通upstream { server ... }块里配了也不起作用
最麻烦的地方在于：timeout 和 keepalive 的效果相互遮蔽。比如 proxy_read_timeout 设成 120，但后端 90 秒就断连，Nginx 可能再等 30 秒才报错，这期间你看到的都是 “upstream timed out”，而不是更具体的连接异常。调的时候得两边日志对着看，不能只盯 Nginx 一边。
