Nginx和Apache该选哪个

装完系统准备把站点往香港机器上搬的时候，不少人会在同一个地方卡住：到底装 Nginx 还是 Apache。论坛里一边说 Nginx 抗并发，一边说 Apache 兼容省心，两句听着都像真的，真要下单配置又怕选错回头重做一遍。这篇不谈什么绝对答案，只把两种服务器软件在真实使用里的差别、各自适合的站点类型，以及怎么在自己手上的机器里验证选型，一条条摆清楚。后面会拿云途的两档香港独服当参照对象。

Nginx 和 Apache 的架构差在哪

Apache 最常见的跑法是每个连接对应一个进程或线程。prefork 模型下一个连接占用一个进程，几百个并发就是几百个进程，进程之间切换的代价、每个进程自己占的内存，都会随连接数线性往上涨。Nginx 的模型完全不同，一个 worker 进程用 epoll 同时守着几千个连接，空闲连接几乎不占额外资源。这个差别在低并发时没什么感觉，一旦几百个连接同时压上来，两条曲线就分开了。

内存是最直观的指标。Apache prefork 每个进程要预留几十 MB 的地址空间，配上 PHP 模块之后还要更多，200 个并发轻松吃掉好几 GB 常驻内存；Nginx 的 worker 数一般与 CPU 核数对齐，单个 worker 从几百 KB 到几 MB，同样的连接量下内存曲线平缓得多，省下来的内存正好能留给数据库和 PHP-FPM。

CPU 的使用方式也不一样。Apache 可以把 PHP 直接编进进程里，省掉一次进程间通信，代价是每个进程都带着一份 PHP 解释器；也可以交给 PHP-FPM 处理，灵活但要自己调进程池数量。Nginx 自己不执行动态脚本，一律通过 fastcgi_pass 把请求甩给 PHP-FPM，它只负责连接管理和请求转发，职责切得很干净。

处理静态文件的时候差距更明显。Nginx 用 sendfile 加零拷贝，图片、CSS、JS 这类小文件基本不经过用户态拷贝，单机日跑几十万 PV 的图片站也能把 CPU 压得很低。Apache 走的流程多一些，单个请求看着差不多，量大之后磁盘读取和上下文切换的成本就会体现出来，带宽利用率也跟着打折。

配置逻辑关系到日常维护。Apache 的 .htaccess 允许在站点目录里改重写规则，改完立刻生效，方便的同时是每次请求都要重新读一遍配置；Nginx 要求集中在 conf 里改完再 reload，流程严谨，也少了那些隐形的运行时开销。团队里新手多、上线频繁的项目，这两种模式各有各的麻烦，选之前最好想清楚以后谁能维护。

以云途 HK.DS.M 那台 350 元档的机器为例，E5-2630 V2 单颗、32GB 内存、480GB SSD、1Gbps 端口、每月 10TB 流量，跑 Nginx 纯静态站撑住几千并发不费劲；同样配置换 Apache prefork，MaxRequestWorkers 就得压到很低才安全，实际能接的连接数差了一截。云途香港独服的配置和价格在这里能直接对照着看。

小内存机器上跑哪个更省资源

内存只有 32GB 的时候，选型逻辑和大机器完全不是一回事。Nginx 自身占用很小，真正吃内存的是它后面的东西：PHP-FPM 的进程池、数据库的缓冲池、系统的 page cache。把 Nginx 顶在前面做反向代理和静态分发，省下来的那部分内存正好留给 PHP-FPM 和 MySQL 用，整机不会因为 Web 服务抢内存而频繁触发 OOM，半夜被监控叫醒的概率也低很多。

Apache prefork 在小机器上的矛盾更尖锐。按每个进程 40MB 估，MaxRequestWorkers 设 150 就要 6GB，还没算 PHP 模块自己的开销；设成 60 又会在流量高峰排队，前端看到的是 502 和 504 交替出现，很容易被误判成程序 bug，其实是进程数量不够、请求在监听队列里等到超时。

