nginx的反向代理由worker进程在事件驱动模型下协同http模块实现，主进程仅管理配置与进程，worker通过proxy_pass等指令调用proxy模块完成请求转发、头改写、连接复用及异步响应处理。
Nginx 的 Worker Process 本身不直接“实现”反向代理转发，它只是执行配置指令的运行实体；真正的反向代理逻辑由 Nginx 的事件驱动模型和 HTTP 模块（如 ngx_http_proxy_module）在 Worker 进程中协同完成。
Worker Process 的角色定位
每个 Worker Process 是一个独立的、非阻塞的单线程进程，负责监听端口、接收客户端连接、解析请求，并根据配置调用相应的处理模块。反向代理不是 Worker 自己写的代码逻辑，而是通过配置触发内置模块的行为。
- 主进程（Master）只负责管理 Worker 进程、读取配置、平滑重启等，不处理请求
- Worker 进程加载配置后，会为每个 upstream server 建立连接池，缓存后端连接，复用 TCP 连接
- 当请求到达，Worker 在 epoll/kqueue 事件循环中读取请求头，匹配 location，然后交由 proxy 模块组装转发请求
关键配置驱动转发行为
反向代理能力依赖于明确的指令配置，Worker 进程按这些指令调度模块工作：
- proxy_pass：指定后端地址（支持域名、IP、变量），是触发反向代理的核心指令
- proxy_set_header：重写请求头（如 Host、X-Real-IP），确保后端能正确识别原始请求
- proxy_http_version 1.1 + proxy_set_header Connection ""：启用 HTTP/1.1 长连接，提升后端复用效率
- proxy_buffering on/off：控制是否缓冲后端响应，影响 Worker 内存占用与响应流式传递
Worker 如何与后端交互
Worker 进程使用异步非阻塞 I/O 完成整个代理流程，不等待后端响应才处理下一个请求：
- 收到客户端请求后，Worker 解析 URI，匹配 location，初始化 upstream 上下文
- 从连接池获取空闲后端连接；若无，则新建连接（受
proxy_connect_timeout约束） - 将改写后的请求（含 headers 和 body）异步发送给后端；同时继续处理其他事件
- 后端响应到达时，Worker 从 socket 读取，经缓冲、过滤（如 gzip、add_header）后，再异步回传给客户端
常见影响转发效果的 Worker 相关设置
虽然转发逻辑由模块实现，但 Worker 数量和资源限制直接影响并发代理能力：
- worker_processes auto：通常设为 CPU 核心数，避免多进程争抢锁，提升吞吐
-
worker_connections 1024：每个 Worker 最大并发连接数，需结合
proxy_buffer_size和后端负载评估 - worker_rlimit_nofile：提高打开文件数限制，防止高并发下 “too many open files” 错误
- use epoll（Linux）：启用高效事件模型，降低 I/O 等待开销
