client到nginx的长连接由keepalive_timeout（默认75s）和keepalive_requests（默认100）控制，http/1.1请求且无connection: close时默认复用；需同时调大二者以防连接过早关闭。

默认情况下，Nginx 与后端 server 之间是短连接（HTTP/1.0），即使客户端用了 HTTP/1.1 + Connection: keep-alive，请求一发完就断开，频繁建连会拖慢吞吐、压高后端 TIME_WAIT 和 TLS 握手开销。要真正实现长连接，必须同时打通 client→nginx 和 nginx→upstream 两条链路。

client 到 Nginx 的长连接靠什么控制？

这个环节由 http 或 server 块的 keepalive 参数决定，不需要额外加 header —— 只要客户端发的是 HTTP/1.1 请求且没显式带 Connection: close，Nginx 就默认复用连接。

• keepalive_timeout：连接空闲多久后关闭，默认 75s；设为 0 则禁用长连接
• keepalive_requests：单个连接最多服务多少请求，默认 100；QPS 高时建议调大（比如 10000），避免连接反复创建销毁
• keepalive_disable：可针对性屏蔽某些 UA 的 keepalive（如 msie6、safari），但现代浏览器基本不用动

常见误操作：只改了 keepalive_timeout 却忽略 keepalive_requests，结果连接刚复用几次就被强制关闭，起不到优化效果。

nginx 到 upstream 必须显式启用 HTTP/1.1 和 Connection 清空

这是最容易漏掉的一环。Nginx 默认向上游发 HTTP/1.0 请求，而 HTTP/1.0 不支持 keep-alive；就算 upstream 支持，Nginx 也不会复用连接。

• 必须在 location 块中加：proxy_http_version 1.1
• 必须加：proxy_set_header Connection "" —— 注意是空字符串，不是 "keep-alive"，否则可能被上游误解为要关闭连接
• 如果 upstream 是自己控制的服务（如 Node.js、Go），确保它返回响应头里有 Connection: keep-alive（多数框架默认支持）

不加这两行，upstream 里的 keepalive 指令完全无效，Nginx 仍走短连接。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

upstream 块里的 keepalive 参数怎么设才合理？

这个 keepalive 是每个 worker 进程维护的空闲连接池大小，不是全局值，单位是「连接数」，和 keepalive_requests（单连接最大请求数）是两回事。

• keepalive 32 表示每个 worker 最多缓存 32 个空闲到该 upstream 的连接
• 初始值建议按：(预估峰值并发 / worker_processes) × 1.2 计算；比如并发 5000、4 个 worker，就设 keepalive 1500
• keepalive_requests 10000 推荐设高些（默认 100 太保守），避免连接过早释放；但注意不要设得远超业务实际，否则连接长期空闲占用资源
• keepalive_timeout 60s 控制空闲连接存活时间，比 client 端的 keepalive_timeout 略短更稳妥（比如 client 设 75s，upstream 设 60s）

老版本 Nginx（keepalive 指令，升级前务必确认版本。

为什么加了配置还是看到大量 TIME_WAIT 或 502？

典型原因不是配置写错，而是上下游行为不匹配：

• 后端服务主动关闭连接（如 Spring Boot 默认 server.connection-timeout 为 -1，但某些中间件或负载均衡器会干预）
• Nginx proxy_read_timeout 小于后端处理耗时，导致 Nginx 主动断连再重试，触发 502
• upstream server 崩溃或拒绝连接，而 max_fails/fail_timeout 没配，Nginx 不剔除节点，持续转发失败
• 用 proxy_pass http://127.0.0.1:8080 直连本地端口时，Linux 本地回环的 TIME_WAIT 更难复用，建议改用 unix socket 或至少加大 net.ipv4.tcp_tw_reuse

真正稳定的长连接，从来不只是加几行配置的事——它要求 client、Nginx、upstream 三方在协议版本、header 语义、超时策略上达成一致。少一个环节，整条链路就退化成短连接。