Nginx 报 "upstream timed out (110: Connection timed out)" 怎么解决？
Nginx upstream timed out (110) 的常见阶段：连接建立（connect）、向上游写入（send）与读取响应（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"那篇的排查路径。
如果应用已接入观测云 APM，可在超时对应的时间窗查找慢链路，检查数据库或下游调用的 Span 耗时；再用相同 trace_id 的日志查看错误上下文，关联方式见日志与链路关联。连接尚未到达应用的超时，仍从上面的网络与监听检查入手。
快速对照表
| 日志文案 | 含义 | 主查方向 |
|---|---|---|
while connecting to upstream |
TCP 握手超时 | 防火墙、监听地址、容器网络 |
while reading response header |
等响应头超时 | 上游应用慢/卡死 |
while reading upstream |
读取响应体时超时 | 上游停顿、网络或传输问题，不足以证明崩溃 |
while sending request to upstream |
两次写入上游之间超时 | 上游读取慢、背压或网络问题 |
常见问题（FAQ）
Q：proxy_connect_timeout 能设多大？
A：文档提示通常不能超过 75 秒，实际受操作系统和网络连接行为影响，不能视为所有环境的固定上限。连接超时该修网络，不该指望调参数。
Q：间歇性出现、大部分请求正常？
A：看上游负载——连接池耗尽、GC 停顿都会表现为间歇超时。给上游加资源或调池子之前，先用监控确认模式（定时出现？随流量涨落？）。
Q：upstream 写了多台机器，会都报超时吗？
A：默认策略包含 error/timeout，但仅在还可重试时生效；已向客户端发送响应、请求体发送状态、非幂等请求限制及重试次数/时间预算都会影响是否切换。若全部超时，多半不是某台机器的问题，而是应用整体过载或公共依赖（数据库）卡了。
