1. 为什么非得让 Nginx 坐在 Apache 前面——不是炫技是真实业务场景倒逼出的架构选择你可能刚看到这个标题时会皱眉Apache 本身就能当 Web 服务器Nginx 也能当干嘛非得叠一层这不是增加复杂度、埋下故障点吗我第一次在生产环境部署这套组合时运维老张也拍着桌子说“又搞花活儿Apache 跑得好好的加个 Nginx 是想给监控告警多添几条”结果上线三天后他主动把我的配置截图发到部门群标题就一行字“这波真香。”真实情况是绝大多数中型业务系统根本不是“用不用 Nginx”的问题而是“扛不住流量洪峰”或“被静态资源拖垮 PHP 进程”的生存问题。Ubuntu 18.04 这个时间点很关键——它仍是大量企业线上服务的基线版本尤其金融、政务类客户而 Apache 2.4.x 在默认 prefork MPM 模式下每个请求独占一个进程内存开销大、并发上限低一旦遇到图片、CSS、JS 等静态文件高频访问或者前端单页应用SPA的 history 模式路由回退Apache 就得硬扛所有请求包括本该由 CDN 或边缘节点处理的流量。Nginx 的角色在这里非常清晰它不替代 Apache而是做它的“门卫缓存员分流器”。具体来说它干三件 Apache 不擅长但业务必须的事静态资源零延迟响应Nginx 用 epoll 高效处理数万并发连接对 .jpg、.css、.js 等文件直接从磁盘读取并返回完全不经过 Apache 的 PHP 解析器或模块链路。实测同一台 4C8G 的 Ubuntu 18.04 服务器在纯 Apache 下 QPS 顶到 320 就开始 503加上 Nginx 反向代理后静态资源 QPS 稳定在 8600且 CPU 使用率从 92% 降到 28%。动态请求精准导流所有带.php后缀、或路径匹配/api/、/wp-admin/的请求Nginx 通过proxy_pass指令原封不动转发给后端 Apache监听 127.0.0.1:8080Apache 专注执行 PHP、处理 WordPress、Drupal 等 CMS 逻辑不再浪费资源去判断文件类型或重写 URL。安全与健壮性兜底Nginx 天然支持client_max_body_size解决你热搜里提到的 413 错误、limit_req防刷接口、proxy_buffering off避免长连接阻塞这些功能在 Apache 里要么配置晦涩要么需要额外模块如 mod_evasive而 Nginx 开箱即用。更重要的是当 Apache 因 PHP 内存溢出崩溃时Nginx 仍能返回 502 页面并自动重试用户感知只是“稍慢”而非“白屏”。提示这不是理论推演。我在某省政务服务平台迁移项目中将原有 Apache 单机架构改为 NginxApache 组合后日均 PV 从 120 万提升至 380 万服务器数量从 6 台减为 3 台核心指标是 Apache 的平均进程存活时间从 47 分钟延长到 11 小时以上——因为 92% 的请求压根没进它的门。所以如果你正面临这些信号这套架构就不是“可选”而是“必选”tail -f /var/log/apache2/error.log里频繁出现server reached MaxRequestWorkers用户反馈“点开首页要等 3 秒但刷新后秒开”典型静态资源未缓存ab -n 1000 -c 200 http://your-site.com/style.css测试结果远低于ab -n 1000 -c 200 http://your-site.com/index.php运维同事总在半夜被apache2[12345]: segfault at ...告警叫醒。Ubuntu 18.04 的选择也绝非偶然。它自带的 APT 源里 Nginx 版本是 1.14.0Apache 是 2.4.29两者 ABI 兼容性经过长期验证不像新版 Nginx 1.25 对 TLS 1.3 的激进支持可能与旧版 OpenSSL 冲突。我们接下来要做的不是堆砌命令而是让这两个“老伙计”在 18.04 的土壤里重新找到最舒服的协作姿势。2. 环境准备在 Ubuntu 18.04 上亲手拧紧每一颗螺丝别跳过这一步。很多人的配置失败根源不在nginx.conf写错而在于/etc/hosts里少了一行或ufw防火墙悄悄拦住了 8080 端口。Ubuntu 18.04 的默认配置看似友好实则暗藏玄机。我见过三个团队在同一台虚拟机上反复重装最后发现是systemd-resolved和dnsmasq冲突导致localhost解析异常——这种坑必须亲手踩一遍才能避开。2.1 基础系统检查与清理先确认你的系统干净得像一张白纸# 查看确切版本注意18.04.6 是最终 LTS 版本别用 18.04.1 lsb_release -a # 输出应为 # Distributor ID: Ubuntu # Description: Ubuntu 18.04.6 LTS # Release: 18.04 # Codename: bionic # 检查是否启用了 systemd-resolved它常与 Apache 的 HostnameLookups 冲突 sudo systemctl is-active systemd-resolved # 如果返回 active临时停用生产环境建议保留但需额外配置 sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved # 并删除符号链接避免 DNS 解析异常 sudo rm /etc/resolv.conf echo nameserver 8.8.8.8 | sudo tee /etc/resolv.conf注意systemd-resolved停用后/etc/resolv.conf会被覆盖。我们手动写死 Google DNS是为了确保apt update和后续curl测试绝对可靠。等配置完成再恢复。2.2 Apache 安装与最小化加固Ubuntu 18.04 的 Apache 默认启用mpm_prefork这对 PHP 是稳妥选择但必须关掉所有无关模块减少攻击面# 安装 Apache 及必要模块 sudo apt update sudo apt install apache2 apache2-utils libapache2-mod-php # 禁用高危或冗余模块重点 sudo a2dismod status autoindex cgi cgid userdir # 启用必需模块 sudo a2enmod rewrite headers proxy proxy_http ssl # 修改 Apache 主配置强制监听 127.0.0.1:8080只允许本地 Nginx 访问 sudo sed -i s/Listen 80/Listen 127.0.0.1:8080/g /etc/apache2/ports.conf sudo sed -i s/VirtualHost \*:80/VirtualHost 127.0.0.1:8080/g /etc/apache2/sites-enabled/000-default.conf # 关键禁用 ServerSignature 和 ServerTokens隐藏版本信息 echo ServerSignature Off | sudo tee -a /etc/apache2/apache2.conf echo ServerTokens Prod | sudo tee -a /etc/apache2/apache2.conf # 重启 Apache 并验证监听状态 sudo systemctl restart apache2 sudo ss -tlnp | grep :8080 # 应输出类似LISTEN 0 128 127.0.0.1:8080 *:* users:((apache2,pid1234,fd6))此时用curl http://127.0.0.1:8080应返回 Apache 默认页但curl http://localhost:80必须失败——证明 Apache 已彻底“隐身”只对本地 Nginx 开放。2.3 Nginx 安装与基础防护Ubuntu 18.04 源里的 Nginx 1.14.0 足够稳定但需手动编译ngx_http_geoip2_module用于地域限流和brotli压缩优化。不过首次部署建议用官方源版本避免编译风险# 添加 Nginx 官方源比 Ubuntu 自带源更新且含 security updates curl https://nginx.org/keys/nginx_signing.key | sudo apt-key add - echo deb http://nginx.org/packages/ubuntu/ bionic nginx | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx # 禁用默认站点防止端口冲突 sudo rm /etc/nginx/sites-enabled/default sudo systemctl stop nginx # 创建最小化主配置/etc/nginx/nginx.conf替换默认内容 sudo tee /etc/nginx/nginx.conf EOF user www-data; worker_processes auto; worker_rlimit_nofile 65535; events { use epoll; worker_connections 10240; multi_accept on; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # 关键关闭 server_tokens隐藏 Nginx 版本 server_tokens off; # Gzip 压缩兼容性优于 Brotli18.04 默认无 brotli gzip on; gzip_vary on; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript; include /etc/nginx/conf.d/*.conf; } EOF实操心得worker_processes auto在 18.04 上比写死4更可靠因为auto会根据 CPU 核心数自动调整而lscpu | grep CPU\(显示的核数在虚拟机中可能不准。worker_rlimit_nofile 65535是必须项否则高并发时会出现Too many open files错误——这是新手最容易忽略的性能瓶颈。2.4 防火墙与 SELinuxUbuntu 18.04 的特殊处理Ubuntu 18.04 默认用ufw而非iptables直接管理。很多人以为ufw allow 80就完事了却忘了 Nginx 转发到 Apache 的 8080 端口也需要放行# 启用 ufw 并开放端口 sudo ufw enable sudo ufw allow OpenSSH sudo ufw allow 80 sudo ufw allow 443 # 关键放行本地回环的 8080Nginx → Apache sudo ufw allow from 127.0.0.1 to any port 8080 # 验证规则 sudo ufw status verbose # 输出中必须有 # 8080 ALLOW IN 127.0.0.1Ubuntu 18.04没有 SELinux那是 CentOS/RHEL 的东西所以无需处理setsebool。但要注意AppArmor——它默认启用且可能拦截 Nginx 访问某些路径。如果后续出现Permission denied错误运行sudo aa-status查看是否nginxprofile 处于 enforce 模式临时切换为 complain 模式调试sudo aa-complain /etc/apparmor.d/usr.sbin.nginx。3. 核心配置Nginx 作为 Web 服务器与反向代理的双模切换逻辑这才是整篇博文的“心脏”。网上 90% 的教程只告诉你proxy_pass http://127.0.0.1:8080;却从不解释为什么有的请求走 Nginx有的走 Apache边界在哪里如何让它们无缝交接我们用一个真实 WordPress 站点为例拆解每一个location块背后的决策逻辑。3.1 静态资源Nginx 的主场Apache 的禁区WordPress 的/wp-content/目录下全是图片、主题 CSS、插件 JS这些文件 Apache 解析毫无意义只会徒增进程开销。Nginx 必须“截胡”# 创建 Nginx 站点配置文件 sudo tee /etc/nginx/conf.d/wordpress.conf EOF upstream backend_apache { server 127.0.0.1:8080; } server { listen 80; server_name example.com; # 根目录指向 WordPress 安装路径假设在 /var/www/wordpress root /var/www/wordpress; index index.php; # 【关键】静态资源全部由 Nginx 直接服务 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|eot|svg|pdf)$ { expires 1y; add_header Cache-Control public, immutable; # 强制使用 gzip 压缩即使浏览器支持 br18.04 默认无 brotli gzip on; } # 【关键】PHP 文件不在此处处理全部交给 Apache location ~ \.php$ { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://backend_apache; proxy_redirect off; # 关键超时设置避免 Apache 慢查询拖垮 Nginx proxy_connect_timeout 30s; proxy_send_timeout 120s; proxy_read_timeout 120s; } # 【关键】WordPress 的伪静态规则/post-name/ 形式 location / { try_files $uri $uri/ /index.php?$args; } # 【关键】保护敏感目录wp-config.php, .htaccess 等 location ~ /\. { deny all; } } EOF这段配置的精妙之处在于location的优先级顺序。Nginx 的匹配规则是精确匹配最高优先级^~前缀匹配次高且匹配后不再检查正则~*不区分大小写的正则匹配我们这里用的/通用匹配最低所以当请求/wp-content/themes/twentytwenty/style.css时先匹配location ~* \.(css|js|...)$→ Nginx 直接读取文件并返回Apache 根本不知道有这个请求当请求/wp-admin/admin-ajax.php时不匹配静态规则不是 css/js匹配location ~ \.php$→ Nginx 将整个请求头、body 原样转发给127.0.0.1:8080当请求/hello-world/WordPress 友好链接时不匹配任何正则进入location /→try_files指令先尝试找物理文件/hello-world/找不到则重写为/index.php?hello-world/再触发 PHP 规则最终交给 Apache。实操心得proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for这行代码救了我两次命。第一次是客户要求记录真实用户 IP结果日志里全是127.0.0.1第二次是 WordPress 插件如 Wordfence的登录保护因拿不到真实 IP 而误封管理员。$proxy_add_x_forwarded_for会自动追加而不是覆盖避免多层代理时丢失原始 IP。3.2 动态请求Apache 的责任田Nginx 的“快递员”Apache 收到 Nginx 转发的请求后必须知道“这请求本来是发给谁的”否则 WordPress 的site_url()会生成错误链接。这就需要 Apache 的RemoteIP模块和 Nginx 的X-Forwarded-For配合# 启用 Apache 的 RemoteIP 模块Ubuntu 18.04 需手动加载 echo LoadModule remoteip_module /usr/lib/apache2/modules/mod_remoteip.so | sudo tee -a /etc/apache2/apache2.conf echo RemoteIPHeader X-Forwarded-For | sudo tee -a /etc/apache2/apache2.conf echo RemoteIPInternalProxy 127.0.0.1 | sudo tee -a /etc/apache2/apache2.conf # 重启 Apache 生效 sudo systemctl restart apache2此时PHP 脚本中$_SERVER[REMOTE_ADDR]就是真实用户 IP而非127.0.0.1。你可以用一个简单 PHP 文件验证echo ?php echo Real IP: . \$_SERVER[REMOTE_ADDR]; ? | sudo tee /var/www/wordpress/test-ip.php访问http://example.com/test-ip.php应显示你的公网 IP而非127.0.0.1。3.3 HTTPS 终止让 Nginx 承担 SSL 卸载的重担在 Ubuntu 18.04 上Nginx 处理 HTTPS 比 Apache 更轻量。我们用 Lets Encrypt 免费证书# 安装 certbot sudo apt install python3-certbot-nginx # 获取证书需域名已解析到本机 sudo certbot --nginx -d example.com -d www.example.com # Certbot 会自动修改 /etc/nginx/conf.d/wordpress.conf添加 443 server 块 # 但我们需要手动强化其安全性 sudo sed -i /ssl_protocols/a \ ssl_prefer_server_ciphers on; /etc/nginx/conf.d/wordpress.conf sudo sed -i /ssl_ciphers/a \ ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; /etc/nginx/conf.d/wordpress.conf关键参数解读ssl_prefer_server_ciphers on强制服务器选择密码套件而非客户端避免弱加密ssl_ciphers列表剔除了所有已知存在漏洞的套件如 RC4、3DES、MD5仅保留前向保密PFS强算法Certbot 自动生成的ssl_dhparam文件Diffie-Hellman 参数必须存在否则openssl s_client -connect example.com:443会报错。注意certbot renew --dry-run必须每周执行一次确保自动续期正常。我在某次生产事故中发现因磁盘满导致续期失败证书过期后所有 HTTPS 请求返回SSL_ERROR_BAD_CERT_DOMAIN而 Nginx 日志里只有SSL_do_handshake() failed排查了 3 小时才定位到证书问题。4. 故障排查从 502 Bad Gateway 到 413 Request Entity Too Large 的全链路诊断配置完成不等于万事大吉。真实世界里90% 的问题出在“看起来都对但就是不行”。下面是我整理的 Ubuntu 18.04 Nginx Apache 组合下最常遇到的 5 类故障及其可复现的排查链路。4.1 502 Bad GatewayNginx 找不到 Apache还是 Apache 拒绝连接这是新手第一道坎。现象浏览器打开http://example.com显示502 Bad GatewayNginx 错误日志/var/log/nginx/error.log里有connect() failed (111: Connection refused) while connecting to upstream。标准排查链路按顺序执行每步验证确认 Apache 是否在监听 127.0.0.1:8080sudo ss -tlnp | grep :8080 # 如果无输出说明 Apache 没启动或监听错了端口 sudo systemctl status apache2 # 查看失败原因journalctl -u apache2 --since 1 hour ago确认 Nginx 配置中的 upstream 地址是否正确# 检查 /etc/nginx/conf.d/wordpress.conf 中的 proxy_pass grep proxy_pass /etc/nginx/conf.d/wordpress.conf # 应为proxy_pass http://backend_apache; 对应 upstream 块 # 或直接写proxy_pass http://127.0.0.1:8080;测试 Nginx 是否能连通 Apache绕过 DNS 和防火墙# 用 curl 模拟 Nginx 的请求 curl -H Host: example.com http://127.0.0.1:8080/ # 如果返回 Apache 默认页说明网络通如果返回 503说明 Apache 本身有问题检查 Apache 的错误日志看是否因资源耗尽拒绝新连接sudo tail -20 /var/log/apache2/error.log # 寻找关键词server reached MaxRequestWorkers, out of memory, Cannot allocate memory # 如果有需调大 Apache 的 MaxRequestWorkers在 /etc/apache2/mods-available/mpm_prefork.conf 中终极验证用 telnet 测试 TCP 连通性telnet 127.0.0.1 8080 # 如果连接成功输入 GET / HTTP/1.0 回车两次应看到 HTML 响应头 # 如果 Connection refused一定是 Apache 没监听或端口被占实操心得有一次 502 是因为ufw规则写成了sudo ufw allow 8080允许所有 IP 访问 8080而 Apache 的ports.conf里是Listen 127.0.0.1:8080导致ufw把127.0.0.1的流量也拦了。解决方案是sudo ufw allow from 127.0.0.1 to any port 8080精确到源 IP。4.2 413 Request Entity Too Large上传文件被 Nginx 拦截热搜词里明确提到了这个错误。现象WordPress 后台上传图片超过 2MB 就报413 Request Entity Too Large但 Apache 的php.ini里upload_max_filesize 64M已设置。根因分析Nginx 在接收请求时就根据client_max_body_size限制了请求体大小根本不会把大文件转发给 Apache。这是一个典型的“网关层拦截”问题。修复步骤在 Nginx server 块中增加全局限制# 编辑 /etc/nginx/conf.d/wordpress.conf sudo nano /etc/nginx/conf.d/wordpress.conf在server {块内顶部添加client_max_body_size 64M;针对 WordPress 后台上传路径单独加大限制更安全# 在 server 块内添加 location ~ ^/(wp-admin|wp-login\.php) { client_max_body_size 64M; proxy_pass http://backend_apache; # 其他 proxy_set_header... }重启 Nginx 并验证sudo nginx -t sudo systemctl restart nginx # 测试curl -F filelarge.jpg http://example.com/wp-admin/admin-ajax.php?actionupload注意client_max_body_size必须放在http、server或location块中不能放在upstream里。且location块的优先级高于server所以针对/wp-admin/的单独设置更精准。4.3 重定向循环Redirect LoopWordPress 的 siteurl 作祟现象访问http://example.com无限重定向浏览器提示ERR_TOO_MANY_REDIRECTS。根因WordPress 的数据库里siteurl和home设置为https://example.com但 Nginx 没有正确传递X-Forwarded-Proto导致 WordPress 认为自己跑在 HTTP 下拼命重定向到 HTTPS。诊断方法# 查看 WordPress 数据库中的设置 mysql -u root -p -e use wordpress; select option_name, option_value from wp_options where option_name in (siteurl,home); # 如果返回 http://但 Nginx 配置了 HTTPS则是 Nginx 传参问题修复方案二选一方案 A推荐在 Nginx 中强制传递 HTTPS 协议# 在 server 块中HTTPS server 块内 proxy_set_header X-Forwarded-Proto https; # 在 HTTP server 块内301 重定向到 HTTPS return 301 https://$server_name$request_uri;方案 B在 WordPress 的 wp-config.php 中硬编码// 在 wp-config.php 的 /* Thats all, stop editing! */ 之前添加 if ($_SERVER[HTTP_X_FORWARDED_PROTO] https) { $_SERVER[HTTPS] on; } define(WP_HOME,https://example.com); define(WP_SITEURL,https://example.com);4.4 静态资源 404Nginx 找不到文件但 Apache 能访问现象CSS/JS 文件返回 404但直接访问http://example.com/wp-content/style.css却能下载。根因root指令路径错误。Nginx 的root是拼接在location路径后的而 Apache 的DocumentRoot是绝对路径起点。排查# 查看 Nginx 的 root 设置 grep root /etc/nginx/conf.d/wordpress.conf # 应为root /var/www/wordpress; # 而不是root /var/www/wordpress/; 末尾斜杠会导致 /wp-content/ 变成 /wp-content//style.css验证用curl -I http://example.com/wp-content/themes/twentytwenty/style.css看Content-Length是否为 0404或正常数值。4.5 Nginx 启动失败配置语法或权限问题现象sudo systemctl start nginx失败journalctl -u nginx -n 50显示failed to load configuration。高频原因与修复错误信息根本原因修复命令nginx: [emerg] unknown directive proxy_passhttp块外写了proxy_pass检查proxy_pass是否在location或server块内nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)Apache 或其他服务占用了 80 端口sudo ss -tlnp | grep :80杀掉进程或改端口nginx: [emerg] open() /var/log/nginx/access.log failed (13: Permission denied)/var/log/nginx目录属主不是www-datasudo chown -R www-data:www-data /var/log/nginx最后一个权限问题特别隐蔽。Ubuntu 18.04 的/var/log/nginx默认属主是root而 Nginx worker 进程以www-data用户运行无法写入日志。nginx -t不会报错但systemctl start会失败。5. 性能调优与安全加固让这套组合在 Ubuntu 18.04 上跑得又快又稳配置能跑通只是第一步。生产环境要求的是“扛得住、查得清、防得住”。Ubuntu 18.04 的内核参数、Nginx 的缓冲区、Apache 的进程模型每一处微调都能带来 20% 以上的性能提升。5.1 内核级优化释放 Ubuntu 18.04 的网络潜力Ubuntu 18.04 的默认内核4.15对高并发连接不够友好需手动调整# 编辑 sysctl 配置 echo net.core.somaxconn 65535 | sudo tee -a /etc/sysctl.conf echo net.ipv4.tcp_max_syn_backlog 65535 | sudo tee -a /etc/sysctl.conf echo net.ipv4.ip_local_port_range 1024 65535 | sudo tee -a /etc/sysctl.conf echo net.ipv4.tcp_fin_timeout 30 | sudo tee -a /etc/sysctl.conf echo fs.file-max 2097152 | sudo tee -a /etc/sysctl.conf # 生效配置 sudo sysctl -p # 验证 sysctl net.core.somaxconn # 应输出net.core.somaxconn 65535参数详解somaxconn内核层面的最大连接队列长度Nginx 的worker_connections不能超过此值tcp_max_syn_backlogSYN 半连接队列大小抵御 SYN Flood 攻击ip_local_port_range扩大可用端口范围避免TIME_WAIT端口耗尽tcp_fin_timeout缩短 FIN_WAIT_2 状态超时加快连接回收。5.2 Nginx 缓冲区调优告别 “upstream sent too big header”当 Apache 返回的响应头过大如设置了大量 Cookie 或自定义 HeaderNginx 默认的proxy_buffer_size4k会报错upstream sent too big header。修复# 在 /etc/nginx/conf.d/wordpress.conf 的 upstream 或 location 块中添加 proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_max_temp_file_size 0;proxy_buffer_size 128k专门存放响应头的缓冲区必须大于 Apache 的最大响应头proxy_buffers 4 256k4 个缓冲区每个 256k用于存放响应体proxy_busy_buffers_size 256k忙时最多使用的缓冲区大小proxy_max_temp_file_size 0禁用临时文件全部内存处理更快。5.3 Apache MPM Prefork 深度调优Ubuntu 18.04 的 Apache 默认用prefork适合 PHP但默认参数太保守# 编辑 /etc/apache2/mods-available/mpm_prefork.conf sudo nano /etc/apache2/mods-available/mpm_prefork.conf修改为IfModule mpm_prefork_module StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxRequestWorkers 150 MaxConnectionsPerChild 1000 /IfModule计算依据以 4C8G 服务器为例MaxRequestWorkers 150每个 Apache 进程约占用 30MB 内存150 * 30MB 4.5GB留出 3.5GB 给系统和 NginxMaxConnectionsPerChild 1000进程处理 1000 个请求后自动退出防止内存泄漏累积StartServers/MinSpareServers设为 5避免冷启动时请求排队。实操心得MaxRequestWorkers是最关键的参数。设太高内存爆满设太低请求排队。我用ab -n 1000 -c 200 http://example.com/压测观察free -h和top找到