一个比较实用的折中是让 Apache 跑 worker 或 event 模式，动态请求交给 FastCGI 处理，同时把 KeepAlive 关掉或缩短，把连接占用的内存还给业务。云途 DS.ES.C 那档 700 元的机型给到 64GB 内存、800GB SSD、2Gbps 端口和每月 40TB 流量，空间宽裕一些，Apache 和 PHP-FPM 一起跑也不至于互相挤，同档位机型的横向对比可以一并参考。

动态站点该怎么组合

站点有登录、有后台、有内容管理，就属于动态站。这类站的瓶颈通常不在 Web 服务本身，而在脚本执行和数据库查询。Nginx 加 PHP-FPM 是现在最常见的组合，Nginx 负责收连接、分发静态文件、转发 php 请求，PHP-FPM 用独立的进程池执行脚本，两边可以分开调优、分开重启，出问题也好定位。

PHP-FPM 的进程池参数要按内存倒推。pm 用 dynamic 时，pm.max_children 按「可用内存除以单进程峰值」估算，32GB 的机器给 30 到 40 个够用，64GB 的机器可以到 60 以上；pm.max_requests 设成 500 到 1000，让进程定期回收，避免长时间运行累积内存碎片，跑一周之后内存曲线还在原地踏步。

opcache 一定要开。脚本每次请求都重新编译很浪费，opcache 打开之后把编译结果放在共享内存里，WordPress 这类框架的响应时间能降一截；opcache.memory_consumption 给 128MB 到 256MB，命中率低于 95% 就说明给少了，往上加一档再观察。

Apache 加 mod_php 的组合在兼容性上有优势。老项目依赖 .htaccess 里的重写规则、依赖 $_SERVER 里某些特定字段、依赖目录级的访问控制，换到 Nginx 要一条条改写，工作量不小。项目本身能跑、流量也不高的情况下，继续用 Apache 是省事的选择，硬换一套反而容易把稳了几个月的东西推翻。

换到 Nginx 之后，伪静态规则要自己写。WordPress 的 try_files 一行能解决，ThinkPHP、Discuz 这些框架的规则要按官方给的写法搬，路径匹配顺序错了会出现后台 404 或者文章页跳首页的问题，改完记得用几条真实 URL 逐个点一遍。

上传大小和超时也要跟着改。Nginx 默认 client_max_body_size 只有 1MB，后台上传大图会直接返回 413；fastcgi_read_timeout 默认 60 秒，导出报表或者跑批量任务很容易被掐断。这两个值按业务实际需求放宽，别照抄网上的模板，模板给的值往往比你的业务小。

日志格式建议在迁移时就统一。Nginx 的 request_time 和 upstream_response_time 能区分「客户端等了多久」和「后端处理了多久」，排障时非常有用；Apache 的 D 字段是微秒口径，两边对不上会给后面的日志分析添麻烦，迁移前先把字段映射表定好，再动手换服务。

两套组合在中等配置上都能跑得不错，关键看团队熟悉哪一套。云途 HK.DS.M 那台 350 元档的 32GB 机器做个人站和小型业务已经足够，预算宽一些的话 云途香港独服里 64GB 起步的机型更适合多站点并行，跑动态站也留得出余量。

反向代理和缓存怎么摆

缓存放在哪一层决定了它能省多少事。放在 Nginx 的 proxy_cache 或者 fastcgi_cache 里，命中时整条请求链路都跳过，连 PHP 都不用启动；放在应用层做页面缓存，灵活但每次还要跑一遍框架引导。流量上来之后，越靠前的缓存收益越大，前端一台机器挡掉的请求，后端就少一批无谓的数据库查询。

缓存键的设计比缓存大小更重要。键里带上 host、uri，再把查询参数排序后拼进去，可以避免不同站点的同名页面互相污染；带用户标识的页面不能进公共缓存，否则会出现一个人看到另一个人的购物车，这种事故补救起来很麻烦。

