proxy_connect_timeout 控制 Nginx 与 upstream 建立 TCP 连接的最长等待时间，超时后返回 502 Bad Gateway 或 504 错误，日志显示“upstream timed out (110: Connection timed out) while connecting to upstream”。
proxy_connect_timeout 控制什么，超时了会报什么错误
proxy_connect_timeout 是 Nginx 与 upstream（比如后端的 Flask、Node.js 或 Java 服务）建立 TCP 连接的最长等待时间。它不涉及 SSL 握手或 HTTP 请求发送，只管“连上没连上”。
如果这个时间到了还没完成三次握手，Nginx 就直接放弃，并返回 502 Bad Gateway 或 504 Gateway Timeout，具体取决于失败阶段——多数情况是 502，日志里会明确写 upstream timed out (110: Connection timed out) while connecting to upstream。
- 默认值是
60s，对大多数内网服务来说太长，建议设为3s～5s - 它只作用于
proxy_pass场景，对fastcgi_pass等无效 - 该值必须小于操作系统层面的
tcp_syn_retries（通常为 6），否则实际超时由内核决定
keepalive_timeout 和 upstream 的长连接有关系吗
没有直接关系。keepalive_timeout 是控制 Nginx 与**客户端**之间 HTTP Keep-Alive 连接的最大空闲时长，和 upstream 完全无关。
很多人混淆是因为名字里都有 “keepalive”——但 upstream 长连接靠的是 keepalive 指令（在 upstream 块里），不是 keepalive_timeout。
-
keepalive_timeout 65;→ 影响浏览器到 Nginx 的连接复用 -
upstream backend { keepalive 32; }→ 影响 Nginx 到后端的连接池大小 - 两者数值可以不同，也不需要对齐；设高了
keepalive_timeout只会让客户端连接挂更久，不改善 upstream 超时
真正影响 upstream 连接复用和 timeout 的是这三个指令
要让 Nginx 复用到后端的连接、避免反复建连导致 upstream timed out，得配齐以下三项：
-
upstream块中加keepalive N;（如keepalive 32;），表示最多缓存 N 个空闲连接 - 对应
location里加proxy_http_version 1.1;和proxy_set_header Connection '';，否则 HTTP/1.0 会主动断连 - 可选但推荐：
proxy_next_upstream error timeout http_502;，让失败请求自动转发到其他节点（如果有多个）
漏掉任意一条，Nginx 都可能每次新建 TCP 连接，而新建连接受 proxy_connect_timeout 约束，网络抖动或后端启动慢时就容易触发超时。
为什么调大 proxy_connect_timeout 通常不是好办法
把 proxy_connect_timeout 从 5s 改成 30s，看似“更宽容”，实则掩盖问题、恶化体验：
- 用户等 30 秒才看到
502，比 5 秒更难排查 - 连接卡在 SYN_SENT 状态，持续占用 Nginx worker 进程，QPS 上不去
- 如果是后端服务没起来、防火墙拦截、DNS 解析失败，加时间毫无意义
- 真正的瓶颈往往在后端响应慢（该调
proxy_read_timeout）或连接池不足（该配keepalive），而不是连不上
线上环境遇到频繁 upstream timed out，优先查后端是否健康、网络是否通、upstream 是否用了域名（DNS 解析慢会拖累 connect 阶段）、以及有没有配 keepalive 连接池——这些点比调 timeout 数值重要得多。
