Upstream连接池未生效主因是keepalive参数位置错误，必须置于upstream块内而非server行后；还需配套设置proxy_http_version 1.1和proxy_set_header Connection ''，并确保后端支持长连接及系统文件描述符充足。
Upstream连接池为什么没生效？检查keepalive参数位置
Upstream连接池不生效，大概率是keepalive没放在正确层级——它必须写在upstream块内部，且**不能**放在server行后面。常见错误写法：server 10.0.1.10:8080 keepalive 32;，这会被Nginx忽略。
正确结构是：
upstream backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
keepalive 32;
}
注意：keepalive值不是越大越好。它表示每个worker进程为该upstream维护的空闲长连接数，设为64以上可能挤占文件描述符，尤其在多upstream共存时。
proxy_http_version和proxy_set_header必须配套启用HTTP/1.1长连接
即使upstream启用了keepalive，如果转发请求时仍用HTTP/1.0，连接会在响应后立即关闭。关键配置必须成对出现：
-
proxy_http_version 1.1;—— 强制使用HTTP/1.1协议 -
proxy_set_header Connection '';—— 清除客户端传来的Connection: close头，避免干扰复用
漏掉第二条，某些Java或Node.js后端会主动断连；漏掉第一条，Nginx默认用HTTP/1.0发起请求，keepalive直接失效。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
后端服务是否真正支持长连接？验证TCP连接复用行为
光配Nginx不够，得确认后端（如Spring Boot、Gin、Express）没有主动发Connection: close或设置短Keep-Alive: timeout=5。用tcpdump或ss -tnp观察实际连接变化：
ss -tnp | grep :8080 | grep ESTAB
高并发压测时，如果ESTABLISHED连接数始终接近并发请求数（而非稳定在几十个），说明连接未复用。此时要检查后端Web容器配置，例如Tomcat需确保connectionTimeout足够长，且未显式关闭keep-alive。
worker_connections和file descriptor限制直接影响最大空闲连接数
每个空闲keepalive连接会持续占用一个文件描述符。若worker_connections 1024;，而你定义了3个upstream，每个keepalive 50;，理论最大空闲连接就达150，再叠加正常请求连接，极易触发open() "/dev/null" failed (24: Too many open files)错误。
实操建议：
- 用
ulimit -n确认系统级fd限制，并在/etc/security/limits.conf中调高nginx用户的nofile - 在
nginx.conf的events块里，把worker_connections设为ulimit -n值的70%左右 - 监控指标：关注
nginx_stub_status输出中的Active connections与Reading/Writing/Waiting比例，Waiting过高往往意味着连接池未被有效利用
Upstream连接池效果高度依赖Nginx worker模型与后端响应模式的匹配，单靠调大keepalive数值解决不了阻塞型后端带来的连接滞留问题。
