先别急。VPS建站后变慢，按带宽延迟基线、系统负载、Web服务器配置、是否上CDN这四层顺序查，问题常常落在第二层和第三层，重装一遍再装一遍，该慢还是慢。Cloudflare官方文档里写，缓存做的事是把常访问内容的副本放到离用户更近的节点上，源站压力小了，网站打开才快。这句话反过来读也成立：源站自己慢，缓存救不回来。
做英文站，时间花在写内容上比花在修服务器上划算。VPS只是一个底座，底座不稳，上面放什么都晃。下面几条是先记下来的东西。
- 先测带宽延迟基线，再谈优化
- 系统负载看CPU、内存、磁盘三项曲线
- Web服务器配置改动必须reload才生效
- CDN缓存所有套餐可用
- 迁移Cache Rules有行为变化，别照搬Page Rules
这篇讲透「已建站后变慢」的四层排查顺序和每层的优化动作，不绕到买机器和装系统上。还没选机器的，先看VPS那篇把基础概念弄清楚。
本文目录
为什么VPS建站后会变慢：先分清是带宽、负载还是配置
VPS上跑一个站，速度慢的来源有四类。带宽与线路，套餐标称的带宽跑不满，或者延迟比同区域机房高，问题在服务商那边，配置改不动。系统负载，CPU、内存、磁盘某一项吃满，网站响应就慢。Web服务器配置，nginx或Apache本身的写法、缓存没开、reload没做，都会让应该快的变慢。源站到用户的距离，用户在美国、服务器在香港，每次请求都要跨半个地球，这是物理距离，只能靠CDN把副本放近。
这四类里，前两类和第四类靠换方案解决，第三类靠改配置解决。分不清是哪一类，换机器和改配置都是碰运气。先搞清楚高速主机和普通主机区别在哪，再判断手上的机器是不是买错了。
速度慢的四个来源：带宽与线路、系统负载、Web服务器配置、源站到用户的距离
带宽与线路的问题，表现为下载速度上不去、ping延迟高、路由绕路。系统负载的问题，表现为网站时快时慢，后台操作卡顿。Web服务器配置的问题，表现为某些页面特别慢，或者改了配置没反应。源站到用户的距离，表现为某个地区的用户打开慢，换个地区就正常。
四条里，第三条是你能在服务器上直接动手的。前两条要找服务商，第四条要加CDN。排查顺序从第一条往下走，是因为下面几层的判断都依赖第一条的基线数据。基线没测，后面看到的所有数字都没有参照。
为什么不能一上来就上CDN：源站本身慢，CDN只是把慢的副本放得更近
CDN做的事，是把源站的内容副本放到离用户近的节点上。用户请求先到节点，节点有副本就直接返回，没有才回源站取。源站本身响应要三秒，节点回源也要三秒，缓存没命中的那次请求，用户还是等三秒。
缓存命中率高的站，上CDN效果明显。动态页面多、登录状态多、缓存规则没配好的站，命中率低，CDN带来的提升有限。所以顺序是先把源站调到正常水平，再考虑CDN，反过来做，等于把慢的内容复制到更多地方。
第一层：先测带宽延迟基线，判断是不是线路问题
第一层要测的是基线。同样的测试，在刚装完系统、装完站、跑了一段时间之后各做一次，记下来做对比。只测一次的数字没有意义，因为你不知道它算快还是算慢。
测的项目有四样：下载速度、ping延迟、路由跳数、服务商面板里的带宽图。下载速度用一个固定大小的文件测，从本地和外部节点各测一次。ping延迟同样从本地和外部节点各测。路由跳数看请求走哪条线，绕不绕路。带宽图看过去一段时间的出入流量，是平稳还是有尖峰。
怎么测：从本地和外部节点分别测下载速度、ping延迟、路由跳数
先用服务商面板里的带宽图和ping工具做粗测，再用外部测速节点复核。面板里的数据是服务商自己统计的，外部节点代表你实际访问的路径，两边对得上，数据才可信。
测的时候注意时间点。晚上八点到十一点是流量高峰，同一台机器在凌晨测和晚上测，结果可能差一截。基线要覆盖高峰和低谷两个时段，不然拿凌晨的数据当标准，晚上一慢就以为出了大问题。
测速时顺带把磁盘IO、带宽、延迟这几项记下来，服务器评测看哪些指标讲的就是这些项。看不懂面板里的曲线，先搞清楚这些指标分别代表什么，再动手测。测出来的数不知道怎么读，等于没测。
怎么判断：带宽跑不满套餐标称、延迟明显高于同区域机房，先怀疑线路和超售
两条判断标准。一条是带宽跑不满套餐标称。买的是高带宽套餐，下载速度长期只有标称的一小半，问题不在你的站，在线路或者服务商。另一条是延迟明显高于同区域机房。同样在美国的机器，延迟差出一大截，先查线路。
这两条出现任何一条，先别改配置。配置改得再好，带宽和延迟是物理层的事，改不动。这时候要做的是拿数据找服务商，或者换一家。
出问题怎么回查：对照服务商面板的带宽曲线，看是持续打满还是尖峰
带宽图上看两种形态。持续打满，说明带宽不够，要么升级套餐，要么把大流量的东西挪走。尖峰，说明某个时间点来了一波流量，比如搜索引擎抓取、某个页面被分享出去，流量过去就恢复，这种情况不用急。
分不清持续和尖峰，把时间轴拉长看一周。一周里每天同一时段都打满，是持续。只有某一天某一个小时高，是尖峰。两种情况的处理方式不一样，别用同一种办法。
第二层：排查系统负载，看CPU、内存、磁盘谁在拖后腿
第一层排除了线路问题，第二层看服务器自己的负载。负载看三项：CPU、内存、磁盘IO。三项里哪一项先到顶，就先处理哪一项。三项一起看容易分不清主次。
怎么开监控，看服务商给什么。DigitalOcean的Monitoring是免费、需要主动开启的服务，装metrics agent之后能看使用图表、告警和自定义指标。官方把这个服务写成「free, opt-in service」，免费，但要自己开。不装agent，面板里没有数据，你看到的空白不代表机器没问题。
怎么开监控：DigitalOcean的Monitoring免费、需主动开启
装metrics agent的文档在DigitalOcean的Monitoring页面里，标题是How to Install the DigitalOcean Metrics Agent。装完之后等一段时间，图表里才有数据。刚装完就去看，曲线是空的，别急着判断agent坏了。
别的服务商给的监控入口不一样，有的在面板里直接有图表，有的要自己装agent。不管用哪家，先确认监控是开着的，再看数据。没开监控就排查负载，跟闭着眼睛开车差不多。
三项怎么看：CPU长期高位是计算瓶颈，内存吃满会触发swap，磁盘IO等待高说明磁盘是瓶颈
CPU长期高位，说明计算是瓶颈。PHP执行、数据库查询、图片处理都吃CPU，哪一块占得多，要登服务器用top看进程。内存吃满，系统会开始用swap，把内存里的数据写到磁盘上，磁盘速度比内存慢一个量级，网站就卡了。磁盘IO等待高，说明读写磁盘的时间长，数据库和日志写入都可能拖慢它。
| 指标 | 高了说明什么 | 先看哪里 |
|---|---|---|
| CPU使用率 | 计算瓶颈 | 监控曲线，再top复核 |
| 内存使用率 | 可能触发swap，拖慢磁盘 | 监控曲线，再free复核 |
| 磁盘IO等待 | 磁盘是瓶颈 | 监控曲线，再iostat复核 |
| 带宽 | 持续打满才是带宽不够，尖峰是流量突增 | 服务商面板带宽曲线 |
三项里哪一项先到顶，就先处理哪一项。四项一起看，容易把主次搞混。
出问题怎么回查：监控曲线和服务器命令对不上，先确认agent是否在跑
监控曲线显示CPU不高，登服务器用top看却一直满，两边对不上，先确认agent是否在跑。agent停了，图表里的数据就停在某个时间点，看起来正常，其实是旧数据。再看数据有没有延迟，有的服务商几分钟才更新一次图表。
两边对上之后，如果三项都正常，网站还是慢，回头查第一层的带宽。同一台物理机上塞的VPS越多，分到每台的IO和带宽越少，这就是超售。超售在监控里看不出来，只能拿实际速度和套餐标称对比，超售这块怎么判断，选机器之前先弄清楚。
第三层：Web服务器配置，nginx和Apache各查什么
前两层没问题，第三层看Web服务器。nginx和Apache是两种常见的Web服务器，查的地方不一样。nginx官方把自己定义成HTTP Web服务器、反向代理、内容缓存、负载均衡、TCP/UDP代理和邮件代理服务器，特点是低资源占用下的高性能。Apache官方把自己定义成快速、可靠、可扩展的开源Web服务器，性能项下列了内容缓存、反向代理、多处理模块和HTTP/2。两种都能用，查法不一样。
nginx查三处：server_name、worker进程数、reload
先说最要命的一处，server_name尽量用精确名称。nginx官方文档里写，正则表达式按顺序逐个测试，是最慢且不可扩展的方式，建议尽量用精确名称。通配符名称的哈希表按域名部分搜索，比精确名称的哈希表慢。一个站上挂了多个域名，server_name写成一堆正则，每来一个请求都要按顺序试一遍，请求量大的时候就是负担。
还有个事，nginx有一个master进程和若干worker进程，master读配置、维护worker，worker实际处理请求。worker进程数量在配置文件里定义，可以固定，也可以自动按可用CPU核数调整。核数少、进程数开太多，进程之间抢CPU，反而慢。
最后是reload。配置改完必须reload才生效，配置文件里的改动，在发送reload命令或重启之前不会生效。reload的命令是nginx -s reload。配置文件默认叫nginx.conf，放在/usr/local/nginx/conf、/etc/nginx或/usr/local/etc/nginx这三个目录之一，具体在哪，看安装方式。
reload失败怎么判断：主进程先检查语法，失败会回滚
reload不是执行了就一定成功。nginx的主进程收到reload信号后，先检查新配置的语法。语法通过，启动新的worker进程，通知旧的worker关闭。语法不通过，主进程回滚这次改动，继续用旧配置。表现出来的样子就是：你改了，也执行了reload，网站还是老样子。
判断方法，执行reload之后去看error.log。日志在/usr/local/nginx/logs或/var/log/nginx目录下，具体在哪看安装方式。日志里有语法报错，说明这次改动没生效，按报错改完再reload一次。日志里没有报错，再确认改动是不是改在了正确的配置文件里。
Apache查两处：版本和性能项
一处是版本。Apache 2.2已经停止支持，最终版本是2.2.34，2017年7月发布，之后不再提供补丁、修复或安全更新。官方建议升级到2.4.x。当前版本是2.4.71，2026年11月11日发布。还在跑2.2的机器，先升级，再谈优化。
另一处是性能项开了没有。Apache官方把内容缓存、反向代理、多处理模块和HTTP/2列在性能项下。内容缓存没开，每个请求都重新生成页面。HTTP/2没开，浏览器和服务器之间的连接效率低一截。这两项在配置文件里开，改完重启服务。
出问题怎么回查：先看access.log和error.log，再确认reload成功
nginx出问题，官方建议去access.log和error.log里找原因。access.log看请求有没有到服务器，error.log看服务器报了什么错。Apache同样有错误日志，位置看配置文件里的ErrorLog指令。先看日志，再去猜配置，顺序别反。
日志里没有异常，再确认改动有没有真的生效。nginx看reload的执行结果，Apache看服务有没有重启成功。配置改对了但没生效，跟没改一样。
第四层：要不要上CDN，缓存规则怎么配才不踩坑
前三层查完，源站调到正常水平，第四层才考虑CDN。什么时候该上，看三个条件：源站已经调好、用户分散在多地、静态资源占比高。三个条件缺一个，CDN的效果就打折扣。源站没调好，上CDN是把慢的副本放得更近。用户集中在一个地区，CDN的节点优势用不上。静态资源占比低，缓存命中率上不去。
什么时候该上：源站调好、用户分散、静态资源占比高
静态资源指的是图片、CSS、JS这类不改动就长期不变的文件。这类文件最适合缓存，缓存命中率也最高。HTML页面更新频率高，缓存时间要短，或者干脆不缓存。用户分散在多个国家，CDN的节点分布才有意义。
源站调好是前提。第一层到第三层都查过，源站响应正常，再上CDN。源站本身响应要好几秒，CDN缓存没命中的请求照样慢，用户感受到的是时快时慢，还不如不上。
怎么配：用Cache Rules指定缓存什么、缓存多久
Cloudflare的Cache Rules用来指定哪些资源应该被缓存、缓存多久。进Cloudflare后台，找到Cache Rules页面，点Create rule，填规则名，设匹配条件，选缓存资格，保存。哪些资源该缓存，看文件类型和路径。图片、CSS、JS这类静态文件可以缓存久一点，HTML页面看更新频率决定。
开Tiered Cache减少回源。Tiered Cache把常访问内容缓存在多个位置，加快交付，减少回源流量。回源少了，源站的压力小，用户拿到的响应也快。改完规则用Purge清缓存。Purge能立即清除缓存文件，强制Cloudflare从Web服务器取新版本，可以清指定文件，也可以全清。改了规则不清缓存，用户可能还在拿旧副本。
Cloudflare的Cache功能在所有套餐可用，免费套餐也能用。Speed功能同样在所有套餐可用，用来评估网站性能、给产品建议。这几个工具配合起来，能看出CDN到底帮上了多少。
迁移的坑：从Page Rules迁到Cache Rules，行为不一样
从Page Rules迁到Cache Rules，有一个行为变化。新建Cache Rule时选Eligible for cache，Cache Everything会默认开启。用Page Rules的时候，Cache Everything要专门开启。同样是「允许缓存」，两种规则的实际行为不一样。
要维持Page Rules原来的行为，也就是不开启Cache Everything，得按顺序先建两条规则。第一条，规则名比如bypass everything，匹配条件选All incoming requests，Cache eligibility选Bypass cache。第二条，规则名比如cache all default cacheable extensions，匹配条件用File extension is in一长串默认可缓存扩展名，Cache eligibility选Eligible for cache。顺序不能反，先建bypass，再建cache。
多条匹配的Cache Rule会组合作用于同一个请求。规则1匹配之后，Cloudflare会继续评估其他Cache Rule。所以规则顺序和匹配条件都要看清楚，后面的规则可能覆盖前面的效果。
出问题怎么回查：缓存没生效先看规则匹配条件，再看规则顺序
缓存没生效，先看规则的匹配条件对不对。条件写窄了，该缓存的没缓存。条件写宽了，不该缓存的缓存了。再看是不是被后面的规则覆盖。多条规则同时匹配，组合作用的结果可能跟你想要的不一样。
四层都查完还是慢：换线路还是换机器
四层走完，问题定位到了带宽或者线路，接下来是换方案。带宽不够，换大带宽的方案。线路绕路，换优化过线路的机房。这两种换法解决的是不同的问题，别搞混。带宽不够的表现是下载速度上不去、带宽图持续打满。线路绕路的表现是延迟高、路由跳数多。前者加带宽，后者换线路。
换机器之前先确认不是配置问题。第三层查完，nginx和Apache的配置都正常，reload也成功了，负载三项也不高，还是慢，再考虑换。配置有问题没解决，换了机器还是一样。换机器解决的是机器本身的问题，解决不了配置写错的问题。
带宽不够、需要更大流量方案的，大带宽的美国VPS讲的是这类机器的选择。换之前把四层的记录拿出来对一遍，确认问题真的在机器和线路上。
排查时容易做反的几件事：没reload、规则顺序、正则写错
排查的时候有几件事容易做反。改完配置没反应，先看reload有没有执行成功。缓存没生效，先看规则匹配条件。越优化越慢，往配置写得太复杂这个方向查。每一条都对应一个具体的检查动作，不是凭感觉猜。
改了配置没反应：先看reload，再看语法
nginx的配置不reload就不生效，这是第一顺位。执行了reload还没反应，看error.log里有没有语法报错。主进程检查语法不通过会回滚，继续用旧配置，表现就是改了跟没改一样。Apache改完配置要重启服务，没重启同样不生效。
缓存不生效：规则顺序和匹配条件写错
Cache Rules的匹配条件写错，规则匹配不到请求，缓存自然不生效。规则顺序写反，多条规则组合作用的结果可能跟想要的不一样，也会让缓存看起来没起作用。多条规则同时匹配时，组合作用的结果要对着规则列表一条一条看。
越优化越慢：正则server_name用太多、语法写错
nginx的server_name用一堆正则，官方说这是最慢且不可扩展的方式。正则写得不对，还会让nginx启动失败。正则里含{和}必须加引号，否则nginx启动时报错，提示server_name没有被分号结束。通配符只能在名称开头或结尾用星号，而且只能在点边界上，www.*.example.org和w*.example.org都是无效名称。正则必须以波浪号开头，域名里的点要用反斜杠转义，建议加^和$锚点。
缓存把动态页面也缓存了，用户看到的是旧内容，看起来像网站出了故障，实际是缓存规则写宽了。
回查顺序：先基线、再负载、再配置、最后CDN
四层顺序不要跳。第一层测基线，第二层看负载，第三层查配置，第四层配CDN。跳层查容易把原因搞混。源站CPU满了，先去配CDN，配完发现还是慢，回头再查CPU，中间浪费的时间比按顺序查多得多。
每一层查完留个记录。测了什么、结果是什么、改了什么、改完什么变化。下一次再出问题，翻记录就知道从哪一层开始，不用从头再来。
AI能帮你做哪几步排查，哪些必须自己上手
AI在排查里能帮的是整理和对照，不是替你在服务器上执行命令。下面四步是它能接的活。
- 把Cloudflare Cache Rules的迁移顺序整理成一张对照清单。先建bypass everything，再建cache all default cacheable extensions，每条规则的规则名、匹配条件、Cache eligibility选项列清楚，供你在后台逐条勾。
- 把nginx的server_name写法按官方优先级整理成自查表。精确名称、星号开头通配符、星号结尾通配符、正则表达式四种写法列出来，标出哪种最慢、哪种不可扩展。
- 把nginx的reload流程和失败回滚逻辑写成一段排查话术。对着error.log判断是语法问题还是没reload，话术里把判断顺序写清楚。
- 把DigitalOcean Monitoring的指标项整理成一张观察顺序表。使用图表、告警、自定义指标分别看什么，先看哪一项，列成顺序。
下面三条提示词是本文给的示例，可以直接复制去用。
「按Cloudflare官方文档，把从Page Rules迁移到Cache Rules需要先建的两条规则，按顺序列成清单，每条写清规则名、匹配条件、Cache eligibility选项，不要补充文档外的内容。」
「按nginx官方server_names文档，把精确名称、星号开头通配符、星号结尾通配符、正则表达式四种写法的匹配优先级列成表，并标出哪种最慢、哪种不可扩展。」
「按nginx官方beginners_guide，把nginx -s reload的执行流程写成5步以内的顺序说明，包含语法检查失败时的回滚行为，不要加文档里没有的命令。」
AI整理完，有三件事必须你自己上手。一是在Cloudflare后台点Create rule，按官方给的字段逐项填，填完点Save或Deploy。二是在服务器上执行nginx -s reload，打开error.log看有没有语法报错，据此决定保留还是回滚这次改动。三是在DigitalOcean后台开启Monitoring并装metrics agent，看CPU、内存、磁盘三项的实际曲线，据此决定是否继续往Web服务器配置层排查。
这几步整理资料、对照官方文档的活，猎者出海的AI Agent能接一部分，省的是翻文档和列清单的时间，服务器上的操作还得自己做。
常见问题
VPS速度慢一定要换机器吗？
不一定。按四层顺序查完，配置问题没解决，换了机器还是一样。
上CDN能提升多少速度？
提升多少取决于缓存命中率和源站本身的响应速度，没有一刀切的数。源站响应慢，缓存命中率低，提升就有限。
nginx改了配置为什么没生效？
两种可能。没执行nginx -s reload，或者reload时语法检查失败，主进程回滚到旧配置。去error.log看有没有报错，报错信息会指出哪一行有问题。
Cloudflare缓存要花钱吗？
Cache在所有套餐可用。要不要升级套餐，看的是缓存之外的功能。
Apache 2.2还能继续用吗？
不建议。官方已经把2.2标为停止支持，之后不再有补丁、修复和安全更新，官方建议升级到2.4.x。
VPS慢这件事，最怕的是没测基线就直接换机器，换完发现还是慢。四层顺序走一遍，每一层留个记录，下一次再出问题就知道从哪一层开始查。
发表评论