Nginx 报 "upstream timed out (110: Connection timed out)" 怎么解决？
Nginx upstream timed out (110) 的两类成因：连接建立超时（connect）与读响应超时（read）；对应参数、网络层排查（防火墙/路由）、上游慢查询定位与 FAQ。
错误码 110 是 Linux 的 ETIMEDOUT——Nginx 与上游之间的 TCP 通信超时。 先看 error.log 里的完整文案区分两类：while connecting to upstream（连不上）和 while reading response（连上了但等响应超时），两者的排查方向完全不同。
类型 A：连接建立超时（while connecting）
proxy_connect_timeout 内连不上上游。这是网络/对端问题，不是慢：
# 在 Nginx 机器上直接测上游
curl -v http://上游IP:端口/
ss -tlnp | grep 端口 # 在上游机器上确认服务真在监听
高频原因：
- 防火墙/安全组没放行 Nginx 到上游的端口（云环境安全组是高发区）；
- 上游没监听在正确的地址：服务只听了
127.0.0.1，而 Nginx 从另一台机器/容器来连； - IP/端口写错：upstream 块里的是旧地址；
- 容器网络：docker-compose 里用了
localhost连别的容器（应为服务名）。
类型 B：读响应超时（while reading）
连接建立了，但上游在 proxy_read_timeout 内没回完数据——这是上游慢：
location / {
proxy_read_timeout 120s; # 默认 60s
proxy_send_timeout 120s;
}
调大只是治标。治本要查上游为什么慢：慢查询、线程池耗尽、又在等更下游的服务……配合"Nginx 反代 504"那篇的排查路径。
快速对照表
| 日志文案 | 含义 | 主查方向 |
|---|---|---|
while connecting to upstream |
TCP 握手超时 | 防火墙、监听地址、容器网络 |
while reading response header |
等响应头超时 | 上游应用慢/卡死 |
while reading upstream |
响应体传输中断 | 上游中途崩溃/超时掐线 |
观测云对照
110 超时的排查本质是回答"慢在/断在哪一段"。观测云 APM 的全链路 Trace 能把一次请求在 Nginx→应用→数据库各段的耗时摊开，超时时刻卡在哪段一目了然；访问日志里 $upstream_response_time 与 $request_time 的对比、对 upstream 超时关键字的告警，让这类问题从"翻 error.log 考古"变成实时可视。
常见问题（FAQ）
Q：proxy_connect_timeout 能设多大？
A：上限约 75 秒（受 TCP 栈自身重传超时限制），设更大也不生效。连接超时该修网络，不该指望调参数。
Q：间歇性出现、大部分请求正常？
A：看上游负载——连接池耗尽、GC 停顿都会表现为间歇超时。给上游加资源或调池子之前，先用监控确认模式（定时出现？随流量涨落？）。
Q：upstream 写了多台机器，会都报超时吗？
A：Nginx 默认 proxy_next_upstream 在超时时会尝试下一台。若全部超时，多半不是某台机器的问题，而是应用整体过载或公共依赖（数据库）卡了。
