nginx高并发反向代理能力源于事件驱动模型与多路复用机制，每个worker进程以单线程方式通过epoll高效处理上万连接，配合多进程架构、合理缓冲及零拷贝优化，实现非阻塞、低延迟、高吞吐的请求转发。
Nginx 的高并发反向代理能力，并不依赖“开启”非阻塞 IO 的配置，而是由底层事件机制（如 Linux 的 epoll）天然承载的。它真正起作用的方式，是让每个 worker 进程以单线程、事件驱动的方式，同时监听并响应成千上万个连接——没有一个连接会卡住整个进程。
事件驱动 + 多路复用：一个进程管上万连接
Linux 下 Nginx 默认启用 epoll，它不轮询所有 socket，只在有数据可读、可写或连接就绪时才通知 worker 进程。这意味着：
- worker 不会因等待某个后端响应而停摆，可以立刻处理其他已就绪的客户端请求
- 即使上游服务（如 Java 微服务）响应慢，Nginx 也能继续收发其他请求，不会被阻塞
- 每个连接生命周期中，accept、read header、read body、proxy write、send response 等阶段都拆解为独立事件，按需触发
多进程协同：避免单点瓶颈
master 进程 fork 出多个 worker，每个 worker 独立运行、互不干扰：
- 默认 worker_processes auto，自动匹配 CPU 核心数，充分利用硬件
- 通过 accept_mutex on 控制连接分发，防止“惊群”，确保新连接只唤醒一个 worker
- 每个 worker 的 worker_connections 4096（或更高）决定了单进程并发上限，整体并发 = worker 数 × connections
缓冲与零拷贝：减少等待和搬运开销
非阻塞本身不提速，但配合合理缓冲策略，才能让非阻塞模型真正高效：
- proxy_buffer_size ≥12k，避免上游响应头过大导致 “upstream sent too big header” 错误
- proxy_buffers 8 16k，为分块响应预留足够内存空间，减少临时文件写入
- 启用 sendfile on 和 tcp_nopush on，让内核直接投递静态资源，跳过用户态拷贝
- 上传场景调大 client_body_buffer_size，避免小文件反复落盘，拖慢代理链路
mTLS 与反向代理不冲突
双向 SSL 认证（mTLS）发生在 TLS 握手阶段，Nginx 将其纳入事件状态机推进：
- 证书验证（如 CA 校验）在用户态完成，不触发系统 I/O 等待
- OCSP stapling 若开启且未缓存，可能引入延迟，建议关闭或设好 ssl_stapling_cache
- 向后端透传客户端证书只需配置 proxy_ssl_certificate 和 proxy_ssl_verify，不影响事件循环效率
