微服务架构下连接风暴主因是空闲长连接堆积，需精准设置keepalive_timeout：健康检查场景建议15–30秒，gRPC/HTTP/2可延至30–60秒，须比客户端timeout小5–10秒，并同步调优upstream keepalive_timeout、keepalive及系统层somaxconn和ulimit参数。
微服务架构下，“连接风暴”往往不是突发流量引发的，而是由大量空闲长连接缓慢堆积、最终挤占资源导致的。关键不在压测峰值，而在 keepalive_timeout 设置是否匹配服务间通信节奏——设太长，连接滞留；设太短，频繁重建；调得准，才能稳住连接池水位。
精准匹配服务间心跳与调用频次
微服务网关常面对高频健康检查（如每5秒一次 /actuator/health）和低频业务调用。若 keepalive_timeout 仍用默认75秒，一个客户端连上来只发一次探针就沉默，Nginx 却要等满75秒才关，大量连接卡在“半活跃”状态。
- 建议设为 15–30秒：略高于典型心跳间隔（如5s×2–3倍），确保健康检查包能复用同一连接，又不给空闲连接过多滞留时间
- 若后端使用 gRPC 或 HTTP/2，可放宽至 30–60秒，因帧复用效率高、连接更“值钱”
- 务必比客户端侧 timeout 小 5–10 秒（如 OkHttp 默认 30s，则 Nginx 设 25s），避免服务端先断连引发 499 或重试震荡
协同 upstream keepalive_timeout 防止连接错配
只调客户端侧不够。如果 Nginx 到后端的 keepalive_timeout（upstream 块内）比客户端侧还短，会出现“刚复用就断”的尴尬——前一个请求刚走，连接就被回收，下一个请求又得重建。
- upstream 中显式设 keepalive_timeout 30s;（不能依赖全局值）
- 该值必须 小于后端服务自身的 keepalive 超时（如 Spring Boot 的 server.tomcat.connection-timeout=45s），否则后端先断，Nginx 连接池里会存一堆“伪可用”连接
- 配合 keepalive 64; 和 keepalive_requests 1000;，让每个 worker 缓存适量连接，并允许单连接承载更多轻量请求
结合系统层参数堵住底层丢连接漏洞
即使 Nginx 配置合理，若内核全连接队列（somaxconn）或文件描述符限制（ulimit -n）没跟上，连接会在 accept 阶段就被丢弃，表现为偶发 502 或连接超时，日志却无异常。
- 确认 net.core.somaxconn ≥ worker_processes × worker_connections（如 4 worker × 65536 = 262144，对应 sysctl 中设为 262144）
- 容器环境必须在 securityContext 或 docker run --ulimit 中显式提升 ulimit，否则默认 1024 会立刻打满
- 启用 multi_accept on; + use epoll;，让单次事件就绪时批量 accept，减少小报文场景下的连接调度抖动
用 ss 和 stub_status 实时验证效果
调优不是改完就结束。真实连接行为需靠观测确认：
- 运行 ss -tnp | grep :80 | wc -l 查看 ESTABLISHED 连接总数，应稳定在 worker_connections × 0.6～0.8 区间，而非持续爬升
- 访问 /nginx_status（需启用 stub_status）观察 Active connections 数，若长期接近 worker_connections 上限，说明 keepalive_timeout 仍偏长或后端响应慢拖住了连接
- 抓包看 TCP 层：空闲连接应在设定 timeout 后收到 FIN，而非突然 RST 或长时间无响应
