nginx 与 Apache：哪个服务器运行哪个工作负载？

要点

• 并发模型决定优势：nginx 的异步事件循环通过少数工作进程处理数千个并发连接，这就是它主导静态和反向代理层的原因； Apache 的事件 MPM 弥补了这一差距，但仍然在相同硬件上为每个连接分配更多资源。
• 配置理念冲突：Apache 携带 .htaccess 和每个目录的覆盖（共享托管的创建便利性），而 nginx 配置是扁平的每个站点包含具有重新加载规则的文件；日常效果是由团队组成的，谁在哪里编辑配置。
• 混合堆栈是合法的，而不是逃避：前面的 nginx 作为 TLS 终结器和静态服务器，后面的 Apache 用于应用程序，是一种经过实战考验的形状，可以保留 htaccess 工具，同时获得 nginx 的边缘性能；成本是多了一层故障排除和监控。
• 每个引擎都完全获胜：nginx 赢得了连接繁重的代理、保持活动的边缘工作和缓慢的客户端耗尽； Apache 赢得了每个目录的配置能力、遗留模块兼容性以及 mod_security/mod_php 级共享托管资产，而其他生态系统都没有如此成熟。
• LiteSpeed 是许多主机寻求的第三个选项（我们的专门文章对此进行了介绍）：与事件驱动并发的 Apache 兼容性，按内核许可，因此存在共享托管经济的“替换 Apache，保留配置”中间路径。
• 在我们的网络服务器类别中保持不变的决策过程：命名工作负载（边缘的 nginx；htaccess 密集型应用程序后面的 Apache），在混合时保持两个角色明确，对您自己的流量进行基准测试（而不是杂志基准测试），并记住这是一个您可以迭代的决定，因为两个引擎可以愉快地共存。

一线手记

教会我们混合堆栈习惯的客户：前面的 nginx 用于 TLS 和静态，后面的 Apache 承载了十二年的 htaccess 知识，没人敢重写。诚实的答案不是“迁移到 nginx”，而是“命名每层的工作负载”。时至今日，它们仍然保持着这种形状，毫无生气，装饰得井井有条。

常见问题