过期时间按内容类型分开设。文章页、商品详情这类更新不频繁的给长一点，半小时到几小时都行；列表页、搜索结果给短一点，几分钟就够。登录态页面和后台路径一律不缓存，用 cookie 判断或者路径前缀排除，规则写清楚之后就不会再纠结。

压缩和 HTTP/2 顺带打开。文本类资源开 gzip，图片和视频不要压，压了白费 CPU；HTTP/2 开启之后浏览器会复用一条连接并发取资源，首屏感知速度的提升比调参数更明显。压测前后各看一次命中率，能到八成以上就算配置到位。命中率卡在五成左右的时候，大多是缓存键带进了时间戳或者随机参数，把缓存拆得七零八落，这种问题调多大数据都救不回来。

换之前先把压测数据跑出来

换服务器软件之前，最好先给现有站点量个体温。记录并发 100 时的响应时间、每秒请求数、CPU 占用和内存余量，这几个数就是你的基线，换完拿同样的条件再跑一次，涨了还是跌了一目了然。没有这组数据，凭感觉判断「好像快了一点」很容易出错。

压测工具不用太复杂。wrk 或者 ab 都够用，命令行带几个参数就能打出持续压力，重点是请求要打到真实页面而不是首页，首页往往被缓存过，测出来的数字好看但没有参考价值。

并发档位按梯度往上推。50、100、200、400 各跑一轮，每轮至少持续一分钟，看响应时间的拐点出现在哪一档。拐点之前的并发就是这套配置的安全区间，拐点之后延迟会成倍上涨，说明瓶颈已经出现。

压的时候盯着三样东西：CPU 的使用率分布、内存余额、连接数。CPU 单核打满而其他核闲着，多半是锁或者单进程瓶颈；内存持续下降到触发 swap，说明并发给多了；连接数接近上限而请求被拒，那就是 Web 服务的连接配置该调了。

错误率要单独统计。压测跑到一半出现 5xx，往往不是程序崩了而是 accept 队列溢出、upstream 超时或者临时端口耗尽，这几种情况的应对方式完全不同，得先把错误码分类再对症处理。

开缓存和关缓存各跑一遍。缓存全关时测出来的是系统的真实处理能力，全开时测的是缓存架构的效果，两组数据都留着，上线之后遇到命中率下跌就知道性能会掉到哪个水平。

结论记成一张表，别只留在脑子里。机型、配置、并发、响应时间、错误率、当时的工作负载，几行数据写下来，下次换机器或者扩配置时直接拿来对照，比翻聊天记录靠谱得多。云途香港独服这类固定配置的机器，压测结论还能反过来帮你判断下一档要不要升级。

迁移路上的几个坑

重写规则是第一道坎。Apache 的 RewriteCond 组合条件搬到 Nginx 要拆成 if 或者 map，语义顺序也容易搞混，搬完先用爬虫把站点的旧链接扫一遍，301 跳对了再考虑上线。带参数的 URL 尤其容易漏，翻页、筛选、搜索这几类路径规则最好单独列出来测。

监控会断档一段时间。换服务之后日志路径、字段格式、状态页都变了，原来的采集配置直接失效，监控空白期里出故障只能靠用户反馈，所以迁移当天最好安排在自己能盯着的时间段。

长连接的处理方式不同。Nginx 给 upstream 的连接池要显式配置 keepalive，不配的话每个请求都新建 TCP 连接，后端压力会比迁移前更大，表现出来的现象是后端 CPU 上升但 QPS 没变，看连接状态里一大批 TIME_WAIT 就知道问题在哪。

重定向链别越堆越长。域名、http/https、带不带 www，这几件事要在一次跳转里收敛，跳两三次之后搜索引擎的抓取效率会下降，用户也会看到地址栏一闪一闪地变。

切换最好留一条退路。先停掉旧服务的写入，让它保持只读跑上一两天，出问题随时切回去；确认新服务稳定之后再彻底下线，比一次性硬切的代价小得多。旧机器空转那两天也别拆配置，DNS 缓存还没刷完的时候，仍旧会有用户落到旧地址上。