Nginx 不采用连接映射机制，其连接由 worker 进程独占并全程处理；所谓“映射”实为 HTTP 请求路径匹配或端口监听绑定，与底层连接无关。
Nginx 不通过“连接映射”这个概念来管理网络连接，它根本不存在传统意义上的连接映射表或连接状态转发机制。它的核心是事件驱动的连接处理模型，所有连接由 worker 进程直接接管、读写、关闭，不经过 master，也不在进程间传递连接句柄。
worker 进程独占连接，无共享映射
每个 TCP 连接一旦被 accept() 接收，就完全绑定到某个 worker 进程的 epoll 实例中。该连接的生命周期（接收请求、解析 HTTP、转发、响应、超时、关闭）全程由该 worker 独立完成。master 仅负责启动、监控和重启 worker，不参与任何连接数据流转。
- 连接不跨 worker 转发，也不存在“把连接从 A 映射到 B”的操作
- 没有全局连接池或连接路由表，避免锁竞争与状态同步开销
- epoll_wait() 返回就绪事件后，worker 直接调用 recv()/send() 操作本进程内的 socket fd
请求路径映射 ≠ 连接映射
用户常混淆的“映射”，实际发生在 HTTP 请求解析之后，属于 请求路径到后端服务的逻辑转发，与底层连接无关：
-
server_name匹配 Host 头，选定 server 块 -
location规则匹配 URI 路径，决定如何处理该请求 -
proxy_pass/alias/root在此阶段生效，仅影响请求内容分发或文件查找，不改变连接归属
端口与监听层面的“映射”本质是监听绑定
所谓“端口映射”，其实是 Nginx 主动在指定 IP:Port 上调用 bind() + listen()，对外暴露服务入口：
-
listen 80;表示 worker 进程共同监听本机 80 端口（通过 SO_REUSEPORT 或 accept mutex 协作） - 多个
server块可共用同一端口，靠 Host 头区分；不同端口则需分别 bind - 内网转发如
proxy_pass http://192.168.1.10:8080是新建 outbound 连接，与 inbound 连接完全独立
没有连接状态维护，靠非阻塞 I/O 驱动
Nginx 不保存连接的业务上下文映射关系。每个请求处理都是轻量、无状态的函数调用链：
- HTTP 解析完成后，立即根据配置决定是返回静态文件、代理到上游、还是返回错误页
- 即使启用 keepalive，复用的也是同一个 socket fd，仍由原 worker 全程持有
- 超时控制（
keepalive_timeout,client_header_timeout）由 event loop 定时器触发，不依赖映射索引
