Apache与Nginx性能调优对比

Apache与Nginx架构解析：Prefork、Event与异步非阻塞模型对比

很多刚入行的同学容易把这两个Web服务器搞混，觉得不就是个处理HTTP请求的软件嘛，有啥区别？可以这么理解，这俩的底层设计哲学完全不一样，这就好比一个是开了很多家实体店（Apache），一个是搞了个超大的中央调度中心（Nginx）。

咱们先看 Apache HTTP Server。目前的长期支持版是 2.4.58（2023年10月更新），这个系列非常稳。Apache最核心的概念就是 多处理模块 (MPM)。这就好比你开餐馆，有三种管理模式：

Prefork MPM：这是最经典的“老派”模式。它就像雇了一堆服务员（进程），每个服务员只服务一桌客人。哪怕客人只是发呆不点菜，这服务员也得在那儿杵着。这种模式最大的好处是稳，因为进程之间互不干扰，一个崩了不影响其他。但致命伤是，资源消耗极大。你的服务器内存是有限的，开几百个进程内存就爆了。所以，现在但凡有点并发要求的，基本都不用这个模式了，除非你跑的是那种非常古老、非线程安全的PHP库。
Worker MPM：这个进化了一点，引入了线程。一个服务员（进程）可以带几个实习生（线程）。这样资源占用少了一点，但线程之间虽然共享内存，处理起来还是阻塞的，一旦某个线程卡住了，同进程下的其他线程也会跟着遭殃。
Event MPM：这是Apache 2.4系列里的“救世主”。它借鉴了点Nginx的思想，搞了个事件驱动。它把“监听连接”和“处理请求”分开了。就像餐馆里有个专门负责带位的，把客人带到座位后，服务员只需要等客人点完菜再过去，而不是一直站在旁边。这大大提升了处理并发的能力。

再来看看 Nginx。最新稳定版已经到了 1.26.0（2024年4月），主线版是 1.25.4。Nginx从娘胎里出来就是基于 异步非阻塞事件驱动 的。它的架构非常简洁：一个Master进程 + 多个Worker进程。

可以这么理解，Nginx的Worker进程就像是一个超级能干的“六边形战士”。它基于 epoll（Linux下）这种机制，可以同时盯着成千上万个连接。当连接A发来数据，Worker就去处理一下；处理完A，马上去处理B，完全不需要等待。它不会因为某个连接慢或者网络卡顿就傻等，而是转头去处理下一个。这就是为什么Nginx在处理高并发静态文件或者做反向代理时，资源占用低得吓人，单Worker就能扛几千连接。

面试的时候经常问，为什么Nginx适合高并发？就是因为它的Worker进程是单线程的（通常配置成和CPU核数一样），没有进程/线程切换的开销，也没有锁的竞争，全靠内核的事件通知机制，效率极高。

架构对比代码示例

虽然架构是概念，但我们可以通过配置看端倪。比如Apache的Prefork配置，你能看到它是如何“堆进程”的：

# Apache Prefork MPM 配置示例 (httpd-mpm.conf)
<IfModule mpm_prefork_module>
    # 启动时就开5个进程
    StartServers             5
    # 最小空闲进程数
    MinSpareServers          5
    # 最大空闲进程数
    MaxSpareServers         10
    # 值得留意的是，这是限制并发的关键，最多256个进程，也就是最多256个并发
    MaxRequestWorkers      256
    # 每个进程处理完3000个请求后重启，防止内存泄漏
    MaxRequestsPerChild   3000
</IfModule>

而Nginx的配置，你看不到“并发数”这种设置，因为它靠的是Worker的连接数：

# Nginx 核心配置片段
user nginx;
worker_processes auto; # 自动设置为CPU核数，这是最佳实践

events {
    # 每个Worker进程能处理的最大连接数
    worker_connections 1024;
    # 使用epoll模型，这是Linux下高性能的基石
    use epoll;
}

📌 要点提醒：如果你现在的服务器还是用的Apache Prefork，赶紧看看 top 命令，是不是一堆 httpd 进程把内存吃光了？如果是，且你不需要 .htaccess 这种目录级配置，强烈建议切换到 Event MPM 或者干脆迁移到 Nginx。

