Nginx微服务网关调优核心是匹配内核与流量特征：启用epoll+multi_accept、worker_connections需满足ulimit和somaxconn、keepalive_timeout设为15s、worker_cpu_affinity auto绑定CPU。

微服务架构下，服务间通信频繁、请求体小、连接数多，Nginx 作为 API 网关或边车代理时，events 块的配置直接影响小报文（如 JSON RPC、gRPC metadata、健康检查）的并发吞吐与延迟稳定性。关键不在“调大数值”，而在匹配内核能力与业务流量特征。

用 epoll + multi_accept 减少事件唤醒开销

Linux 下默认使用 epoll，但需显式启用并配合 multi_accept 才能高效处理突发的小连接请求（如服务发现心跳、熔断器探测）：

• 必须写明 use epoll;：避免 Nginx 在运行时自动降级为较慢的 select 或 poll
• 开启 multi_accept on;：让单次事件就绪后尽可能多地 accept 新连接，降低小报文场景下“一次只收一个连接”的调度抖动
• 不建议混用 accept_mutex（默认 on）：微服务网关常为单 worker 多核绑定或容器化部署，mutex 会人为串行化 accept，反而增加首包延迟

worker_connections 要匹配 ulimit 和 net.core.somaxconn

设为 65536 不代表真能撑住 6.5 万并发连接——它受限于系统层两个硬指标：

• ulimit -n 必须 ≥ worker_processes × worker_connections：否则 Nginx 启动报错或静默降级
• net.core.somaxconn（内核全连接队列长度）应 ≥ worker_connections：尤其在秒级高频健康检查（如 /actuator/health）下，避免连接被内核丢弃
• 容器环境注意：Docker/K8s 默认限制 ulimit，需在 securityContext 或 docker run --ulimit 中显式提升

keepalive_timeout 和 keepalive_requests 针对短会话调优

微服务间 HTTP/1.1 调用多为“一请求一响应”，长连接价值有限，但盲目关闭又增 TLS 握手开销。折中策略是：

• keepalive_timeout 15s;：比默认 75s 更激进，快速回收空闲连接，释放 fd 给新请求
• keepalive_requests 100;：限制单连接最大请求数，防个别客户端长期霸占连接（如 misconfigured sidecar）
• 若用 HTTP/2 或 gRPC over TLS，可适当延长 keepalive_timeout 至 30–60s，因复用更充分

worker_cpu_affinity 自动绑定提升缓存局部性

在多核宿主机或 K8s 节点上，让每个 worker 固定绑定 CPU 核心，减少上下文切换和 L3 缓存失效：

• 推荐写法：worker_cpu_affinity auto;（Nginx 1.9.10+）：自动按核心数分配，比手动写 0001 0010 更健壮
• 配合 worker_processes auto;：确保 worker 数 ≤ CPU 核心数，避免争抢
• K8s 中若设置 resources.limits.cpu: "2"，则 worker_processes 2; + worker_cpu_affinity auto; 是安全组合