Nginx是高并发系统的流量调度中枢，非吞并发主力；需通过auto worker_processes、epoll/reuseport、加权轮询、健康检查及分层限流等协同优化，实现轻量入口、精准分发与可靠透传。
Nginx 本身不是“吞并发”的主力，而是高并发系统中高效、稳定、可干预的流量调度中枢。要承载千万级流量，关键不在堆 Nginx 实例数量，而在于用对它的角色——做轻量入口、精准分发、快速拦截、可靠透传，并与后端架构深度协同。
主从进程模型必须匹配硬件与负载特征
worker_processes 必须设为 auto，让 Nginx 自动绑定 CPU 核心，避免跨 NUMA 节点调度带来的缓存失效；配合 worker_rlimit_nofile 提升单进程文件描述符上限（如设为 65536），再通过系统级 ulimit -n 调整至 1048576，才能支撑单机 10 万+ 并发连接。每个 worker 进程独立处理事件，无锁竞争，这是高并发稳定性的底层保障。
连接模型要消除瓶颈点
启用 epoll（Linux）或 kqueue（BSD）事件驱动机制，确保 I/O 多路复用效率；在 listen 指令中加入 reuseport，使多个 worker 进程能各自监听同一端口，彻底缓解“惊群效应”；关闭 access_log 或启用 buffered 日志 + flush 控制刷盘节奏，防止磁盘 I/O 成为性能短板；静态资源服务开启 sendfile、tcp_nopush 和 gzip，实测可提升文件交付吞吐 300%。
上游分发不能只靠默认轮询
根据后端实际状态选算法：性能不均时用加权轮询（weight 参数）；登录态强依赖 session 的业务启用 ip_hash（注意 NAT 环境下失真，可改用 cookie hash）；长连接密集型服务（如 WebSocket）优先 least_conn；延迟敏感接口结合 proxy_next_upstream error timeout http_502 实现自动故障转移，并配 health_check 主动探测后端健康状态。
限流与容错必须分层落地
limit_req_zone 只适合单机轻量预判（如每秒 50 请求防扫描），不能承担千万 IP 全局限速任务；真正的分布式限流需下沉到 Redis Cluster，用滑动窗口 + LRU 本地缓存平衡精度与性能；proxy_next_upstream 配置 error timeout http_500–504，确保一次失败不直接甩给用户；max_fails=2 fail_timeout=15s 让异常节点快速摘除、自动试探恢复。