2024实战：Apache 2.4 MPM Event调优与Nginx 1.26核心参数配置

光知道理论不行，咱们得动手调。2024年了，如果你还在用默认配置跑生产环境，那简直就是在“裸奔”。咱们分别针对 Apache 2.4.58 和 Nginx 1.26.0 来一套实战调优。

先说 Apache 2.4 MPM Event。这是目前Apache跑动态应用（比如PHP）最推荐的模式。调优的核心在于平衡“进程/线程数”和“内存”。

在Event模式下，Apache不再是一个连接占用一个进程了，而是引入了专门的“监听线程”和“工作线程池”。配置的时候，你要关注这几个参数：

ServerLimit：整个Apache能启动的最大进程数。
MaxRequestWorkers：能同时处理的最大请求数。这是硬限制，决定了你的并发上限。
ThreadsPerChild：每个进程里开多少个线程。
AsyncRequestWorkerFactor：这是Event MPM的精髓，用来控制异步连接的数量，防止慢连接（比如下载慢）占满Worker。

举个例子，假设你有一台4核8G的服务器，跑的是WordPress。你不能把 MaxRequestWorkers 设得太高，不然内存爆了系统直接卡死。一般一个Apache进程（包含PHP）可能占30-50MB内存，8G内存你最多也就跑100-150个左右，还得给系统留点。

再来看 Nginx 1.26.0。Nginx的调优更多是在操作系统层面和IO模型上。除了刚才说的 worker_processes 和 worker_connections，你还得关注 sendfile、tcp_nopush 和 tcp_nodelay。

sendfile on：这玩意儿必须开。简单来说，就是让内核直接把文件从磁盘发到网卡，不用经过用户态（Nginx）的拷贝，性能提升巨大。
tcp_nopush on：配合 sendfile 使用，把HTTP响应头和文件的开头打包一起发，减少网络包数量。
tcp_nodelay on：这是针对小数据包的，比如API请求，要求实时性高，禁用Nagle算法，有数据立马发。

实战配置代码

Apache 2.4 Event MPM 调优配置：

# 编辑 /etc/httpd/conf.modules.d/00-mpm.conf 或 httpd-mpm.conf
<IfModule mpm_event_module>
    # 服务器启动时建立的子进程数
    StartServers             3
    # 空闲子进程的最小数量
    MinSpareThreads         75
    # 空闲子进程的最大数量
    MaxSpareThreads        250 
    # 每个子进程产生的线程数量
    ThreadsPerChild         25
    # 最大请求数量，这里算一下：ServerLimit * ThreadsPerChild
    # 假设我们设 ServerLimit 为 20，那就是 20 * 25 = 500 并发
    MaxRequestWorkers      500
    # 允许同时存在的连接数（包括正在处理的和空闲的），通常设为 MaxRequestWorkers 的1-2倍
    # 2024年的新特性，对HTTP/2和慢连接支持更好
    AsyncRequestWorkerFactor 2
    # 每个子进程在死亡之前允许处理的请求数量，防止内存泄漏
    MaxConnectionsPerChild   10000
</IfModule>

Nginx 1.26 核心参数调优配置：

