Nginx 不为每个虚拟主机启动独立进程或实例，而是由 Master 进程加载全部 server 块配置并管控 worker 进程，各 worker 统一通过 Host 头或监听端口匹配请求、处理所有虚拟主机流量。

Nginx 并不通过 Master 进程“管理多个虚拟主机的实例”。这个说法存在概念混淆——Nginx 没有为每个虚拟主机（server 块）单独启动进程或实例，而是由一组工作进程（worker processes）共同处理所有配置的虚拟主机请求。

Master 进程只负责全局控制，不参与请求处理

Master 进程是 Nginx 的主控进程，职责包括：

• 读取并校验配置文件（如 nginx.conf 中的多个 server 块）
• 启动、监控和优雅重启 worker 进程
• 接收信号（如 reload、stop）并协调 worker 行为
• 不处理任何 HTTP 请求，也不感知具体哪个虚拟主机被访问

Worker 进程统一处理所有虚拟主机的请求

所有 server 块（即虚拟主机）都加载在内存中，由每个 worker 进程按需匹配和响应：

• 当请求到达时，worker 根据 Host 请求头 或 监听地址+端口 匹配对应的 server 块
• 同一个 worker 可能先后处理来自 example.com、api.test 和默认 server 的请求
• 虚拟主机之间共享同一套事件循环、连接池和缓存机制，无隔离性

虚拟主机不是独立进程，更不是“实例”

“实例”通常指独立运行、有自己内存空间和生命周期的进程（如多个 nginx -c conf1.conf 启动）。而 Nginx 中的虚拟主机只是配置层面的逻辑分组：

• 没有单独 PID、资源配额或故障隔离能力
• 一个 server 块出错（如 rewrite 循环）可能影响整个 worker 的稳定性
• 若需强隔离，应使用容器（Docker）、命名空间或部署多个 Nginx 实例（不同端口/配置/用户）

如何正确理解 Nginx 的多站点架构

典型做法是：

• 在主配置中用 include sites-enabled/*.conf; 统一管理多个 server 块
• 每个 server 块定义自己的 server_name、root、SSL 配置等
• 通过 worker_processes auto; 让 Nginx 自动适配 CPU 核心数，提升并发处理效率
• 借助 limit_conn、limit_req 等指令实现 per-server 流量控制（非进程级）