# 编辑 /etc/nginx/nginx.conf
user nginx;
worker_processes auto; # 自动检测CPU核数
worker_cpu_affinity auto; # 2024年推荐开启，将worker绑定到特定CPU核，减少上下文切换

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 4096; # 单worker连接数，配合 worker_rlimit_nofile 使用
    use epoll;
    multi_accept on; # 一次accept多个新连接，高并发下更快
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 开启高效文件传输模式
    sendfile on;
    # 优化数据包发送，仅在sendfile开启时有效
    tcp_nopush on;
    # 禁用Nagle算法，提升实时性
    tcp_nodelay on;

    # 连接超时时间，别设太长，防止资源占用
    keepalive_timeout 65;
    
    # 开启gzip压缩，省带宽
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    # 包含其他配置
    include /etc/nginx/conf.d/*.conf;
}

🔧 实战技巧：调完配置千万别忘了做压力测试。用 ab（ApacheBench）或者 wrk 打一下流量，看看错误率和响应时间。比如 wrk -t12 -c400 -d30s http://your-site.com。如果Apache的 MaxRequestWorkers 设低了，你会看到很多请求被拒绝或者排队；如果Nginx的 worker_connections 不够，错误日志里会有 "worker_connections exceed" 的提示。

进阶技巧：Nginx零停机热部署与Apache .htaccess性能陷阱规避

做运维或者全栈开发，最怕的就是改个配置还要重启服务，导致用户断线。这节咱们聊聊怎么优雅地操作，以及怎么避开Apache的一个大坑。

先说 Nginx 1.26.0 的零停机热部署（Hot Deployment）。这绝对是Nginx的一大杀器。可以这么理解，就是在不停止服务的情况下，把Nginx二进制文件升级了，或者仅仅是重载配置。

Nginx有个Master-Worker模型。Master负责管理，Worker负责干活。当你修改了 nginx.conf，只需要执行 nginx -s reload。这时候Master会启动新的Worker进程（用新的配置），然后给旧的Worker进程发信号，让它们“处理完手头的活就退休”。整个过程用户完全感知不到，连接不会断。

更牛的是升级二进制文件。你编译好新的Nginx，把旧的二进制文件替换掉，然后给Master进程发一个 USR2 信号。Master会启动一个新的Master和新的Worker。这时候新旧两套进程并存。如果新版没问题，你就给旧Master发 WINCH 信号让它优雅退出；如果有问题，直接给新Master发 QUIT，回滚到旧版本。这简直是救火神技。

再说说 Apache的 .htaccess 陷阱。很多用Apache的同学特别喜欢 .htaccess，因为方便，放在网站目录里就能生效，不用重启服务器。但是，这是性能杀手。

简单来说，Apache为了支持 .htaccess，必须在处理每一个请求的时候，去遍历请求路径下的所有目录，查找是否有 .htaccess 文件，并读取解析它。比如你的请求是 /var/www/html/a/b/c/index.php，Apache得查 /、/a、/a/b、/a/b/c 这四个目录里有没有 .htaccess。在高并发下，这全是磁盘I/O开销，而且是完全没必要的。

在生产环境，一定要在 httpd.conf 里把 AllowOverride 设为 None。把原本在 .htaccess 里的规则（比如伪静态重写），全部挪到 VirtualHost 配置里。这样Apache只在启动的时候读一次配置，性能直接起飞。

实战操作代码

Nginx 平滑重载与升级示例：

# 1. 修改配置后，测试配置是否正确
sudo nginx -t

# 2. 平滑重载配置（零停机）
sudo nginx -s reload

# 3. 二进制热升级（假设你要从1.24升级到1.26）
# 先备份旧的二进制
mv /usr/sbin/nginx /usr/sbin/nginx.old
# 把新的二进制拷贝过去
cp /path/to/new/nginx /usr/sbin/nginx

# 找到当前的Nginx Master进程PID
ps aux | grep nginx
# 假设Master PID是 12345
# 发送 USR2 信号，启动新的Master和Worker
kill -USR2 12345

# 此时 ps aux 会看到两组Nginx进程
# 确认新版本工作正常后，给旧Master发 WINCH 信号，让它优雅关闭旧Worker
kill -WINCH 12345

# 最后确认没问题，彻底关闭旧Master
kill -QUIT 12345

Apache 禁用 .htaccess 并迁移规则示例：

# 在 httpd.conf 或虚拟主机配置中
<VirtualHost *:80>
    ServerName www.example.com
    DocumentRoot /var/www/html
    
    # 注意，关闭 .htaccess 支持，提升性能
    <Directory /var/www/html>
        Options FollowSymLinks
        # 设为 None，禁止解析 .htaccess
        AllowOverride None
        Require all granted
    </Directory>

    # 把原本在 .htaccess 里的 Rewrite 规则写在这里
    # 比如 WordPress 的伪静态规则
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteRule ^index\.php$ - [L]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]
    </IfModule>
</VirtualHost>

📌 要点提醒：如果你现在用的是Apache且没法换（比如老项目依赖太多），请务必检查一下 AllowOverride 的设置。用 strace 跟踪一下Apache进程，看看它是不是在疯狂 stat .htaccess 文件。如果是，赶紧关掉，性能至少提升20%-30%，这可是白捡的优化。

场景对决：高并发静态资源与动态PHP应用（mod_php vs PHP-FPM）调优

咱们最后来点硬碰硬的实战场景。Web服务器主要干两件事：一是发静态文件（图片、CSS、JS），二是跑动态应用（比如PHP）。这两个场景下，Apache和Nginx的表现简直是天壤之别。

场景一：高并发静态资源。

可以这么理解，这就好比送快递。Nginx是那种自带GPS、路线规划极其牛逼的快递员，一次能送几百单。Apache（即使是Event模式）更像是一个个开着小货车（进程/线程）的司机，送完一个再送下一个。

Nginx在处理静态文件时，配合 sendfile 和 aio（异步IO），效率极高。而且Nginx本身内存占用极小，10k个连接可能也就占几十兆内存。Apache如果要处理10k并发，你得开多少进程？光进程表就能把内核累死。所以，做图片服务器、CDN边缘节点、静态资源站，闭着眼选Nginx。

场景二：动态PHP应用。

这里有个历史遗留问题。老派的LAMP架构是 Apache + mod_php。mod_php 是把PHP解释器直接编译进Apache进程里的。好处是快，不用启动外部进程。坏处是，Apache进程再大，内存占用飙升。而且，哪怕你只是请求一张图片，Apache也得加载整个PHP解释器，纯属浪费。

现在的主流是 Nginx + PHP-FPM 或者 Apache + PHP-FPM。

Apache + PHP-FPM：Apache通过 mod_proxy_fcgi 把PHP请求转发给后端的FPM服务。这比 mod_php 省内存，因为Apache进程不需要带PHP了。但依然受限于Apache的进程模型。
Nginx + PHP-FPM：这是2024年的绝对主流。Nginx负责抗并发、处理静态文件，遇到PHP请求，通过FastCGI协议扔给PHP-FPM。FPM是专门管理PHP进程的，效率极高。而且Nginx和FPM可以分开部署在不同的机器上，架构扩展性极强。

注意：面试常问 mod_php 和 PHP-FPM 的区别。记住一点：mod_php 是Apache的一部分，而 PHP-FPM 是一个独立的服务。独立意味着你可以独立重启、独立调优，不会被Web服务器拖后腿。

场景配置代码

Nginx + PHP-FPM 配置（现代主流）：

server {
    listen 80;
    server_name example.com;
    root /var/www/html/wordpress;
    index index.php index.html;

    # 静态文件直接处理，高并发下表现极佳
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 365d;
        add_header Cache-Control "public, immutable";
        # 值得留意的是，静态文件不需要记录日志，省IO
        access_log off;
    }

    # 动态请求交给 PHP-FPM
    location ~ \.php$ {
        # 确保文件存在，防止恶意上传脚本执行
        try_files $uri =404;
        
        # 这里用 unix socket 通信，比 TCP 端口更快
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_index index.php;
        
        # 引入 FastCGI 参数
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        
        # 提升性能：设置脚本执行超时时间
        fastcgi_read_timeout 300;
        
        # 2024年推荐：开启缓冲，防止大请求体阻塞
        fastcgi_buffering on;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
    }
}

Apache 2.4 + PHP-FPM (Event MPM) 配置：

# 1. 确保启用了必要的模块
# a2enmod proxy_fcgi setenvif
# 2. 在虚拟主机配置中
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html/wordpress

    <Directory /var/www/html/wordpress>
        Options FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    # 静态文件缓存
    <FilesMatch "\.(ico|jpg|jpeg|png|gif|css|js)$">
        Header set Cache-Control "max-age=31536000, public"
    </FilesMatch>

    # 核心要点：使用 ProxyPassMatch 把 PHP 请求转给 FPM
    # 注意这里的 socket 路径或端口
    <FilesMatch \.php$>
        # 如果FPM在本地监听9000端口
        # SetHandler "proxy:fcgi://127.0.0.1:9000"
        # 如果用 unix socket
        SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"
    </FilesMatch>

    # 别忘了关掉旧的 mod_php (如果加载了的话)
    # 在 conf 里注释掉 LoadModule php_module ...
</VirtualHost>

💡 经验总结：如果你的业务是动态为主的，比如电商网站，不要纠结了，直接上 Nginx + PHP-FPM。调优的时候，重点看 php-fpm.conf 里的 pm.max_children（决定最多能处理多少并发PHP请求）和 pm.max_requests。同时，Nginx那边的 fastcgi_buffer_size 也要调大一点，防止PHP输出的页面太大导致502错误。

5. 容器化与云原生：Docker/K8s环境下Apache与Nginx的轻量化部署

可以这么理解，现在咱们搞部署，要是还只盯着裸机或者虚拟机，那真的有点跟不上时代了。2024年了，大家都在玩 Docker 和 Kubernetes (K8s)。在这个场景下，Apache 和 Nginx 的表现那可真是天差地别，避雷经验的经历能写满几页纸。

先聊聊 Nginx。这货天生就是为轻量化而生的。你看最新的 Nginx 1.25.4 (主线版) 或者 1.26.0 (稳定版)，它的镜像体积控制得相当好。在 K8s 里，Nginx 通常作为 Ingress Controller 或者前端代理，启动速度极快，内存占用低得感人。它的 Master-Worker 进程模型在容器里表现非常稳，配合 K8s 的探针（Liveness/Readiness Probes），简直丝滑。

再看看 Apache。Apache 2.4.58 虽然稳定，但在容器化里就有点“重”了。特别是如果你还抱着老一套的 Prefork MPM 不放，那在容器里分分钟把内存撑爆。容器讲究的是单进程管理（PID 1 问题），Apache 默认的那套启动逻辑有时候会让你在 Docker 日志里抓瞎。不过，Apache 有个大杀器叫 Event MPM，这在容器化环境下是救命稻草。

咱们直接上干货，看怎么写 Dockerfile。

Nginx 的轻量化 Dockerfile 示例

这是我自己常用的一个基于 Alpine 的 Nginx 配置，主打一个快和稳：

# 使用 Nginx 1.25.4 的 Alpine 版本，体积小，安全性高
FROM nginx:1.25.4-alpine

# 把本地的 nginx 配置文件拷贝进去
# 值得留意的是，这里建议把配置文件先准备好，不要在容器里改
COPY nginx.conf /etc/nginx/nginx.conf
COPY default.conf /etc/nginx/conf.d/default.conf

# 静态资源直接打进镜像，或者挂载 Volume
COPY static-html-dir /usr/share/nginx/html

# 暴露 8080 端口，别用默认的 80，容器里非 root 用户跑更香
EXPOSE 8080

# 健康检查，K8s 必备
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1

# 启动命令，alpine 版本里的 nginx 默认就是前台运行
CMD ["nginx", "-g", "daemon off;"]

Apache 的容器化生存指南

Apache 在容器里跑，必须得改掉“肥大”的毛病。下面这个 Dockerfile 展示了如何基于 httpd:2.4.58 切换到 Event MPM：

FROM httpd:2.4.58

# 启用 Event MPM 并禁用 Prefork
# 可以这么理解，就是把配置文件里的 LoadModule 换一下
RUN cd /usr/local/apache2/conf && \
    sed -i 's/^#LoadModule mpm_event_module/LoadModule mpm_event_module/' httpd.conf && \
    sed -i 's/^LoadModule mpm_prefork_module/#LoadModule mpm_prefork_module/' httpd.conf

# 复制你自己的配置文件
COPY httpd.conf /usr/local/apache2/conf/httpd.conf
COPY my-site.conf /usr/local/apache2/conf/extra/my-site.conf

# 开放端口
EXPOSE 8080

# 关键：让 Apache 前台运行，不然容器会秒退
# 这是新手实际案例最多的地方，忘了 -D FOREGROUND
CMD ["httpd", "-D", "FOREGROUND"]

在 K8s 里，Nginx 目前是绝对的王者，尤其是作为 Ingress Controller。虽然 Apache 也有 httpd-operator，但生态确实没那么活跃。如果你在 K8s 里跑 Apache，建议一定要用 Event MPM，并且把 MaxRequestWorkers 调低一点，因为容器是有内存限制的，不像物理机那样随便造。

💡 经验总结：

在 K8s 里跑 Apache 时，千万别挂载大的 ConfigMap 到 /etc/apache2/ 然后频繁修改。Apache 不像 Nginx 那样支持无缝的 nginx -s reload 且不影响连接，频繁重启 Apache 进程会导致你的 Pod 健康检查失败。尽量把配置打进镜像里，或者只在发布新版本时更新。

6. 常见面试题与排错：惊群效应、Worker进程优化及连接数限制

面试的时候，面试官特别喜欢问底层原理，尤其是那个“惊群”问题。简单来说，这题就是想考你知不知道服务器是怎么处理网络连接的。

惊群效应（Thundering Herd）与 Nginx 的解决之道

啥是惊群？想象一下，你有一堆 Worker 进程（比如 Nginx），它们都守在门口（accept() 调用）等着接客（新连接）。突然来了一个客人，结果所有进程都被惊动了，都去抢着接这个客人，最后只有一个抢到了，其他的白忙活一场。这就是惊群，浪费 CPU 资源。

Nginx 是怎么解决的？早期的 Nginx 用了 accept_mutex 这个指令。简单来说，就是给这帮 Worker 进程加一把锁，谁拿到锁谁才能去 accept 新连接，没拿到的就老实待着。这样就避免了集体去抢。

在最新版的 Nginx (比如 1.25.x 或 1.26.0) 里，其实在 epoll 这种先进的 I/O 多路复用机制下，内核层面已经帮我们解决了大部分惊群问题（通过 EPOLLEXCLUSIVE 标志）。但了解 accept_mutex 依然是个考点。

Worker 进程优化与连接数

不管是 Apache 还是 Nginx，调优的核心都在“进程”和“连接”上。

Nginx 的优化示例：

咱们看一段 Nginx 的核心配置，这可是生产环境的标准配置：

user nginx;
# 自动设置 Worker 数量，通常等于 CPU 核心数
worker_processes auto;

# 注意，绑定 CPU 亲和性，减少上下文切换
worker_cpu_affinity auto;

events {
    # 单个 Worker 能处理的最大连接数
    # 注意：这个连接数指的是单个 Worker 的连接，总连接数是 worker_processes * worker_connections
    worker_connections 10240;
    
    # 使用 epoll 模型，Linux 下性能最优
    use epoll;
    
    # 这个指令现在已经很少显式配置了，因为默认开启且逻辑优化了
    # accept_mutex on; 
}

http {
    # 开启高效文件传输模式
    sendfile on;
    # 防止网络阻塞
    tcp_nopush on;
    
    # 保持连接超时时间
    keepalive_timeout 65;
    
    # 限制单个 IP 的连接数，防 DOS 攻击
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    limit_conn perip 10;
    
    server {
        listen 80;
        server_name localhost;
        
        location / {
            root /usr/share/nginx/html;
            index index.html;
        }
    }
}

Apache 的 MPM 调优示例：

Apache 这边，如果你还在用 Prefork，那你得赶紧切到 Event MPM。这是 Apache 2.4.58 里推荐的配置：

<IfModule mpm_event_module>
    # 服务器启动时创建的子进程数
    StartServers             3
    # 空闲子进程的最小数量
    MinSpareThreads         75
    # 空闲子进程的最大数量
    MaxSpareThreads        250 
    # 每个子进程产生的线程数
    ThreadsPerChild        25
    # 允许同时处理的最大请求数（核心指标）
    MaxRequestWorkers      400
    # 每个子进程在其生命周期内允许处理的最大请求数，防止内存泄漏
    MaxConnectionsPerChild   1000
</IfModule>

# 连接数限制和超时
Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

# 限制请求体大小，防止大文件上传攻击
LimitRequestBody 1048576

面试常问：Nginx 里的 worker_connections 设置成 10240，是不是说最多只能有 10240 个人访问？

答案是：错！这里有个坑。如果是作为反向代理，worker_connections 指的是建立的连接数（包括客户端到 Nginx 和 Nginx 到后端），所以实际并发数要除以 2。如果是静态服务器，那就是直接面对客户端，worker_connections 基本就是并发上限。

⚡ 效率提示：

排查连接数问题的时候，别光看配置。在 Linux 上，记得检查 ulimit -n。很多时候配置文件里写了 worker_connections 65535，但系统限制每个进程只能开 1024 个文件描述符（FD），那也是白搭。在 Docker 容器里，记得在 K8s 的 deployment.yaml 里加上 securityContext 或者调整 initContainers 来修改 ulimit。

7. 总结与选型：2024-2026技术趋势下的Web服务器决策指南

做了这么多年全栈，经常有人问我：“老哥，新项目来了，我到底是用 Apache 还是 Nginx？”

其实到了 2024 年，答案已经越来越清晰了，但也不是绝对的。咱们得结合未来的技术趋势来看。

核心差异回顾与技术趋势

从架构上看，Nginx 的异步非阻塞事件驱动模型，在处理高并发静态资源、作为 API 网关或者反向代理时，那是碾压级的优势。特别是现在 Nginx 1.26.0 (稳定版) 对 HTTP/3 和 QUIC 协议的支持越来越成熟，这在未来的网络加速中会是标配。而且，Nginx 在 Kubernetes Ingress 领域的统治地位，决定了它在云原生时代是绝对的主角。

反观 Apache HTTP Server 2.4.58，它依然有不可替代的场景。特别是那种传统的、依赖 .htaccess 进行目录级配置的项目（比如很多老牌的 PHP 虚拟主机环境），或者是深度依赖 mod_php 的遗留系统。不过，Apache 社区也在努力，正在向 云原生轻量化 改进，并且也在加强对 HTTP/3 的支持。但说实话，它的进程模型决定了它在微服务架构里会显得有些笨重。

决策指南：什么时候选谁？

直接上结论，不绕弯子：

选 Nginx 的场景：

- 你要做一个 高并发的 API 网关 或者 微服务入口。

- 你的主要任务是处理 静态资源（图片、视频、前端打包文件），或者做 CDN 边缘节点。

- 你要部署在 Docker/K8s 环境里，需要极低的镜像体积和快速启动。

- 你需要做七层负载均衡，并且需要复杂的路由规则（虽然 OpenResty/Lua 更灵活，但原生 Nginx 也够用）。

- 注意：如果你在关注 2024-2026 的 HTTP/3 趋势，Nginx 的落地实践目前比 Apache 更丰富。

选 Apache 的场景：

- 你在维护一个老旧的 LAMP 栈应用，贸然换成 Nginx 改造成本太高。

- 你的客户是那种传统的虚拟主机用户，他们习惯用 .htaccess 改配置，你没法控制他们的操作习惯。

- 你的应用强依赖 Apache 特有的模块（比如某些特定的 WAF 规则或者认证模块），且迁移难度大。

2024-2026 年的新考量

未来的两年，咱们选型不能只看现在。两个趋势必须考虑：

零信任安全与 WAF：不管是 Nginx 还是 Apache，集成 Web Application Firewall (WAF) 都会越来越重要。Nginx 有 NAXSI 和 ModSecurity 的适配，Apache 原生对 ModSecurity 支持很好。
动态配置与 API 化：Nginx 正在努力减少对配置文件的依赖，通过 API 动态修改 upstream 是趋势。如果你选 Nginx，尽量往这个方向靠，别老是 nginx -s reload，在大规模集群里这会是个痛点。

🔧 实战技巧：

如果你现在正在启动一个新项目，且没有任何历史包袱，无脑选 Nginx。直接上 1.26.0 稳定版，配合 Docker 部署。如果你必须要用 Apache，请务必在编译或者 Dockerfile 里启用 Event MPM，并且把 MaxRequestWorkers 根据容器内存算好，别让 Apache 把容器内存吃光导致 OOM (Out Of Memory) Kill。

其实，技术选型没有绝对的对错，只有适不适合当下的业务场景和未来的扩展需求。作为工程师，我们要做的就是看清趋势，别在即将淘汰的技术上浪费太多时间。